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 desynchronizować kolejkę odpowiedzi proxy.
Dzieje się tak, ponieważ będziemy w stanie desynchronizować 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.
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 ten sposób, 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 legitnym żądaniem, smuggled response zostanie wysłana do ofiary. W ten sposób 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 odpowiedziana przed żądaniem atakującego. Odpowiedź do ofiary zostanie wysłana do atakującego, kradnąc odpowiedź do 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 smugglingowym, 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ą desynchronizować dziesiątki użytkowników, którzy będą otrzymywać wstrzyknięte odpowiedzi.
Oprócz możliwości łatwiejszego rozprzestrzeniania dziesiątek exploitów wśród legitnych użytkowników, może to być również 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 powszechna 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 wystarczy, że wysłany content będzie odzwierciedlony 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 odzwierciedlonego 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 desynchronizowanie 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 do atakującego, 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ź 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 z 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ź do 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 o ofierze 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)
