diff --git a/src/pentesting-web/http-connection-request-smuggling.md b/src/pentesting-web/http-connection-request-smuggling.md index aa9b0c94f..5d731b907 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}} -**To jest podsumowanie posta** [**https://portswigger.net/research/browser-powered-desync-attacks**](https://portswigger.net/research/browser-powered-desync-attacks) +**Ta strona podsumowuje, rozszerza i aktualizuje** przełomowe badania PortSwigger na temat [Browser-Powered Desync Attacks](https://portswigger.net/research/browser-powered-desync-attacks) oraz późniejsze prace dotyczące nadużyć stanu połączenia HTTP/2. Skupia się na lukach, w których **pochodzenie jest ustalane tylko raz na połączenie TCP/TLS**, co umożliwia atakującemu „przemycenie” żądań do innego wewnętrznego hosta po nawiązaniu kanału. ## Ataki na stan połączenia ### Walidacja pierwszego żądania -Podczas routingu żądań, serwery proxy odwrotne mogą polegać na **nagłówku Host**, aby określić docelowy serwer zaplecza, często opierając się na białej liście hostów, które mają dostęp. Jednak w niektórych proxy istnieje luka, w której biała lista jest egzekwowana tylko w przypadku początkowego żądania w połączeniu. W związku z tym, atakujący mogą to wykorzystać, najpierw wysyłając żądanie do dozwolonego hosta, a następnie żądając dostępu do wewnętrznej strony przez to samo połączenie: -``` +Podczas routingu żądań, serwery proxy odwrotne mogą polegać na nagłówku **Host** (lub **:authority** w HTTP/2), aby określić docelowy serwer zaplecza, często opierając się na białej liście hostów, które mają dostęp. Jednak w wielu proxy istnieje luka, w której biała lista jest **egzekwowana tylko przy bardzo pierwszym żądaniu w połączeniu**. W konsekwencji atakujący mogą uzyskać dostęp do wewnętrznych wirtualnych hostów, najpierw wysyłając dozwolone żądanie, a następnie ponownie wykorzystując to samo podstawowe połączenie: +```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 ``` ### Routing pierwszego żądania -W niektórych konfiguracjach serwer front-end może używać **nagłówka Host pierwszego żądania** do określenia routingu back-end dla tego żądania, a następnie trwale kierować wszystkie kolejne żądania z tego samego połączenia klienta do tego samego połączenia back-end. Można to zademonstrować jako: -``` +Wiele odwrotnych proxy HTTP/1.1 mapuje połączenie wychodzące do zaplecza **wyłącznie na podstawie pierwszego żądania, które przekazują**. Wszystkie kolejne żądania wysyłane przez ten sam front-end socket są cicho ponownie używane, niezależnie od ich nagłówka Host. Można to połączyć z klasycznymi [atakami na nagłówek Host](https://portswigger.net/web-security/host-header), takimi jak złośliwe resetowanie hasła lub [zatrucie pamięci podręcznej](https://portswigger.net/web-security/web-cache-poisoning), aby uzyskać dostęp podobny do SSRF do innych wirtualnych hostów: +```http GET / HTTP/1.1 -Host: example.com +Host: public.example POST /pwreset HTTP/1.1 -Host: psres.net +Host: private.internal ``` -Ten problem może być potencjalnie połączony z [atakami na nagłówki Host](https://portswigger.net/web-security/host-header), takimi jak trucie resetu hasła lub [trucie pamięci podręcznej web](https://portswigger.net/web-security/web-cache-poisoning), aby wykorzystać inne luki lub uzyskać nieautoryzowany dostęp do dodatkowych wirtualnych hostów. +> [!TIP] +> W Burp Suite Professional ≥2022.10 możesz włączyć **HTTP Request Smuggler → Connection-state probe**, aby automatycznie wykrywać te słabości. -> [!NOTE] -> Aby zidentyfikować te luki, można wykorzystać funkcję 'connection-state probe' w HTTP Request Smuggler. +--- + +## NOWOŚĆ w 2023-2025 – Nadużycie koalescencji połączeń HTTP/2/3 + +Nowoczesne przeglądarki rutynowo **koalescują** żądania HTTP/2 i HTTP/3 na jednym połączeniu TLS, gdy certyfikat, protokół ALPN i adres IP są zgodne. Jeśli front-end autoryzuje tylko pierwsze żądanie, każde kolejne koalescowane żądanie dziedziczy tę autoryzację – **nawet jeśli Host/:authority się zmienia**. + +### Scenariusz wykorzystania +1. Atakujący kontroluje `evil.com`, które rozwiązuje się do tego samego węzła krawędzi CDN co cel `internal.company`. +2. Przeglądarka ofiary ma już otwarte połączenie HTTP/2 do `evil.com`. +3. Atakujący osadza ukryty `` na swojej stronie. +4. Ponieważ parametry połączenia są zgodne, przeglądarka ponownie wykorzystuje **istniejące** połączenie TLS i multiplexuje żądanie do `internal.company`. +5. Jeśli CDN/router tylko walidował pierwsze żądanie, wewnętrzny host jest ujawniony. + +PoC dla Chrome/Edge/Firefox są dostępne w wystąpieniu Jamesa Kettle’a *“HTTP/2: The Sequel is Always Worse”* (Black Hat USA 2023). + +### Narzędzia +* **Burp Suite 2023.12** wprowadził eksperymentalny punkt wstawiania **HTTP/2 Smuggler**, który automatycznie próbuje koalescencji i technik TE/CL. +* **smuggleFuzz** (https://github.com/microsoft/smugglefuzz) – Framework Pythona wydany w 2024 roku do brutalnego wymuszania wektorów desynchronizacji front-end/back-end przez HTTP/2 i HTTP/3, w tym permutacji stanu połączenia. + +### Środki zaradcze +* Zawsze **ponownie waliduj Host/:authority przy każdym żądaniu**, a nie tylko przy tworzeniu połączenia. +* Wyłącz lub ściśle ogranicz **koalescencję pochodzenia** na warstwach CDN/ładowania balansu (np. `http2_origin_cn` wyłączone w NGINX). +* Wdrażaj oddzielne certyfikaty lub adresy IP dla wewnętrznych i zewnętrznych nazw hostów, aby przeglądarka nie mogła ich legalnie koalescować. +* Preferuj **connection: close** lub `proxy_next_upstream` po każdym żądaniu, gdzie to możliwe. + +--- + +## Przykłady z życia (2022-2025) + +| Rok | Komponent | CVE | Uwagi | +|------|-----------|-----|-------| +| 2022 | AWS Application Load Balancer | – | Nagłówek Host był walidowany tylko przy pierwszym żądaniu; naprawione przez poprawki silnika reguł (ujawnione przez SecurityLabs). | +| 2023 | Apache Traffic Server < 9.2.2 | CVE-2023-39852 | Umożliwił smuggling żądań przez ponowne użycie połączenia HTTP/2, gdy `CONFIG proxy.config.http.parent_proxy_routing_enable` było ustawione. | +| 2024 | Envoy Proxy < 1.29.0 | CVE-2024-2470 | Niewłaściwa walidacja :authority po pierwszym strumieniu umożliwiła smuggling żądań między najemcami w współdzielonych sieciach. | + +--- + +## Arkusz wykrywania + +1. Wyślij dwa żądania w **tym samym** połączeniu TCP/TLS z różnymi nagłówkami Host lub :authority. +2. Obserwuj, czy druga odpowiedź pochodzi z pierwszego hosta (bezpieczne) czy drugiego hosta (wrażliwe). +3. W Burp: `Repeat → keep-alive → Send → Follow`. +4. Podczas testowania HTTP/2 otwórz **dedykowany** strumień (ID 1) dla nieszkodliwego hosta, a następnie multiplexuj drugi strumień (ID 3) do wewnętrznego hosta i szukaj odpowiedzi. + +--- + +## Odniesienia + +* PortSwigger Research – *HTTP/2: The Sequel is Always Worse* (Black Hat USA 2023) +* Envoy Security Advisory CVE-2024-2470 – Niewłaściwa walidacja autorytetu {{#include ../banners/hacktricks-training.md}}