TL;DR

• Нова техніка обходу механізму Device-Bound-Protection у браузерах на базі Chromium (зокрема, в Edge)

Терміни

• App-Bound Protection (Захист прив'язки до програми): Шифрує куки, прив'язуючи їх до програми, яка їх створила, що перешкоджає несанкціонованому доступу з інших програм.
• Device-Bound Protection (Захист прив'язки до пристрою): Прив'язує сесійні куки до конкретного пристрою за допомогою криптографічних ключів, забезпечуючи їх використання лише на цьому пристрої.
• OAuth 2.0 Authorization Code Flow (Потік коду авторизації OAuth 2.0): Безпечний процес, за якого код, виданий сервером, обмінюється на токени доступу та оновлення.
• Remote Debugging (Віддалене налагодження) (Функція в браузерах на базі Chromium): Дозволяє здійснювати зовнішнє керування процесами браузера для налагодження або захоплення куків під час виконання.
• Burp Suite: Інструмент для забезпечення веб-безпеки, що дозволяє перехоплювати, змінювати та аналізувати HTTP-трафік та процеси автентифікації.
• COM (Component Object Model): Архітектура для забезпечення міжпроцесної комунікації та повторного використання об'єктів в Windows.
• Chromium: Проект відкритого коду для веб-браузерів, на основі якого побудовані такі популярні браузери, як Chrome та Edge.

Вступ

Усе почалося з ідеї записати навчальне відео для YouTube про крадіжку куків та зробити його цікавішим, поцупивши куки глобального адміністратора за допомогою облікових даних користувача домену. Використовуючи найбільш відомі методи, я зрозумів, що більшість із них вже не працюють, а ті, що все ще працюють, не підходять для облікових записів Microsoft і Google. Засмучений і з бажанням записати відео (я вже створив ескіз!) я занурився в пошуки і зрозумів, як обійти захисти, реалізовані в Chromium (або Edge).

Відомі захисти в Chromium

Досліджуючи захисти, опубліковані в Chromium, я знайшов два, які могли б заблокувати мої старі методи крадіжки куків:

• App-Bound Protection (Захист прив'язки до програми): Ця функція забезпечує надійне прив'язування куків до системи, до якої вони належать, шифруючи їх таким чином, що тільки браузер Chrome на цій системі може їх розшифрувати.

В Chrome 127 ми вводимо новий захист на Windows, який покращує DPAPI, забезпечуючи Application-Bound (App-Bound) шифрування. Тепер Chrome може шифрувати дані, прив'язані до ідентичності програми, подібно до того, як працює Keychain на macOS. — Google Security Blog

Архітектура захисту прив'язки до програми

• Device-bound protection (Захист прив'язки до пристрою) — це функція безпеки, що запобігає крадіжці куків, гарантуючи, що сесійні куки можуть використовуватись лише на тому пристрої, на якому вони були створені. Це досягається шляхом прив'язки сесії до унікальної пари криптографічних ключів, що генеруються і зберігаються на пристрої користувача. Коли користувач входить на сайт, браузер створює пару публічний/приватний ключ, причому приватний ключ зберігається в захищеному апаратному модулі, наприклад, в Trusted Platform Module (TPM). Сервер пов'язує сесію з публічним ключем і вимагає підтвердження володіння приватним ключем для валідації сесії.

Обхід захисту прив'язки до програми

Щоб зрозуміти, як працює захист прив'язки до програми, я почав з вивчення робочих POC для обходу, таких як:
https://github.com/xaitax/Chrome-App-Bound-Encryption-Decryption?tab=readme-ov-file

Було одне питання з цим інструментом — він вимагав, щоб локальний адміністратор помістив інструмент у правильну папку.

Інструмент працював чудово (для локальних адміністраторів), але жодна стаття не пояснювала, як саме працює цей інструмент.
So I had to dig further.

Досліджуючи код, автор використав специфічний COM-об'єкт під назвою “Elevator”, який вперше був виявлений у коді тут.

У офіційному репозиторії Chromium (Open Source Project) можна знайти IDL (конфігураційний файл COM-сервера і клієнта) тут:
https://chromium.googlesource.com/chromium/src/+/master/chrome/elevationservice/elevationservice_idl.idl

Аналізуючи файл IDL, я з'ясував, що компонент COM “Elevator” перевіряє адміністративні права через просту перевірку. Зокрема, він перевіряє, що виконуваний файл, який використовується для розшифровки даних, знаходиться в тій самій директорії, де виконувалося шифрування. Ця директорія повинна мати адміністративні права для проходження перевірки.

Висновок — захист прив'язки до програми не є проблемою, якщо ми маємо права адміністратора. Але в нашому випадку ми повинні отримати куки без прав адміністратора.

Повернення до початкових розробок

Моє початкове дослідження було зосереджено на пошуку методу для користувача без прав адміністратора вкрасти куки. Однак поточні техніки обходу захисту прив'язки до програми виявилися неефективними для цієї ситуації. Тому я вирішив досліджувати глибше.

Тоді я натрапив на наступну статтю:

Стаття від Bleeping Computer

У статті йшлося про кілька Infostealers, які активно намагаються обійти функцію захисту прив'язки до програми. Також була наведена цікава хронологія від Elastic Labs, яка показує еволюцію таких технік з часом:

Хронологія Infostealers, які працюють з захистом App-Bound

Одна техніка, яка одразу привернула мою увагу, це “віддалене налагодження” (remote debugging), яку використовує шкідливе ПЗ під назвою “PHEMEDRONE”. Що робить її особливою, так це те, що вона працює без необхідності мати права адміністратора, що робить її унікальною і надзвичайно тривожною.

Навчання у "поганих хлопців"

Бажаючи дізнатися більше про PHEMEDRONE, я знайшов наступну статтю від Elastic Labs:

[

Katz and Mouse Game: MaaS Infostealers Adapt to Patched Chrome Defenses - Elastic Security Labs

Elastic Security Labs розбирає реалізації обходу в екосистемі infostealer після патчів Chrome 127…

www.elastic.co

](https://www.elastic.co/security-labs/katz-and-mouse-game?source=post_page-----bc641cc76477--------------------------------)

Після зворотного інженерії PHEMEDRONE, Elastic Labs знайшли наступний код PHEMEDRONE:

Взято з статті Elastic Labs

Здається досить просто. Крім того, є стаття, опублікована на Embrace The Red, яка детально описує, як ми можемо використати цю техніку для збору куків:

[

Pivot to the Clouds: Cookie Theft in 2024 · Embrace The Red

Нещодавно Google опублікував блог про виявлення крадіжки даних з браузера за допомогою Windows Event Logs. Є деякі хороші…

embracethered.com

](https://embracethered.com/blog/posts/2024/cookie-theft-in-2024-and-what-todo/?source=post_page-----bc641cc76477--------------------------------)

І це все? Не зовсім.

Захоплений і дуже мотивований, я заглибився у метод віддаленого налагодження з метою створення захоплюючого відео для YouTube під назвою “Як вкрасти куки від Azure Global Admin — Спрощено”. Спочатку я досяг успіху у витягуванні куків з таких платформ, як GitHub і WhatsApp, що підвищило мою впевненість.
However, a significant challenge arose when my primary objective — stealing Microsoft cookies — ultimately failed.

Чому ж? Привіт, Device-Bound Protection.

Захист сесій, прив'язаних до пристрою

Під час аналізу того, чому передача поточних куків не вдалася на платформах, таких як Microsoft і Google, я виявив додатковий рівень захисту, спрямований на запобігання крадіжці куків. Поглиблений аналіз показав, що цей механізм є Device-Bound Protection. Детальне технічне пояснення того, як цей захист працює, можна знайти в офіційній документації Chromium;

[

Боремося з крадіжкою куків за допомогою сесій, прив'язаних до пристрою

Куки — маленькі файли, які створюються сайтами, які ви відвідуєте, — є основою сучасного вебу. Вони роблять ваш досвід в Інтернеті…

blog.chromium.org

](https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html?source=post_page-----bc641cc76477--------------------------------)

[

dbsc/README.md at main · WICG/dbsc

Зробіть внесок у розвиток WICG/dbsc, створивши акаунт на GitHub.

github.com

](https://github.com/WICG/dbsc/blob/main/README.md?source=post_page-----bc641cc76477--------------------------------#browser-initiated-refreshes)

Поглиблене вивчення цього захисту показало, що Device-Bound Protection є причиною, чому я не можу отримати куки Microsoft з браузера Edge.

Глибше занурення

Використовуючи Burp Suite як проксі-сервер для перехоплення, я ініціював вхід до Microsoft через браузер Edge на хості, де обліковий запис Microsoft уже був автентифікований. Я систематично аналізував HTTP-заголовки відповідно до документації Chromium на GitHub, зокрема шукав відповідні заголовки, які могли б надати інформацію про процес автентифікації;

• Sec-Session-Registration
• Sec-Session-Challenge
• Sec-Session-Id

На жаль, жоден запит або відповідь не містили згаданих заголовків.

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

Давайте розглянемо цей цікавий запит

Endpoint :

GET /oauth20_authorize.srf?scope=openid+profile+email+offline_access  
 &response_type=code  
 &client_id=51497842-085c-4d86-bf88-cf50c7252078  
 &response_mode=form_post  
 &redirect_uri=https%3a%2f%2flogin.microsoftonline.com%2fcommon%2ffederation%2foauth2msa  
 &state=...  
 &estsfed=1  
 &uaid=c26ed6ab80bd46311c981213adc8f924  
 &cobrandid=ed5d1994-9544-4e70-8f68-5ee5e35afbef  
 &fci=c44b4083-3bb0-49c1-b47d-974e78cbdf3c  
 &username=  
 &login_hint=

• Контекст: Цей запит є частиною потоку входу Microsoft через OAuth 2.0.
• Scopes: openid, profile, email, offline_access. Це вказує на те, що запит шукає ID токен (openid), базову інформацію про профіль, електронну адресу та refresh token (offline_access).
• Response Type: code вказує на те, що використовується потік авторизації OAuth 2.0 (Authorization Code Flow), який є більш безпечним та поширеним підходом.
• Redirect URI: Потік зрештою перенаправить назад на login.microsoftonline.com/...
• State Parameter: Дуже великий і, ймовірно, закодований Base64/URL або обфускований іншим чином. Використовується для збереження стану додатку, запобігання CSRF і для обробки обміну після входу.

Оскільки запит шукає Refresh Token, це означає, що цей запит є першою частиною потоку OAuth 2.0.

Cookies:

CAW cookie :

CAW cookie є зашифрованим представленням Primary Refresh Token (PRT).
The PRT is a key component in Microsoft’s authentication framework, facilitating Single Sign-On (SSO) across various applications and services.

Розуміння кука CAW та PRT:

• CAW Cookie: Цей кук містить зашифровану версію PRT, що забезпечує безпеку токена під час передачі та зберігання. Шифрування запобігає несанкціонованому доступу до вмісту токена, зберігаючи цілісність процесу автентифікації.
• Primary Refresh Token (PRT): PRT — це JSON Web Token (JWT), що видається користувачу на конкретному пристрої. Він містить заяви, подібні до стандартних refresh токенів, а також специфічні для пристрою заяви, такі як Device ID. PRT дозволяє безперешкодно отримувати доступ до ресурсів без необхідності частої повторної автентифікації. Він використовується такими компонентами, як Microsoft Entra CloudAP plugin та Microsoft Entra WAM plugin для запиту access токенів для застосунків, забезпечуючи SSO на пристроях Windows 10 або новіших.

DIDC & DIDCL

Device ID Cookie (DIDC) зберігає інформацію про пристрій, який використовується для автентифікації. Це допомагає розпізнавати довірені пристрої та може спростити процес автентифікації, зменшуючи потребу в додаткових етапах перевірки на відомих пристроях. Дані зашифровані, і, ймовірно, використовується nonce для

Подібно до DIDC, Device ID Cookie Long-term (DIDCL) зберігає інформацію про пристрій, але призначений для довгострокового використання. Він допомагає в постійному розпізнаванні пристроїв між сесіями, покращуючи користувацький досвід, зменшуючи кількість повторних запитів на автентифікацію на знайомих пристроях.

Це відкриття було особливо цікавим, оскільки воно вказувало на те, що цей запит може бути фактичним впровадженням захисту Device-Bound Protection у Edge від Microsoft.

(Деталі інших куків опускаю — вони не мають відношення до нашого дослідження.)

Розуміння нашої проблеми

Тепер, коли ми розуміємо, що одним з основних компонентів механізму автентифікації Microsoft є зашифрований кук PRT (CAW), і з урахуванням попереднього дослідження атаки Pass The PRT, ми знаємо, що потік автентифікації має сильний захист. Так чому ж просто не вкрасти куки CAW, DIDC і DIDCL?

Ось у чому суть: ці куки генеруються в реальному часі під час процесу автентифікації. Зокрема, коли браузер (в даному випадку Edge) ініціює запит на автентифікацію з такими сайтами, як Azure, процес залежить від кука PRT для шифрування та дешифрування.

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

Але як це зробити?

Ми можемо скористатися автоматичним процесом входу Edge, просто перейшовши на сайт. Для цього нам потрібно лише налаштувати наш скрипт для крадіжки куків у режимі розробника, додавши один аргумент і включивши невеликий затримку (sleep). Це дозволить браузеру безперешкодно пройти процес автентифікації, що полегшить захоплення відповідних куків.

Start-Process "msedge.exe" "https://outlook.com --remote-debugging-port=9222 --remote-allow-origins=* --restore-last-session"  
Start-Sleep 10

У цьому прикладі я запустив браузер Edge для відкриття Outlook. За лаштунками браузер був перенаправлений на login.microsoft.com і виконав процес автентифікації. Під час цього процесу був отриманий PRT, створені зашифровані куки, і ці куки були передані Microsoft. В результаті браузер отримав сесійні куки Microsoft — куки, які не захищені Device-Bound Protection.

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

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

https://github.com/OGcyberfischer/CookieFisch

Перекладено з: Breaking Through Chromium Protections