diff --git a/src/pentesting-web/http-connection-request-smuggling.md b/src/pentesting-web/http-connection-request-smuggling.md index eea99cbbd..257edeaad 100644 --- a/src/pentesting-web/http-connection-request-smuggling.md +++ b/src/pentesting-web/http-connection-request-smuggling.md @@ -2,33 +2,82 @@ {{#include ../banners/hacktricks-training.md}} -**Це резюме посту** [**https://portswigger.net/research/browser-powered-desync-attacks**](https://portswigger.net/research/browser-powered-desync-attacks) +**Ця сторінка узагальнює, розширює та оновлює** основоположне дослідження PortSwigger про [Browser-Powered Desync Attacks](https://portswigger.net/research/browser-powered-desync-attacks) та подальшу роботу з зловживанням станом з'єднання HTTP/2. Вона зосереджується на вразливостях, де **походження визначається лише один раз на з'єднанні TCP/TLS**, що дозволяє зловмиснику "переправляти" запити до іншого внутрішнього хоста після встановлення каналу. -## Атаки на стан з'єднання +## Connection-State Attacks -### Валідація першого запиту +### First-request Validation -При маршрутизації запитів зворотні проксі можуть покладатися на **заголовок Host**, щоб визначити сервер на задньому плані, часто спираючись на білий список хостів, яким дозволено доступ. Однак у деяких проксі існує вразливість, де білий список застосовується лише до початкового запиту в з'єднанні. Внаслідок цього зловмисники можуть скористатися цим, спочатку зробивши запит до дозволеного хоста, а потім запитуючи внутрішній сайт через те ж з'єднання: -``` +При маршрутизації запитів зворотні проксі можуть покладатися на заголовок **Host** (або **:authority** в HTTP/2), щоб визначити сервер призначення, часто спираючись на білий список хостів, яким дозволено доступ. Однак існує вразливість у ряді проксі, де білий список **застосовується лише до самого першого запиту в з'єднанні**. Внаслідок цього зловмисники можуть отримати доступ до внутрішніх віртуальних хостів, спочатку надіславши дозволений запит, а потім повторно використовуючи те ж саме підключення: +```http GET / HTTP/1.1 -Host: [allowed-external-host] +Host: allowed-external-host.example -GET / HTTP/1.1 -Host: [internal-host] +GET /admin HTTP/1.1 +Host: internal-only.example ``` ### First-request Routing -В деяких конфігураціях, фронтальний сервер може використовувати **заголовок Host першого запиту** для визначення маршрутизації на бекенді для цього запиту, а потім постійно маршрутизувати всі наступні запити з того ж клієнтського з'єднання до того ж бекенд-з'єднання. Це можна продемонструвати як: -``` +Багато HTTP/1.1 зворотних проксі відображають вихідне з'єднання до пулу бекенду **виключно на основі першого запиту, який вони пересилають**. Усі наступні запити, надіслані через той же фронтальний сокет, безшумно повторно використовуються, незалежно від їх заголовка Host. Це можна поєднати з класичними [атаками на заголовок Host](https://portswigger.net/web-security/host-header), такими як отруєння скидання пароля або [отруєння веб-кешу](https://portswigger.net/web-security/web-cache-poisoning), щоб отримати доступ, подібний до SSRF, до інших віртуальних хостів: +```http GET / HTTP/1.1 -Host: example.com +Host: public.example POST /pwreset HTTP/1.1 -Host: psres.net +Host: private.internal ``` -Цю проблему можна потенційно поєднати з [атаками на заголовок Host](https://portswigger.net/web-security/host-header), такими як отруєння скидання пароля або [отруєння веб-кешу](https://portswigger.net/web-security/web-cache-poisoning), щоб експлуатувати інші вразливості або отримати несанкціонований доступ до додаткових віртуальних хостів. +> [!TIP] +> У Burp Suite Professional ≥2022.10 ви можете увімкнути **HTTP Request Smuggler → Connection-state probe** для автоматичного виявлення цих вразливостей. -> [!NOTE] -> Для виявлення цих вразливостей можна використовувати функцію 'connection-state probe' у HTTP Request Smuggler. +--- + +## НОВЕ у 2023-2025 – Зловживання з'єднаннями HTTP/2/3 + +Сучасні браузери регулярно **об'єднують** запити HTTP/2 та HTTP/3 в одне TLS-з'єднання, коли сертифікат, протокол ALPN та IP-адреса збігаються. Якщо фронтенд авторизує лише перший запит, кожен наступний об'єднаний запит успадковує цю авторизацію – **навіть якщо змінюється Host/:authority**. + +### Сценар експлуатації +1. Зловмисник контролює `evil.com`, який розв'язується до того ж краєвого вузла CDN, що й цільовий `internal.company`. +2. Браузер жертви вже має відкрите HTTP/2 з'єднання з `evil.com`. +3. Зловмисник вбудовує прихований `` на свою сторінку. +4. Оскільки параметри з'єднання збігаються, браузер повторно використовує **існуюче** TLS-з'єднання та мультиплексує запит для `internal.company`. +5. Якщо CDN/маршрутизатор лише перевіряв перший запит, внутрішній хост стає доступним. + +PoCs для Chrome/Edge/Firefox доступні в доповіді Джеймса Кеттла *“HTTP/2: The Sequel is Always Worse”* (Black Hat USA 2023). + +### Інструменти +* **Burp Suite 2023.12** представив експериментальну точку вставки **HTTP/2 Smuggler**, яка автоматично намагається об'єднувати та використовувати техніки TE/CL. +* **smuggleFuzz** (https://github.com/microsoft/smugglefuzz) – Фреймворк на Python, випущений у 2024 році для брутфорсу векторів десинхронізації фронтенду/бекенду через HTTP/2 та HTTP/3, включаючи перестановки стану з'єднання. + +### Заходи пом'якшення +* Завжди **повторно перевіряйте Host/:authority на кожному запиті**, а не лише під час створення з'єднання. +* Вимкніть або строго обмежте **об'єднання за походженням** на шарах CDN/балансувальника навантаження (наприклад, `http2_origin_cn` вимкнено в NGINX). +* Використовуйте окремі сертифікати або IP-адреси для внутрішніх та зовнішніх імен хостів, щоб браузер не міг легально їх об'єднувати. +* Віддавайте перевагу **connection: close** або `proxy_next_upstream` після кожного запиту, де це можливо. + +--- + +## Реальні випадки (2022-2025) + +| Рік | Компонент | CVE | Примітки | +|------|-----------|-----|-------| +| 2022 | AWS Application Load Balancer | – | Заголовок Host перевірявся лише на першому запиті; виправлено шляхом патчування правил двигуна (розкрито SecurityLabs). | +| 2023 | Apache Traffic Server < 9.2.2 | CVE-2023-39852 | Дозволяв зловживання запитами через повторне використання з'єднання HTTP/2, коли було встановлено `CONFIG proxy.config.http.parent_proxy_routing_enable`. | +| 2024 | Envoy Proxy < 1.29.0 | CVE-2024-2470 | Неправильна перевірка :authority після першого потоку дозволила зловживання запитами між орендарями в спільних мережах. | + +--- + +## Чек-лист для виявлення + +1. Надішліть два запити в **одному** TCP/TLS з'єднанні з різними заголовками Host або :authority. +2. Спостерігайте, чи другий відповідь походить з першого хоста (безпечний) або з другого хоста (вразливий). +3. У Burp: `Repeat → keep-alive → Send → Follow`. +4. При тестуванні HTTP/2 відкрийте **окремий** потік (ID 1) для безпечного хоста, потім мультиплексуйте другий потік (ID 3) до внутрішнього хоста та шукайте відповідь. + +--- + +## Посилання + +* PortSwigger Research – *HTTP/2: The Sequel is Always Worse* (Black Hat USA 2023) +* Envoy Security Advisory CVE-2024-2470 – Неправильна перевірка авторитету {{#include ../banners/hacktricks-training.md}}