Не так давно появилась «новая» атака, позволяющая повысить привилегии в Windows с обычного пользователя до SYSTEM. Причем работает она практически «из коробки» под всеми современными версиями Windows, впрочем, должна и под древними. Ее название — Hot Potato.
Интересно, что сама атака состоит из нескольких отдельных техник, и каждая из них уже всплывала у нас в Easy Hack. И так как ты наверняка читаешь каждый выпуск и помнишь все, что прочитал, я не буду разбирать все шаги подробно и опишу лишь общую последовательность.
В основе данной атаки лежат результаты исследователя из Google. Как ты, наверное, помнишь, Windows поддерживает автоматическую аутентификацию, а также протокол NTLM (с помощью которого и аутентифицируется). То есть если мы можем зaставить какой-то процесс попытаться подключиться по протоколу SMB, HTTP и так далее и используем аутентификацию NTLM, то процесс отправит нам свои креды. Когда-то можно было отправить эти креды обратно по тому же протоколу — на этом и была основана первая вариация атаки SMBRelay. Но в Microsoft выпустили патч, и теперь разрешено делать relay либо между разными хостами, либо между разными протоколами.
По итогам исследования Google был представлен proof of concept, который демонстрировал, как системный процесс можно заставить подключиться к локально поднятому серверу WebDAV с NTLM-аутентификацией, а потом он релеил полученные креды на SMB того же хоста. В результате появлялась возможность выполнять команды от имени системного процесса.
[ad name=»Responbl»]
У PoC было две основные проблемы. Во-первых, работал он в основном на клиентских тачках, так как требовал предустановленный компонент в ОС — клиент WebDAV. Во-вторых, использовал возможность антивируса Microsoft проверять удаленные файлы, а она дoступна только в определенных версиях.
Ребята из Foxglove Security исправили эти недостатки. Причем особо наркоманским образом — как раз как мы любим.
Как ты знаешь, в Windows есть автоматическое обнаружение прокси, которое включено по умолчанию. ОС систематически ищет в сети хост с именем WPAD и если находит, то скачивает с него настройки для прокси-сервера. Эти настройки ко всему прочему используются системными службами, в том числе и Windows Update.
Второй важный момент заключается в том, что ОС также автоматически пытается аутентифицироваться на прокси (если сервер этого требует). То есть WPAD-прокси решает первую проблему PoC — нам не требуется WebDAV-клиент в ОС, так как прокси и аутентификация на нем поддерживается из коробки всеми версиями Windows. Теперь наша задача сводится к тому, чтобы «представиться» хостом WPAD для нашей ОС. И для ee решения мы можем использовать локальный NBNS spoofing.
Опять-таки, NBNS spoofing — классическая атака. Windows сначала ищет WPAD, запрашивая его у DNS-сервера, но, не найдя на DNS, переходит к другим протоколам для поиска хоста по имени, включая NBNS (NetBIOS Name Service). Поэтому ОС систематически отправляет по UDP широковещательные запросы к NBNS. Но как нам на них ответить? Привилегий на сниф трафика у нас нет, а использовать сторонний хост мы не можем, так как в этом случае нам придет «пустая» учетка системного процесса.
[ad name=»Responbl»]
Однако тут есть интересный момент. У запроса NBNS есть специальное поле — TXID. Это что-то вроде идентификатора, который нужен для того, чтобы соотносить запрос и ответ. Размер поля — 2 байта, то есть 65 536 значений. Локально мы можем послать множество NBNS-ответов со всеми возможными вариантами TXID. И так как сеть практически не задействуется (все проиcходит на lookback-интерфейсе), то мы можем это сделать очень быстро.
В результате получается такая последовательность. Мы отправляем множество NBNS-ответов с WPAD-сервером (и прокси-сервером), который мы поднимаем на каком-нибудь высоком порту — прав хватит. Таким образом, мы подменяем системный прокси. И как только какому-то системному процессу потребуется выйти в интернет, он отправится на наш прокси, где будет запрошена NTLM-аутентификация. Креды процесса мы релеим уже на SMB и получаем RCE от SYSTEM.
У атаки Hot Potato еще остается небольшая проблема: как заставить системный процесс куда-то пойти? Авторы придумали целый ряд способов — выбор зависит от версии ОС. Чаще всего для эксплуатации необходимо подождать какое-то время (полчаса или несколько часов). Подробнее смотри в блоге исследователей.
Здесь я хотел бы отметить еще две интересные техники. Во-первых, в том случае, если запись про WPAD есть на DNS-сервере, хост не будет использовать NBNS для поиска WPAD. Но мы можем забиндить все UDP-порты в системе, тогда DNS-запрос просто не будет отправлен, так как ОС не сможет привязать запрос ни к одному порту. Если DNS-запрос не отправлен, ОС использует NBNS.
Во-вторых, ресерчеры из Foxglove утверждают, что атака на перебор TXID для NBNS-ответов работает и против удаленных хостов. Если хост подключен напрямую к интернету или находится в другой сети, то мы можем удаленно слать множество NBNS-ответов на него. И если удача нам улыбнется, то мы сможем удаленно подменить запись WPAD или какую-то другую.
