ARP-spoofing & MAC-flooding
C0RS|E7Всем привет! На связи C0RS, и сегодня мы поговорим о таких сетевых атаках, как ARP-spoofing и MAC-flooding.
ARP-spoofing - разновидность MITM-атаки, использующая слабые места протокола ARP (Address Resolution Protocol). Давайте разберемся, что такое ARP и для чего он нужен.
ARP предназначен для определения MAC-адреса по IP-адресу другого компьютера. Протокол позволяет запрашивать, какому конкретно устройству в сети (MAC-адрес) назначен конкретный IP-адрес в данный момент. Также устройства могут самостоятельно сообщать об этом назначении остальной части сети, без запроса. В целях эффективности устройства обычно кэшируют эти ответы и создают список текущих назначений MAC-IP.
Протокол ARP создан в 1982 году и является уязвимым, так как не проверяет подлинность ARP-запросов и ответов. Так как ARP-ответы могут приниматься без запроса этого ответа, возможна атака ARP-spoofing. Любое устройство в нашем сегменте сети может ответить на запрос ARP, кому предназначался этот запрос. Например, если компьютер A запрашивает MAC-адрес компьютера B, ответить может злоумышленник на компьютере C, и компьютер A примет этот ответ как достоверный. За счет этой уязвимости было проведено огромное количество атак. Используя легкодоступные инструменты, можно «отравить» кэш ARP других хостов в локальной сети, заполнив его неверными данными.
Давайте же рассмотрим атаку на конкретном примере.
Начинаем атаку
Допустим, что при проведении пентеста мы получили доступ к сети и повысили привилегии до root на Linux-машине. Во время обычного перечисления ОС мы поняли, что это хост подключен к двум (или более) сетям. Мы решили исследовать эту сеть, чтобы узнать, можем ли мы двигаться вбок.
Исследуем сеть
Как мы выяснили, хост подключен к одной или нескольким дополнительным сетям. В настоящее время мы подключены к машине через SSH через Ethernet-адаптер eth0. Интересующая нас сеть подключена к Ethernet-адаптеру eth1. Давайте взглянем на адаптер:
ip address show eth1
Запустим ARP-сканирование сети с помощью nmap:
sudo nmap -PR -sn 192.168.12.66/24
Как видим, помимо нас (192.168.12.66) в сети присутствует ещё 2 хоста. Приступаем :)
Пассивный сниффинг сети
Простое сканирование этих узлов не поможет нам собрать полезную информацию, поэтому попробуем перехватить трафик этой сети.
Диаграмма ниже описывает нашу текущую ситуацию, в которой мы являемся атакующим и имеем постоянный доступ к машине eve.
Попробуем запустить tcpdump на сетевом интерфейсе eth1:
tcpdump -i eth1
Видим, что компьютеры eve и bob обмениваются ICMP-пакетами.
Теперь давайте изучим захваченные пакеты! Мы можем перенаправить их в файл pcap, указав файл назначения с помощью аргумента -w:
tcpdump -A -i eth1 -w /tmp/tcpdump.pcap
Захватим трафик около минуты, затем перенесем pcap-файл на свой компьютер, чтобы открыть его в Wireshark.
К сожалению, нам пока не удалось зафиксировать какой-либо интересный трафик. Однако мы не собираемся так просто сдаваться. Мы можем попытаться запустить атаку MAC flooding на L2-коммутатор.
Сниффинг во время MAC Flooding
Осторожно: MAC flooding может вызвать тревогу в SOC. Нет, серьезно, подозрительный трафик L2 может быть легко обнаружен и зарегистрирован современными и правильно настроенными сетевыми устройствами. Хуже того, ваш сетевой порт может быть даже заблокирован сетевым устройством, в результате чего ваша машина окажется заблокированной в сети. В случае, если через это сетевое соединение работают производственные службы или направляется производственный трафик, это может даже привести к эффективному отказу в обслуживании.
Однако, если нам это удастся, коммутатор перейдет в режим fail-open и временно будет работать аналогично сетевому хабу, пересылая все полученные кадры на все подключенные порты (кроме порта, с которого был отправлен трафик). Это позволит пентестеру прослушивать сетевой трафик между другими узлами, который при нормальной работе коммутатора не был бы получен.
Рассматривать такой вектор атаки рекомендуется в том случае, если у вас есть основания полагать, что это действительно коммутируемая сеть, а не виртуальный мост, и коммутатор может быть пользовательским (неуправляемым) коммутатором или администраторы сети не настроили средства защиты, такие как, например, динамическая проверка ARP (DAI).
Предположим, что у нас есть все основания и приступим к делу. Запустим ettercap с плагином random_flood для флуда нашего свитча случайными MAC-адресами :
ettercap -T -i eth1 -P rand_flood -q -w /tmp/tcpdump2.pcap
Через 30 секунд захвата трафика оставим оба приложения и также отправим файл в Wireshark. Отсортируем трафик и видим, что картина несколько изменилась. Куча случайных запросов по IPv4, но среди них так же присутствуют запросы по протоколу ICMP хостов, которые по идее не должны "общаться" между собой, следовательно мы смогли изменить поведение свитча.
Как вы могли заметить, MAC-flooding - довольно шумна техника. Чтобы снизить риск обнаружения и DoS, мы оставим MAC-flooding в покое и проведем атаку ARP-spoofing между компьютерами Alice и Bob, пытаясь стать полноценным человеком посередине (MITM).
ARP-spoofing
Я немного изменил конфигурацию нашей лабораторной сети, давайте же снова просканируем сеть на предмет живых хостов с помощью nmap, но теперь также посмотрим порты. Напомню, делать это мы может только находясь внутри целевой сети.
В целом всё осталось так же, только немного изменились IP-адреса наших соседей. Здесь я не включал динамическую проверку ARP, поэтому ARP-spoofing становится возможен ;) Попробуем посмотреть, что же такое висит на 80 порту, и заодно послушаем наш интерфейс, чтобы понять, есть ли по нему какой-либо трафик:
Страница нам недоступна, да и трафика по сети нет. Давайте исправим ситуацию. Запускаем ARP-spoofing и наблюдаем, как полетели пакеты с помошью tcpdump:
ettercap -T -i eth1 -M arp tcpdump -vvA -i eth1
Давайте повнимательнее рассмотрим вывод ettercap. Вдруг там пролетит что-то интересное.
И действительно, сервер нас с кем-то "перепутал" и решил прям-таки сразу выдать нам практически все свои секреты. Можно сделать вывод, что ARP-spoofing прошел успешно. При большом количестве хостов гораздо удобнее сделать вывод ettercap в файл .pcap и спокойно рассмотреть на своей машине с помощью Wireshark, но в нашем случае достаточно просто наблюдать за процессом работы ettercap. Остановим атаку, нажав q, и полюбуемся, как изящно ettercap вернет все данные ARP на свои места. Соберем нашу добычу и попробуем пройти на заветный 80-й порт машинки нашего соседа Боба, используя добытые учетные данные:
Здесь с помощью простого GET-запроса мы можем прочитать хранящиеся файлы. Мы отравили кэш ARP и смогли выдать себя за другое устройство, и тем самым смогли подсмотреть процесс авторизации на сервере, а также извлечь учетные данные. Да, они передавались в открытом виде, но во внутренних сетях мы довольно часто можем встретить авторизацию по незащищенному HTTP, так как передача данных во внешний мир по дефолту не подразумевается ;) Можно довести всё это дело до полноценной MITM атаки, но это уже немного другая история, которую я расскажу в следующий раз.
Продолжение следует.