OAuth to Account takeover
Last updated
Last updated
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
OAuth пропонує різні версії, з основними відомостями, доступними в документації OAuth 2.0. Це обговорення в основному зосереджене на широко використовуваному типі надання авторизаційного коду OAuth 2.0, що забезпечує рамки авторизації, які дозволяють додатку отримувати доступ або виконувати дії в обліковому записі користувача в іншому додатку (сервер авторизації).
Розгляньте гіпотетичний веб-сайт https://example.com, призначений для демонстрації всіх ваших публікацій у соціальних мережах, включаючи приватні. Для цього використовується OAuth 2.0. https://example.com запитає вашу згоду на доступ до ваших публікацій у соціальних мережах. Відповідно, на https://socialmedia.com з'явиться екран згоди, що описує дозволи, які запитуються, та розробника, який робить запит. Після вашої авторизації https://example.com отримує можливість доступу до ваших публікацій від вашого імені.
Важливо зрозуміти наступні компоненти в рамках OAuth 2.0:
власник ресурсу: Ви, як користувач/суб'єкт, авторизуєте доступ до вашого ресурсу, наприклад, до публікацій у вашому обліковому записі соціальних мереж.
сервер ресурсу: сервер, що керує аутентифікованими запитами після того, як додаток отримав access token від імені власника ресурсу, наприклад, https://socialmedia.com.
клієнтський додаток: додаток, що запитує авторизацію у власника ресурсу, наприклад, https://example.com.
сервер авторизації: сервер, що видає access tokens клієнтському додатку після успішної аутентифікації власника ресурсу та отримання авторизації, наприклад, https://socialmedia.com.
client_id: Публічний, унікальний ідентифікатор для додатку.
client_secret: Конфіденційний ключ, відомий лише додатку та серверу авторизації, що використовується для генерації access_tokens.
response_type: Значення, що вказує тип запитуваного токена, наприклад, code.
scope: рівень доступу, який клієнтський додаток запитує у власника ресурсу.
redirect_uri: URL, на який користувач перенаправляється після авторизації. Це зазвичай має відповідати попередньо зареєстрованому URL перенаправлення.
state: Параметр для збереження даних під час перенаправлення користувача до та з сервера авторизації. Його унікальність є критично важливою для виконання механізму захисту від CSRF.
grant_type: Параметр, що вказує тип надання та тип токена, що повертається.
code: Авторизаційний код з сервера авторизації, що використовується разом з client_id та client_secret клієнтським додатком для отримання access_token.
access_token: токен, який клієнтський додаток використовує для API запитів від імені власника ресурсу.
refresh_token: Дозволяє додатку отримати новий access_token без повторного запиту у користувача.
Фактичний потік OAuth відбувається наступним чином:
Ви переходите на https://example.com і вибираєте кнопку “Інтегрувати з соціальними мережами”.
Сайт надсилає запит на https://socialmedia.com, просячи вашу авторизацію для надання доступу додатку https://example.com до ваших публікацій. Запит структурований як:
Вам буде представлена сторінка згоди.
Після вашого схвалення, Соціальна Медіа надсилає відповідь на redirect_uri з параметрами code та state:
https://example.com використовує цей code, разом із своїм client_id та client_secret, щоб зробити запит на стороні сервера для отримання access_token від вашого імені, що дозволяє доступ до дозволів, на які ви погодилися:
Нарешті, процес завершується, коли https://example.com використовує ваш access_token для виконання API виклику до Social Media для доступу
redirect_uri є критично важливим для безпеки в реалізаціях OAuth та OpenID, оскільки він вказує, куди надсилаються чутливі дані, такі як коди авторизації, після авторизації. Якщо він неправильно налаштований, це може дозволити зловмисникам перенаправляти ці запити на шкідливі сервери, що дозволяє захоплення облікових записів.
Методи експлуатації варіюються в залежності від логіки валідації авторизаційного сервера. Вони можуть коливатися від суворого співпадіння шляхів до прийняття будь-якого URL в межах вказаного домену або підкаталогу. Загальні методи експлуатації включають відкриті редиректи, обходи шляхів, експлуатацію слабких регулярних виразів та HTML-ін'єкції для крадіжки токенів.
Окрім redirect_uri, інші параметри OAuth та OpenID, такі як client_uri, policy_uri, tos_uri та initiate_login_uri, також підлягають атакам редиректу. Ці параметри є необов'язковими, і їх підтримка варіюється між серверами.
Для тих, хто націлений на сервер OpenID, кінцева точка виявлення (**.well-known/openid-configuration**) часто містить цінні деталі конфігурації, такі як registration_endpoint, request_uri_parameter_supported та "require_request_uri_registration. Ці деталі можуть допомогти в ідентифікації кінцевої точки реєстрації та інших специфікацій конфігурації сервера.
Як згадано в цьому звіті про баги https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html, можливо, що URL редиректу відображається у відповіді сервера після аутентифікації користувача, будучи вразливим до XSS. Можливий корисний вантаж для тестування:
У реалізаціях OAuth неправильне використання або пропуск параметра state може значно підвищити ризик атак Cross-Site Request Forgery (CSRF). Ця вразливість виникає, коли параметр state або не використовується, використовується як статичне значення, або не перевіряється належним чином, що дозволяє зловмисникам обходити захист від CSRF.
Зловмисники можуть скористатися цим, перехоплюючи процес авторизації, щоб зв'язати свій обліковий запис з обліковим записом жертви, що може призвести до потенційних взломів облікових записів. Це особливо критично в додатках, де OAuth використовується для автентифікаційних цілей.
Приклади цієї вразливості в реальному світі були задокументовані в різних CTF викликах та хакерських платформах, підкреслюючи її практичні наслідки. Проблема також поширюється на інтеграції з сторонніми сервісами, такими як Slack, Stripe та PayPal, де зловмисники можуть перенаправляти сповіщення або платежі на свої облікові записи.
Належне оброблення та перевірка параметра state є критично важливими для захисту від CSRF та забезпечення безпеки потоку OAuth.
Без перевірки електронної пошти при створенні облікового запису: Зловмисники можуть заздалегідь створити обліковий запис, використовуючи електронну пошту жертви. Якщо жертва пізніше використовує сторонній сервіс для входу, додаток може ненавмисно зв'язати цей сторонній обліковий запис з попередньо створеним обліковим записом зловмисника, що призведе до несанкціонованого доступу.
Використання слабкої перевірки електронної пошти в OAuth: Зловмисники можуть скористатися сервісами OAuth, які не перевіряють електронні адреси, зареєструвавшись у їхньому сервісі, а потім змінивши електронну пошту облікового запису на електронну пошту жертви. Цей метод також несе ризик несанкціонованого доступу до облікового запису, подібно до першого сценарію, але через інший вектор атаки.
Визначення та захист секретних параметрів OAuth є критично важливими. Хоча client_id можна безпечно розкривати, розкриття client_secret несе значні ризики. Якщо client_secret буде скомпрометовано, зловмисники можуть скористатися ідентичністю та довірою додатка, щоб вкрасти access_tokens користувачів та приватну інформацію.
Загальна вразливість виникає, коли додатки помилково обробляють обмін авторизаційним code на access_token на стороні клієнта, а не на стороні сервера. Ця помилка призводить до розкриття client_secret, що дозволяє зловмисникам генерувати access_tokens під виглядом додатка. Більше того, через соціальну інженерію зловмисники можуть підвищити привілеї, додаючи додаткові області до авторизації OAuth, ще більше експлуатуючи довірений статус додатка.
Ви можете спробувати брутфорсити client_secret постачальника послуг з ідентифікатором постачальника, щоб спробувати вкрасти облікові записи. Запит на BF може виглядати приблизно так:
Якщо клієнт має код і стан, і вони відображаються в заголовку Referer при переході на іншу сторінку, то це вразливість.
Перейдіть до історії браузера і перевірте, чи збережено там токен доступу.
Код авторизації повинен існувати лише деякий час, щоб обмежити часовий проміжок, протягом якого зловмисник може його вкрасти і використати.
Якщо ви можете отримати код авторизації і використати його з іншим клієнтом, то ви можете захопити інші акаунти.
У цьому звіті про баг-баунті: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ ви можете побачити, що токен, який AWS Cognito повертає користувачу, може мати достатньо прав для перезапису даних користувача. Тому, якщо ви можете змінити електронну пошту користувача на іншу електронну пошту, ви можете захопити акаунти інших.
Для більш детальної інформації про те, як зловживати AWS cognito, перегляньте:
Як зазначено в цьому звіті, потоки OAuth, які очікують отримати токен (а не код), можуть бути вразливими, якщо не перевіряють, що токен належить додатку.
Це пов'язано з тим, що зловмисник може створити додаток, що підтримує OAuth і входити через Facebook (наприклад) у своєму додатку. Потім, коли жертва входить через Facebook у додатку зловмисника, зловмисник може отримати OAuth токен користувача, наданий його додатку, і використовувати його для входу в OAuth додаток жертви, використовуючи токен користувача жертви.
Отже, якщо зловмисник зможе отримати доступ користувача до свого OAuth додатку, він зможе захопити обліковий запис жертви в додатках, які очікують токен і не перевіряють, чи був токен наданий їхньому ID додатку.
Згідно з цим звітом, було можливим змусити жертву відкрити сторінку з returnUrl, що вказує на хост зловмисника. Ця інформація буде збережена в cookie (RU), а на пізнішому етапі підказка запитає користувача, чи хоче він надати доступ до цього хосту зловмисника.
Щоб обійти цю підказку, було можливим відкрити вкладку для ініціювання Oauth потоку, яка встановить це RU cookie, закрити вкладку до того, як з'явиться підказка, і відкрити нову вкладку без цього значення. Тоді підказка не повідомить про хост зловмисника, але cookie буде встановлено на нього, тому токен буде надіслано на хост зловмисника під час редиректу.
Як пояснено в цьому відео, деякі реалізації OAuth дозволяють вказати параметр prompt GET як None (&prompt=none), щоб запобігти запитам до користувачів на підтвердження наданого доступу в підказці в вебі, якщо вони вже увійшли на платформу.
Як пояснено в цьому відео, можливо вказати параметр response_mode, щоб вказати, де ви хочете, щоб код був наданий у фінальному URL:
response_mode=query -> Код надається всередині GET параметра: ?code=2397rf3gu93f
response_mode=fragment -> Код надається всередині фрагменту URL параметра #code=2397rf3gu93f
response_mode=form_post -> Код надається всередині POST форми з полем введення, названим code, і значенням
response_mode=web_message -> Код надсилається в повідомленні: window.opener.postMessage({"code": "asdasdasd...
Згідно з цим блогом, це OAuth потік, який дозволяє входити в OAuth через ім'я користувача та пароль. Якщо під час цього простого потоку повертається токен з доступом до всіх дій, які може виконати користувач, то можливо обійти 2FA, використовуючи цей токен.
Цей блог коментує, як було можливим зловживати відкритим редиректом на значення з реферера, щоб зловживати OAuth для ATO. Атака була:
Жертва заходить на веб-сторінку зловмисника
Жертва відкриває шкідливе посилання, і відкривач запускає Google OAuth потік з response_type=id_token,code&prompt=none як додатковими параметрами, використовуючи реферер веб-сайт зловмисника.
В відкривачі, після того, як постачальник авторизує жертву, він повертає їх до значення параметра redirect_uri (веб-сайт жертви) з кодом 30X, який все ще зберігає веб-сайт зловмисника в реферері.
Веб-сайт жертви ініціює відкритий редирект на основі реферера, перенаправляючи користувача жертви на веб-сайт зловмисника, оскільки respose_type був id_token,code, код буде надіслано назад до зловмисника у фрагменті URL, що дозволяє йому захопити обліковий запис користувача через Google на сайті жертви.
Перевірте це дослідження Для подальших деталей цієї техніки.
Динамічна реєстрація клієнтів у OAuth є менш очевидним, але критично важливим вектором для вразливостей безпеки, зокрема для атак Server-Side Request Forgery (SSRF). Цей кінцевий пункт дозволяє OAuth серверам отримувати деталі про клієнтські додатки, включаючи чутливі URL, які можуть бути використані в атаках.
Ключові моменти:
Динамічна реєстрація клієнтів часто відображається на /register і приймає деталі, такі як client_name, client_secret, redirect_uris та URL для логотипів або JSON Web Key Sets (JWKs) через POST запити.
Ця функція відповідає специфікаціям, викладеним у RFC7591 та OpenID Connect Registration 1.0, які включають параметри, потенційно вразливі до SSRF.
Процес реєстрації може ненавмисно піддавати сервери SSRF кількома способами:
logo_uri: URL для логотипу клієнтського додатку, який може бути отриманий сервером, викликаючи SSRF або призводячи до XSS, якщо URL обробляється неналежно.
jwks_uri: URL до документа JWK клієнта, який, якщо зловмисно створений, може змусити сервер здійснити вихідні запити до сервера, контрольованого зловмисником.
sector_identifier_uri: Посилається на JSON масив redirect_uris, який сервер може отримати, створюючи можливість SSRF.
request_uris: Перераховує дозволені запитувані URI для клієнта, які можуть бути використані, якщо сервер отримує ці URI на початку процесу авторизації.
Стратегія експлуатації:
SSRF може бути ініційовано реєстрацією нового клієнта з шкідливими URL в параметрах, таких як logo_uri, jwks_uri або sector_identifier_uri.
Хоча пряма експлуатація через request_uris може бути зменшена контролем білого списку, надання попередньо зареєстрованого, контрольованого зловмисником request_uri може полегшити SSRF під час етапу авторизації.
Якщо платформа, яку ви тестуєте, є постачальником OAuth прочитайте це, щоб перевірити можливі умови гонки.
Вчіться та практикуйте Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Вчіться та практикуйте Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
