Ucz się i ćwicz Hacking AWS:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Ucz się i ćwicz Hacking GCP: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* **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.
**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)
**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**.
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**.
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**).
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.
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.
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**.
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**:
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**.
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**.
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**.
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):
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:
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**.
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ą.
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:**
**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**.
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:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Ucz się i ćwicz Hacking GCP: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* **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.
