Pull to refresh

Атакуем DHCP часть 2. DHCP + WiFi = MiTM

Network technologies *Wireless technologies *

LOGO


В данной статье я расскажу про еще один способ осуществления MiTM в WiFi сети, не самый простой, но работающий. Прежде чем читать эту статью настоятельно рекомендую ознакомиться с первой частью, в которой я попытался объяснить принцип работы протокола DHCP и как с его помощью атаковать клиентов и сервер.


Как и всегда для осуществления данной атаки есть пару ограничений:


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

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


  1. Производим атаку DHCP Starvation;
  2. Отправляем WiFi DeAuth пакеты;
  3. Перехватываем ARP запросы от клиентов, отвечаем на них, чтобы создать конфликт IP-адресов и принудить клиента отправить DHCPDECLINE;
  4. Перехватываем DHCPDISCOVER и DHCPREQUEST запросы, отвечаем на них;
  5. Profit!

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


DHCP Starvation


Подключаемся к атакуемой WiFi сети и производим атаку DHCP Starvation с целью переполнить пул свободных IP-адресов.
Как это работает:


  1. Формируем и отправляем широковещательный 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.
    DHCPDISCOVER


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


  3. После получения 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 должны быть одинаковыми, иначе сервер отбросит запрос, ведь это будет выглядеть, как другая транзакция от того же клиента, либо другой клиент с той же транзакцией.
    DHCPREQUEST


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



WiFi DeAuth


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


WiFi DeAuth


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


Wlan1 set monitor mode


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


Send deauth packets


DHCPDECLINE


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


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


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


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


DHCPDISCOVER


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


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


Отвечаем DHCPOFFER:
Attacker DHCPOFFER


В DHCPOFFER мы предложили клиенту IP-адрес 192.168.1.2. Клиент получив данное предложение только от нас отправляет DHCPREQUEST, выставляя при этом в requested ip значение 192.168.1.2.


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


Отвечаем DHCPACK:
Attacker DHCPACK


Клиент принимает наш DHCPACK и в качестве шлюза по умолчанию и DNS-сервера выставляет наш IP-адрес: 192.168.1.172, а DHCPNAK от точки доступа присланный на 2 секунды позже просто проигнорирует.
Client network settings


Вопрос: Почему точка доступа прислала DHCPOFFER и DHCPNAK на 2-е секунды позже, да еще и предложила тот же IP-адрес 192.168.1.102, ведь клиент отказался от него?
DHCPOFFER from AP


Чтобы ответить на данный вопрос немного изменим фильтр в WireShark и посмотрим ARP запросы от точки доступа:
Add ARP requests from AP


Ответ: После проведения атаки DHCP Starvation у DHCP-сервера не оказалось свободных IP-адресов, кроме того, от которого отказался один из клиентов: 192.168.1.102. Поэтому, получив DHCPDISCOVER-запрос, DHCP-сервер в течении 2-ух секунд отправляет три ARP-запроса, чтобы узнать кто использует IP-адрес: 192.168.1.102, и после того, как сервер убедился что данный IP-адрес свободен, поскольку никто не ответил, выдает его клиенту. Но уже слишком поздно злоумышленник успел ответить быстрее.


Результаты:


Таким образом, мы можем выставлять любые сетевые параметры, а именно: шлюз по умолчанию, DNS сервер и другие — любому подключенному или новому клиенту в атакуемой WiFi сети, при условии, что мы к ней уже подключены и можем прослушивать широковещательный трафик.


Видео проведения атаки на MacOS Siera и Windows 10:



Ну и конечно же PoC.

Tags:
Hubs:
Total votes 12: ↑12 and ↓0 +12
Views 15K
Comments Comments 6