Використовуйте [**Trickest**](https://trickest.com/?utm\_source=hacktricks\&utm\_medium=text\&utm\_campaign=ppc\&utm\_term=trickest\&utm\_content=race-condition), щоб легко створювати та **автоматизувати робочі процеси**, які підтримуються **найсучаснішими** інструментами спільноти.\
Вивчайте та практикуйте AWS Hacking:<imgsrc="../.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="../.gitbook/assets/arte.png"alt=""data-size="line">\
Вивчайте та практикуйте GCP Hacking: <imgsrc="../.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="../.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
Для отримання глибокого розуміння цієї техніки перевірте оригінальний звіт за адресою [https://portswigger.net/research/smashing-the-state-machine](https://portswigger.net/research/smashing-the-state-machine)
Основною перешкодою для використання race conditions є забезпечення одночасної обробки кількох запитів з **дуже незначною різницею в їх часі обробки — ідеально, менше 1 мс**.
* **HTTP/2**: Підтримує надсилання двох запитів через одне TCP-з'єднання, зменшуючи вплив мережевого джиттера. Однак через варіації на стороні сервера два запити можуть бути недостатніми для послідовної експлуатації race condition.
* **HTTP/1.1 'Синхронізація останнього байта'**: Дозволяє попередньо надсилати більшість частин 20-30 запитів, утримуючи невеликий фрагмент, який потім надсилається разом, досягаючи одночасного прибуття на сервер.
Наступне надсилання утримуваних кадрів має призвести до їх прибуття в одному пакеті, що можна перевірити за допомогою Wireshark. Цей метод не застосовується до статичних файлів, які зазвичай не беруть участі в атаках RC.
Розуміння архітектури цілі важливе. Фронтальні сервери можуть по-різному маршрутизувати запити, що впливає на час. Попереднє розігрівання з'єднання на стороні сервера через незначні запити може нормалізувати час запитів.
Фреймворки, такі як обробник сесій PHP, серіалізують запити за сесією, що може приховувати вразливості. Використання різних токенів сесії для кожного запиту може обійти цю проблему.
Якщо розігрів з'єднання неефективний, навмисне викликання затримок обмежень швидкості або ресурсів веб-серверів через потік фальшивих запитів може полегшити однопакетну атаку, викликавши затримку на стороні сервера, сприятливу для race conditions.
* **Tubo Intruder - однопакетна атака HTTP2 (1 кінцева точка)**: Ви можете надіслати запит до **Turbo intruder** (`Extensions` -> `Turbo Intruder` -> `Send to Turbo Intruder`), ви можете змінити в запиті значення, яке хочете брутфорсити для **`%s`**, як у`csrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%s`, а потім вибрати **`examples/race-single-packer-attack.py`** з випадаючого списку:
* **Tubo Intruder - HTTP2 атака з одним пакетом (Кілька кінцевих точок)**: У випадку, якщо вам потрібно надіслати запит до 1 кінцевої точки, а потім кілька до інших кінцевих точок, щоб активувати RCE, ви можете змінити скрипт `race-single-packet-attack.py` на щось на зразок:
* Для **connection warming** ви можете **додати** на **початку****групи** кілька **запитів** до деякої нестатичної частини веб-сервера.
* Для **delaying** процесу **між** обробкою **одного запиту та іншого** в 2 підстанах, ви можете **додати додаткові запити між** обома запитами.
* Для **multi-endpoint** RC ви можете почати надсилати **запит**, який **перейде в прихований стан**, а потім **50 запитів** одразу після нього, які **використовують прихований стан**.
* **Автоматизований python-скрипт**: Мета цього скрипта полягає в тому, щоб змінити електронну пошту користувача, постійно перевіряючи її, поки токен підтвердження нової електронної пошти не надійде на останню електронну пошту (це пов'язано з тим, що в коді спостерігалася RC, де було можливо змінити електронну пошту, але підтвердження надсилалося на стару, оскільки змінна, що вказує на електронну пошту, вже була заповнена першою).\
Коли слово "objetivo" знаходиться в отриманих електронних листах, ми знаємо, що отримали токен підтвердження зміненої електронної пошти, і ми закінчуємо атаку.
У початковому дослідженні пояснюється, що ця атака має обмеження в 1,500 байт. Однак у [**цьому пості**](https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/) пояснюється, як можливо розширити обмеження в 1,500 байт атаки з одного пакета до **65,535 B віконного обмеження TCP, використовуючи фрагментацію на рівні IP** (розділення одного пакета на кілька IP-пакетів) і надсилання їх у різному порядку, що дозволяє запобігти повторній збірці пакета, поки всі фрагменти не досягнуть сервера. Ця техніка дозволила досліднику надіслати 10,000 запитів приблизно за 166 мс. 
Зверніть увагу, що хоча це поліпшення робить атаку більш надійною в RC, яка вимагає, щоб сотні/тисячі пакетів прибули одночасно, це також може мати деякі програмні обмеження. Деякі популярні HTTP-сервери, такі як Apache, Nginx і Go, мають суворе налаштування `SETTINGS_MAX_CONCURRENT_STREAMS` на 100, 128 і 250. Однак інші, такі як NodeJS і nghttp2, мають його без обмежень.\
Це в основному означає, що Apache буде враховувати лише 100 HTTP-з'єднань з одного TCP-з'єднання (обмежуючи цю атаку RC).
Ви можете знайти деякі приклади використання цієї техніки в репозиторії [https://github.com/Ry0taK/first-sequence-sync/tree/main](https://github.com/Ry0taK/first-sequence-sync/tree/main).
Перед попереднім дослідженням були деякі корисні навантаження, які просто намагалися надсилати пакети якомога швидше, щоб викликати RC.
* **Повторювач:** Перегляньте приклади з попереднього розділу.
* **Зловмисник**: Надішліть **запит** до **Зловмисника**, встановіть **кількість потоків** на **30**у**меню параметрів**і виберіть як навантаження **Null payloads** та згенеруйте **30.**
Це найосновніший тип гонки, де **вразливості** з'являються в місцях, які **обмежують кількість разів, коли ви можете виконати дію**. Наприклад, використання одного й того ж коду знижки в інтернет-магазині кілька разів. Дуже простий приклад можна знайти в [**цьому звіті**](https://medium.com/@pravinponnusamy/race-condition-vulnerability-found-in-bug-bounty-program-573260454c43) або в [**цьому багу**](https://hackerone.com/reports/759247)**.**
Експлуатація складних гонок часто передбачає використання коротких можливостей для взаємодії з прихованими або**непередбаченими підстанціями машини**. Ось як підійти до цього:
* Почніть з визначення кінцевих точок, які змінюють або взаємодіють з критичними даними, такими як профілі користувачів або процеси скидання паролів. Зосередьтеся на:
* **Зберігання**: Віддавайте перевагу кінцевим точкам, які маніпулюють постійними даними на стороні сервера, а не тими, що обробляють дані на стороні клієнта.
* **Дія**: Шукайте операції, які змінюють існуючі дані, оскільки вони більш імовірно створюють експлуатовані умови в порівнянні з тими, що додають нові дані.
* **Ключування**: Успішні атаки зазвичай включають операції, які ключуються на одному й тому ж ідентифікаторі, наприклад, ім'я користувача або токен скидання.
* Тестуйте визначені кінцеві точки з атаками гонки, спостерігаючи за будь-якими відхиленнями від очікуваних результатів. Несподівані відповіді або зміни в поведінці програми можуть сигналізувати про вразливість.
* Звузьте атаку до мінімальної кількості запитів, необхідних для експлуатації вразливості, часто всього до двох. Цей етап може вимагати кількох спроб або автоматизації через точний таймінг.
Точність у таймінгу запитів може виявити вразливості, особливо коли використовуються передбачувані методи, такі як мітки часу, для безпекових токенів. Наприклад, генерація токенів скидання паролів на основі міток часу може дозволити ідентичні токени для одночасних запитів.
* Використовуйте точний таймінг, наприклад, атаку з одного пакета, щоб зробити одночасні запити на скидання пароля. Ідентичні токени вказують на вразливість.
Перевірте це [**PortSwigger Lab**](https://portswigger.net/web-security/logic-flaws/examples/lab-logic-flaws-insufficient-workflow-validation), щоб дізнатися, як **платити** в магазині та **додати додатковий** товар, за який **не потрібно платити**.
Згідно з [**цим дослідженням**](https://portswigger.net/research/smashing-the-state-machine), Gitlab був вразливий до захоплення таким чином, оскільки він міг **надіслати****токен перевірки електронної пошти однієї електронної адреси на іншу електронну адресу**.
Якщо **використовуються 2 різні записи** для **додавання****інформації** в **базу даних**, існує невеликий проміжок часу, коли **лише перші дані були записані** в базу даних. Наприклад, при створенні користувача **ім'я користувача** та **пароль** можуть бути **записані**, а**потім записується токен** для підтвердження новоствореного облікового запису. Це означає, що протягом короткого часу **токен для підтвердження облікового запису є нульовим**.
Отже, **реєстрація облікового запису та надсилання кількох запитів з порожнім токеном** (`token=` або`token[]=`або будь-яка інша варіація) для негайного підтвердження облікового запису може дозволити **підтвердити обліковий запис**, де ви не контролюєте електронну пошту.
Є кілька [**постачальників OAUth**](https://en.wikipedia.org/wiki/List\_of\_OAuth\_providers). Ці сервіси дозволять вам створити додаток і аутентифікувати користувачів, яких зареєстрував постачальник. Для цього **клієнт** повинен **дозволити вашому додатку** отримати доступ до деяких їхніх даних у**постачальника OAUth**.\
Отже, до цього моменту це просто звичайний вхід через google/linkedin/github..., де вам пропонують сторінку з повідомленням: "_Додаток \<InsertCoolName> хоче отримати доступ до вашої інформації, чи хочете ви це дозволити?_"
**Проблема** виникає, коли ви **приймаєте це**і автоматично надсилаєте **`authorization_code`** зловмисному додатку. Потім цей **додаток зловживає умовою гонки в сервісі OAUth, щоб згенерувати більше ніж один AT/RT** (_Токен аутентифікації/Токен оновлення_) з **`authorization_code`** для вашого облікового запису. В основному, він зловживає тим фактом, що ви прийняли додаток для доступу до ваших даних, щоб **створити кілька облікових записів**. Потім, якщо ви **припините дозволяти додатку доступ до ваших даних, одна пара AT/RT буде видалена, але інші залишаться дійсними**.
Якщо ви **отримали дійсний RT**, ви можете спробувати **зловживати ним для генерації кількох AT/RT**, і**навіть якщо користувач скасовує дозволи** для зловмисного додатку на доступ до його даних, **кілька RT залишаться дійсними.**
У [**WS\_RaceCondition\_PoC**](https://github.com/redrays-io/WS\_RaceCondition\_PoC) ви можете знайти PoC на Java для надсилання вебсокетних повідомлень **паралельно**, щоб зловживати **умовами гонки також у вебсокетах**.
Learn & practice AWS Hacking:<imgsrc="../.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="../.gitbook/assets/arte.png"alt=""data-size="line">\
Learn & practice GCP Hacking: <imgsrc="../.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="../.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
Use [**Trickest**](https://trickest.com/?utm\_source=hacktricks\&utm\_medium=text\&utm\_campaign=ppc\&utm\_term=trickest\&utm\_content=race-condition) to easily build and **automate workflows** powered by the world's **most advanced** community tools.\