HTTP Connection Request Smuggling

Reading time: 5 minutes

tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks

Ta strona podsumowuje, rozszerza i aktualizuje przełomowe badania PortSwigger na temat 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 (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.example

GET /admin HTTP/1.1
Host: internal-only.example

Routing pierwszego żądania

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, takimi jak złośliwe resetowanie hasła lub zatrucie pamięci podręcznej, aby uzyskać dostęp podobny do SSRF do innych wirtualnych hostów:

http
GET / HTTP/1.1
Host: public.example

POST /pwreset HTTP/1.1
Host: private.internal

tip

W Burp Suite Professional ≥2022.10 możesz włączyć HTTP Request Smuggler → Connection-state probe, aby automatycznie wykrywać te słabości.

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 <img src="https://internal.company/…"> 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)

RokKomponentCVEUwagi
2022AWS Application Load Balancer–Nagłówek Host był walidowany tylko przy pierwszym żądaniu; naprawione przez poprawki silnika reguł (ujawnione przez SecurityLabs).
2023Apache Traffic Server < 9.2.2CVE-2023-39852Umożliwił smuggling żądań przez ponowne użycie połączenia HTTP/2, gdy CONFIG proxy.config.http.parent_proxy_routing_enable było ustawione.
2024Envoy Proxy < 1.29.0CVE-2024-2470Niewł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

tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks