10 KiB
HTTP Response Smuggling / Desync
Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!
Inne sposoby wsparcia HackTricks:
- Jeśli chcesz zobaczyć swoją firmę reklamowaną w HackTricks lub pobrać HackTricks w formacie PDF, sprawdź PLANY SUBSKRYPCYJNE!
- Zdobądź oficjalne gadżety PEASS & HackTricks
- Odkryj Rodzinę PEASS, naszą kolekcję ekskluzywnych NFT
- Dołącz do 💬 grupy Discord lub grupy telegramowej lub śledź nas na Twitterze 🐦 @carlospolopm.
- Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do HackTricks i HackTricks Cloud na GitHubie.
Technika tej publikacji została zaczerpnięta z wideo: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s
Desynchronizacja Kolejki Żądań HTTP
Po pierwsze, ta technika wykorzystuje podatność na Desynchronizację Żądań HTTP, więc musisz wiedzieć, co to jest:
Główną różnicą między tą techniką a zwykłym Desynchronizacją Żądań HTTP jest to, że zamiast atakować żądanie ofiary, dodając do niego prefiks, będziemy ujawniać lub modyfikować odpowiedź, którą otrzymuje ofiara. Robimy to, wysyłając 2 kompletnie różne żądania, aby desynchronizować kolejkę odpowiedzi proxy.
Ponieważ będziemy w stanie desynchronizować kolejkę odpowiedzi, odpowiedź z legitymalnego żądania ofiary zostanie wysłana do atakującego, lub przez wstrzyknięcie kontrolowanej treści atakującego w odpowiedź do ofiary.
Desynchronizacja Potoku HTTP
HTTP/1.1 pozwala na żądanie różnych zasobów bez konieczności oczekiwania na poprzednie. Dlatego, jeśli jest proxy pośrodku, to zadaniem proxy jest utrzymywanie zsynchronizowanego dopasowania wysłanych żądań do backendu i odpowiedzi z niego.
Jednakże, istnieje problem desynchronizacji kolejki odpowiedzi. Jeśli atakujący wysyła atak Desynchronizacji Odpowiedzi HTTP i odpowiedzi na początkowe żądanie i to podszyte są odpowiedziane natychmiast, odpowiedź podszyta nie zostanie wstawiona do kolejki odpowiedzi ofiary, ale po prostu zostanie odrzucona jako błąd.
Dlatego konieczne jest, aby podszyte żądanie zajęło więcej czasu na przetworzenie w serwerze backendowym. Dlatego, gdy podszyte żądanie zostanie przetworzone, komunikacja z atakującym będzie zakończona.
Jeśli w tej konkretnej sytuacji ofiara wysłała żądanie i podszyte żądanie zostanie odpowiedziane przed prawidłowym żądaniem, podszyta odpowiedź zostanie wysłana do ofiary. W rezultacie atakujący będzie kontrolować żądanie "wykonane" przez ofiarę.
Co więcej, jeśli atakujący wykonuje żądanie i legitymacyjna odpowiedź na żądanie ofiary jest odpowiedziana przed żądaniem atakującego. Odpowiedź do ofiary zostanie wysłana do atakującego, kradnąc odpowiedź dla ofiary (która może zawierać na przykład nagłówek Set-Cookie).
Wielokrotne Zagnieżdżone Wstrzyknięcia
Inną ciekawą różnicą w porównaniu z zwykłym Desynchronizacją Żądań HTTP jest to, że w zwykłym ataku desynchronizacji żądań HTTP, celem jest modyfikacja początku żądania ofiary, aby wykonała ona nieoczekiwane działanie. W ataku Desynchronizacji Odpowiedzi HTTP, wysyłając pełne żądania, można wstrzyknąć w jednym ładunku dziesiątki odpowiedzi, które będą desynchronizować dziesiątki użytkowników, którzy będą odbierać wstrzyknięte odpowiedzi.
Oprócz możliwości łatwiejszego rozprowadzania dziesiątek exploitów wśród prawidłowych użytkowników, można to również wykorzystać do spowodowania DoS na serwerze.
Organizacja Exploitu
Jak wyjaśniono wcześniej, aby wykorzystać tę technikę, konieczne jest, aby pierwsza podszyta wiadomość do serwera zajmowała dużo czasu na przetworzenie.
Ten czasochłonny żądanie jest wystarczający, jeśli chcemy spróbować ukraść odpowiedź ofiary. Ale jeśli chcesz przeprowadzić bardziej złożony exploit, to będzie to powszechna struktura dla exploitu.
Po pierwsze początkowe żądanie wykorzystujące Desynchronizację Żądań HTTP, następnie czasochłonne żądanie, a następnie 1 lub więcej żądań ładunkowych, których odpowiedzi zostaną wysłane do ofiar.
Wykorzystanie Desynchronizacji Kolejki Odpowiedzi HTTP
Przechwytywanie żądań innych użytkowników
Podobnie jak w przypadku znanych ładunków Desynchronizacji Żądań HTTP, możesz ukraść żądanie ofiary z jedną ważną różnicą: W tym przypadku potrzebujesz, aby wysłana treść została odzwierciedlona w odpowiedzi, nie jest wymagane 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 zaraz po odzwierciedlonym parametrze:
Następnie ofiara otrzyma odpowiedź na żądanie śpiące i jeśli w międzyczasie atakujący wysłał kolejne żądanie, odpowiedź z żądania odzwierciedlonej treści zostanie wysłana do niego.
Desynchronizacja Odpowiedzi
Do tej pory nauczyliśmy się wykorzystywać ataki Desynchronizacji Żądań HTTP do kontroli żądania, na które odpowiedź otrzyma klient i jak można wtedy ukraść odpowiedź, która była przeznaczona dla ofiary.
Ale nadal można jeszcze bardziej desynchronizować odpowiedzi.
Istnieją interesujące żądania, takie jak żądanie HEAD, które są określone jako nieposiadające żadnej zawartoś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óra będzie zawierać Content-Length, ale w ogóle nie będzie zawierać treści. Dlatego, proxy nie wyśle tej odpowiedzi do ofiary, ale będzie czekać na jakąś treść, która faktycznie będzie odpowiedzią na żądanie żółte (również wstrzyknięte przez atakującego):
Zamieszanie w treści
W oparciu o poprzedni przykład, mając świadomość, że można kontrolować treść żądania, którego odpowiedź otrzyma ofiara, a odpowiedź HEAD zazwyczaj zawiera w nagłówkach Content-Type i Content-Length, można wysłać żądanie takie jak to poniżej, aby wywołać XSS u ofiary, nawet jeśli strona nie jest podatna na XSS:
Zatrucie pamięci podręcznej
Wykorzystując wcześniej omawiany atak zamieszania treści odpowiedzi desynchronizacji, jeśli pamięć podręczna przechowuje odpowiedź na żądanie wykonane przez ofiarę, a ta odpowiedź jest wstrzyknięta i powoduje XSS, to pamięć podręczna jest zatruta.
Złośliwe żądanie zawierające ładunek XSS:
Złośliwa odpowiedź dla ofiary zawierająca nagłówek wskazujący pamięci podręcznej, aby przechowywała odpowiedź:
{% 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 zostanie zapisany w pamięci podręcznej za pomocą złośliwej odpowiedzi. {% endhint %}
Oszustwo pamięci podręcznej sieci Web
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:
Podział odpowiedzi
Celem tego ataku jest ponowne wykorzystanie desynchronizacji odpowiedzi w celu przekazania przez proxy odpowiedzi w 100% wygenerowanej przez atakującego.
Aby osiągnąć ten cel, atakujący musi znaleźć punkt końcowy aplikacji internetowej, który odzwierciedla pewne wartości w odpowiedzi i znać długość treści odpowiedzi HEAD.
Wyśle exploit tak jak:
Po rozwiązaniu i odesłaniu pierwszego żądania do atakującego, żądanie ofiary zostaje dodane do kolejki:
Ofiara otrzyma jako odpowiedź odpowiedź HEAD + treść odpowiedzi drugiego żądania (zawierająca część odzwierciedlonych danych):
Zauważ jednak, że odzwierciedlone dane miały rozmiar zgodny z Content-Length odpowiedzi HEAD, co wygenerowało poprawną odpowiedź HTTP w kolejce odpowiedzi.
Dlatego następne żądanie drugiej ofiary otrzyma jako odpowiedź coś całkowicie spreparowanego przez atakującego. Ponieważ odpowiedź jest całkowicie spreparowana przez atakującego, może on również spowodować, że proxy przechowa odpowiedź.