АТАКА № 2. Злом паролів за даними попередньої аутентифікації Kerberos

Запобігання атаки № 2

Існує два способи протидії атакам на дані попередньої аутентифікації Kerberos. По-перше, використання смарт-карт для реєстрації в мережі, по-друге, шифрування мережевого трафіку між клієнтом Kerberos і контролером домену за допомогою протоколу IPsec. Реєстрація за допомогою смарт-карт використовує розширення Kerberos PKINIT, яке застосовує для шифрування даних не майстер-ключ користувача, а його секретний пароль. Більш детальну інформацію про PKINIT можна знайти в статті «Public Key Cryptography for Initial Authentication in Kerberos», доступною на сторінці http://www.ietf.org/proceedings/03mar/ID/draft-ietf-cat-kerberos-pk-init-16.txt . В даний час вважається неможливим здійснити злом повним перебором пакетів, які зашифровані криптографічними засобами відкритого-закритого ключа. Відомості про налаштування IPsec можна знайти в урізанні «Використання політик безпеки IP для захисту серверів» .

Атака № 3. Підвищення привілеїв за допомогою вразливості SIDHistory

Атрибут SIDHistory був доданий до облікового запису користувача в AD в Windows 2000. SIDHistory призначений для забезпечення доступу до ресурсів при перенесенні облікового запису користувача між доменами і для забезпечення переміщення облікового запису користувача всередині лісу. Наприклад, при міграції користувальницької облікового запису з домену Windows NT 4.0 в домен Windows 2000, Windows автоматично заповнює атрибут SIDHistory для щойно створеного облікового запису в домені Windows 2000 значенням SID відповідного користувача в домені NT 4.0. При реєстрації дані авторизації користувача (членство в групах і т. П.) Заповнюються в домені Windows 2000, і контролер домена додає старий SID користувача в дані авторизації. При цьому заново надавати доступ до ресурсів в старому домені (їх списки ACL не оновлюється) не потрібно, і користувач автоматично отримує доступ до них з новою обліковим записом.

В принципі недобросовісний адміністратор AD може спробувати змінити атрибут SIDHistory облікового запису користувача для підвищення рівня привілеїв. Наприклад, при наявності довірчих відносин між доменами можна спробувати додати SID облікового запису адміністратора довіряє домену в атрибут SIDHistory користувальницької облікового запису в довіреному домені.

У перших випусках Windows 2000 контролери довіряє домену не виконували перевірку даних аутентифікації, що передаються разом із запитом на доступ до ресурсу, отриманим з довіреної домену. Довіряє домен автоматично припускав, що запити містять тільки ті SID, які були успішно авторизовані контролерами довіреної домену.

Хоча підміна атрибута SIDHistory для облікового запису користувача AD - процедура не зовсім проста (і може бути виконана тільки, коли AD знаходиться в автономному режимі), але все ж здійсненна. Доступні програми, які допоможуть адміністратору цілеспрямовано змінити атрибут SIDHistory. Одну з таких програм - SHEdit - можна завантажити за адресою http://www.tbrio.com/projects/shedit/index.htm .

Атака цього типу може бути здійснена за будь-якої конфігурації довірчих відносин між доменами: між доменами одного лісу або між доменами, пов'язаними зовнішніми або довірчими стосунками між лісами. У разі одного лісу, наприклад, ображений адміністратор або звичайний користувач, який має доступ до контролера домену, може спробувати скористатися вразливістю SIDHistory і отримати права групи Enterprise Administrators.

Запобігання атаки № 3

Для мінімізації ризиків, пов'язаних з можливістю атаки з використанням атрибута SIDHistory, в першу чергу слід особливо ретельно вибирати осіб, яким надаються права груп Enterprise Admins і Domain Admins. Необхідно також забезпечити високий рівень фізичного захисту контролерів домену, щоб ніхто не зміг відключити контролер домену від мережі і скористатися даною вразливістю.

Для запобігання редагування атрибута SIDHistory адміністратором можна включити фільтрацію SID для довірчих відносин між різними листами. Фільтрація SID дозволяє адміністраторам встановити карантин для свого домену. При включенні фільтрації SID контролер довіряє домену буде перевіряти, чи належать передані довіреною доменом в запиті на доступ до ресурсу дані авторизації до довіряємо доменів. У цьому випадку контролер довіряє домену буде автоматично видаляти сторонні SID, що не належать до довіряємо доменів. При цьому автоматично будуть видалені всі дані, що передаються в атрибуті SIDHistory. Іншими словами, атрибут SIDHistory і фільтрація SID є речі взаємовиключні.

Фільтрація SID введена в Windows 2000 SP2 і реалізована в наступних версіях. Для включення або відключення цього режиму можна скористатися утилітою командного рядка netdom.exe. Щоб увімкнути фільтрування SID в Windows 2000, слід скористатися параметрами trust і filtersids, як описано в статті бази знань Microsoft «MS02-001: Forged SID could result in elevated privileges in Windows 2000», доступною за адресою http://support.microsoft.com/?kbid=289243 . У Windows 2003 будуть використовуватися установки trust і quarantine, причому за замовчуванням фільтрація SID включена для зовнішніх відносин і довірчих відносин між лісами.

Не слід використовувати фільтрацію SID для довірчих відносин всередині лісу, оскільки вона призведе в цьому випадку до розриву реплікації AD і транзитивних довірчих відносин. Якщо потрібно використовувати карантин для певного домену, потрібно помістити його в окремий ліс.

Атака № 4. Виклики відмови в обслуговуванні (DoS) при масовому створенні об'єктів AD

Користувач, що володіє правами адміністратора, може провести DoS-атаку на домен AD шляхом створення великої кількості об'єктів AD. Авторизований користувач може, наприклад, вивести сервер AD з ладу, створивши таку кількість об'єктів, що на сервері буде вичерпано дисковий простір. Інший тип атаки - авторизований користувач може виконати додавання кількох тисяч учасників до групи, виконавши всього одну команду додавання.

Запобігання атаки № 4

Для захисту від атак такого роду необхідно гранично обережно надавати права створення об'єктів AD. Слід також використовувати квоти об'єктів AD. Цей механізм з'явився тільки в Windows 2003, але і в Windows 2000 були деякі засоби, що дозволяють встановити обмеження на об'єкти.

Квоти об'єктів AD дозволяють обмежити число об'єктів, що належать принципалу безпеки в контексті іменування AD або розділі каталогу. Квотування об'єктів AD може налаштовуватися індивідуально для кожного контексту іменування або розділу, але не можна визначити квоти для контексту іменування схеми. Можна задати квоту за замовчуванням для кожного контексту іменування і розділу; якщо ж цього не зробити, квота за замовчуванням буде без обмежень.

Мітки на видалення об'єктів (tombstone) AD, що належать принципалу безпеки, витрачають квоту даного принципала. Мітки на видалення є тимчасові об'єкти AD, створювані при видаленні об'єкта AD. AD використовує їх для підтримання цілісності даних, що належать віддаленим об'єктам на контролерах домену. Для кожного контролера і розділу можна задати ваговий коефіцієнт, з яким мітка враховується при розрахунку витрачання квоти. Так, якщо коефіцієнт в даному розділі або контексті іменування встановлений рівним 25, то мітки на видалення будуть враховуватися з коефіцієнтом 0,25. За замовчуванням коефіцієнт дорівнює 100, т. Е. Мітки на видалення враховуються так само, як і звичайні об'єкти.

Можна призначити квоти для кожного принципала безпеки - облікового запису користувача, комп'ютера, групи, а також принципалів inetOrg-Person. Принципалу може відповідати безліч квот, наприклад, може бути призначена квота облікового запису користувача, при цьому користувач може входити в групу безпеки, якої в свою чергу призначена інша квота. В цьому випадку квота принципала буде дорівнює максимальної із застосовуваних квот. На членів груп Domain Admins і Enterprise Admins квотування не поширюється.

Квоти об'єктів AD зберігаються в контейнері NTDS Quotas контексту іменування AD як об'єкти класу msDS-QuotaControl. Щоб для користувача Joe в домені Accounting встановити квоту AD дорівнює 10, слід ввести наступну команду Dsadd:

Dsadd quota -part DC = Accounting, DC = COM -acct AccountingJoe -qlimit 10 -desc "Quota for Joe"

Для встановлення коефіцієнта квоти для міток на видалення в домені Accounting рівним 25 використовується команда Dsmod:

Dsmod partition DC = Accounting, DC = COM -qtmbstnwt 25

Щоб встановити квоту об'єктів за замовчуванням в домені Accounting рівною 0, використовується команда:

Dsmod partition DC = Accounting, DC = COM -qdefault 0

Встановлювати квоти може тільки контролер домену, який працює під Windows 2003. Квоти застосовуються лише при виконанні операцій над каталогом, але не при операціях реплікації. Для ефективного використання квот об'єктів AD в розділі домену необхідно, щоб всі контролери домену працювали під Windows 2003 (іншими словами, всі домени і ліс повинні бути Windows 2003 з рівнем функціональності 2). Зверніть увагу, що можливість використання квотування об'єктів AD не пов'язана з рівнем функціональності і буде працювати на будь-якому контролері домена з Windows 2003. Якщо в домені Windows 2003 визначені квоти і при цьому ще є контролери Windows 2000, користувачі зможуть обійти обмеження квотування завдяки старим контролерам домену .

У Windows 2000 підтримується досить обмежена модель квотування - адміністратори можуть обмежити кількість облікових записів комп'ютерів, створюваних одним користувачем. Для цього використовується атрибут ms-DS-MachineAccountQuota об'єкта домену AD. У Windows 2000 квотування не поширюється на членів адміністративних груп Domain Admins і Account Operators. Атрибут ms-DS-MachineAccountQuota підтримується в Windows 2003 (має значення за замовчуванням, рівне 10). Щоб заборонити користувачам додавати облікових записів комп'ютерів, слід зробити цей атрибут рівним 0.

Аналогічного ефекту можна домогтися, відібравши право Add worksttions to domain у групи Authenticated Users (за замовчуванням це право надається групі Authenticated Users і в Windows 2003, і ​​в Windows 2000).

АТАКА № 5. Відмова в обслуговуванні (DoS-атака) з використанням уразливості MaxTokenSize

Розробники Microsoft розширили базовий протокол Kerberos, щоб дозволити включення до аутентифікаційний квиток Kerberos даних авторизації. Квитки Windows Kerberos і TGT (Ticket Granting Ticket) містять спеціальне поле PAC (Privilege Attribute Certificate), що дозволяє протоколу Kerberos передавати всередині квитка аутентифікації дані авторизації, наприклад права і членство користувача в групах.

Квиток Kerberos має фіксований розмір, що в свою чергу обмежує і розмір PAC. Якщо користувач є членом великої кількості груп (скажімо, більше 100), обсяг даних може перевищити надається квитком розмір, що може привести до відмови в аутентифікації Windows або збою обробки групових політик. Користувачі, що володіють в AD правами створення і зміни груп, можуть скористатися цією вразливістю для організації DoS-атаки на облікові записи адміністраторів. В результаті такої атаки адміністратори не зможуть реєструватися в мережі.

Запобігання атаки № 5

Для запобігання описаної атаки слід в першу чергу з особливою обережністю підходити до делегування адміністративних повноважень управління групами AD. Необхідно також максимально обмежити членство в адміністративних групах. Налаштування дозволів AD за замовчуванням ускладнюють подібне розмежування, оскільки у разі делегування адміністративних прав «довіреною» адміністраторам не потрібні додаткові дозволи для додавання будь-яких облікових записів користувачів в локальні і універсальні групи, правами на управління якими ці адміністратори мають. Тому облікові записи Enterprise Administrator і Domain Administrators слід помістити в окрему організаційну одиницю, причому делеговані адміністратори не повинні мати право читання цієї організаційної одиниці

Крім того, є можливість налаштування розміру квитка Kerberos за допомогою параметра реєстру HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ControlLsaKerberosParametersMaxTokenSize. Використання параметра Max TokenSize описано в статті бази знань Microsoft «New resolution for problems that occur when users belong to many groups» за адресою http://support.microsoft.com/?kbid=327825 ).

Параметр MaxTokenSize (REG_DWORD) повинен бути налаштований на всіх комп'ютерах, де користувачі задіють протокол Kerberos для реєстрації в домені. У Windows 2000 за замовчуванням розмір MaxTokenSize дорівнює 8000 байт. У Windows 2000 SP2 і пізніших версіях розмір MaxTokenSize збільшений до 12 000 байт.

Для скорочення розміру PAC Microsoft починаючи з Windows 2000 SP4 використовує новий спосіб зберігання даних авторизації в PAC. Коротко новий спосіб зберігання даних авторизації можна описати таким чином.

• Для локальних груп, а також для груп з інших доменів весь SID групи (т. Е. -1-5-21-1275210071-789336058-1957994488-3140) зберігається в PAC.
• Якщо глобальна або універсальна група, в яку входить користувач, - локальна для домену, членом якого даний користувач є, зберігається тільки відносний ідентифікатор групи (RID), т. Е. 3140.

Під час авторизації Windows використовує спеціальний алгоритм перетворення RID назад в формат SID на стороні клієнта і на стороні сервера. Слід мати на увазі, що необхідність настройки значення MaxTokenSize може виникнути навіть на тих платформах, де використовується новий метод зберігання даних PAC в квитку авторизації. Альтернативний спосіб - обмежити число груп, членами яких можуть бути користувачі.

Для скорочення вимог до розміру поля PAC в квитку Kerberos слід видалити атрибут SIDHistory з облікових записів AD. Цей атрибут виникає при перенесенні облікових записів домену Windows NT 4 в середу Windows 2003 або Windows 2000. Процедура видалення SIDHistory досить докладно розглядається в статті бази знань Microsoft «How To Use Visual Basic Script to Clear SidHistory» за адресою http://support.microsoft.com/?kbid=295758 .

Для боротьби з проблемами недостатнього розміру квитка Kerberos розробники Microsoft створили утиліту Tokensz, яка доступна для завантаження зі сторінки http://www.microsoft.com/downloads/details.aspx?familyid=4a303fa5-cf20-43fb-9483-0f0b0dae265c&displaylang=en . Наведена нижче команда дозволяє визначити поточне значення MaxTokenSize і розмір поточного квитка.

tokensz / compute_tokensize / package: negotiate / use_delegation / target_server:

Додаткові відомості про використання Tokensz можна знайти в статті «Troubleshooting Kerberos Errors» за адресою http://www.microsoft.com/downloads/details.aspx?familyid=7dfeb015-6043-47db-8238-dc7af89c93f1&displaylang=en

По всіх фронтах

Описані в цій статті атаки підкреслюють важливість багаторівневого підходу до забезпечення захисту інфраструктури AD. Крім технологічних аспектів і рішень, необхідно подбати про заходи фізичної безпеки і організаційних процедурах. Важливо забезпечити захист від несанкціонованого фізичного доступу контролерів домену, мережевої інфраструктури і будівель своєї організації. Організаційні заходи включають в себе розробку політик безпеки, операційних процедур, регулярне виконання аудиту безпеки інфраструктури AD із залученням незалежних фахівців, а також постійне навчання адміністраторів і користувачів заходам безпеки і аналіз передового досвіду. Забезпечення захисту AD - одна з найважливіших задач, для вирішення якої слід створити команду професіоналів, які подбають про технічну, фізичну і організаційної захисту.