HTTP Response Smuggling / Desync
Last updated
Last updated
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Technika opisana w tym poście została zaczerpnięta z wideo: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s
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.
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.
Najpierw atakujący wysyła ładunek zawierający ostateczne żądanie POST z odzwierciedlonym parametrem na końcu i dużym Content-Length.
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.
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:
Następnie, gdy niebieskie zostanie odpowiedziane atakującemu, następne żądanie ofiary zostanie wprowadzone do kolejki:
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.
Złośliwe żądanie zawierające ładunek XSS:
Złośliwa odpowiedź dla ofiary, która zawiera nagłówek wskazujący pamięci podręcznej, aby przechować odpowiedź:
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.
Wyśle exploit jak:
Po tym, jak pierwsze żądanie zostanie rozwiązane i odesłane do atakującego, żądanie ofiary zostanie dodane do kolejki:
Ofiara otrzyma jako odpowiedź odpowiedź HEAD + treść odpowiedzi drugiego żądania (zawierającą część odzwierciedlonych danych):
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ź.
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
