hacktricks/pentesting-web/oauth-to-account-takeover.md

OAuth до захоплення облікового запису

{% hint style="success" %} Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Підтримайте HackTricks

• Перевірте плани підписки!
• Приєднуйтесь до 💬 групи Discord або групи Telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
• Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на GitHub.

{% endhint %}

{% embed url="https://websec.nl/" %}

Основна інформація

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 відбувається наступним чином:

1. Ви переходите на https://example.com і вибираєте кнопку “Інтегрувати з соціальними мережами”.
2. Сайт надсилає запит на https://socialmedia.com, просячи вашу авторизацію для надання доступу додатку https://example.com до ваших публікацій. Запит структурований як:

https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123

3. Вам буде представлена сторінка згоди.
4. Після вашого схвалення, Соціальна Медіа надсилає відповідь на redirect_uri з параметрами code та state:

https://example.com?code=uniqueCode123&state=randomString123

5. https://example.com використовує цей code, разом із своїм client_id та client_secret, щоб зробити запит на стороні сервера для отримання access_token від вашого імені, що дозволяє доступ до дозволів, на які ви погодилися:

POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}

6. Нарешті, процес завершується, коли https://example.com використовує ваш access_token для виконання API виклику до Social Media для доступу

Вразливості

Відкритий redirect_uri

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. Ці деталі можуть допомогти в ідентифікації кінцевої точки реєстрації та інших специфікацій конфігурації сервера.

XSS в реалізації редиректу

Як згадано в цьому звіті про баги https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html, можливо, що URL редиректу відображається у відповіді сервера після аутентифікації користувача, будучи вразливим до XSS. Можливий корисний вантаж для тестування:

https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>

CSRF - Неправильна обробка параметра state

У реалізаціях OAuth неправильне використання або пропуск параметра state може значно підвищити ризик атак Cross-Site Request Forgery (CSRF). Ця вразливість виникає, коли параметр state або не використовується, використовується як статичне значення, або не перевіряється належним чином, що дозволяє зловмисникам обходити захист від CSRF.

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

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

Належна обробка та перевірка параметра state є критично важливими для захисту від CSRF та забезпечення безпеки потоку OAuth.

Перед взломом облікового запису

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

Розкриття секретів

Визначення та захист секретних параметрів OAuth є критично важливими. Хоча client_id можна безпечно розкривати, розкриття client_secret несе значні ризики. Якщо client_secret буде скомпрометовано, зловмисники можуть скористатися ідентичністю та довірою додатка, щоб вкрасти access_tokens користувачів та приватну інформацію.

Загальна вразливість виникає, коли додатки помилково обробляють обмін авторизаційного code на access_token на стороні клієнта, а не на стороні сервера. Ця помилка призводить до розкриття client_secret, що дозволяє зловмисникам генерувати access_tokens під виглядом додатка. Більше того, через соціальну інженерію зловмисники можуть підвищити привілеї, додаючи додаткові області до авторизації OAuth, ще більше експлуатуючи довірений статус додатка.

Брутфорс секрету клієнта

Ви можете спробувати брутфорсити client_secret постачальника послуг з ідентифікатором постачальника, щоб спробувати вкрасти облікові записи.
Запит на BF може виглядати приблизно так:

POST /token HTTP/1.1
content-type: application/x-www-form-urlencoded
host: 10.10.10.10:3000
content-length: 135
Connection: close

code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce]

Referer Header leaking Code + State

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

Access Token Stored in Browser History

Перейдіть до історії браузера і перевірте, чи збережено там токен доступу.

Everlasting Authorization Code

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

Authorization/Refresh Token not bound to client

Якщо ви можете отримати код авторизації і використати його з іншим клієнтом, то ви можете захопити інші акаунти.

Happy Paths, XSS, Iframes & Post Messages to leak code & state values

Перевірте цей пост

AWS Cognito

У цьому звіті про баг-баунті: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ ви можете побачити, що токен, який AWS Cognito повертає користувачу, може мати достатньо прав для перезапису даних користувача. Тому, якщо ви можете змінити електронну пошту користувача на іншу електронну пошту, ви можете захопити акаунти інших.

# Read info of the user
aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]

# Change email address
aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ[...] --user-attributes Name=email,Value=imaginary@flickr.com
{
"CodeDeliveryDetailsList": [
{
"Destination": "i***@f***.com",
"DeliveryMedium": "EMAIL",
"AttributeName": "email"
}
]
}

For more detailed info about how to abuse AWS cognito check:

{% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum" %}

Abusing other Apps tokens

Як зазначено в цьому звіті, OAuth потоки, які очікують отримати токен (а не код), можуть бути вразливими, якщо не перевіряють, що токен належить додатку.

Це пов'язано з тим, що зловмисник може створити додаток, що підтримує OAuth і входити через Facebook (наприклад) у своєму додатку. Потім, коли жертва входить через Facebook у додатку зловмисника, зловмисник може отримати OAuth токен користувача, наданий його додатку, і використовувати його для входу в OAuth додаток жертви, використовуючи токен користувача жертви.

{% hint style="danger" %} Отже, якщо зловмисник зможе отримати доступ користувача до свого OAuth додатку, він зможе захопити обліковий запис жертви в додатках, які очікують токен і не перевіряють, чи був токен наданий їхньому ID додатку. {% endhint %}

Two links & cookie

Згідно з цим звітом, було можливо змусити жертву відкрити сторінку з returnUrl, що вказує на хост зловмисника. Ця інформація буде збережена в cookie (RU), а на пізнішому етапі підказка запитає користувача, чи хоче він надати доступ до цього хосту зловмисника.

Щоб обійти цю підказку, було можливо відкрити вкладку для ініціювання Oauth потоку, яка встановить цей RU cookie, закрити вкладку до того, як з'явиться підказка, і відкрити нову вкладку без цього значення. Тоді підказка не повідомить про хост зловмисника, але cookie буде встановлено на нього, тому токен буде надіслано на хост зловмисника під час редиректу.

Prompt Interaction Bypass

Як пояснено в цьому відео, деякі реалізації OAuth дозволяють вказати параметр prompt GET як None (&prompt=none), щоб запобігти запитам до користувачів на підтвердження наданого доступу в підказці на веб-сторінці, якщо вони вже увійшли на платформу.

response_mode

Як пояснено в цьому відео, можливо вказати параметр 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...

SSRFs parameters

Перевірте це дослідження Для подальших деталей цієї техніки.

Динамічна реєстрація клієнтів у 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 providers Race Conditions

Якщо платформа, яку ви тестуєте, є постачальником OAuth прочитайте це, щоб перевірити можливі Race Conditions.

References

• https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1
• https://portswigger.net/research/hidden-oauth-attack-vectors

{% embed url="https://websec.nl/" %}

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!
• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}