Ukranian - Ht
HackTricks Training Twitter Linkedin Sponsor

OAuth to Account takeover

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

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

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:

  • власник ресурсу: Ви, як користувач/сутність, авторизуєте доступ до свого ресурсу, наприклад, до постів у вашому обліковому записі у соціальних мережах.

  • сервер ресурсів: Сервер, що керує аутентифікованими запитами після того, як додаток отримав токен доступу від власника ресурсу, наприклад, https://socialmedia.com.

  • клієнтський додаток: Додаток, який шукає авторизацію від власника ресурсу, наприклад https://example.com.

  • сервер авторизації: Сервер, який видаватиме токени доступу для клієнтського додатку після успішної аутентифікації власника ресурсу та отримання авторизації, наприклад, https://socialmedia.com.

  • client_id: Публічний, унікальний ідентифікатор додатку.

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

  • response_type: Значення, що вказує тип запитаного токена, наприклад, код.

  • scope: Рівень доступу, який клієнтський додаток запитує від власника ресурсу.

  • redirect_uri: URL, на який користувач буде перенаправлений після авторизації. Зазвичай це повинно відповідати попередньо зареєстрованому URL перенаправлення.

  • state: Параметр для збереження даних під час перенаправлення користувача до та від сервера авторизації. Його унікальність є критичною для використання як механізм захисту від CSRF.

  • grant_type: Параметр, що вказує тип надання та тип токена, який повернеться.

  • code: Код авторизації від сервера авторизації, який використовується разом з client_id та client_secret клієнтським додатком для отримання токена доступу.

  • access_token: Токен, який використовує клієнтський додаток для запитів API від імені власника ресурсу.

  • refresh_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

  1. Потім вам відображається сторінка згоди.

  2. Після вашого схвалення, соціальні мережі відправляють відповідь на redirect_uri з параметрами code та state:

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

  1. 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"}

  1. Нарешті, процес завершується, оскільки https://example.com використовує ваш access_token для здійснення виклику API до соціальних мереж для доступу

Вразливості

Відкритий 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 - Неналежна обробка параметра стану

При реалізації 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 та особистої інформації.

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

Перебір секретного клієнта

Ви можете спробувати перебрати секрет клієнта постачальника послуг з постачальником ідентифікації, щоб спробувати вкрасти облікові записи. Запит до 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 з кодом + State

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

Токен доступу збережений в історії браузера

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

Вічний код авторизації

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

Код авторизації/оновлення не пов'язаний з клієнтом

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

Щасливі шляхи, XSS, Iframes та Post Messages для витоку коду та значень State

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

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"
}
]
}

Для отримання докладної інформації про те, як зловживати AWS Cognito перевірте:

Зловживання токенами інших додатків

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

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

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

Два посилання та cookie

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

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

Параметри SSRF

Перевірте це дослідження для отримання додаткових відомостей про цю техніку.

PreviousNoSQL injectionNextOpen Redirect

Last updated