У цій статті детально розглядається теоретична основа протоколу Kerberos, який використовується для аутентифікації в комп'ютерних мережах.
395 
У цій статті детально розглядається важливий аспект безпеки Active Directory – делегування на основі ресурсів (RBCD). Це одна з ключових функцій у системах, що використовують протокол автентифікації Kerberos, яка дозволяє службам працювати від імені інших користувачів. Вона відкриває нові можливості для оптимізації процесів доступу, але водночас може стати серйозною загрозою, якщо використовується неправильно.
Дисклеймер: Ми усвідомлюємо, що на деяких фото або в матеріалах можуть зустрічатися написи російською мовою. Проте хіба це не чудово — використовувати їхню ж мову проти них?
Раніше ми вже розбиралися з тим, як працюють механізми необмеженого та обмеженого делегування в Active Directory через протокол Kerberos. Тепер настав час перейти до найцікавішої частини – делегування на основі ресурсів, яке особливо приваблює увагу, коли мова заходить про потенційні атаки.
Делегування на основі ресурсів, або ж RBCD (Resource Based Constrained Delegation), вперше з’явилося у Windows Server 2012.
Якщо раніше для налаштування необмеженого чи звичайного обмеженого делегування потрібні були спеціальні привілеї на рівні адміністратора домену, такі як SeEnableDelegation, то з появою RBCD ситуація змінилася. Тепер саме сервіс визначає, кому дозволено діяти від імені інших користувачів, що значно спрощує процес налаштування, але водночас додає певних ризиків у питаннях безпеки.
Далі для зручності будемо використовувати абревіатуру RBCD замість повної назви цього виду делегування.
Раніше призначався відповідальний, який визначав, до кого можна звертатися і від чийого імені це робити. З появою нового підходу кожен сервіс самостійно вирішує, кому дозволити доступ до себе від імені інших користувачів.
Для функціонування механізму делегування на основі ресурсів використовуються розширення S4U2Self та S4U2Proxy.
Щоб зрозуміти, як ці розширення працюють у контексті RBCD, можна розглянути такий приклад: у облікового запису “Власник Б” налаштоване делегування, яке дозволяє будь-якому сервісу облікового запису “Власник А” діяти від імені незахищених користувачів, звертаючись до будь-якого свого сервісу.
Розглянемо процес RBCD за пунктами:
Як User пройшов аутентифікацію до Сервісу А неважливо, припустимо, що з використанням відмінного від Kerberos протоколу NTLM.
Сервіс А звертається до контролера домену для отримання TGS-квитка “на себе” від імені користувача User.
Контролер домену перевіряє, що обліковий запис “Власник А” активний прапор TRUSTED_TO_AUTH_FOR_DELEGATION . Зазначений прапор не активний , тому у відповідь відправляється звичайний nonforwardable TGS-квиток без права передачі для User до Сервісу А. Таким чином, S4U2Self працює так само, як і у випадку класичного обмеженого делегування.
З використанням отриманого TGS-квитка Сервіс А звертається до контролера домену для отримання Forwardable TGS-квитка до Сервісу Б від імені User. Контролер домену перевіряє, що в атрибуті msDS-AllowedToActOnBehalfOfOtherIdentity облікового запису “Власник Б” встановлено SID облікового запису “Власник А”. Також контролер домену перевіряє, що “Власник А” має хоча б один SPN. В результаті контролер домену відправляє у відповідь Forwardable TGS-квиток.
Зазначена поведінка є важливою відмінністю. У RBCD S4U2Proxy повертає Forwardable TGS-квиток при наданні Nonforwardable квитка, в той час як при обмеженому делегуванні S4U2Proxy повертає Forwardable TGS-квиток тільки при наданні Forwardable квитка.
Сервіс А звертається від імені User до Сервісу Б з використанням отриманого Forwardable TGS-квитка.
Ще раз зазначимо:
S4U2Self у RBCD повертає Nonforwardable TGS-квиток.
S4U2Proxy завжди у разі успіху повертає Forwardable TGS-квиток.
Умови проведення атаки:
Можливість змінювати вміст атрибуту msDS-AllowedToActOnBehalfOfOtherIdentity атакованого облікового запису.
Контроль над обліковим записом, що має SPN.
У разі успішної атаки зловмисник отримує доступ з адміністративними правами до сервера, на якому функціонує сервіс, що працює від імені облікового запису з налаштованим RBCD.
Перший етап атаки полягає у внесенні SID підконтрольного облікового запису, що має SPN, в атрибут msDS-AllowedToActOnBehalfOfOtherIdentity облікового запису, який атакують. У результаті підконтрольний обліковий запис отримує можливість діяти від імені майже будь-якого користувача, звертаючись до сервісу, пов’язаного з атакованим обліковим записом.
rbcd.py 'DomainFQDN'/'Username':'Password' -delegate-from 'ControlledAccountWithSPN' -delegate-to 'Target$' -dc-ip 'DC_IP' -action write
На другому кроці атакуючий виконує S4U2Self запит TGS-квитка від імені адміністративного користувача до сервісу, що працює з-під контрольованого облікового запису. В результаті запиту атакуючий отримує Nonforwardable TGS-квиток.
getST.py -spn "cifs/target" -impersonate $AdminAccountName -dc-ip $DomainController $DomainFQDN/$ControlledAccountWithSPN:$Password
На третьому етапі атаки зловмисник використовує отриманий Nonforwardable TGS-квиток для виконання запиту S4U2Proxy. У разі успішного запиту він отримує Forwardable TGS-квиток до сервісу облікового запису, який атакують, діючи від імені адміністративного користувача. На цьому етапі атака завершується, оскільки зловмисник уже володіє повним доступом до сервісу.
Спочатку ця атака може здатися малоймовірною для практичного застосування. Дійсно, необхідність мати змогу змінювати атрибут msDS-AllowedToActOnBehalfOfOtherIdentity у цільового облікового запису виглядає значною перешкодою, оскільки така дія вимагає привілеїв адміністратора. До того ж виникає питання: як отримати обліковий запис із необхідним SPN?
Однак є кілька нюансів, які значно спрощують виконання цієї атаки в реальних умовах. Далі будуть розглянуті важливі фактори, що збільшують імовірність успішного проведення атаки.
На рівні домену існує атрибут ms-DS-MachineAccountQuota ( MAQ ), який відповідає за кількість машинних облікових записів, яку може додати непривілейований користувач зазначеного домену.
За промовчанням значення атрибута ms-DS-MachineAccountQuota дорівнює 10.
Перевірити поточне значення MAQ можна наприклад за допомогою спеціального модуля CrackMapExec:
crackmapexec ldap $DC -u $Username -p $Password -d $DomainFQDN -M MAQ
Зазвичай машинний обліковий запис одразу після створення автоматично отримує кілька SPN. Окрім цього, користувач, який створив машинний обліковий запис, має ряд прав на нього, включно з можливістю додавати нові SPN.
Це означає, що зловмисник, захопивши навіть звичайний непривілейований обліковий запис, може створити власний машинний обліковий запис і налаштувати його для подальшого використання в атаках на RBCD.
addcomputer.py -computer-name 'evilcomputer$' -computer-pass $GeneratedPass -dc-ip $DC_IP $Domain_FQDN/$Username:$Password
У скрипті addcomputer.py передбачений параметр -method, який дозволяє обрати протокол для додавання машинного облікового запису. Доступні два варіанти: SAMR та LDAPS. За замовчанням використовується SAMR, оскільки LDAPS може бути недоступним у деяких випадках.
Важливий момент: якщо додавання облікового запису виконується за допомогою SAMR, SPN не створюються автоматично. У такій ситуації необхідно скористатися окремим скриптом addspn.py, щоб додати потрібні SPN вручну.
addspn.py -u '$DomainFQDD'\'evilcomputer$' -p $LM:$NT -s anyRecordName.$DomainFQDN $DC_FQDN
Нещодавно був відкритий спосіб проводити RBCD-атаки і за відсутності можливості додавати машинні облікові записи в домен, у тому числі коли атрибут ms-DS-MachineAccountQuota дорівнює 0. У цьому випадку наявність облікового запису з SPN несуттєво і для атаки досить мати звичайну непривілейовану обліковий запис користувача.
Один момент, який хочеться відзначити: аналізований спосіб передбачає зміну пароля підконтрольного облікового запису користувача. Таким чином, атака призводить до непрацездатності зазначеного облікового запису з боку атакованої організації, тобто “відмови в обслуговуванні”, що слід брати до уваги.
Володіння одним із прав щодо облікового запису, що атакується:
GenericAll
GenericWrite
WriteDACL
WriteOwner
Дозволяє атакуючому змінювати атрибут msDS-AllowedToActOnBehalfOfOtherIdentity. Примітка: наявність наведених прав можна перевірити або пошукати за допомогою Bloodhound.
Розглянемо ще один важливий спосіб. Раніше зазначалося, що обліковий запис, який атакується, може самостійно змінювати значення свого атрибута msDS-AllowedToActOnBehalfOfOtherIdentity, і для цього не потрібні адміністративні привілеї. Однак виникає питання: як змусити обліковий запис змінити значення цього атрибута і вписати туди SID облікового запису, який контролюється атакуючим?
Відповідь полягає у використанні Relay-атаки.
У короткому викладі, в результаті цієї атаки перехоплюється запит на аутентифікацію NetNTLMv1/2, і отримані аутентифікаційні дані перенаправляються для подальшого виконання команд від імені облікового запису, що атакують. Одним із можливих результатів такої атаки є зміна значення атрибута msDS-AllowedToActOnBehalfOfOtherIdentity.
Проте для початківців розуміння цього процесу може бути складним. Спочатку було бажання розглянути RBCD у зв’язці з Relay-атаками, але виникли певні труднощі:
Тема Relay-атак дуже велика і заслуговує на окрему статтю, а іноді й кілька статей. Опис принципів та умов проведення цих атак виходить за межі поточного матеріалу.
Якщо продовжити без пояснення Relay-атак, це може порушити логіку розповіді, оскільки від читача вимагатимуть знання, які раніше не були обговорені. У попередніх статтях матеріал подавали послідовно “з нуля”, і це є важливою особливістю, від якої автор не хоче відступати.
Зважаючи на це, було ухвалено рішення завершити статтю про атаки на RBCD. Однак це не означає, що автор не повернеться до цієї теми в майбутньому, наприклад, після матеріалу, присвяченого Relay-атакам.
Провести інвентаризацію домену на наявність облікових записів з невикористовуваним налаштованим RBCD.
Додати критично важливі облікові записи домену до групи Protected Users або активувати опцію “Account is sensitive and cannot be delegated” в атрибутах зазначених облікових записів.
По можливості призначати власниками сервісів виділені облікові записи користувача. Забезпечити складність паролів і періодичну змінність для зазначених облікових записів.
Встановити атрибут ms-DS-MachineAccountQuota = 0.
Підписувати SMB та LDAP повідомлення на всіх об’єктах домену.
Налаштувати та використовувати LDAP channel binding.
Вимкнути службу друку Print Spooler на всіх об’єктах домену, де вона не використовується.
Коригувати налаштування міжмережевих екранів для обмеження можливості примусової автентифікації.
Відключити використання протоколу NetNTLM v1. По можливості відмовитися від використання NetNTLM v2 (що важко досягнути на практиці).
Використовувати актуальні версії операційних систем з встановленими критичними оновленнями, що допомагає захиститися від атак Drop the Mic або PrivExchange.
Виключити входження групи “Authenticated Users” у стандартну групу “Pre-Windows 2000 Compatible Access”.
За допомогою групових політик вимкнути використання небезпечних широкомовних протоколів NetBIOS, LLMNR, а також служби автоматичного налаштування проксі WPAD і протоколу IPv6 на об’єктах домену.
Примітка: Підходити до виконання цих рекомендацій слід індивідуально, оскільки не можна дати універсальних порад для всіх мереж і доменів. Перш ніж виконувати зміни, слід переконатися в доцільності цих коригувань. Наприклад, протокол IPv6 або служба WPAD можуть бути необхідні для роботи мережі, і замість їх відключення краще внести коригування в налаштування.
395 
389 
330 
379 
510