Kerberos із обмеженим делегуванням, усе, що потрібно знати для тестування безпеки (Частина 4)

Стаття розкриває ключові аспекти протоколу Kerberos та його механізму обмеженого делегування. Ви дізнаєтесь, як працюють розширення S4U2Proxy і S4U2Self, та які ризики виникають через делегування доступу. Пояснюємо, чому зловмисники можуть скористатися делегуванням для отримання привілейованого доступу до ресурсів, та надає рекомендації, як захистити мережу від подібних атак.

• Дисклеймер: Ми усвідомлюємо, що на деяких фото або в матеріалах можуть зустрічатися написи російською мовою. Проте хіба це не чудово — використовувати їхню ж мову проти них?

У попередній частині ми вже обговорювали, як працюють атаки на Active Directory через необмежене делегування у Kerberos. Також коротко пояснили основи цього протоколу, щоб читачам було легше зрозуміти подальший матеріал. Тепер настав час детальніше розібратися з тим, які ризики приховує обмежене делегування і як на нього можна здійснити атаки.

Обмежене делегування

Обмежене делегування було впроваджене у Windows Server 2003, щоб зменшити масштаби делегування та зробити систему безпечнішою. Сервіс із правом обмеженого делегування може діяти від імені будь-якого користувача, але лише при зверненні до конкретних, заздалегідь визначених сервісів.

Розглянемо загальну схему обмеженого делегування з використанням лише протоколу Kerberos:

1. User стандартно отримує TGS-квиток з прапором Forwardable для доступу до Сервісу A та відправляє його на вказаний сервіс.

2. Сервіс А пересилає отриманий TGS-квиток на контролер домену з метою отримання доступу до Сервісу Б від імені User. Як було зазначено раніше, TGS-квиток містить ім’я користувача для якого він призначався. Таким чином, Сервіс А доводить, що User дійсно звертався до нього.

3. Контролер домену перевіряє, що атрибут msds-allowedtodelegateto “Власника А” містить SPN Сервісу Б і у разі успішної перевірки надсилає Сервісу А Forwardable TGS-квиток до Сервісу Б для User.

Важливо, що в результаті успішного виконання S4U2Proxy запит завжди повертається Forwardable TGS-квиток.

Обмежене делегування зі зміною протоколу (S4U2Self та S4U2Proxy)

Розширення S4U2Self (Service for User to Self) використовується, коли автентифікація клієнта до сервісу з обмеженим делегуванням відбувається за допомогою будь-якого іншого протоколу, окрім Kerberos, наприклад NTLM. У таких випадках клієнт може пройти автентифікацію, але не здатний передати TGS-квиток, оскільки протокол Kerberos не задіяний. S4U2Self дає можливість сервісу отримати у контролера домену Forwardable TGS-квиток до самого себе від імені користувача, що звертається.

Щоб обліковий запис міг використовувати обмежене делегування з переходом між протоколами (S4U2Self), потрібно встановити спеціальний прапор TRUSTED_TO_AUTH_FOR_DELEGATION в атрибуті UserAccountControl цього облікового запису. Прапор відповідає цілому значенню 16777216.

На прикладі розглянемо механізм обмеженого делегування зі зміною протоколу:

1. User проходить автентифікацію до Сервісу А за будь-яким відмінним від Kerberos протоколом, допустимо NTLM.

2. Сервіс А запитує у контролера домену Forwardable TGS-квиток до себе від імені User.

3. Контролер домену перевіряє, що обліковий запис “Власник А” в атрибуті UserAccountControl встановлений прапор TRUSTED_TO_AUTH_FOR_AUTHENTICATION.

Якщо перевірка проходить невдало, наприклад, коли прапор TRUSTED_TO_AUTH_FOR_DELEGATION не встановлений або користувач належить до групи “Protected Users”, сервіс отримає TGS-квиток без права передачі (Nonforwardable) для цього користувача до Сервісу А.

Таким чином, квиток, виданий у відповідь на запит S4U2Self, може містити або не містити прапор Forwardable — це залежить від налаштувань облікового запису та сервісу. Якщо налаштування дозволяють делегування, квиток буде з прапором Forwardable; якщо ж ні — без нього, що обмежує можливість подальшої передачі квитка іншим сервісам.

4. Надалі для отримання Forwardable TGS-квиток до Сервісу Б від імені User використовується розширення S4U2Proxy .

Важливо, що S4U2Self-запит TGS-квитка від імені довільного користувача може бути ініційований будь-яким обліковим записом, що володіє SPN, не чекаючи автентифікації зазначеного користувача.

Класична атака на обмежене делегування

Умова для атаки: пароль (NT хеш) до облікового запису, що має право на обмежене делегування зі зміною протоколу до певного сервісу.

Деякі варіанти виконання умови:

• Пароль до облікового запису користувача може бути отриманий в результаті атаки Kerberoasting або підібраний оффлайн в результаті перехоплення Net-NTLMv2 хеша.

• Паролі (NT хеші) можуть бути вилучені з оперативної пам’яті сервера або робочої станції.

Результат успішної атаки : доступ з адміністративними правами до сервера, призначеного для функціонування сервісу, до якого здійснюється делегування.

Ідея атаки полягає в уособленні привілейованого користувача при зверненні до сервісу якого налаштовано обмежене делегування.

Розглянемо проведення атаки на практичному прикладі з лабораторної роботи Exploiting Active Directory (доступна за платною підпискою). У атакуючого є обліковий запис svcIIS з наступними налаштуваннями делегування:

findDelegation.py $Domain_FQDN/$Username:$Password

Налаштування делегування svcIIS дозволяють отримати віддалений привілейований доступ до THMSERVER1 за допомогою служби WinRM.

У результаті, резюмуючи вищевикладене, виходить наступний порядок дії щодо атаки:

1. Запросити TGT для користувача svcIIS

2. З використанням отриманого TGT запросити TGS-квитки до сервісів HTTP/THMSERVER1.za.tryhackme.loc та WSMAN/THMSERVER1.za.tryhackme.loc від імені привілейованого користувача T1_Trevor.jones

3. З використанням отриманих TGS-квитків підключитися до THMSERVER1.za.tryhackme.loc від імені привілейованого користувача T1_Trevor.jones за допомогою PassTheTicket та WinRM

Для кращого розуміння проведемо атаку двома способами. Перший спосіб трохи надмірний, але добре ілюструє кожен крок окремо. Другий спосіб більш автоматизований та наближений до практики.

“Детальний” спосіб (Kekeo + Windows)

Запитуємо TGT для облікового запису svcIIS:

tgt::ask /user:$Username /domain:$Domain_FQDN /password:$Password

Запитуємо TGS-квиток до HTTP/THMSERVER1.za.tryhackme.loc від імені T1_Trevor.jones:

tgs::s4u /tgt:$path_to_TGT /user:$Username /service:$SPN

Аналогічно запитуємо TGS-квиток до WSMAN/THMSERVER1.za.tryhackme.loc

За допомогою Mimikatz завантажуємо здобуті TGS-квитки в LSA для PtT:

Для наочності переконаємося, що квитки справді завантажені:

Список кешованих квитків Kerberos

Створимо нову сесію:

Здійснимо вхід до створеної сесії:

AnySPN атака

Розглянутий вище спосіб атаки не дуже практичний, оскільки для його успішного виконання необхідно, щоб обмежене делегування було налаштоване саме для тих сервісів, які використовуються для віддаленого підключення. Це суттєво обмежує можливість реалізації такого сценарію в реальних умовах.

Як видно з ілюстрації, якщо хоча б один із сервісів облікового запису має налаштоване обмежене делегування, зловмисник може скористатися цим і отримати доступ до інших сервісів, пов’язаних із цим обліковим записом.

Однак важливо пам’ятати, що якщо в SPN вказаний порт, наприклад, mssqlsvc\server01.domain.local:1433, отримати TGS-квиток для підмінного сервісу не вдасться. У такому випадку, під час спроби змінити цільовий SPN, контролер домену поверне повідомлення KDC_ERR_S_PRINCIPAL_UNKNOWN, що вказує на відсутність зареєстрованого SPN.

“Практичний” спосіб (Impacket + Linux)

Спробуємо повторити атаку, але цього разу скористаємося скриптами з набору Impacket. Першим кроком буде запит TGS-квитка до сервісу HTTP/THMSERVER1.za.tryhackme.loc від імені привілейованого користувача T1_Trevor.jones. Це дозволить перевірити, чи налаштовано обмежене делегування для цільового сервісу та чи є можливість використати отриманий квиток для подальших дій.

Завдяки скриптам Impacket процес запиту TGS-квитка можна автоматизувати, що значно полегшує виконання атаки та прискорює її реалізацію.

getST.py -spn $SPN -impersonate $ImpersonatedUsername $Domain_FQDN/$Username:$Password

Експортуємо отриманий TGS-квиток у кеш і встановимо віддалене підключення, наприклад за допомогою wmiexec:

export KRB5CCNAME=$PathToCacheFile

wmiexec.py -k -no-pass $Domain_FQDN/$ImpersonatedUsername@$TargetDnsName

Доступ отримано, атака успішно завершена.

Для загального пізнання запустимо ту саму команду в режимі налагодження:

Рекомендації

• Проведіть перевірку домену для виявлення облікових записів із налаштованим, але невикористовуваним обмеженим делегуванням.

• Використовуйте обмежене делегування лише для конкретних сервісів і тільки в разі реальної потреби.

• Додайте критично важливі облікові записи до групи Protected Users або активуйте параметр «Обліковий запис чутливий і не може делегуватись» у налаштуваннях цих записів.

• По можливості створюйте окремі облікові записи для сервісів і призначайте їх власниками сервісів.

• Забезпечте використання складних паролів для сервісних облікових записів та їх регулярну зміну.

• Під час створення SPN завжди вказуйте порт, щоб унеможливити небажане делегування.