Як працює протокол Kerberos для тестування на проникнення: просто про складне (Частина 1)

Розглядається теоретична основа протоколу Kerberos, який використовується для аутентифікації в комп’ютерних мережах. Ви дізнаєтьсь, як працює цей протокол, які основні етапи його функціонування, а також специфіку застосування в середовищі Active Directory. Окрім цього, стаття розкриває можливі вразливості Kerberos і пояснює, як тестувальники на проникнення можуть використовувати їх під час оцінювання безпеки систем.

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

Вступ

Екскурс. Короткий та історичний

Протокол Kerberos був створений у MIT як частина проекту «Афіна», що мав на меті розробку розподіленого освітнього середовища. До 1988 року проект досяг своїх цілей, і було опубліковано опис протоколу Kerberos v4, який став основою системи єдиного входу для цього середовища. Ранні версії 1-3 були прототипами та не знайшли застосування за межами MIT.

У 1989 році відбувся офіційний випуск Kerberos v4, але протокол все ще потребував удосконалення. Основними його недоліками були слабкі криптографічні алгоритми, архітектурні уразливості, що дозволяли здійснювати офлайн-атаки на паролі, а також відсутність підтримки делегування облікових даних і використання додаткових факторів автентифікації.

Для вирішення цих проблем у 1993 році було випущено оновлену версію протоколу — Kerberos v5. Згодом, у 1999 році, компанія Microsoft оголосила про інтеграцію Kerberos v5 у свою нову операційну систему Windows 2000, що стало важливим етапом у розвитку Active Directory. До цього для аутентифікації у робочих групах Windows використовувався протокол NT LAN Manager (NTLM), одна з удосконалених версій якого — NTLM v2 — досі застосовується для локальної аутентифікації у сучасних системах. Однак цей протокол також мав певні недоліки, які вдалося вирішити з появою Kerberos v5 у Windows 2000.

Сьогодні, попри свій вік, Kerberos v5 активно використовується у багатьох системах, не лише в Active Directory. Ось деякі з них:

• Amazon Web Services

• Apple macOS

• Google Cloud

• Microsoft Azure

• Oracle Solaris

• Red Hat Linux

У цій статті далі розглядатиметься саме версія Kerberos v5, яку для зручності буде названо просто Kerberos.

Вимоги до протоколу Kerberos

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

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

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

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

• Повинна підтримуватись технологія єдиного входу (Single Sign-On). Це обмеження обумовлено тим, що користувачу незручно щоразу при зверненні до ресурсу заново вводити пароль.

• Успішне закінчення роботи протоколу має означати успішну взаємну автентифікацію сторін.

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

Список термінів

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

• Kerberos – насамперед протокол аутентифікації, але при цьому передбачає можливість транспортування інформації, необхідної для авторизації.

Важливо не плутати:

1. Аутентифікація – процес автентифікації. Тобто перевірка того, що користувач, який намагається отримати доступ до системи, саме той, за кого себе видає.

2. Авторизація – процес перевірки прав доступу. Авторизація може бути застосована тільки до автентифікованого користувача, оскільки перед тим, як перевіряти права доступу, необхідно з’ясувати особу об’єкта, якому зазначені права планується надати.

• Сервер – мережевий об’єкт, який би функціонування однієї чи кількох сервісів. Приклади сервера: файловий сервер, поштовий сервер.

• Клієнт – об’єкт, який звертається до сервісу з отримання доступу до ресурсам. Приклади клієнтів: обліковий запис чи робоча станція користувача.

• Область дії ( Realm ) – сукупність клієнтів, серверів та сервісів, що у протоколі Kerberos.

• Принципал ( Principal ) – це рядок, що повністю ідентифікує учасника протоколу Kerberos.

Принципал може бути або ім’ям сервісу (Service Principal Name), або ім’ям клієнта (User Principal Name). Формати принципалів для клієнтів та сервісів мають певні відмінності.

Формат принципала клієнта

Принципал клієнта має вигляд:

principal-name[/instance-name]@REALM

• Якщо ім’я користувача – Ivan, а область дії – DOMAIN.LOCAL, повний принципал буде:[email protected]

• Розширення instance-name є опціональним. Воно дозволяє одному користувачу мати кілька різних принципалів.Наприклад, якщо Ivan є адміністратором у DOMAIN.LOCAL, його принципал буде: Ivan/[email protected] Такий принципал матиме окремі права доступу.

Формат принципала сервісу

Принципал сервісу має форму:

service-name/host[:port]@REALM

• service-name – унікальний рядок, що ідентифікує сервіс на хості.

• host – доменне ім’я хоста, де працює сервіс.

• port – порт, на якому запущено службу (може бути опущений).

Приклад: Для сервісу ftp, який працює на хості fileserver.example.com у домені @EXAMPLE.COM, принципал буде:

ftp/[email protected]

Використання принципалів для ідентифікації

Kerberos для ідентифікації сервера використовує саме принципал (ім’я), тоді як NTLM може працювати з IP-адресою.

Приклад: Є робоча станція з такими параметрами:

• DNS-ім’я: station.domain.local

• IP-адреса: 192.168.10.12

• Загальнодоступна мережна папка: scan

При відкритті провідника і переході за UNC-шляхом:

• \\station.domain.local\scan — буде використовуватися Kerberos.

• \\192.168.10.12\scan — буде використовуватися NTLM, оскільки принципал для IP-адреси не створюється.

Адміністратори часто залишають підтримку NTLM увімкненою, оскільки деяке застаріле мережеве обладнання, як-от принтери та роутери, може працювати лише зі статичними IP-адресами або зовсім не підтримувати Kerberos.

Центр розподілу ключів (KDC)

Key Distribution Center (KDC) — це довірений центр автентифікації всіх учасників протоколу Kerberos у межах певної області дії (REALM).

Основні компоненти KDC

1. База даних Kerberos. Містить інформацію про всі принципали та їхні секрети.

2. Сервер аутентифікації (Authentication Server, AS). Обробляє запити на автентифікацію клієнтів у межах області дії.

3. Сервер видачі дозволів (Ticket Granting Server, TGS). Відповідає за обробку запитів клієнтів на автентифікацію до конкретного сервісу у межах зазначеної області дії.

Проілюструємо вищезазначене наступним замальовкою:

Автентифікація за допомогою Kerberos

Почнемо від загального та перейдемо до приватного.

Розглянемо трохи вигадану, але корисну для наступних аналогій ситуацію. Уявимо парк розваг. Припустимо, що перелік дозволених відвідувачів парку міститься у спеціальній базі даних. Для тих, хто в базі відсутній прохід заборонено. Як організовано відвідування парку:

1. Відвідувач приходить на вхід та показує охоронцеві свій паспорт.

2. Охоронець перевіряє наявність відвідувача у базі даних.

3. Охоронець видає відвідувачу добовий квиток на відвідування парку.

4. Відвідувач вибирає атракціон, що йому сподобався, і йде на касу, щоб отримати квиток.

5. На касі перевіряють добовий квиток відвідувача та видають квиток на атракціон.

6. Відвідувач іде на обраний атракціон і показує наглядачеві атракціону, отриманий на касі квиток.

7. Доглядач перевіряє квиток та пропускає відвідувача.

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

Якщо відвідувач захотів піти на інший атракціон, він знову йде на касу та показує добовий квиток. Далі повторюється процес кроків 5, 6, 7 тільки з іншим доглядачем та іншим атракціоном.

По верхах у загальному вигляді

Тепер за аналогією розглянемо спрощену схему автентифікації за допомогою Kerberos:

1. Клієнт надсилає запит на автентифікацію до дії.

2. Сервер автентифікації перевіряє справжність Клієнта за допомогою Бази даних Kerberos.

3. Сервер видає Клієнту дозвіл (поки просто назвемо його TGT) на отримання окремих дозволів (далі – ST), потрібних для доступу до сервісів, що входять до області дії.

4. З використанням отриманого на кроці №3 дозволу (TGT) Клієнт запитує дозвіл на доступ до Сервісу А (ST для А).

5. Сервер видачі дозволів перевіряє TGT і видає Клієнту ST доступу до сервісу А.

6. Клієнт із використанням «ST для А» запитує у Сервісу А доступ до його ресурсів.

7. Сервіс А перевіряє ST для А і надає Клієнту доступ до своїх ресурсів. За потреби сервіс також проходить аутентифікацію перед клієнтом.

Надалі за необхідності доступу до іншого сервісу:

8. З використанням отриманого на кроці №3 дозволу (TGT) Клієнт запитує дозвіл на доступ до Сервісу Б (ST для Б).

9. Сервер видачі дозволів перевіряє TGT і видає Клієнту ST доступу до сервісу Б.

10. Клієнт із використанням «ST для Б» запитує у Сервісу Б доступ до його ресурсів.

11. Сервіс Б перевіряє ST для Б і надає Клієнту доступ до своїх ресурсів.

Видно, що сторони обмінюються повідомленнями, що містять запити та відповіді з дозволами. Офіційно формати зазначених повідомлень задокументовані RFC 4120.

Тепер переназвемо повідомлення, що передаються у відповідність з RFC:

• Запит на аутентифікацію до дії (крок 1) – повідомлення KRB_AS_REQ .

• Відповідь сервера на запит автентифікації клієнта (крок 3) – повідомлення KRB_AS_REP .

• Дозвіл на отримання дозволів – TGT ( Ticket Granting Ticket ).

Інші назви, що зустрічаються в літературі: мандат / квиток на отримання дозволів, первинне посвідчення користувача.

Примітка: у різних джерелах часто зустрічається словосполучення TGT квиток, але в абревіатурі TGT вже закладено слово квиток – Ticket Granting Ticket, тому правильніше говорити просто TGT.

• Запит на доступ до сервісу (крок 4) – повідомлення KRB_TGS_REQ .

• Відповідь сервера видачі дозволів (крок 5) – повідомлення KRB_TGS_REP .

• Дозвіл на доступ до сервісу – ST ( Service Ticket ) Інші назви, що зустрічаються: TGS квиток, квиток сервісу, мандат сервісу.

• Запит клієнта на аутентифікацію до сервісу (крок 6) – повідомлення KRB_AP_REQ .

• Опціональна відповідь з аутентифікацією сервісу перед клієнтом (крок 7) – повідомлення KRB_AP_REP .

Щоб простіше було запам’ятати:

• KRB ~ K e RB eros

• AS ~ A uthentication S erver

• REP ~ RE s P onse

• REQ ~ REQ uest

• AP ~ AP plication server

Далі кожен запит буде розібрано докладніше.

Розбір аутентифікації в Kerberos згідно RFC

На початку є три учасники протоколу Kerberos:

1. Клієнт

2. Сервіс

3. Центр розподілу ключів

Кожен із учасників має свій довготривалий секрет (ключ). Крім того, центр розподілу ключів має секрети всіх учасників.

Алгоритм формування ключа

Джерела:

• Kerberos from Hacker recipes

• A Note on Calculating Kerberos Keys для AD Accounts (snovvcrash)

Клієнт відправляє серверу автентифікації запит, що містить:

• Принципав клієнта

• Строк життя квитка

Примітка: якщо це не перший матеріал за Kerberos, який ви читаєте і виникає питання, чому відсутня попередня аутентифікація, то поясню – це додаткове налаштування протоколу, яке в «класичній» реалізації за замовчуванням відключено. У реалізації Kerberos для Active Directory, зазначене налаштування навпаки за замовчуванням активне і цей випадок буде розглянутий трохи пізніше.

KRB_AS_REP

Сервер автентифікації за отриманим принципалом знаходить у базі Kerberos секрет клієнта. Крім того, для подальшого спілкування з KDC сервер аутентифікації випадково генерує сесійний ключ. У результаті у відповідь клієнту надсилаються два повідомлення.

Перше повідомлення зашифроване з використанням секрету клієнта та містить:

• Сесійний ключ для KDC

• Мітка часу

• Термін життя TGT

Друге повідомлення (TGT) зашифроване вже з використанням (!) секрету KDC і включає в себе ті самі дані, що і перше повідомлення, але разом з принципалом клієнта.

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

Клієнт, прийнявши відповідь, може розшифрувати лише перше повідомлення. Таким чином, він отримує сесійний ключ для подальшого спілкування з KDC. TGT також зберігається у клієнта у зашифрованому вигляді.

KRB_TGS_REQ

Після успішної автентифікації клієнт надсилає запит на доступ до певного сервісу серверу видачі дозволів (TGS). Цей запит містить кілька важливих елементів:

• Принципал сервісу, до якого клієнт хоче отримати доступ.

• Аутентифікатор, що включає принципал клієнта та мітку часу, зашифровані сесійним ключем, отриманим під час автентифікації.

• TGT (Ticket Granting Ticket), виданий на попередньому етапі.

Отримавши запит, сервер видачі дозволів виконує такі дії:

1. Розшифровує TGT за допомогою секретного ключа KDC.

2. Перевіряє термін дії мітки часу в TGT, щоб переконатися, що він ще дійсний.

3. Отримує сесійний ключ із TGT. Оскільки TGT може створити та змінити лише KDC, отриманим із нього даним можна повністю довіряти, тому необхідності зберігати сесійний ключ у базі даних немає.

Захист від атак

Виникає логічне питання: як можна бути впевненим, що перехоплений зловмисником TGT не використовується повторно? Для цього використовується автентифікатор, який додається до запиту. Він зашифрований сесійним ключем, доступ до якого має лише клієнт, що успішно пройшов автентифікацію та отримав відповідь KRB_AS_REP від KDC.

Мітка часу в автентифікаторі захищає від атак повтору, унеможливлюючи використання старого автентифікатора. Сервер видачі дозволів перевіряє, що автентифікатор був створений не пізніше, ніж дві хвилини тому, а також звіряє принципали клієнта в TGT і автентифікаторі. Лише після успішного проходження всіх перевірок клієнт отримує квиток для доступу до потрібного сервісу.

KRB_TGS_REP

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

• Сесійний ключ для спілкування із сервісом

• Мітка часу

• Строк життя TGS квитка

• Принципал сервісу

Друге повідомлення (TGS квиток) зашифроване з використанням секрету сервісу і включає ті самі дані, що і перше повідомлення, а також принципал клієнта.

Клієнт, прийнявши відповідь, може розшифрувати лише перше повідомлення. Таким чином він отримує сесійний ключ для подальшого спілкування із сервісом. TGS квиток зберігається у клієнта у зашифрованому вигляді.

KRB_AP_REQ

Клієнт відправляє сервісу запит на отримання доступу, що містить:

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

• Збережений TGS квиток

• Прапор взаємної автентифікації

Прийнявши запит, сервіс насамперед виконує перевірку отриманих даних. Спочатку з використанням свого секрету сервіс розшифровує TGS (1) і за міткою часу з терміном дії переконується, що TGS не протухає (2).

TGS квиток не може бути змінений будь-ким крім того, хто знає секрет сервісу, а це KDC і сам сервіс Довіряє KDC, таким чином витягнутим з TGS квитка даним сервіс також може довіряти.

Аналогічно KRB_TGS_REQ розшифровується автентифікатор та виконуються інші перевірки. Зверніть увагу на те, що сервіс засвідчується в справжності клієнта, не звертаючись до KDC.

KRB_AP_REP

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

Kerberos у Active Directory

Щоб донести ідею, її треба розповісти тричі, але різними словами» — так і зробимо.

У Active Directory реалізація протоколу Kerberos має певні відмінності та особливості порівняно зі стандартною схемою. Спершу варто уточнити термінологію:

1. Область дії у контексті Active Directory відповідає поняттю домену.

2. Центр розподілу ключів (KDC) реалізовано на рівні контролера домену.

3. Сервер автентифікації (AS) та сервер видачі дозволів (TGS) об’єднані в один компонент, який також працює на контролері домену.

4. База даних Kerberos — це файл ntds.dit на контролері домену, де зберігається інформація про секрети користувачів.

5. krbtgt — спеціальний обліковий запис, який автоматично створюється разом із доменом і містить секретний ключ контролера домену.

Після таких уточнень структура роботи Kerberos у Active Directory стає зрозумілішою: контролер домену виступає центральною точкою автентифікації та видачі дозволів, зберігаючи всі необхідні дані про облікові записи користувачів і їхні секрети.

Хоча загальна робота Kerberos у Active Directory відповідає специфікації RFC, є деякі специфічні відмінності. Подальший розгляд цих відмінностей краще провести на конкретному прикладі, що дозволить більш наочно пояснити особливості цієї реалізації.

Доменна автентифікація користувача до робочої станції Active Directory

Спочатку на робочій станції активно наступне діалогове вікно:

Коли користувач вводить свої облікові дані (домен, ім’я користувача та пароль) і натискає “OK”, система передає запит на автентифікацію до локального центру безпеки (Local Security Authority, LSA). Цей центр керує різними динамічними бібліотеками, які забезпечують виконання операцій автентифікації, зміни паролів та видачі токенів. Усі ці бібліотеки працюють у контексті процесу lsass.exe (Local Security Authority Subsystem Service).

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

• msv1_0.dll — для NTLM

• kerberos.dll — для протоколу Kerberos

• SChannel.dll — для TLS/SSL

• WDigest.dll — для digest-автентифікації

За замовчуванням, якщо користувач входить до домену, система використовує бібліотеку kerberos.dll, що відповідає за реалізацію протоколу Kerberos.

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

У результаті маємо таку картину:

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

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

KRB_AS_REQ із попередньою автентифікацією

У цьому випадку клієнт надсилає серверу автентифікації запит, що містить:

• Принципав клієнта

• Мітка часу, зашифрована з використанням секрету клієнта

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

KRB_AS_REP (AD)

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

Ще одна важлива особливість реалізації Kerberos у Active Directory — це поле PAC (Privilege Attribute Certificate), яке додається до вмісту TGT. PAC — це набір даних, що використовується для авторизації користувача після його автентифікації.

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

У контексті Active Directory PAC містить наступну інформацію:

• Ідентифікатор безпеки (SID) користувача.

• Ідентифікатори груп, членом яких є користувач.

Ця інформація використовується для визначення рівня доступу до ресурсів. Щоб забезпечити її цілісність, PAC підписується двічі:

1. Перший підпис додається обліковим записом krbtgt, який відповідає за видачу квитків і автентифікацію.

2. Другий підпис накладається сервісом, до якого звертається клієнт. У випадку відповіді KRB_AS_REP цей підпис також належить krbtgt.

Таким чином, PAC гарантує, що інформація про права доступу користувача є достовірною і захищеною від підробок.

KRB_TGS_REQ (AD)

Запит проводиться аналогічно розглянутому раніше RFC.

KRB_TGS_REP (AD)

PAC з TGT, отриманий у попередньому повідомленні, розміщується у TGS квиток. На цей раз PAC підписується не тільки з використанням секрету krbtgt, але і секрету системи.

LOGON

З використанням сесійного ключа LSA отримує підписаний PAC з TGS квитка. LSA перевіряє підпис PAC за допомогою секрету системи і далі з урахуванням добутих з PAC доменних груп безпеки формує процес Winlogon з відповідним струменем доступу клієнта.

Опціонально система може запросити контролер домену, щоб виконати додаткову перевірку підпису з PAC за допомогою секрету krbtgt.

Підсумок

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