Содержание статьи
Повышаем привилегии в Windows с помощью Hot Potato
Не так давно появилась «новая» атака, позволяющая повысить привилегии в Windows с обычного пользователя до SYSTEM. Причем работает она практически «из коробки» под всеми современными версиями Windows, впрочем, должна и под древними. Ее название — Hot Potato.
Интересно, что сама атака состоит из нескольких отдельных техник, и каждая из них уже всплывала у нас в Easy Hack. И так как ты наверняка читаешь каждый выпуск и помнишь все, что прочитал, я не буду разбирать все шаги подробно и опишу лишь общую последовательность.
В основе данной атаки лежат результаты исследователя из Google. Как ты, наверное, помнишь, Windows поддерживает автоматическую аутентификацию, а также протокол NTLM (с помощью которого и аутентифицируется). То есть если мы можем заставить какой-то процесс попытаться подключиться по протоколу SMB, HTTP и так далее и используем аутентификацию NTLM, то процесс отправит нам свои креды. Когда-то можно было отправить эти креды обратно по тому же протоколу — на этом и была основана первая вариация атаки SMBRelay. Но в Microsoft выпустили патч, и теперь разрешено делать relay либо между разными хостами, либо между разными протоколами.
По итогам исследования Google был представлен proof of concept, который демонстрировал, как системный процесс можно заставить подключиться к локально поднятому серверу WebDAV с NTLM-аутентификацией, а потом он релеил полученные креды на SMB того же хоста. В результате появлялась возможность выполнять команды от имени системного процесса.
У PoC было две основные проблемы. Во-первых, работал он в основном на клиентских тачках, так как требовал предустановленный компонент в ОС — клиент WebDAV. Во-вторых, использовал возможность антивируса Microsoft проверять удаленные файлы, а она доступна только в определенных версиях.
Ребята из Foxglove Security исправили эти недостатки. Причем особо наркоманским образом — как раз как мы любим.
Как ты знаешь, в Windows есть автоматическое обнаружение прокси, которое включено по умолчанию. ОС систематически ищет в сети хост с именем WPAD и если находит, то скачивает с него настройки для прокси-сервера. Эти настройки ко всему прочему используются системными службами, в том числе и Windows Update.
Второй важный момент заключается в том, что ОС также автоматически пытается аутентифицироваться на прокси (если сервер этого требует). То есть WPAD-прокси решает первую проблему PoC — нам не требуется WebDAV-клиент в ОС, так как прокси и аутентификация на нем поддерживается из коробки всеми версиями Windows. Теперь наша задача сводится к тому, чтобы «представиться» хостом WPAD для нашей ОС. И для ее решения мы можем использовать локальный NBNS spoofing.
Опять-таки, NBNS spoofing — классическая атака. Windows сначала ищет WPAD, запрашивая его у DNS-сервера, но, не найдя на DNS, переходит к другим протоколам для поиска хоста по имени, включая NBNS (NetBIOS Name Service). Поэтому ОС систематически отправляет по UDP широковещательные запросы к NBNS. Но как нам на них ответить? Привилегий на сниф трафика у нас нет, а использовать сторонний хост мы не можем, так как в этом случае нам придет «пустая» учетка системного процесса.
Однако тут есть интересный момент. У запроса NBNS есть специальное поле — TXID. Это что-то вроде идентификатора, который нужен для того, чтобы соотносить запрос и ответ. Размер поля — 2 байта, то есть 65 536 значений. Локально мы можем послать множество NBNS-ответов со всеми возможными вариантами TXID. И так как сеть практически не задействуется (все происходит на lookback-интерфейсе), то мы можем это сделать очень быстро.
В результате получается такая последовательность. Мы отправляем множество NBNS-ответов с WPAD-сервером (и прокси-сервером), который мы поднимаем на каком-нибудь высоком порту — прав хватит. Таким образом, мы подменяем системный прокси. И как только какому-то системному процессу потребуется выйти в интернет, он отправится на наш прокси, где будет запрошена NTLM-аутентификация. Креды процесса мы релеим уже на SMB и получаем RCE от SYSTEM.
У атаки Hot Potato еще остается небольшая проблема: как заставить системный процесс куда-то пойти? Авторы придумали целый ряд способов — выбор зависит от версии ОС. Чаще всего для эксплуатации необходимо подождать какое-то время (полчаса или несколько часов). Подробнее смотри в блоге исследователей.
Здесь я хотел бы отметить еще две интересные техники. Во-первых, в том случае, если запись про WPAD есть на DNS-сервере, хост не будет использовать NBNS для поиска WPAD. Но мы можем забиндить все UDP-порты в системе, тогда DNS-запрос просто не будет отправлен, так как ОС не сможет привязать запрос ни к одному порту. Если DNS-запрос не отправлен, ОС использует NBNS.
Во-вторых, ресерчеры из Foxglove утверждают, что атака на перебор TXID для NBNS-ответов работает и против удаленных хостов. Если хост подключен напрямую к интернету или находится в другой сети, то мы можем удаленно слать множество NBNS-ответов на него. И если удача нам улыбнется, то мы сможем удаленно подменить запись WPAD или какую-то другую.
Ищем Java-сериализацию при помощи SuperSerial
Стоило нам начать подробно разбирать Java-сериализацию в рубрике Easy Hack, как этот вектор атаки стал настолько модным, что ломают с его помощью все подряд. Я знаю как минимум с десяток продуктов, в которых была найдена соответствующая уязвимость, и с пяток случаев нахождения таких уязвимостей участниками разных bug bounty. А ведь то же самое могло начаться еще примерно год назад!
Надеюсь, к одному из следующих выпусков Easy Hack я смогу заново осознать эксплоит и объяснить его простыми славами, без дебрей Java. А посему сегодня мы коснемся сугубо практической части: поговорим о том, как же выискивать уязвимое ПО.
На самом деле задачи обычно две. Во-первых, обнаружить дырку в ПО, в которую мы можем слать сериализованный объект, чтобы он был десериализован. А во-вторых, понять, использует ли программа уязвимую версию библиотеки.
Вторая задача хоть и важна, но не особенно. Решается она чисто экспериментально (нужно послать сериализованный запрос с пейлоадом) или путем анализа либ (когда есть доступ к исходникам). Если нет уязвимой либы, то приложение всегда можно задосить, но это уже нехорошо.
Для решения задачи с поиском уязвимости позволь предложить тебе специальный плагин для Burp Suite — SuperSerial. Он прост, но полезен. Он пытается отыскать в запросах и ответах от сервера сериализованные объекты, в том числе представленные как Base64.
С таким инструментом ты не пропустишь момента, когда один из кучи сервисов системы отдаст тебе маленький сериализованный объект (реальный случай из жизни). Один нюанс: у меня есть некоторые сомнения в том, что плагин умеет выделять Java-объекты, когда они перемешаны с другими данными.
У SuperSerial есть собрат SuperSerial-Active. Он расширяет возможности активного сканера Burp, добавляя проверку на Java-сериализацию. Фактически он тупо шлет сериализованный объект с пейлоадом (используется ysoserial) на каждый URL. Пейлоад представляет собой простую команду для отстука на наш веб-сервер. Типичный метод Out of band (OOB). Плагин отображает, по какому из URL произошла обработка объекта и какой из запросов ее вызвал. Топорно, конечно, но это может сработать. Обычно для таких целей лучше использовать не внешний веб-сервер, а DNS-сервер, так как исходящие подключения часто заблокированы на файрволе, а вот DNS-туннель блокируют редко.
Получаем RCE в SAML через XSLT
Мы уже рассматривали атаки с использованием XSLT, но все равно стоит напомнить, что это за технология. Она позволяет с помощью XSL-стиля поменять структуру XML. Но для нас XSLT интересен тем, что позволяет напрямую писать код в стилях XSL, и этот код будет выполняться в процессе преобразования. В классическом случае проблема такой атаки в том, что чаще всего мы контролируем только сам XML-документ, но не XSL-стиль, по которому он будет преобразован. Однако на самом деле это не всегда так.
Есть ряд ситуаций, когда XSL-стиль может находиться прямо внутри самого XML. Да-да, в документе указывается описание того, как его необходимо преобразовать. Делается это за счет добавления в документ еще одного namespace (xmlns:xsl=http://www.w3.org/1999/XSL/Transform). Предостерегаю тебя от того, чтобы пихать XSLT-вектор в каждый XML по аналогии c XXE. Поддержка XSLT на принимающей стороне (в XML-парсере) не появляется просто так.
Увидеть, есть ли в браузере поддержка XSL внутри документов XML, мы можем при обработке файлов SVG, а также при использовании «глубоких» XML-технологий — таких как XML Digital Signature.
XML DSig используется для подписи XML-документов. Этот стандарт позволяет указывать XSLT-преобразования для документа до того, как будет проверена подпись. По идее, это было сделано для более гибкого взаимодействия. Когда есть разница между тем, как подпись считается на принимающей и на отправляющей стороне (разные кодировки, учет переносов и лишних пробелов — проблем возникает много), с помощью XSL-стиля можно компенсировать эту разницу. Для описания преобразования используется элемент Transform (в Transforms). Пример ты можешь увидеть на картинке.
Xakep #205. Взлом Single Sign-On
Получается, что у нас есть технология, которая из коробки поддерживает XSLT-трансформацию. Если видишь какой-то сервис, использующий XML DSig, значит, можешь попробовать заслать на него что-нибудь хорошее. При этом помни, что твой документ должен быть валидным и все элементы подписи тоже должны присутствовать. Сама она может и не быть валидной, но она нужна, чтобы пройти первичный парсинг на корректность документа. А далее выполнятся наши действия из стиля, и только после этого произойдет проверка подписи.
Если вспомнить, где XML DSig используется постоянно, то на ум приходит Security Assertion Markup Language (SAML). Это такой открытый стандарт на базе XML, который используется для создания централизованной аутентификации и авторизации. Сам по себе он непрост, так что подробно разбирать его не будем. Важно, что он часто используется в крупных компаниях.
Что мы имеем в итоге? Есть протокол аутентификации SAML, в котором используется технология XML DSig, которая, в свою очередь, поддерживает XSLT-трансформацию. Эта длинная цепочка дает нам возможность до аутентификации получить RCE. Очень удобно! Конечно, в реальности все не всегда так просто: если разработчики или админы в курсе проблемы, то кастомные стили для XML DSig могут быть и отключены.
