Злой роутинг. Проворачиваем атаку MITM в Wi-Fi-сети. Часть 1

Атака «человек посередине», пожалуй, первое, что приходит на ум, когда возникает задача получить пользовательские данные, такие как логины и пароли к различным сервисам, а также передаваемую информацию: почту, сообщения мессенджеров и прочее. ARP-спуфинг, DNS-спуфинг, ICMP-редирект, Evil twin — про все эти техники ты уже, возможно, слышал. В данной статье я расскажу тебе про еще один способ устроить MITM в Wi-Fi-сети, не самый простой, но работоспособный.

Преамбула

Итак, как и всегда, для данной атаки есть пара ограничений:

Мы должны быть подключены к атакуемой точке доступа.
У нас должна быть возможность прослушивать широковещательный трафик в сети и перехватывать широковещательные запросы DHCPDISCOVER, DHCPREQUEST и ARP, чтобы обнаруживать конфликты адресов в локальной сети.

Итак, как же это работает? Атака разделяется на несколько этапов:

Производим атаку DHCP Starvation.
Отправляем Wi-Fi Deauth пакеты.
Перехватываем ARP-запросы от клиентов, отвечаем на них, чтобы создать конфликт IP-адресов и принудить клиента отправить DHCPDECLINE.
Перехватываем запросы DHCPDISCOVER и DHCPREQUEST, отвечаем на них.
Profit!

Разберемся в этой схеме поподробнее.

DHCP Starvation

Подключаемся к атакуемой Wi-Fi-сети и производим атаку DHCP Starvation с целью пополнить пул свободных IP-адресов. Для этого необходимо выполнить следующие шаги.

Формируем и отправляем широковещательный DHCPDISCOVER-запрос, при этом представляемся как DHCP relay agent. В поле giaddr (Relay agent IP) указываем свой IP-адрес 192.168.1.172, в поле chaddr (Client MAC address) — рандомный MAC 00:01:96:E5:26:FC, при этом на канальном уровне в SRC MAC выставляем свой MAC-адрес: 84:16:F9:1B:CF:F0.

Сервер отвечает сообщением DHCPOFFER агенту ретрансляции (нам) и предлагает клиенту с MAC-адресом 00:01:96:E5:26:FC IP-адрес 192.168.1.156.

После получения DHCPOFFER отправляем широковещательный DHCPREQUEST-запрос, при этом в DHCP-опции с кодом 50 (Requested IP address) выставляем предложенный клиенту IP-адрес 192.168.1.156, в опции с кодом 12 (Host Name Option) — рандомную строку dBDXnOnJ. Важно:значения полей xid (Transaction ID) и chaddr (Client MAC address) в DHCPREQUEST и DHCPDISCOVER должны быть одинаковыми, иначе сервер отбросит запрос, ведь это будет выглядеть как другая транзакция от того же клиента либо другой клиент с той же транзакцией.

Сервер отправляет агенту ретрансляции сообщение DHCPACK. С этого момента IP-адрес 192.168.1.156 считается зарезервированным за клиентом с MAC-адресом 00:01:96:E5:26:FC на 12 ч(время аренды по умолчанию).

Wi-Fi Deauth

Следующим шагом проводим Wi-Fi Deauth. Работает эта схема примерно так.

Подробнее о деаутентификации клиентов в Wi-Fi-сети можно почитать здесь и здесь.

Переводим свободный беспроводной интерфейс в режим мониторинга:

Отправляем deauth-пакеты с целью отсоединить атакуемого клиента 84:16:F9:19:AD:14 Wi-Fi-сети ESSID: WiFi DHCP MiTM.

DHCPDECLINE

После того как клиент 84:16:F9:19:AD:14 отсоединился от точки доступа, вероятнее всего, он заново попробует подключиться к Wi-Fi-сети WiFi DHCP MiTM и получить IP-адрес по DHCP. Так как ранее он уже подключался к этой сети, то будет отправлять только широковещательный DHCPREQUEST.

Мы перехватываем запрос клиента, но ответить быстрее точки доступа мы, само собой, не успеем. Поэтому клиент получает от DHCP-сервера IP-адрес, полученный ранее: 192.168.1.102. Далее клиент с помощью протокола ARP пытается обнаружить конфликт IP-адресов в сети.

Естественно, такой запрос широковещательный, поэтому мы можем его перехватить и ответить на него.

После этого клиент фиксирует конфликт IP-адресов и отправляет широковещательное сообщение отказа DHCP — DHCPDECLINE:

DHCPDISCOVER

Итак, последний этап атаки. После отправки DHCPDECLINE клиент с самого начала проходит процедуру получения IP-адреса, а именно отправляет широковещательный DHCPDISCOVER. Легитимный DHCP-сервер не может ответить на этот запрос, так как пул свободных IP-адресов переполнен после проведения атаки DHCP Starvation и поэтому заметно тормозит, зато на DHCPDISCOVER можем ответить мы — 192.168.1.172.

Клиент 84:16:F9:19:AD:14 (Win10-desktop) отправляет широковещательный DHCPDISCOVER.

Отвечаем DHCPOFFER.

Продолжение следует...

Источник