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

    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.

    • +12
    • 12,3k
    • 6
    Поделиться публикацией
    Комментарии 6
      0

      Это будет работать только в простейшей wireless сети без контроллера. В энтерпрайзе все эти дыры прикрыты: траффик клиент-клиент запрещён, DHCP проксируется или выдаётся контроллером и так далее.

        0
        Полностью с вами согласен.
          0
          Хотя, меняя мак, можно провести DHCP Starvation. Но это будет просто DoS без угрозы компрометации других клиентов.
            0
            Что провести атаку DHCP Starvation необязательно менять мак, достаточно представиться как Relay Agent.
              0
              С большинством контроллеров это не сработает, они не будут обслуживать DHCP-запросы от Relay Agent, только прямые броадкасты.
          0
          В Энтерпрайзе м.б. и не сработает, а вот в кафешках с FreeWiFi и роутером аля TpLink из ближайшего магазина электроники очень даже сработает.

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое