Новости из Блогов Hot Potato – злободневный вопрос повышения привилегий

Совсем недавно компанией «FoxGlove Security» (foxglovesecurity.com) был представлен интересный метод для поднятия своих привилегий.
Этот метод использует давно известные особенности (баги) Windows платформы, которые в том или ином виде присутствуют в дефолтных конфигурациях различных версий ОС.
При этом используются ранее многократно описанные и изученные приемы, такие как NTLM релеи и NBNS спуфинг.
Но тем не менее используя несколько комбинированных техник удается поднять привилегии на рабочей станции Windows от самого низко привилегированного уровня до максимально возможного – “NT AUTHORITY\SYSTEM”.
Подвержены практически все версии от Windows 7 до Windows 10, включая и серверные реализации.

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

Все рассматриваемые далее приемы известны уже много лет, некоторым уже почти 15 лет, и конечно же Microsoft прекрасно знает о их сущесовавании, но они по прежнему актуальны по той причине, что все они лежат глубоко в архитектуре и дизайне Windows платформы.
И все они успешно перекочевывают из одной версии в другую в рамках сохранения пресловутой обратной совместимости.

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

Первая часть — NBNS спуфер​

Напомню, что NBNS (NetBIOS Name Service) – это широковещательный UDP протокол, который служит для разрешения имен хостов в Windows среде.
Когда нужно узнать какое-нибудь доменное имя, первым делом Windows посмотрит содержимое файла hosts, если там ничего подходящего нет, то затем будет произведен стандартный DNS запрос.
Если же и DNS запрос не сможет вернуть ничего внятного, то вот тогда и будет задействован протокол NBNS.
Он активно используется в локальных сетях и соответственно будет отправлен широковещательный запрос на поиск IP-адреса для хоста с именем, равным нашему неизвестному значению.

Здесь сразу стоит отметить, что у нас не будет возможности сниффать протокол NBNS потому что это потребует прав локального администратора.
Но как же тогда мы проведем спуфинг?
Дело в том, что если мы будем заранее знать запрос на какое имя хоста целевой хост (в нашем случае наш целевой хост это естественно 127.0.0.1) будет отправлять NBNS запрос, то мы сможем без особых проблем изготовить поддельный ответ и затем довольно быстро его отправить.
Главная сложность всего действа заключается в том, что значение 2-х байтового поля «Transaction ID» в пакете NBNS должно совпадать и в запросе и в ответе, и мы помним, что возможности засниффить запрос у нас не будет.


Поэтому нам остается лишь быстро выстреливать UDP пакетами, перебирая все возможные значения, которых наберется 65536.

Но остается еще одна проблема, что если будет найдена DNS запись для хоста, имя которого мы планируем заспуфить?
В этом случае, мы можем использовать прием, который называется «UDP port exhaustion» (исчерпание UDP портов).
Cуть этого метода заключается в доведении системы до состояния невозможности провести DNS запрос, а для этого нам придется занять все возможные UDP порты.
Это приведет к неработоспособности DNS резолвера потому что не останется ни одного доступного UDP source порта для проведения запроса.
А мы помним, что когда DNS не работает, то в игру вступает NBNS.
В результате мы получаем почти 100% работающий метод, так как скорости отправки UDP пакетов на 127.0.0.1 весьма значительны.
Остается разобраться откуда мы будем знать исходный запрос, а вот для этого нам понадобиться вторая часть атаки.

Вторая часть — WPAD прокси сервер​

Это тоже очень давно известная техника.
Браузер IE по дефолту будет автоматически пытаться определить сетевые настройки пробуя обратиться по адресу «http://wpad/wpad.dat»
Как ни странно подобным поведением обладает не только IE, но и некоторые сервисы Windows, например Windows Update.
Стоит отметить, что ситуация с сервисами будет различаться в зависимости от используемой версии ОС, подробнее про это будет далее.
Разумеется имя хоста «wpad» скорее всего не существует и мы можем задействовать рассмотренный ранее механизм NBNS спуфинга.
И в случае успешного спуфинга мы сможем заявить, что хост с именем «WPAD» имеет адрес 127.0.0.1
В это же самое время у нас будет работать небольшой HTTP сервер, естественно на том же адресе 127.0.0.1
Именно он и будет обслуживать запросы вида «http://wpad/wpad.dat»
А в ответе он будет сообщать, что прокси сервер находится по адресу 127.0.0.1:80
В результате проведенного действа весь HTTP трафик жертвы будет заворачиваться на наш небольшой HTTP сервер, по прежнему работающий на 127.0.0.1
Подобная атака затронет всех пользователей работающих на целевом хосте, включая администраторов и системных учетных записей.
Ну а теперь заключительный аккорд и последний третий компонент атаки.

Третья часть — SMB NTLM релей​

Атаки типа SMB релей тоже известны много лет, существуют различные реализации и инструменты, нацеленные как на NTLM первой версии, так и версии 2.
Так же давно известно, что протокол NTLM подвержен атакам типа man-in-the-middle.
Атакующий может заставить жертву аутентифицироваться используя NTLM и затем перенаправить эту попытку аутентификации на другой хост.
Когда-то давным давно атакующий мог перенаправить учетные данные жертвы на саму жертву и таким образом получить доступ сразу на нее.
Такая ситуация не продлилась очень долго потому что Microsoft выпустила патч, который закрыл возможность проводить аутентификацию на самого себя.
Но при этом осталась возможность проводить атаки вида SMB релей на третий хост, а так же осталась возможность кросс-протокольных атак, то есть к примеру перенаправление учетных данных с HTTP на SMB в рамках одного и того же хоста.
То что нам и нужно!
Возвращаясь к нашему основному повествованию и держа в уме тот факт, что весь HTTP трафик начал проходить через наш небольшой локальный веб сервер, мы теперь сможем провести подобное перенаправление как только произойдет запрос на NTLM аутентификацию.
Для того чтобы не ждать подобную ситуацию, а автоматизировать этот процесс, абсолютно все HTTP запросы будут вначале редиректится на адрес «http://localhost/GETHASHExxxx», где xxxx – это некий уникальный идентификатор.
Ну а те запросы, что приедут уже на адрес «http://localhost/GETHASHExxxx» будут получать в ответ статус 401 (для доступа к запрашиваемому ресурсу требуется аутентификация) и соответствующим запросом на NTLM аутентификацию.
После этого, любые полученные учетные данные будут перенаправлятся на локальный дефолтный SMB листенер для создания нового системного сервиса, который в свою очередь будет выполнять наши кастомные команды.
Это уже стандартный функционал Windows без каких-либо дополнительных условий.
И соответственно, когда подобный HTTP запрос приедет от высоко привилегированного сервиса (например службы Windows Update) то и команды будут выполняться с уровнем «NT AUTORITY\SYSTEM».

Вот таким образом и происходит вся атака.
NBNS спуфер → WPAD прокси → HTTP2SMB релей
С одной стороны наблюдаем давно известные приёмы, а с другой — использование их совместно на одном и том же хосте.

После разбора основной концепции перейдем к непосредственному проведению подобной атаки на примерах Windows 7 и Windows 10.

Практическое применение​

Здесь сразу же нужно заметить, что проведение атаки будет разным в зависимости от используемой версии ОС.

Так же, атака не всегда может сработать с первого раза, это очевидно, так как Windows кеширует записи для WPAD, поэтому после запуска лучше оставить поработать некоторое время, и если ничего не произошло, то попробовать еще раз.
В лабораторных условиях всё работало отлично.

Исходный код и скомпилированные бинарники доступны на https://github.com/foxglovesec/Potato

Самый простой вариант атаки будет на Windows 7, поэтому с нее мы и начнем.

Запускаем Potato.exe от низко привилегированного пользователя:

Code:

Potato.exe -ip -cmd [что_выполнить] -disable_exhaust true

В качестве значения параметра cmd может выступать например команда вида

Code:

"C:\\Windows\\System32\\cmd.exe /K net localgroup administrators USERNAME /add"

При этом будет сначала запущен NBNS спуфер, затем обработан запрос на имя «WPAD», а далее будет произведена проверка обновлений для Windows Defender.
В случае, если в сети есть реальная DNS запись для WPAD, то можно указать опцию «disable_exhaust false».
И в таком случае будет проведена атака на истощение портов и ОС перейдет на протокол NBNS.



В случае более новых версий Windows (например Windows 8/10/2012) ситуация несколько усложняется.
Ни Windows Defender ни Windows Update уже не будут искать WPAD сервер.
Поэтому нам придется полагаться на новую фичу под названием «автоматическое обновление отозванных сертификатов».
Подбности этой фичи описаны на technet (https://technet.microsoft.com/en-us/library/dn265983.aspx)
Нас же будет интересовать тот факт, что по дефолту все новые версии Windows раз в день выкачивают списки доверенных сертификатов (certificate trust lists или CTLs).
Как ни странно именно этот компонент обращается к WPAD в процессе своей работы.

В результате, запуск атаки будет выглядеть следующим образом:

Code:

Potato.exe -ip -cmd [что_выполнить] -disable_exhaust true -disable_defender true

И после этого придется подождать максимум 24 часа, чтобы получить результат.



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

Так как все используемые приемы опираются исключительно на архитектурные особенности Windows, то будет интересно проследить за реакцией Microsoft и предпринятыми действиями.

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

18.01.2016 @ 15:08
https://defcon.ru/network-security/2303/
http://foxglovesecurity.com/2016/01/16/hot-potato/​

 

Картинки не резолвятся.
Просьба перелить на Imgur\Habrastorage.