Выявление атаки человек-посередине (Man in the middle, MitM-атак)


Атака человек-посередине — это обобщённое название для различных методик, направленных на получение доступа к трафику в качестве посредника. Из-за большого разнообразия этих методик, проблематично реализовать единый инструмент выявления этих атак, который бы работал для всех возможных ситуаций. Например, при атаке человек-посередине в локальной сети, обычно используется ARP-спуфинг (травление). И многие инструменты по «выявлению атаки человек-посередине» следят за изменением пар адресов Ethernet/IP или сообщают о подозрительной ARP-активности пассивным мониторингом ARP запросов/ответов. Но если эта атака используется на злонамеренно настроенном прокси-сервере, VPN, либо при других вариантах, когда не используется ARP-травление, то такие инструменты оказываются беспомощными.

Цель этого раздела — рассмотреть некоторые методики выявления атак человек-посередине, а также некоторые инструменты, предназначенные для определения, что в отношении вас осуществляется MitM-атака. Из-за разнообразия методик и сценариев реализации, невозможно гарантировать 100-процентное выявление.

1. Выявление модификации трафика

Как уже было сказано, при атаках человек-посередине не всегда используется ARP-спуфинг. Поэтому хотя обнаружение активности на уровне ARP является самым популярным способом выявления, более универсальным способом является обнаружение модификации трафика. В этом нам может помочь программа mitmcanary.

Принцип работы программы заключается в том, что она делает «контрольные» запросы и сохраняет полученные ответы. После этого она через определённые интервалы повторяет эти же запросы и сравнивает получаемые ответы. Программа достаточно интеллектуальна и для избежания ложных срабатываний выявляет динамические элементы в ответах и корректно их обрабатывает. Как только программа зафиксировала следы активности инструментов для MitM-атак, она сообщает об этом.

Примеры, как могут «наследить» некоторые инструменты:

  • MITMf, по умолчанию меняет все HTTPS URL в HTMLкоде на HTTP. Выявляется по сравнению содержимого HTTP.
  • Zarp + MITMProxy, MITMProxy имеет функционал, позволяющий очищать HTTP сжатие, это применяется для прозрачности передаваемого трафика, эта связка выявляется по исчезновению ранее присутствующего сжатия
  • Responder, выявляется по внезапным изменениям в преобразовании ответов mDNS: неожиданный ответ; ответ является внутренним, а ожидается внешний; ответ отличен от ожидаемого IP

Автор программы подготовил несколько видео, на которых видно, как выявляется атака человек-посередине:

Программа mitmcanary в настоящее время отсутствует в репозиториях Kali Linux и BlackArch, но имеется простая инструкция по установке. Во всех примерах я буду вести атаки из BlackArch, а выявлять атаки в Kali Linux. Поэтому начинаю с установки mitmcanary в Kali Linux (инструкция по установке и запуску mitmcanary в BlackArch также имеется в Энциклопедии инструментов для хакинга):

sudo pip install Cython
sudo apt-get install python-kivy python-dbus
sudo pip install plyer uuid urlopen analysis request simplejson datetime
git clone https://github.com/CylanceSPEAR/mitmcanary.git
cd mitmcanary/

Как уже было сказано, работу mitmcanary нужно начать с контрольных запросов. Для этого перейдите в каталог

cd service/

И запустите файл setup_test_persistence.py:

python2 setup_test_persistence.py

Это займёт некоторое время — дождитесь окончания. Не должны выводиться сообщения об ошибках (если так, то у вас не хватает каких-то зависимостей).

Будет выведено что-то вроде этого:

mial@HackWare:~/bin/mitmcanary/service$ python2 setup_test_persistence.py
[WARNING] [Config      ] Older configuration version detected (0 instead of 14)
[WARNING] [Config      ] Upgrading configuration in progress.
Purge log fired. Analysing...
Purge finished!
[INFO   ] [Logger      ] Record log in /home/mial/.kivy/logs/kivy_16-11-01_0.txt
[INFO   ] [Kivy        ] v1.9.1
[INFO   ] [Python      ] v2.7.12+ (default, Sep  1 2016, 20:27:38) 
[GCC 6.2.0 20160927]

31

После окончания этого процесса, в этой же директории выполните (это запустит фоновый процесс):

python2 main.py

После этого откройте новое окно терминала и перейдите в коневую директорию с mitmcanary. У меня это директория bin/mitmcanary/, поэтому я ввожу

cd bin/mitmcanary/

и выполните там:

python2 main.py

В первом окне выводиться что-то вроде:

mial@HackWare:~/bin/mitmcanary/service$ python2 main.py
[INFO   ] [Logger      ] Record log in /home/mial/.kivy/logs/kivy_16-11-01_1.txt
[INFO   ] [Kivy        ] v1.9.1
[INFO   ] [Python      ] v2.7.12+ (default, Sep  1 2016, 20:27:38) 
[GCC 6.2.0 20160927]
[INFO   ] [OSC         ] using <multiprocessing> for socket
[INFO   ] [OSC         ] listening for Tuio on 127.0.0.1:3000
Sleeping for 60 seconds
Sleeping for 60 seconds
Sleeping for 60 seconds
Sleeping for 60 seconds
Sleeping for 60 seconds
Sleeping for 60 seconds

Т.е. программа раз в минуту делает контрольные запросы и ищет в них признаки атаки человек-посередине.


Во втором окне также присутствует вывод + открывается тёмное окно, авторы программы называют это окно «графическим интерфейсом»:

41

Можно подождать некоторое время, посёрфить по Интернету, чтобы убедиться, что программа не делает никаких ложных предупреждений.

Попробуем классическую программу Ettercap.

Я запускаю обычную MitM-атаку с ARP-спуфингом. На само травление mitmcanary не реагирует. Инструмент mitmcanary сам генерирует трафик, т. е. действий со стороны пользователя не требуется. Спустя некоторое время появляется одно единственное предупреждение, которое при последующих ближайших проверках не подтверждается. Но подобное же предупреждение появляется через несколько минут. Без дополнительного анализа я затрудняюсь сказать, является ли это примером ложного срабатывания — очень похоже на это. Вполне возможно, что это предупреждение вызвано нарушением связи, обусловленное необходимостью прохождения трафиком дополнительных маршрутов, либо особенностями моего некачественного Интернет-подключения.

42

Поскольку результат неочевиден (скорее «нет», чем «да»), то давайте попробуем программу Bettercap, которая имеет разнообразные модули. Не сомневаюсь, что при использовании различных плагинов Ettercap и/или дополнительных программ для расширения функциональности, мы бы также «засветились» для mitmcanary.

Для чистоты эксперимента я перезапускаю оборудование, запускаю mitmcanary на атакуемой машине и Bettercap на атакующей. При этом на атакуемой машине необязательно заново делать контрольные запросы — они сохраняются в файле внутри директории с программой. Т.е. достаточно запустить службу и графический интерфейс.

А в атакующей машине мы запустим Bettercap с включёнными парсерами:

sudo bettercap -X

Появляются отдельные предупреждения, которые также больше похожи на ложные срабатывания.

Зато запуск такой команды:

sudo bettercap -X --proxy

На атакуемой машине вызывает большое количество предупреждений о возможной атаке человек-посередине:

44

46


Итак, чем функциональней инструмент для атаки человек-посередине, тем больше следов он оставляет в трафике. Для практического использования mitmcanary необходимо соблюсти следующие условия:


  • делать первоначальные запросы в доверенной сети, когда вы уверены, что посредник при передаче трафика отсутствует;
  • отредактировать ресурсы, к которым делаются проверочные запросы, поскольку профессиональный злоумышленник может добавить дефолтные ресурсы в исключения, что сделает его невидимым для этого инструмента.

2. Выявление ARP-спуфинга (травления кэша ARP)

Очень часто атака человек-посередине в локальной сети начинается с ARP травления. Именно поэтому в основе многих инструментов, предназначенных для выявления MitM-атак, лежит механизм слежения за изменением ARP кэша, в котором приписаны соответствия между Ethernet (MAC-адресами) и IP адресами.

В качестве примера таких программ можно вспомнить arpwatch, arpalert и большое количество новых программ. Программа ArpON не только следит за изменениями ARP кэша, но и защищает его от них.

В качестве примера запустим arpwatch в режиме отладки, без создания форков в фоне и отправки сообщений по почте. Вместо этого сообщения отправляются в stderr (стандартный вывод ошибок).

sudo /usr/sbin/arpwatch -d

На атакующей машине запустим Ettercap и начнём ARP-спуфинг. На атакуемой машине наблюдаем:

101

Программа arpwatch поможет быстро узнать о новых подключившихся устройствах в вашу локальную сеть, а также об изменениях ARP кэша.

Ещё один инструмент для выявления ARP спуфинга в реальном времени, это плагин самой Ettercap, который называется arp_cop. На атакуемой машине запустим Ettercap следующим образом:

sudo ettercap -TQP arp_cop ///

А на атакующей начнём ARP-травление. На атакуемой машине сразу начинают выводиться предупреждения:

47

3. Выявление DNS спуфинга

DNS спуфинг свидетельствует, что между вами и пунктом назначения присутствует посредник, который может модифицировать ваш трафик. Как можно обнаружить, что DNS записи были подменены? Самый простой способ это сделать — сравнить с ответами сервера имён, которому вы доверяете. Но ведь записи в ответе, присланный на ваш запрос, также могут быть подменены…

Т.е. проверять нужно либо через зашифрованный канал (например, через Tor), либо использовать нестандартные настройки (другой порт, TCP вместо UDP). Примерно для этого предназначена программа sans от XiaoxiaoPu (по крайней мере, я так понял). У меня получилось с помощью этой программы перенаправлять DNS запросы через Tor и через нестандартные настройки на свой DNS сервер. Но я так и не смог от неё добиться, чтобы она показывала мне сообщения о спуфинге DNS ответов. А без этого смысл программы теряется.

Более достойных альтернатив мне найти не удалось.

В принципе, учитывая, что DNS спуферы, обычно, следят только за 53 портом, и только за протоколом UDP, то даже вручную достаточно просто проверить факт DNS спуфинга, правда для этого нужен свой собственный DNS сервер с нестандартной конфигурацией. Например, на атакующей машине я создал файл dns.conf со следующим содержанием:

local mi-al.ru

Т.е. при запросе DNS записи для сайта mi-al.ru вместо реального IP будет присылаться IP машины злоумышленника.

Запускаю на атакующей машине:


sudo bettercap --dns dns.conf

А на атакуемой делаю две проверки:

dig mi-al.ru
# и 
dig mi-al.ru -p 4560 @185.117.153.79

Результаты:

mial@HackWare:~$ dig mi-al.ru

; <<>> DiG 9.10.3-P4-Debian <<>> mi-al.ru
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51993
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;mi-al.ru.			IN	A

;; ANSWER SECTION:
mi-al.ru.		86400	IN	A	192.168.1.48

;; Query time: 2 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Nov 02 09:25:20 MSK 2016
;; MSG SIZE  rcvd: 42

mial@HackWare:~$ dig mi-al.ru -p 4560 @185.117.153.79

; <<>> DiG 9.10.3-P4-Debian <<>> mi-al.ru -p 4560 @185.117.153.79
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 401
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;mi-al.ru.			IN	A

;; ANSWER SECTION:
mi-al.ru.		3799	IN	A	185.26.122.50

;; Query time: 304 msec
;; SERVER: 185.117.153.79#4560(185.117.153.79)
;; WHEN: Wed Nov 02 09:25:27 MSK 2016
;; MSG SIZE  rcvd: 53

201

Видно, что для «обычного» DNS запроса прислан локальный IP 192.168.1.48, а при запросе к DNS на нетипичном порту присылается верный IP сервера.

Если бы сервер был настроен для работы с протоколом TCP (а не UDP), тогда команда выглядела бы так:

dig mi-al.ru -p 4560 +tcp @185.117.153.79

Явно не хватает инструмента, который сам бы отслеживал DNS ответы в трафике, перепроверял бы их по альтернативному источнику и поднимал тревогу в случае спуфинга.

Чтобы обойтись без настройки своего собственного удалённого DNS, можно сделать запросы к серверу имён через Tor. Поскольку весь трафик Tor шифруется, то полученные таким образом DNS ответы не по зубам посреднику. Если Tor ещё не установлен, то установите его.

В Kali Linux:

sudo apt-get install tor

В BlackArch:

sudo pacman -S tor

Запустите службу:

sudo systemctl start tor

Если это вам нужно, добавьте эту службу в автозагрузку:

sudo systemctl enable tor

Откройте файл /etc/tor/torrc и добавьте туда следующие строки:

DNSPort 530
AutomapHostsOnResolve 1
AutomapHostsSuffixes .exit,.onion

Обратите внимание на цифру 530. Это номер порта, вместо 530 можно указать любой другой (незанятый) порт. Главное, запомните его.

Опять делаем проверки:

dig mi-al.ru
# и
dig mi-al.ru -p 530 @localhost

Теперь в качестве сервера мы указываем localhost, а номер порта пишите тот, который указали в настройках /etc/tor/torrc.

Как видно из следующего скриншота, в отношении машины, на которой сделана проверка, осуществляется атака DNS спуфинг:

11

4. Поиск сетевых интерфейсов в неразборчивом режиме (promiscuous mode)

Если в вашей локальной сети есть (а особенно если внезапно появилось) оборудование в неразборчивом режиме, это очень подозрительно, хотя и не свидетельствует однозначно об атаке человек-посередине.

В этом режиме сетевая плата позволяет принимать все пакеты независимо от того, кому они адресованы.

В нормальном состоянии на Ethernet-интерфейсе используется фильтрация пакетов канального уровня и если MAC-адрес в заголовке назначения принятого пакета не совпадает с MAC-адресом текущего сетевого интерфейса и не является широковещательным, то пакет отбрасывается. В «неразборчивом» режиме фильтрация на сетевом интерфейсе отключается и все пакеты, включая непредназначенные текущему узлу, пропускаются в систему.

Большинство операционных систем требуют прав администратора для включения «неразборчивого» режима. Т.е. перевод сетевой карты в неразборчивый режим – это сознательное действие, которое может преследовать цели сниффинга.

Для поиска сетевых интерфейсов в неразборчивом режиме имеется плагин Ettercap, который называется search_promisc.

Пример запуска плагина:

sudo ettercap -TQP search_promisc ///

Работа плагина не является полностью надёжной, могут иметь место ошибки в определении режима сетевого интерфейса.

Заключение

Некоторые методы атаки человек-посередине оставляют много следов, а некоторые (например, пассивный поиск учётных данных на прокси) невозможно или почти невозможно обнаружить.


Рекомендуется Вам:

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *