# Взлом облікового запису {{#include ../banners/hacktricks-training.md}} ## **Проблема авторизації** Електронну пошту облікового запису слід спробувати змінити, і процес підтвердження **повинен бути перевірений**. Якщо він виявиться **слабким**, електронну пошту слід змінити на адресу запланованої жертви, а потім підтвердити. ## **Проблема нормалізації Unicode** 1. Обліковий запис запланованої жертви `victim@gmail.com` 2. Слід створити обліковий запис, використовуючи Unicode\ наприклад: `vićtim@gmail.com` Як пояснено в [**цьому виступі**](https://www.youtube.com/watch?v=CiIyaZ3x49c), попередню атаку також можна здійснити, зловживаючи сторонніми постачальниками ідентичності: - Створіть обліковий запис у сторонньому постачальнику ідентичності з подібною електронною поштою до жертви, використовуючи деякий символ unicode (`vićtim@company.com`). - Сторонній постачальник не повинен перевіряти електронну пошту. - Якщо постачальник ідентичності перевіряє електронну пошту, можливо, ви зможете атакувати доменну частину, наприклад: `victim@ćompany.com` і зареєструвати цей домен, сподіваючись, що постачальник ідентичності згенерує ASCII-версію домену, поки платформа жертви нормалізує ім'я домену. - Увійдіть через цього постачальника ідентичності на платформу жертви, яка повинна нормалізувати символ unicode і дозволити вам отримати доступ до облікового запису жертви. Для отримання додаткових деталей зверніться до документа з нормалізації Unicode: {{#ref}} unicode-injection/unicode-normalization.md {{#endref}} ## **Повторне використання токена скидання** Якщо цільова система дозволяє **повторне використання посилання на скидання**, слід докласти зусиль, щоб **знайти більше посилань на скидання**, використовуючи такі інструменти, як `gau`, `wayback` або `scan.io`. ## **Перед взломом облікового запису** 1. Електронну пошту жертви слід використовувати для реєстрації на платформі, і слід встановити пароль (слід спробувати підтвердити його, хоча відсутність доступу до електронних листів жертви може зробити це неможливим). 2. Слід дочекатися, поки жертва зареєструється, використовуючи OAuth, і підтвердить обліковий запис. 3. Сподіваємося, що звичайна реєстрація буде підтверджена, що дозволить отримати доступ до облікового запису жертви. ## **Неправильна конфігурація CORS для взлому облікового запису** Якщо сторінка містить **неправильні конфігурації CORS**, ви можете **вкрасти чутливу інформацію** у користувача, щоб **взяти під контроль його обліковий запис** або змусити його змінити інформацію про авторизацію з тією ж метою: {{#ref}} cors-bypass.md {{#endref}} ## **CSRF для взлому облікового запису** Якщо сторінка вразлива до CSRF, ви можете змусити **користувача змінити свій пароль**, електронну пошту або аутентифікацію, щоб потім отримати до них доступ: {{#ref}} csrf-cross-site-request-forgery.md {{#endref}} ## **XSS для взлому облікового запису** Якщо ви знайдете XSS в додатку, ви можете вкрасти куки, локальне сховище або інформацію зі сторінки, що може дозволити вам взяти під контроль обліковий запис: {{#ref}} xss-cross-site-scripting/ {{#endref}} ## **Те ж саме походження + куки** Якщо ви знайдете обмежений XSS або захоплення піддомену, ви можете грати з куками (наприклад, фіксуючи їх), щоб спробувати скомпрометувати обліковий запис жертви: {{#ref}} hacking-with-cookies/ {{#endref}} ## **Атака на механізм скидання пароля** {{#ref}} reset-password.md {{#endref}} ## **Маніпуляція відповіддю** Якщо відповідь аутентифікації можна **звести до простого булевого значення, просто спробуйте змінити false на true** і подивіться, чи отримаєте ви доступ. ## OAuth для взлому облікового запису {{#ref}} oauth-to-account-takeover.md {{#endref}} ## Впровадження заголовка Host 1. Заголовок Host змінюється після ініціації запиту на скидання пароля. 2. Заголовок проксі `X-Forwarded-For` змінюється на `attacker.com`. 3. Заголовки Host, Referrer і Origin одночасно змінюються на `attacker.com`. 4. Після ініціації скидання пароля та вибору повторної відправки електронної пошти використовуються всі три вищезгадані методи. ## Маніпуляція відповіддю 1. **Маніпуляція кодом**: Статус-код змінюється на `200 OK`. 2. **Маніпуляція кодом і тілом**: - Статус-код змінюється на `200 OK`. - Тіло відповіді змінюється на `{"success":true}` або на порожній об'єкт `{}`. Ці техніки маніпуляції ефективні в сценаріях, де JSON використовується для передачі та отримання даних. ## Зміна електронної пошти поточної сесії З [цього звіту](https://dynnyd20.medium.com/one-click-account-take-over-e500929656ea): - Зловмисник запитує зміну своєї електронної пошти на нову - Зловмисник отримує посилання для підтвердження зміни електронної пошти - Зловмисник надсилає жертві посилання, щоб вона його натиснула - Електронна пошта жертви змінюється на вказану зловмисником - Зловмисник може відновити пароль і взяти під контроль обліковий запис Це також сталося в [**цьому звіті**](https://dynnyd20.medium.com/one-click-account-take-over-e500929656ea). ### Обхід перевірки електронної пошти для взлому облікового запису - Зловмисник входить з attacker@test.com і підтверджує електронну пошту під час реєстрації. - Зловмисник змінює підтверджену електронну пошту на victim@test.com (без вторинної перевірки при зміні електронної пошти) - Тепер веб-сайт дозволяє victim@test.com увійти, і ми обійшли перевірку електронної пошти користувача жертви. ### Старі куки Як пояснено [**в цьому пості**](https://medium.com/@niraj1mahajan/uncovering-the-hidden-vulnerability-how-i-found-an-authentication-bypass-on-shopifys-exchange-cc2729ea31a9), було можливим увійти в обліковий запис, зберегти куки як аутентифікований користувач, вийти, а потім знову увійти.\ При новому вході, хоча можуть бути згенеровані інші куки, старі знову почали працювати. ## Посилання - [https://infosecwriteups.com/firing-8-account-takeover-methods-77e892099050](https://infosecwriteups.com/firing-8-account-takeover-methods-77e892099050) - [https://dynnyd20.medium.com/one-click-account-take-over-e500929656ea](https://dynnyd20.medium.com/one-click-account-take-over-e500929656ea) {{#include ../banners/hacktricks-training.md}}