hacktricks/src/pentesting-web/h2c-smuggling.md

# Upgrade Header Smuggling

{{#include ../banners/hacktricks-training.md}}

### H2C Smuggling <a href="#http2-over-cleartext-h2c" id="http2-over-cleartext-h2c"></a>

#### HTTP2 Over Cleartext (H2C) <a href="#http2-over-cleartext-h2c" id="http2-over-cleartext-h2c"></a>

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 ciągłej 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 związane z routowaniem jest zakończone po nawiązaniu połączenia. Wykorzystanie H2C Smuggling pozwala na obejście reguł odwrotnego proxy stosowanych podczas przetwarzania żądań, takich jak routowanie oparte na ścieżkach, uwierzytelnianie i przetwarzanie WAF, zakładając, że połączenie H2C zostało pomyślnie nawiązane.

#### Wrażliwe Proxysy <a href="#exploitation" id="exploitation"></a>

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 <a href="#exploitation" id="exploitation"></a>

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ć wariant niezgodny `Connection: Upgrade`, który wyklucza wartość `HTTP2-Settings` z nagłówka `Connection`, ponieważ niektóre backendy mogą nie przestrzegać standardów.

> [!CAUTION]
> 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**](https://github.com/BishopFox/h2csmuggler) i [**h2csmuggler by assetnote**](https://github.com/assetnote/h2csmuggler) 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**](../network-services-pentesting/pentesting-web/nginx.md#proxy_set_header-upgrade-and-connection).

## 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. Złośliwy klient dąży do uzyskania dostępu do wewnętrznego API REST. Atak przebiega w kilku krokach:

1. 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.
2. 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.
3. 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.

![https://github.com/0ang3el/websocket-smuggle/raw/master/img/2-4.png](https://github.com/0ang3el/websocket-smuggle/raw/master/img/2-4.png)

### 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:

1. 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.
2. 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.

![https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-4.png](https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-4.png)

> **Warning:** 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.

![https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-5.png](https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-5.png)

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

#### Laboratoria

Sprawdź laboratoria, aby przetestować oba scenariusze w [https://github.com/0ang3el/websocket-smuggle.git](https://github.com/0ang3el/websocket-smuggle.git)

### Odnośniki

- [https://blog.assetnote.io/2021/03/18/h2c-smuggling/](https://blog.assetnote.io/2021/03/18/h2c-smuggling/)
- [https://bishopfox.com/blog/h2c-smuggling-request](https://bishopfox.com/blog/h2c-smuggling-request)
- [https://github.com/0ang3el/websocket-smuggle.git](https://github.com/0ang3el/websocket-smuggle.git)

{{#include ../banners/hacktricks-training.md}}