HTTP Response Smuggling / Desync

Reading time: 6 minutes

tip

Ucz się i ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Wsparcie HackTricks

Technika opisana w tym poście została zaczerpnięta z wideo: 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 typowym HTTP Request smuggling polega na tym, że zamiast atakować żądanie ofiary poprzez dodanie do niego 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 wstrzykiwanie treści kontrolowanej przez atakującego w odpowiedzi do ofiary.

Desync w 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, a odpowiedzi na początkowe żądanie i smuggled one są natychmiastowe, 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 momencie, gdy smuggled request jest przetwarzane, komunikacja z atakującym będzie zakończona.

Jeśli w tej konkretnej sytuacji ofiara wysłała żądanie i smuggled request jest odpowiedziane przed legitymnym żądaniem, smuggled response 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 legitymna odpowiedź na żądanie ofiary jest odpowiedziana 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).

Wiele zagnieżdżonych wstrzyknięć

Inna interesująca różnica w porównaniu do typowego HTTP Request Smuggling polega na tym, że w typowym 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 legitymnych 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ść do serwera 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 typowa 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

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.

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 wstrzykuje żądanie HEAD, jak na tych obrazach:

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):

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:

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:

Złośliwa odpowiedź dla ofiary, która zawiera nagłówek wskazujący pamięci podręcznej, aby przechować odpowiedź:

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 w pamięci podręcznej z złośliwą odpowiedzią.

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:

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:

Po rozwiązaniu pierwszego żądania i odesłaniu go do atakującego, żądanie ofiary zostaje 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, która wygenerowała 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ź w pamięci podręcznej.

tip

Ucz się i ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Wsparcie HackTricks