mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-23 21:24:06 +00:00
134 lines
11 KiB
Markdown
134 lines
11 KiB
Markdown
# Aktualizacja Przemytu Nagłówków
|
|
|
|
<details>
|
|
|
|
<summary><strong>Zacznij od zera i stań się ekspertem od hakowania AWS dzięki</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ą na HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLANY SUBSKRYPCYJNE**](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) na GitHubie.
|
|
|
|
</details>
|
|
|
|
**Grupa Try Hard Security**
|
|
|
|
<figure><img src="/.gitbook/assets/telegram-cloud-document-1-5159108904864449420.jpg" alt=""><figcaption></figcaption></figure>
|
|
|
|
{% embed url="https://discord.gg/tryhardsecurity" %}
|
|
|
|
***
|
|
|
|
### Przemyt 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 tymczasowych połączeń HTTP, aktualizując standardowe połączenie HTTP **do trwałego**. To zaktualizowane połączenie wykorzystuje binarny protokół http2 do ciągłej komunikacji, w przeciwieństwie do jednorazowego charakteru protokołu HTTP w tekście czystym.
|
|
|
|
Rdzeń problemu przemytu pojawia się przy użyciu **serwera proxy odwrotnego**. Zazwyczaj serwer proxy odwrotny 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 widziany w połączeniach websocket), serwer **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
|
|
```
|
|
# Wykorzystanie H2C Smuggling <a href="#exploitation" id="exploitation"></a>
|
|
|
|
Podatność 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 ustanowieniu połączenia. Wykorzystanie H2C Smuggling pozwala na obejście reguł odwrotnego proxy stosowanych podczas przetwarzania żądania, takich jak routowanie oparte na ścieżce, uwierzytelnianie i przetwarzanie WAF, zakładając, że połączenie H2C zostało pomyślnie zainicjowane.
|
|
|
|
#### Narażone Proksy <a href="#exploitation" id="exploitation"></a>
|
|
|
|
Podatność zależy od obsługi przez odwrotne proxy nagłówków `Upgrade` i czasami `Connection`. Następujące proksy z natury przekazują te nagłówki podczas przekazywania proxy-pass, co z natury umożliwia H2C smuggling:
|
|
|
|
* HAProxy
|
|
* Traefik
|
|
* Nuster
|
|
|
|
Z kolei te usługi z natury nie przekazują obu nagłówków podczas przekazywania proxy-pass. Jednakże mogą być skonfigurowane w sposób niebezpieczny, umożliwiając 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>
|
|
|
|
Należy zauważyć, że nie wszystkie serwery z natury przekazują wymagane nagłówki do zgodnej aktualizacji połączenia H2C. Dlatego serwery takie jak AWS ALB/CLB, NGINX i Apache Traffic Server, między innymi, naturalnie blokują połączenia H2C. Niemniej warto przetestować z niezgodną wersją `Connection: Upgrade`, która wyklucza wartość `HTTP2-Settings` z nagłówka `Connection`, ponieważ niektóre backendy mogą nie być zgodne ze standardami.
|
|
|
|
{% hint style="danger" %}
|
|
Niezależnie od określonej **ścieżki** w adresie URL `proxy_pass` (np. `http://backend:9999/socket.io`), ustanowione połączenie domyślnie przekierowuje do `http://backend:9999`. Pozwala to na interakcję z dowolną ścieżką wewnątrz tego wewnętrznego punktu końcowego, wykorzystując tę technikę. W rezultacie określenie ścieżki w adresie 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 narzuconych przez proxy zabezpieczeń** 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, szczególnie dotyczące NGINX, zapoznaj się z [**tym szczegółowym źródłem**](../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 kieruje atak na backend oferujący publiczne API Websocket obok niedostępnego wewnętrznego API REST, chcąc uzyskać dostęp do wewnętrznego API REST. Atak składa się z kilku kroków:
|
|
|
|
1. Klient rozpoczyna wysyłając żądanie Upgrade do odwrotnego 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 ważne i przekazuje je do backendu.
|
|
2. Backend odpowiada kodem stanu `426`, wskazując nieprawidłową wersję protokołu w nagłówku `Sec-WebSocket-Version`. Odwrotne proxy, ignorując odpowiedź backendu, zakłada gotowość do komunikacji Websocket i przekazuje odpowiedź klientowi.
|
|
3. W rezultacie odwrotne proxy zostaje wprowadzone w błąd, uznają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 API REST poprzez to połączenie.
|
|
|
|
Narażone odwrotne proksy obejmują Varnish, który odmówił rozwiązania problemu, oraz odwrotne proxy Envoy w wersji 1.8.0 lub starszej, przy czym późniejsze wersje zmieniły mechanizm aktualizacji. Inne proksy mogą również być 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 posiadającego zarówno publiczne API Websocket, jak i publiczne API REST do sprawdzania stanu zdrowia, obok 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 zdrowia, zawierając dodatkowy nagłówek HTTP `Upgrade: websocket`. NGINX, działający jako odwrotne proxy, interpretuje to jako standardowe żądanie Upgrade oparte wyłącznie na nagłówku `Upgrade`, pomijają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 przez backend i przekazaniu do NGINX, wprowadza proxy w błąd, sugerując, że ustanowione zostało połączenie Websocket ze względu na jego walidację tylko statusu odpowiedzi.
|
|
|
|
![https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-4.png](https://github.com/0ang3el/websocket-smuggle/raw/master/img/3-4.png)
|
|
|
|
> **Ostrzeżenie:** Złożoność tej techniki wzrasta, ponieważ wymaga zdolności do interakcji z punktem końcowym zdolnym do zwrócenia statusu 101.
|
|
|
|
Ostatecznie NGINX zostaje oszukany, ż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 zdrowia. Niemniej jednak odwrotne proxy utrzymuje otwarte połączenie, umożliwiając klientowi dostęp do prywatnego API REST poprzez 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 stopniu ryzyka.
|
|
|
|
#### Laboratoria
|
|
|
|
Sprawdź laboratoria, aby przetestować oba scenariusze na [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)
|
|
|
|
|
|
**Try Hard Security Group**
|
|
|
|
<figure><img src="/.gitbook/assets/telegram-cloud-document-1-5159108904864449420.jpg" alt=""><figcaption></figcaption></figure>
|
|
|
|
{% embed url="https://discord.gg/tryhardsecurity" %}
|
|
|
|
<details>
|
|
|
|
<summary><strong>Naucz się 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ź [**PLANY SUBSKRYPCYJNE**](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>
|