mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-23 13:13:41 +00:00
159 lines
12 KiB
Markdown
159 lines
12 KiB
Markdown
# HTTP Response Smuggling / Desync
|
|
|
|
{% hint style="success" %}
|
|
Ucz się i ćwicz Hacking AWS:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
|
Ucz się i ćwicz Hacking GCP: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
|
|
|
<details>
|
|
|
|
<summary>Wsparcie HackTricks</summary>
|
|
|
|
* Sprawdź [**plany subskrypcyjne**](https://github.com/sponsors/carlospolop)!
|
|
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Podziel się sztuczkami hackingowymi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repozytoriów github.
|
|
|
|
</details>
|
|
{% endhint %}
|
|
|
|
**Technika opisana w tym poście została zaczerpnięta z wideo:** [**https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s**](https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s)
|
|
|
|
## Desynchronizacja kolejki żądań HTTP
|
|
|
|
Przede wszystkim, ta technika **wykorzystuje lukę w HTTP Request Smuggling**, więc musisz wiedzieć, co to jest:
|
|
|
|
**Główna** **różnica** między tą techniką a powszechnym HTTP Request smuggling polega na tym, że **zamiast** **atakować** **żądanie** **ofiary** **poprzez dodanie prefiksu**, zamierzamy **wyciekować lub modyfikować odpowiedź, którą otrzymuje ofiara**. Robimy to, zamiast wysyłać 1,5 żądania, aby wykorzystać HTTP Request smuggling, **wysyłamy 2 pełne żądania, aby zdesynchronizować kolejkę odpowiedzi proxy**.
|
|
|
|
Dzieje się tak, ponieważ będziemy w stanie **zdesynchronizować kolejkę odpowiedzi**, tak aby **odpowiedź** z **legitnego** **żądania** **ofiary została wysłana do atakującego**, lub poprzez **wstrzyknięcie treści kontrolowanej przez atakującego w odpowiedzi do ofiary**.
|
|
|
|
### Desynchronizacja potoku HTTP
|
|
|
|
HTTP/1.1 pozwala na żądanie **różnych zasobów bez konieczności czekania na poprzednie**. Dlatego, jeśli w **środku** znajduje się **proxy**, to zadaniem proxy jest **utrzymanie zsynchronizowanego dopasowania wysłanych żądań do backendu i odpowiedzi z niego**.
|
|
|
|
Jednakże, istnieje problem z desynchronizacją kolejki odpowiedzi. Jeśli atakujący wyśle atak HTTP Response smuggling i odpowiedzi na **początkowe żądanie oraz smuggled one są natychmiastowo odpowiadane**, odpowiedź smuggled nie zostanie wstawiona do kolejki odpowiedzi ofiary, ale **zostanie po prostu odrzucona jako błąd**.
|
|
|
|
.png>)
|
|
|
|
Dlatego konieczne jest, aby **smuggled** **żądanie** **zajmowało więcej czasu na przetworzenie** w serwerze backendowym. W związku z tym, w momencie, gdy smuggled żądanie jest przetwarzane, komunikacja z atakującym będzie zakończona.
|
|
|
|
Jeśli w tej konkretnej sytuacji **ofiara wysłała żądanie** i **smuggled żądanie jest odpowiadane przed** legitnym żądaniem, **odpowiedź smuggled zostanie wysłana do ofiary**. W związku z tym atakujący będzie **kontrolował żądanie "wykonane" przez ofiarę**.
|
|
|
|
Co więcej, jeśli **atakujący następnie wykona żądanie** i **legitna odpowiedź** na **żądanie ofiary** jest **odpowiadana** **przed** żądaniem atakującego. **Odpowiedź dla ofiary zostanie wysłana do atakującego**, **kradnąc** odpowiedź dla ofiary (która może zawierać na przykład nagłówek **Set-Cookie**).
|
|
|
|
.png>)
|
|
|
|
.png>)
|
|
|
|
### Wiele zagnieżdżonych wstrzyknięć
|
|
|
|
Inną **interesującą różnicą** w porównaniu do powszechnego **HTTP Request Smuggling** jest to, że w powszechnym ataku smuggling, **celem** jest **zmodyfikowanie początku żądania ofiary**, aby wykonało nieoczekiwaną akcję. W **ataku HTTP Response smuggling**, ponieważ **wysyłasz pełne żądania**, możesz **wstrzyknąć w jednym ładunku dziesiątki odpowiedzi**, które będą **zdesynchronizować dziesiątki użytkowników**, którzy będą **otrzymywać** **wstrzyknięte** **odpowiedzi**.
|
|
|
|
Oprócz możliwości **łatwiejszego rozprzestrzenienia dziesiątek exploitów** wśród legitnych użytkowników, może to również być użyte do spowodowania **DoS** na serwerze.
|
|
|
|
### Organizacja exploitów
|
|
|
|
Jak wcześniej wyjaśniono, aby wykorzystać tę technikę, konieczne jest, aby **pierwsza smuggled wiadomość** w serwerze **wymagała dużo czasu na przetworzenie**.
|
|
|
|
To **czasochłonne żądanie jest wystarczające**, jeśli chcemy tylko **spróbować ukraść odpowiedź ofiary**. Ale jeśli chcesz przeprowadzić bardziej złożony exploit, to będzie to wspólna struktura dla exploita.
|
|
|
|
Przede wszystkim **początkowe** żądanie wykorzystujące **HTTP** **Request** **smuggling**, następnie **czasochłonne żądanie** i potem **1 lub więcej żądań ładunkowych**, których odpowiedzi będą wysyłane do ofiar.
|
|
|
|
## Wykorzystywanie desynchronizacji kolejki odpowiedzi HTTP
|
|
|
|
### Przechwytywanie żądań innych użytkowników <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
|
|
|
|
Podobnie jak w przypadku znanych ładunków HTTP Request Smuggling, możesz **ukraść żądanie ofiary** z jedną ważną różnicą: W tym przypadku potrzebujesz tylko, aby **wysłana treść została odzwierciedlona w odpowiedzi**, **nie jest potrzebne trwałe przechowywanie**.
|
|
|
|
Najpierw atakujący wysyła ładunek zawierający **ostateczne żądanie POST z odzwierciedlonym parametrem** na końcu i dużym Content-Length.
|
|
|
|
.png>)
|
|
|
|
Następnie, gdy **początkowe żądanie** (niebieskie) zostało **przetworzone** i **podczas** gdy **śpiące** jest przetwarzane (żółte), **następne żądanie, które przychodzi od ofiary**, zostanie **dodane do kolejki tuż po odzwierciedlonym parametrze**:
|
|
|
|
.png>)
|
|
|
|
Następnie **ofiara** otrzyma **odpowiedź** na **śpiące** żądanie, a jeśli w międzyczasie **atakujący** **wysłał** **kolejne** **żądanie**, **odpowiedź z żądania odzwierciedlonej treści zostanie mu wysłana**.
|
|
|
|
## Desynchronizacja odpowiedzi
|
|
|
|
Do tego momentu nauczyliśmy się, jak wykorzystywać ataki HTTP Request Smuggling, aby **kontrolować** **żądanie**, **którego** **odpowiedź** **klient** ma **otrzymać** i jak można następnie **ukraść odpowiedź, która była przeznaczona dla ofiary**.
|
|
|
|
Ale nadal możliwe jest **jeszcze większe zdesynchronizowanie** odpowiedzi.
|
|
|
|
Istnieją interesujące żądania, takie jak **żądanie HEAD**, które są określone, aby nie miały **żadnej treści w ciele odpowiedzi** i które powinny (muszą) **zawierać Content-Length** żądania, jak **gdyby to było żądanie GET**.
|
|
|
|
Dlatego, jeśli atakujący **wstrzyknie** **żądanie HEAD**, jak na tych obrazkach:
|
|
|
|
.png>)
|
|
|
|
Następnie, **gdy niebieskie zostanie odpowiedziane atakującemu**, następne żądanie ofiary zostanie wprowadzone do kolejki:
|
|
|
|
.png>)
|
|
|
|
Następnie **ofiara** otrzyma **odpowiedź** z **żądania HEAD**, które **będzie zawierać Content-Length, ale żadnej treści**. Dlatego proxy **nie wyśle tej odpowiedzi** do ofiary, ale **czeka** na jakąś **treść**, która w rzeczywistości będzie **odpowiedzią na żółte żądanie** (również wstrzyknięte przez atakującego):
|
|
|
|
.png>)
|
|
|
|
### Zamieszanie treści
|
|
|
|
Podążając za poprzednim przykładem, wiedząc, że możesz **kontrolować ciało** żądania, którego odpowiedź ma otrzymać ofiara i że **odpowiedź HEAD** zazwyczaj zawiera w swoich nagłówkach **Content-Type i Content-Length**, możesz **wysłać żądanie jak poniższe**, aby **spowodować XSS** u ofiary, nawet jeśli strona nie jest podatna na XSS:
|
|
|
|
.png>)
|
|
|
|
### Zatrucie pamięci podręcznej
|
|
|
|
Wykorzystując wcześniej omówioną desynchronizację odpowiedzi ataku Zamieszanie treści, **jeśli pamięć podręczna przechowuje odpowiedź na żądanie wykonane przez ofiarę, a ta odpowiedź jest wstrzyknięta, powodując XSS, to pamięć podręczna jest zatruta**.
|
|
|
|
Złośliwe żądanie zawierające ładunek XSS:
|
|
|
|
.png>)
|
|
|
|
Złośliwa odpowiedź dla ofiary, która zawiera nagłówek wskazujący pamięci podręcznej, aby przechować odpowiedź:
|
|
|
|
.png>)
|
|
|
|
{% hint style="warning" %}
|
|
Zauważ, że w tym przypadku, jeśli **"ofiara" jest atakującym**, może teraz przeprowadzić **zatrucie pamięci podręcznej w dowolnych adresach URL**, ponieważ może **kontrolować adres URL, który ma być przechowywany** z złośliwą odpowiedzią.
|
|
{% endhint %}
|
|
|
|
### Oszustwo pamięci podręcznej w sieci
|
|
|
|
Ten atak jest podobny do poprzedniego, ale **zamiast wstrzykiwać ładunek do pamięci podręcznej, atakujący będzie przechowywał informacje ofiary w pamięci podręcznej:**
|
|
|
|
.png>)
|
|
|
|
### Rozdzielanie odpowiedzi
|
|
|
|
**Celem** tego ataku jest ponowne wykorzystanie **desynchronizacji** **odpowiedzi**, aby **sprawić, że proxy wyśle 100% odpowiedź wygenerowaną przez atakującego**.
|
|
|
|
Aby to osiągnąć, atakujący musi znaleźć punkt końcowy aplikacji webowej, który **odzwierciedla pewne wartości w odpowiedzi** i **zna długość treści odpowiedzi HEAD**.
|
|
|
|
Wyśle **exploit** jak:
|
|
|
|
.png>)
|
|
|
|
Po tym, jak pierwsze żądanie zostanie rozwiązane i odesłane do atakującego, **żądanie ofiary zostanie dodane do kolejki**:
|
|
|
|
.png>)
|
|
|
|
Ofiara otrzyma jako odpowiedź **odpowiedź HEAD + treść odpowiedzi drugiego żądania (zawierającą część odzwierciedlonych danych):**
|
|
|
|
.png>)
|
|
|
|
Jednakże, zauważ, jak **odzwierciedlone dane miały rozmiar zgodny z Content-Length** odpowiedzi **HEAD**, co **wygenerowało ważną odpowiedź HTTP w kolejce odpowiedzi**.
|
|
|
|
Dlatego **następne żądanie drugiej ofiary** będzie **otrzymywać** jako **odpowiedź coś całkowicie stworzonego przez atakującego**. Ponieważ odpowiedź jest całkowicie stworzona przez atakującego, może również **sprawić, że proxy przechowa odpowiedź**.
|
|
|
|
{% hint style="success" %}
|
|
Ucz się i ćwicz Hacking AWS:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
|
Ucz się i ćwicz Hacking GCP: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
|
|
|
<details>
|
|
|
|
<summary>Wsparcie HackTricks</summary>
|
|
|
|
* Sprawdź [**plany subskrypcyjne**](https://github.com/sponsors/carlospolop)!
|
|
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Podziel się sztuczkami hackingowymi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repozytoriów github.
|
|
|
|
</details>
|
|
{% endhint %}
|