Злой роутинг. Проворачиваем атаку MITM в Wi-Fi-сети. Часть 2
Life-Hack [Жизнь-Взлом]/ХакингВ DHCPOFFER мы предложили клиенту IP-адрес 192.168.1.2. Клиент, получив данное предложение только от нас, отправляет DHCPREQUEST, выставляя при этом в requested ipзначение 192.168.1.2, и мы отвечаем DHCPACK.
Клиент 84:16:F9:19:AD:14 (Win10-desktop) отправляет широковещательный DHCPREQUEST.
Отвечаем DHCPACK.
Клиент принимает наш DHCPACK и в качестве шлюза по умолчанию и DNS-серверавыставляет наш IP-адрес: 192.168.1.172, а DHCPNACK от точки доступа, присланный на две секунды позже, просто проигнорирует.
Вопрос: почему точка доступа прислала DHCPOFFER и DHCPNACK на две секунды позже, да еще и предложила тот же IP-адрес 192.168.1.102, ведь клиент отказался от него?
Чтобы ответить на этот вопрос, немного изменим фильтр в Wireshark и посмотрим ARP-запросы от точки доступа.
Ответ: после проведения атаки DHCP Starvation у DHCP-сервера не оказалось свободных IP-адресов, кроме того, от которого отказался один из клиентов: 192.168.1.102. Поэтому, получив DHCPDISCOVER-запрос, DHCP-сервер в течение двух секунд отправляет три ARP-запроса, чтобы узнать, кто использует IP-адрес 192.168.1.102, и после того, как сервер убедится, что данный IP-адрес свободен, поскольку никто не ответил, выдает его клиенту. Но уже слишком поздно: злоумышленник успел ответить быстрее.
Результаты
Таким образом, мы можем выставлять любые сетевые параметры: шлюз по умолчанию, DNS-сервер и другие — любому подключенному или новому клиенту в атакуемой Wi-Fi-сети, при условии, что мы к ней уже подключены и можем прослушивать широковещательный трафик.
PoC
Ну и конечно же, PoC.
Послесловие. Apple vs DHCP
Как оказалось, macOS и iOS переплюнули всех в плане получения сетевых настроек по протоколу DHCP. Когда эти операционные системы отправляют DHCPREQUEST, DHCP-сервер отвечает им DHCPACK, и они выставляют сетевые настройки из ответа сервера. Вроде пока все как у всех:
Но проблема в том, что DHCPREQUEST широковещательный и злоумышленник, как правило, без особых проблем может его перехватить и ответить DHCPACK, но, конечно, позднее легитимного DHCP-сервера, то есть ответ злоумышленника приходит вторым. Все остальные DHCP-клиенты на других ОС просто проигнорируют второй DHCPACK, но на macOS и iOS все не так.
Как ты думаешь, какие настройки выставляют данные операционные системы? Ответ: те настройки, которые будут содержаться в DHCPACK злоумышленника (во втором DHCPACK ~~во втором DHCPACK, Карл!~~).
Как ты думаешь, баг это или фича? Я подумал — баг и на всякий случай завел заявку на Apple Bug Reporter. Скоро этой заявке исполнится месяц, но ни одного комментария от специалистов Apple я так и не получил.
На заявке в Apple Bug Reporter я не остановился и написал письмо в product-security@apple.com.
Специалисты Apple совсем не быстро, но все же ответили и сказали, что их DHCP-клиент работает в соответствии с RFC 2131. То есть это не бага, а фича — вот и конец истории.
Apple Wifi MiTMer
В аргументах скрипта всего-то нужно указать имя беспроводного интерфейса, который уже подключен к исследуемой Wi-Fi-сети, и еще один беспроводной интерфейс для отправки deauth-пакетов. Как это работает, можно посмотреть тут.