Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
В этой статье мы поговорим о разных вариациях кросс‑протокольной атаки NTLM Relay с использованием эксплоита RemotePotato0, а также на этом примере обсудим, как можно спрятать сигнатуру исполняемого файла от статического анализа.
Эта история относится к категории «байки с внутренних пентестов», когда мы попали в среду Active Directory, где члены группы безопасности Domain Users (все пользователи домена) обладали привилегией для удаленного подключения к контроллерам домена по протоколу RDP. Хоть это уже само по себе ужасная «мисконфига», потенциальный злоумышленник все еще должен найти способ для локального повышения привилегий на DC, что проблематично, если на системе стоят все хотфиксы.
Здесь и приходит на помощь баг фича из серии Microsoft Won’t Fix List — кросс‑сессионное провоцирование вынужденной аутентификации по протоколу RPC. При отсутствии защиты службы LDAP от атак NTLM Relay оно мгновенно подарит тебе «ключи от королевства».
Итак, внутренний пентест. Все по классике: только я, мой ноутбук, капюшон и маска Гая Фокса переговорка, скоммутированная розетка RJ-45 и просторы корпоративной сети жертвы аудита. Отсутствие правил фильтрации IPv6 в моем широковещательном домене — в роли уязвимости, отравленные пакеты DHCPv6 Advertise с link-local IPv6-адресом моего ноутбука (mitm6) — в роли атаки, и вот получен первоначальный аутентифицированный доступ в среду AD. Далее сбор дампа «блада» с помощью BloodHound.py, пока все как обычно.
Но вот то, что было дальше, повергло меня в шок… Оказалось, что все доменные «пользаки» могут коннектиться к контроллерам домена по RDP. Действительно, что может пойти не так?
Найди уязвимость на картинке
В этот момент можно начинать потирать руки в предвкушении кредов доменадмина. Убедимся, что мы можем релеить Net-NTLMv2-аутентификацию на службы LDAP(S) с помощью LdapRelayScan.
~$ python3 LdapRelayScan.py -method BOTH -dc-ip -u -p
PARTY TIME!
Неудивительно, что LDAP Signing (защита LDAP, 389/TCP) и LDAP Channel Binding (защита LDAPS, 636/TCP) отключены, — еще мало кто осознал, что это мастхев-mitigations для AD в наше время.
А теперь по порядку, что со всем этим можно сделать.
В далеком 2016 году умные люди придумали RottenPotato — технику локального повышения привилегий с сервисных аккаунтов Windows (например, IIS APPPOOLDefaultAppPool
или NT ServiceMSSQL$SQLEXPRESS
), обладающих привилегией олицетворения чужих токенов безопасности (aka SeImpersonatePrivilege), до NT AUTHORITYSYSTEM
.
Для этого атакующий должен был:
NT AUTHORITYSYSTEM
на машине‑жертве через триггер API-ручки DCOM/RPC CoGetInstanceFromIStorage
в отношении локального слушателя (выступает в роли «человека посередине»).
AcceptSecurityContext
, передавая ему содержимое NTLM-части запроса Negotiate (NTLM Type 1) от NT AUTHORITYSYSTEM
.
AcceptSecurityContext
, и продолжить изначальный релей на RPC из шага 1. В этом контексте NTLM-ответ службы RPC (135/TCP) используется просто как шаблон сетевого ответа, в который мы инжектим нужное нам тело NTLM-челленджа.
AcceptSecurityContext
и получить токен системы. На этом NTLM Relay окончен.
NT AUTHORITYSYSTEM
. Мы можем это сделать потому, что у нас есть привилегия SeImpersonatePrivilege.
Механизм работы RottenPotato (изображение — jlajara.gitlab.io)
Некоторое время спустя лавочку прикрыли, запретив DCOM/RPC общаться с локальными слушателями, — никаких тебе больше митмов. Но «картошки» все равно претерпевали изменения: были напилены LonelyPotato (неактуально) и JuicyPotato — улучшенная версия RottenPotato, умеющая работать с разными значениями CLSID (Class ID, идентификатор COM-класса) для «арбузинга» других служб (помимо BITS, которую использовала оригинальная «картошка»), в которых реализован интерфейс IMarshal для триггера NTLM-аутентификации.
JuicyPotato
В данном случае провоцирование NTLM-аутентификации в своей основе имеет принцип, схожий с вредоносной десериализацией объектов, только здесь это называется «анмаршалинг» — процесс восстановления COM-объекта из последовательности битов после его передачи в целевой метод в качестве аргумента.
Атакующий создает вредоносный COM-объект класса IStorage
и вызывает API CoGetInstanceFromIStorage
с указанием создать объект класса с конкретным идентификатором CLSID и инициализировать его состоянием из маршализированного вредоносного объекта. Одно из полей маршализированного объекта содержит указатель на подконтрольный атакующему слушатель, на который автоматически приходит отстук с NTLM-аутентификацией в процессе анмаршалинга.
public static void BootstrapComMarshal(int port){ IStorage stg = ComUtils.CreateStorage(); // Use a known local system service COM server, in this cast BITSv1 Guid clsid = new Guid("4991d34b-80a1-4291-83b6-3328366b9097"); TestClass c = new TestClass(stg, String.Format("127.0.0.1[{0}]", port)); MULTI_QI[] qis = new MULTI_QI[1]; qis[0].pIID = ComUtils.IID_IUnknownPtr; qis[0].pItf = null; qis[0].hr = 0; CoGetInstanceFromIStorage(null, ref clsid, null, CLSCTX.CLSCTX_LOCAL_SERVER, c, 1, qis);}
Подробнее о механизме триггера NTLM-аутентификации в ходе абьюза DCOM/RPC можно почитать в первом репорте Project Zero на эту тему.
С релизом RoguePotato — эволюционировавшей версией JuicyPotato — был продемонстрирован альтернативный подход к имперсонации привилегированных системных токенов:
ncacn_np:localhost/pipe/RoguePotato[pipeepmapper]
.
IRemUnkown2
) с подключением к подконтрольному атакующему пайпу из шага 3, что позволяет нам имперсонировать подключившийся клиент с помощью RpcImpersonateClient
, как это описал @itm4n в судьбоносном ресерче PrintSpoofer — Abusing Impersonation Privileges on Windows 10 and Server 2019.
Механизм работы RoguePotato (изображение — jlajara.gitlab.io)
С базовой теорией закончили.
www
Potatoes — Windows Privilege Escalation — статья с хорошим описанием всех «картошек» и таймлайном их появления.
RemotePotato0 — успешный результат попытки расширить область применения RoguePotato для проведения атак на доменные учетные записи.
Источник: xakep.ru