Эксплуатация широковещательного разрешения имен через протокол WPAD

Эксплуатация широковещательного разрешения имен через протокол WPAD

Один из наиболее распространенных типов атак, используемых во время пентестов, – несанкционированная эксплуатация широковещательного разрешения имен.

Автор: Josh Abraham
Один из наиболее распространенных типов атак, используемых во время пентестов, – несанкционированная эксплуатация широковещательного разрешения имен (Broadcast Name Resolution Poisoning). Недавно группа US-CERT опубликовала бюллетень, где описывается схема удаленной реализации данного вида атаки. Злоумышленники регистрировали новые домены верхнего уровня (gTLDS) и настраивали записи для протокола WPAD (Web Proxy Auto-Discovery Protocol, протокол автоматической настройки прокси). По сути, устаревшая схема атаки была переделана на новый лад.

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

Системы, подверженные угрозе

Windows, MacOSX и Linux.

Общая схема реализации

Злоумышленник может выполнить атаку «Человек посередине» против уязвимых систем, если эти системы находятся в той же локальной сети, что и система жертвы (внутренняя сеть, кафе, аэропорт).

Злоумышленник может выполнить атаку «Человек посередине» через интернет в случае регистрации gTLD домена, конфликтующего с внутренней схемой имен, и развернуть поддельный WPAD-прокси.

Подробное описание схемы

Существует несколько вариантов атаки, но базовая идея не меняется. Злоумышленник конфигурирует систему жертвы для ответа на аутентификационные запросы посредством спуфинга запросов, связанных с разрешением имен. Как только клиент пытается найти систему, не имеющей корректной записи DNS, происходит переключение на менее известные протоколы, например, на NBNS и LLMNR. Порядок поиска систем выглядит следующим образом:

  1. Записи файла Host
  2. DHCP
  3. DNS
  4. NBNS
  5. LLMNR

Вначале система Windows ищет имя WPAD. Используя это имя, в Internet Explorer можно найти настройки для автоматического детектирования прокси-сервера. Если запись WPAD в DNS отсутствует, то злоумышленник может организовать поддельный сервер для перехвата аутентификационных запросов. Например, если пользователь пытается посмотреть общий файловый ресурс или авторизоваться на веб-портале, учетные записи домена (или аутентификационные хеши) могут быть перехвачены. Подобная схема работает и для других протоколов: SMB, HTTP, MSSQL, FTP и т. д.

В некоторых случаях можно перехватить учетные записи в чистом виде (в случае базового протокола HTTP, FTP или MSSQL). Хотя в основном перехватываются учетные данные по протоколам NetNTLMv1 или NetNTLMv2. Поскольку оба эти формата содержат challenge, злоумышленнику доступен либо взлом хеша, либо одноразовое повторное воспроизведение.  

Целью новой WPAD-атаки являются клиенты, находящиеся вне внутренней корпоративной сети (домашняя сеть, аэропорт или кофе). Если злоумышленник владеет доменом gTLD, используемым организацией для внутренних целей, то становится возможным перехват WPAD (или схожих) запросов. Для пентестеров эта информация не представляет особой ценности, но организациям следует понимать потенциальные риски.

Далее мы продемонстрируем насколько просто можно взломать учетные записи и скомпрометировать Windows-домен.

Демонстрация атаки

WPAD – не единственное имя, которые пытается найти клиент. Все зависит от конфигурации системы и сети. Во время демонстрации атаки будет использоваться имя CORP (домен нашей лаборатории).

Кроме того, будут использоваться утилиты: Gladius, Hob0Rules и Responder.

Вначале устанавливаем Gladius для мониторинга и автоматического взлома хешей. После запуска Gladius стартуем Responder и ждем того момента, когда жертва попытается аутенцифицироваться. На рисунке ниже видно, как жертва пытается воспользоваться именем CORP, а система злоумышленника отвечает и перехватывает учетные записи.


Рисунок 1: Ответ злоумышленника на запрос пользователя

На рисунке выше видно, что пользователь с именем Administrator отправил учетную запись в формате NetNTLMv2. Gladius автоматически перехватывает данные и начинает взлом хеша.


Рисунок 2: Взлом перехваченной учетной записи

По результатам взлома выяснилось, что пароль администратора - ‘Password1!!’. Найденные учетные записи могут быть использоваться для доступа к серверу электронной почты или VPN.

Но мы пойдем другим путем и воспользуемся утилитой CrackMapExec.


Рисунок 3: Запуск команды whoami

Кроме того, мы можем извлечь все хеши из текущего контроллера домена, поскольку у нас есть учетная запись администратора домена.


Рисунок 4: Выгрузка всех хешей домена

В результате мы полностью скомпрометировали домен. Администраторам следует иметь в виду подобного рода атаки, которые показали высокую эффективность во время пентестов.

Рекомендации

Чтобы полностью защититься от этой угрозы, рекомендуется использоваться комплексный подход. Методы защиты, касающиеся новой схемы, помечены курсивом.

Методы защиты:

  • Создайте запись WPAD, которая указывает на корпоративный прокси сервер или отключите автоматическое детектирование прокси в Internet Explorer.
  • Отключите NBNS и LLMNR (но прежде протестируйте эти настройки перед выкатыванием во всех системах).
  • Настройте корректные DNS-записи для внутренних и внешних ресурсов
  • Осуществляйте мониторинг сети на предмет атак, связанных со злоупотреблением широковещательных запросов (broadcast poisoning attacks).
  • Ограничьте внешние соединения 53/tcp и 445/tcp для всех внутренних систем.

Кроме того, US-CERT дает пользователям и сетевым администраторам следующие рекомендации для повышения уровня безопасности сетевой инфраструктуры:

  • Отключите поиск/конфигурацию автоматического прокси сервера в браузерах и операционных системах во время установки новых устройств, если подобная возможность не нужна для внутренних сетей.
  • Используйте полностью определенное имя домена (Fully Qualified Domain Name; FQDN) от глобального DNS-сервера как основу (root) для корпоративного и других внутренних пространств имен.
  • Конфигурируйте внутренние DNS-сервера для весомого ответа на внутренние TLD-запросы.
  • Настройте фаерволы и прокси для логирования и блокирования внешних запросов к файлам wpad.dat.  
  • Идентифицируйте ожидаемый сетевой трафик, связанный с WPAD, осуществляйте мониторинг публичного пространства имен или рассмотрите превентивную регистрацию доменов для избежания будущей коллизии имен.
  • Отправляйте отчеты в ICANN (https://forms.icann.org/en/help/name-collision/report-problems), если ваша система испытывает серьезные последствия от коллизии имен. 

Мир сходит с ума и грянет киберапокалипсис. Подпишись на наш Телеграм канал, чтобы узнать первым, как выжить в цифровом кошмаре!