mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00

Translator 740fcc5872 Translated ['src/README.md', 'src/binary-exploitation/rop-return-oriente

2025-01-03 18:15:23 +00:00

28 KiB

Raw Blame History

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

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

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 до ваших публікацій. Запит структурований як:

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

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

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

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

Нарешті, процес завершується, коли 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 - Неправильна обробка параметра стану

У реалізаціях 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 може виглядати приблизно так:

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

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

{{#ref}} https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum {{#endref}}

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

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

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

Caution

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

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

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

Обхід взаємодії з підказкою

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

OAuth ROPC потік - обхід 2 FA

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

ATO на веб-сторінці, що перенаправляє на основі відкритого редиректу на реферер

Цей блог коментує, як було можливим зловживати відкритим редиректом на значення з реферера, щоб зловживати OAuth для ATO. Атака була:

Жертва заходить на веб-сторінку зловмисника
Жертва відкриває шкідливе посилання, і відкривач запускає Google OAuth потік з response_type=id_token,code&prompt=none як додаткові параметри, використовуючи як реферер веб-сайт зловмисника.
У відкривачі, після того як постачальник авторизує жертву, він повертає їх назад до значення параметра redirect_uri (веб-сайт жертви) з кодом 30X, який все ще зберігає веб-сайт зловмисника в реферері.
Веб-сайт жертви ініціює відкритий редирект на основі реферера, перенаправляючи користувача жертви на веб-сайт зловмисника, оскільки respose_type був id_token,code, код буде надіслано назад до зловмисника у фрагменті URL, що дозволяє йому захопити обліковий запис користувача через Google на сайті жертви.

Параметри SSRFs

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

Динамічна реєстрація клієнтів у 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 прочитайте це, щоб перевірити можливі умови гонки.

28 KiB Raw Blame History Unescape Escape