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

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

{% hint style="success" %}
Вивчайте та практикуйте AWS Hacking:<img src="../.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../.gitbook/assets/arte.png" alt="" data-size="line">\
Вивчайте та практикуйте GCP Hacking: <img src="../.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>Підтримайте HackTricks</summary>

* Перевірте [**плани підписки**](https://github.com/sponsors/carlospolop)!
* **Приєднуйтесь до** 💬 [**групи Discord**](https://discord.gg/hRep4RUj7f) або [**групи Telegram**](https://t.me/peass) або **слідкуйте** за нами в **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Діліться хакерськими трюками, надсилаючи PR до** [**HackTricks**](https://github.com/carlospolop/hacktricks) та [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) репозиторіїв на GitHub.

</details>
{% endhint %}

<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>

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

## Основна інформація <a href="#d4a8" id="d4a8"></a>

OAuth пропонує різні версії, з основними відомостями, доступними в [документації OAuth 2.0](https://oauth.net/2/). Це обговорення в основному зосереджене на широко використовуваному [типі надання авторизаційного коду OAuth 2.0](https://oauth.net/2/grant-types/authorization-code/), що забезпечує **рамки авторизації, які дозволяють додатку отримувати доступ або виконувати дії в обліковому записі користувача в іншому додатку** (сервер авторизації).

Розгляньте гіпотетичний веб-сайт _**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](https://example.com) і вибираєте кнопку “Інтегрувати з соціальними мережами”.
2. Сайт надсилає запит на [https://socialmedia.com](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 для доступу

## Вразливості <a href="#id-323a" id="id-323a"></a>

### Відкритий redirect\_uri <a href="#cc36" id="cc36"></a>

`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 в реалізації редиректу <a href="#bda5" id="bda5"></a>

Як згадано в цьому звіті про баг-баунті [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](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 <a href="#bda5" id="bda5"></a>

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

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

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

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

### Перед взломом облікового запису <a href="#ebe4" id="ebe4"></a>

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

### Розкриття секретів <a href="#e177" id="e177"></a>

Визначення та захист секретних параметрів 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

[**Перевірте цей пост**](https://labs.detectify.com/writeups/account-hijacking-using-dirty-dancing-in-sign-in-oauth-flows/#gadget-2-xss-on-sandbox-third-party-domain-that-gets-the-url)

### AWS Cognito <a href="#bda5" id="bda5"></a>

У цьому звіті про баги: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) ви можете побачити, що **токен**, який **AWS Cognito** повертає користувачу, може мати **достатньо прав для переписування даних користувача**. Тому, якщо ви можете **змінити електронну пошту користувача на іншу електронну пошту**, ви можете **захопити** акаунти інших.
```bash
# 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"
}
]
}
```
Для більш детальної інформації про те, як зловживати AWS cognito, перегляньте:

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

### Зловживання токенами інших додатків <a href="#bda5" id="bda5"></a>

Як [**зазначено в цьому звіті**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), потоки OAuth, які очікують отримати **токен** (а не код), можуть бути вразливими, якщо не перевіряють, що токен належить додатку.

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

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

### Два посилання та cookie <a href="#bda5" id="bda5"></a>

Згідно з [**цим звітом**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), було можливим змусити жертву відкрити сторінку з **returnUrl**, що вказує на хост зловмисника. Ця інформація буде **збережена в cookie (RU)**, а на **пізнішому етапі** **підказка** запитає **користувача**, чи хоче він надати доступ до цього хосту зловмисника.

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

### Обхід взаємодії з підказкою <a href="#bda5" id="bda5"></a>

Як пояснено в [**цьому відео**](https://www.youtube.com/watch?v=n9x7\_J\_a\_7Q), деякі реалізації OAuth дозволяють вказати параметр **`prompt`** GET як None (**`&prompt=none`**), щоб **запобігти запитам до користувачів на підтвердження** наданого доступу в підказці в вебі, якщо вони вже увійшли на платформу.

### response\_mode

Як [**пояснено в цьому відео**](https://www.youtube.com/watch?v=n9x7\_J\_a\_7Q), можливо вказати параметр **`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 ROPC потік - обхід 2 FA <a href="#b440" id="b440"></a>

Згідно з [**цим блогом**](https://cybxis.medium.com/a-bypass-on-gitlabs-login-email-verification-via-oauth-ropc-flow-e194242cad96), це OAuth потік, який дозволяє входити в OAuth через **ім'я користувача** та **пароль**. Якщо під час цього простого потоку повертається **токен** з доступом до всіх дій, які може виконати користувач, то можливо обійти 2FA, використовуючи цей токен.

### Параметри SSRFs <a href="#bda5" id="bda5"></a>

[**Перевірте це дослідження**](https://portswigger.net/research/hidden-oauth-attack-vectors) **Для подальших деталей цієї техніки.**

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

Якщо платформа, яку ви тестуєте, є постачальником OAuth, [**прочитайте це, щоб перевірити можливі умови гонки**](race-condition.md).

## Посилання

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

<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>

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

{% hint style="success" %}
Вивчайте та практикуйте Hacking AWS:<img src="../.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../.gitbook/assets/arte.png" alt="" data-size="line">\
Вивчайте та практикуйте Hacking GCP: <img src="../.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>Підтримати HackTricks</summary>

* Перевірте [**плани підписки**](https://github.com/sponsors/carlospolop)!
* **Приєднуйтесь до** 💬 [**групи Discord**](https://discord.gg/hRep4RUj7f) або [**групи Telegram**](https://t.me/peass) або **слідкуйте за нами в** **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Діліться хакерськими трюками, надсилаючи PR до** [**HackTricks**](https://github.com/carlospolop/hacktricks) та [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) репозиторіїв на github.

</details>
{% endhint %}