Upgrade Header Smuggling

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Try Hard Security Group

Join the Try Hard Security Discord Server!Discord

H2C Smuggling

HTTP2 Over Cleartext (H2C)

H2C, czyli http2 over cleartext, odbiega od normy przejrzystych połączeń HTTP, aktualizując standardowe połączenie HTTP do połączenia trwałego. To zaktualizowane połączenie wykorzystuje binarny protokół http2 do bieżącej komunikacji, w przeciwieństwie do jednorazowego charakteru tekstowego HTTP.

Sedno problemu z smugglingiem pojawia się przy użyciu reverse proxy. Zwykle reverse proxy przetwarza i przekazuje żądania HTTP do backendu, zwracając odpowiedź backendu po tym. Jednak gdy nagłówek Connection: Upgrade jest obecny w żądaniu HTTP (często spotykanym w połączeniach websocket), reverse proxy utrzymuje trwałe połączenie między klientem a serwerem, ułatwiając ciągłą wymianę wymaganą przez niektóre protokoły. Dla połączeń H2C przestrzeganie RFC wymaga obecności trzech specyficznych nagłówków:

Upgrade: h2c
HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA
Connection: Upgrade, HTTP2-Settings

Wrażliwość pojawia się, gdy po zaktualizowaniu połączenia, odwrotny proxy przestaje zarządzać poszczególnymi żądaniami, zakładając, że jego zadanie routingu jest zakończone po nawiązaniu połączenia. Wykorzystanie H2C Smuggling pozwala na obejście zasad odwrotnego proxy stosowanych podczas przetwarzania żądań, takich jak routing oparty na ścieżkach, uwierzytelnianie i przetwarzanie WAF, zakładając, że połączenie H2C zostało pomyślnie nawiązane.

Wrażliwe Proxysy

Wrażliwość zależy od obsługi przez odwrotny proxy nagłówków Upgrade i czasami Connection. Następujące proxy z natury przekazują te nagłówki podczas proxy-pass, co z natury umożliwia H2C smuggling:

HAProxy
Traefik
Nuster

Z drugiej strony, te usługi nie przekazują z natury obu nagłówków podczas proxy-pass. Mogą jednak być skonfigurowane w sposób niebezpieczny, co pozwala na nieprzefiltrowane przekazywanie nagłówków Upgrade i Connection:

AWS ALB/CLB
NGINX
Apache
Squid
Varnish
Kong
Envoy
Apache Traffic Server

Wykorzystanie

Ważne jest, aby zauważyć, że nie wszystkie serwery z natury przekazują nagłówki wymagane do zgodnej aktualizacji połączenia H2C. W związku z tym serwery takie jak AWS ALB/CLB, NGINX i Apache Traffic Server, między innymi, naturalnie blokują połączenia H2C. Niemniej jednak warto przetestować niezgodną wersję Connection: Upgrade, która wyklucza wartość HTTP2-Settings z nagłówka Connection, ponieważ niektóre backendy mogą nie przestrzegać standardów.

Niezależnie od konkretnej ścieżki wyznaczonej w URL proxy_pass (np. http://backend:9999/socket.io), nawiązane połączenie domyślnie odnosi się do http://backend:9999. Umożliwia to interakcję z dowolną ścieżką w tym wewnętrznym punkcie końcowym, wykorzystując tę technikę. W związku z tym określenie ścieżki w URL proxy_pass nie ogranicza dostępu.

Narzędzia h2csmuggler by BishopFox i h2csmuggler by assetnote ułatwiają próby obejścia zabezpieczeń nałożonych przez proxy poprzez nawiązanie połączenia H2C, co umożliwia dostęp do zasobów chronionych przez proxy.

Aby uzyskać dodatkowe informacje na temat tej wrażliwości, szczególnie w odniesieniu do NGINX, zapoznaj się z tym szczegółowym zasobem.

Websocket Smuggling

Websocket smuggling, w przeciwieństwie do tworzenia tunelu HTTP2 do punktu końcowego dostępnego przez proxy, ustanawia tunel Websocket, aby obejść potencjalne ograniczenia proxy i umożliwić bezpośrednią komunikację z punktem końcowym.

Scenariusz 1

W tym scenariuszu atakowany jest backend, który oferuje publiczne API WebSocket obok niedostępnego wewnętrznego API REST. Atak przebiega w kilku krokach:

Klient inicjuje, wysyłając żądanie Upgrade do odwrotnego proxy z nieprawidłową wersją protokołu Sec-WebSocket-Version w nagłówku. Proxy, nie weryfikując nagłówka Sec-WebSocket-Version, uważa, że żądanie Upgrade jest ważne i przekazuje je do backendu.
Backend odpowiada kodem statusu 426, wskazując na nieprawidłową wersję protokołu w nagłówku Sec-WebSocket-Version. Odwrotny proxy, pomijając status odpowiedzi backendu, zakłada gotowość do komunikacji WebSocket i przekazuje odpowiedź do klienta.
W konsekwencji odwrotny proxy jest wprowadzany w błąd, wierząc, że nawiązano połączenie WebSocket między klientem a backendem, podczas gdy w rzeczywistości backend odrzucił żądanie Upgrade. Mimo to proxy utrzymuje otwarte połączenie TCP lub TLS między klientem a backendem, co pozwala klientowi na nieograniczony dostęp do prywatnego API REST przez to połączenie.

Dotknięte odwrotne proxy obejmują Varnish, który odmówił rozwiązania problemu, oraz wersję proxy Envoy 1.8.0 lub starszą, przy czym nowsze wersje zmieniły mechanizm aktualizacji. Inne proxy mogą być również podatne.

Scenariusz 2

Ten scenariusz dotyczy backendu z publicznym API WebSocket oraz publicznym API REST do sprawdzania stanu, a także niedostępnego wewnętrznego API REST. Atak, bardziej złożony, obejmuje następujące kroki:

Klient wysyła żądanie POST, aby uruchomić API sprawdzania stanu, w tym dodatkowy nagłówek HTTP Upgrade: websocket. NGINX, działający jako odwrotny proxy, interpretuje to jako standardowe żądanie Upgrade wyłącznie na podstawie nagłówka Upgrade, pomijając inne aspekty żądania, i przekazuje je do backendu.
Backend wykonuje API sprawdzania stanu, kontaktując się z zewnętrznym zasobem kontrolowanym przez atakującego, który zwraca odpowiedź HTTP z kodem statusu 101. Ta odpowiedź, po odebraniu przez backend i przekazaniu do NGINX, wprowadza proxy w błąd, myśląc, że nawiązano połączenie WebSocket z powodu jego weryfikacji tylko na podstawie kodu statusu.

Ostrzeżenie: Złożoność tej techniki wzrasta, ponieważ wymaga możliwości interakcji z punktem końcowym zdolnym do zwrócenia kodu statusu 101.

Ostatecznie NGINX jest wprowadzany w błąd, wierząc, że istnieje połączenie WebSocket między klientem a backendem. W rzeczywistości takie połączenie nie istnieje; celem było API REST sprawdzania stanu. Niemniej jednak odwrotny proxy utrzymuje połączenie otwarte, umożliwiając klientowi dostęp do prywatnego API REST przez nie.

Większość odwrotnych proxy jest podatna na ten scenariusz, ale wykorzystanie zależy od obecności zewnętrznej wrażliwości SSRF, zazwyczaj uważanej za problem o niskim ciężarze.