mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-27 07:01:09 +00:00
99 lines
8.9 KiB
Markdown
99 lines
8.9 KiB
Markdown
# Ulepszenie Smuglowania Nagłówka
|
|
|
|
<details>
|
|
|
|
<summary><strong>Dowiedz się, jak hakować AWS od zera do bohatera z</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
|
|
|
Inne sposoby wsparcia HackTricks:
|
|
|
|
* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLAN SUBSKRYPCJI**](https://github.com/sponsors/carlospolop)!
|
|
* Zdobądź [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com)
|
|
* Odkryj [**Rodzinę PEASS**](https://opensea.io/collection/the-peass-family), naszą kolekcję ekskluzywnych [**NFT**](https://opensea.io/collection/the-peass-family)
|
|
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
|
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
|
|
|
</details>
|
|
|
|
<figure><img src="/.gitbook/assets/image (675).png" alt=""><figcaption></figcaption></figure>
|
|
|
|
Znajdź najważniejsze podatności, aby móc je szybko naprawić. Intruder śledzi powierzchnię ataku, wykonuje proaktywne skanowanie zagrożeń, znajduje problemy w całym stosie technologicznym, od interfejsów API po aplikacje internetowe i systemy chmurowe. [**Wypróbuj go za darmo**](https://www.intruder.io/?utm\_source=referral\&utm\_campaign=hacktricks) już dziś.
|
|
|
|
{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}
|
|
|
|
***
|
|
|
|
## Smuglowanie H2C <a href="#http2-over-cleartext-h2c" id="http2-over-cleartext-h2c"></a>
|
|
|
|
### HTTP2 nad czystym tekstem (H2C) <a href="#http2-over-cleartext-h2c" id="http2-over-cleartext-h2c"></a>
|
|
|
|
H2C, czyli **http2 nad czystym tekstem**, odbiega od normy przejściowych połączeń HTTP, uaktualniając standardowe połączenie HTTP do trwałego. To uaktualnione połączenie wykorzystuje binarny protokół http2 do ciągłej komunikacji, w przeciwieństwie do jednorazowego charakteru czystego HTTP.
|
|
|
|
Istota problemu smuglowania wynika z użycia **odwróconego proxy**. Zwykle odwrócone 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 widoczny w połączeniach websocket), odwrócone **proxy utrzymuje trwałe połączenie** między klientem a serwerem, ułatwiając ciągłą wymianę wymaganą przez pewne protokoły. Dla połączeń H2C, zgodność z RFC wymaga obecności trzech konkretnych nagłówków:
|
|
```
|
|
Upgrade: h2c
|
|
HTTP2-Settings: AAMAAABkAARAAAAAAAIAAAAA
|
|
Connection: Upgrade, HTTP2-Settings
|
|
```
|
|
Podatność pojawia się, gdy po uaktualnieniu połączenia, odwrócony proxy przestaje zarządzać poszczególnymi żądaniami, zakładając, że jego zadanie polegające na kierowaniu jest zakończone po ustanowieniu połączenia. Wykorzystanie H2C Smuggling umożliwia obejście reguł odwróconego proxy stosowanych podczas przetwarzania żądania, takich jak kierowanie oparte na ścieżce, uwierzytelnianie i przetwarzanie WAF, zakładając, że połączenie H2C zostanie pomyślnie nawiązane.
|
|
|
|
### Podatne proxy <a href="#exploitation" id="exploitation"></a>
|
|
|
|
Podatność zależy od obsługi nagłówków `Upgrade` i czasami `Connection` przez odwrócone proxy. Następujące proxy domyślnie przekazują te nagłówki podczas proxy-pass, co umożliwia automatyczne włączenie H2C smuggling:
|
|
|
|
- HAProxy
|
|
- Traefik
|
|
- Nuster
|
|
|
|
Z kolei te usługi nie przekazują obu nagłówków domyślnie podczas proxy-pass. Jednak mogą być skonfigurowane w sposób niebezpieczny, umożliwiający niefiltrowane 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>
|
|
|
|
Warto zauważyć, że nie wszystkie serwery domyślnie przekazują nagłówki wymagane do zgodnego uaktualnienia połączenia H2C. Dlatego warto przetestować wariant niezgodny z zasadami, który nie zawiera wartości `HTTP2-Settings` w nagłówku `Connection`, ponieważ niektóre backendy mogą nie być zgodne ze standardami.
|
|
|
|
{% hint style="danger" %}
|
|
Niezależnie od określonej **ścieżki** w URL `proxy_pass` (np. `http://backend:9999/socket.io`), ustanowione połączenie domyślnie odwołuje się do `http://backend:9999`. Pozwala to na interakcję z dowolną ścieżką wewnątrz tego wewnętrznego punktu końcowego, wykorzystując tę technikę. Określenie ścieżki w URL `proxy_pass` nie ogranicza dostępu.
|
|
{% endhint %}
|
|
|
|
Narzędzia [**h2csmuggler od BishopFox**](https://github.com/BishopFox/h2csmuggler) i [**h2csmuggler od assetnote**](https://github.com/assetnote/h2csmuggler) ułatwiają próby **obejścia ochrony narzuconej przez proxy** poprzez ustanowienie połączenia H2C, umożliwiając dostęp do zasobów zabezpieczonych przez proxy.
|
|
|
|
Aby uzyskać dodatkowe informacje na temat tej podatności, zwłaszcza dotyczące NGINX, odwołaj się do [**tego szczegółowego źródła**](../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 za pośrednictwem proxy, ustanawia tunel Websocket w celu obejścia potencjalnych ograniczeń proxy i ułatwienia bezpośredniej komunikacji z punktem końcowym.
|
|
|
|
## Scenariusz 1
|
|
|
|
W tym scenariuszu złośliwy klient, który chce uzyskać dostęp do wewnętrznego REST API, kieruje atak na backend, który oferuje publiczne API Websocket obok niedostępnego wewnętrznego REST API. Atak składa się z kilku kroków:
|
|
|
|
1. Klient rozpoczyna, wysyłając żądanie Upgrade do odwróconego proxy z nieprawidłową wersją protokołu `Sec-WebSocket-Version` w nagłówku. Proxy, nie sprawdzając nagłówka `Sec-WebSocket-Version`, uznaje żądanie Upgrade za prawidłowe i przekazuje je do backendu.
|
|
2. Backend odpowiada kodem stanu `426`, wskazującym nieprawidłową wersję protokołu w nagłówku `Sec-WebSocket-Version`. Odwrócone proxy, pomijając status odpowiedzi backendu, zakłada gotowość do komunikacji Websocket i przekazuje odpowiedź do klienta.
|
|
3. W rezultacie odwrócone proxy zostaje wprowadzone w błąd, wierząc, że zostało ustanowione 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, umożliwiając klientowi nieograniczony dostęp do prywatnego REST API za pośrednictwem tego połączenia.
|
|
|
|
Podatne odwrócone proxy obejmują Varnish, który odmówił rozwiązania tego problemu, oraz proxy Envoy w wersji 1.8.0 lub starszej, przy czym późniejsze wersje zmieniły mechanizm uaktualniania. Inne proxy mogą również być podatne.
|
|
|
|
|
|
|
|
## Scenariusz 2
|
|
|
|
Ten scenariusz dotyczy backendu posiadającego zarówno publiczne API Websocket, jak i publiczne API REST do sprawdzania stanu zdrowia, oraz niedostępnego wewnętrznego REST API. Atak, bardziej złożony, obejmuje następujące kroki:
|
|
|
|
1. Klient wysyła żądanie POST, aby uruchomić API sprawdzania stanu zdrowia, zawierając dodatkowy nagłówek HTTP `Upgrade: websocket`. NGINX, działający jako odwrócone proxy, interpretuje to jako standardowe żądanie Upgrade, opierając się wyłącznie na nagłówku `Upgrade`, ignorując inne aspekty żądania, i przekazuje je do backendu.
|
|
2. Backend wykonuje API sprawdzania stanu zdrowia, sięgając do zewnętrznego zasobu kontrolowanego przez atakującego, który zwraca odpowiedź HTTP ze statusem `101`. Ta odpowiedź, po otrzymaniu jej przez backend i przekazaniu do NGINX, wprowadza proxy w błąd, sugerując, że zostało ustanowione połączenie Websocket ze względu na sprawdzenie tylko kodu stanu.
|
|
|
|
|
|
|
|
> **Ostrzeżenie:** Złożoność tej techniki wzrasta, ponieważ wymaga możliwości interakcji z punktem końcowym, który może zwrócić kod stanu 101.
|
|
|
|
Ostatecznie NGINX zostaje wprowadzone 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ła REST API sprawdzania stanu zdrowia. Niemniej jednak, odwrócone proxy utrzymuje otwarte połączenie, umożliwiając klientowi dostęp do prywatnego REST API za pośrednictwem niego.
|
|
|
|
![https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-5.png](https://github.com/0ang3el/web
|