HTTP Response Smuggling / Desync
Technika tego posta 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ć, czym jest to:
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. Jest to osiągane poprzez wysłanie 2 kompletnych żądań, aby desynchronizować kolejkę odpowiedzi proxy, zamiast wysłania 1 żądania i pół, aby wykorzystać Desynchronizację Żądań HTTP.
Ponieważ będziemy w stanie desynchronizować kolejkę odpowiedzi, odpowiedź z legitymnego żądania ofiary zostanie wysłana do atakującego, lub poprzez wstrzyknięcie kontrolowanej przez atakującego zawartości w odpowiedzi 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 pochodzących 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 podrzucane są odpowiedzi natychmiast, odpowiedź podrzucana nie zostanie wstawiona do kolejki odpowiedzi ofiary, ale po prostu zostanie odrzucona jako błąd.
Dlatego konieczne jest, aby podrzucone żądanie zajęło więcej czasu na przetworzenie w serwerze backendowym. Dlatego, gdy podrzucone żądanie zostanie przetworzone, komunikacja z atakującym będzie zakończona.
Jeśli w tej konkretnej sytuacji ofiara wysłała żądanie i podrzucone żądanie zostanie odpowiedziane przed legitymnym żądaniem, podrzucona 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 legitymna odpowiedź na żądanie ofiary zostanie 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ń, celem jest modyfikacja początku żądania ofiary, aby wykonała ona nieoczekiwane działanie. W ataku Desynchronizacji Odpowiedzi HTTP, 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ą odbierać wstrzyknięte odpowiedzi.
Oprócz możliwości łatwiejszego rozprowadzania dziesiątek exploitów wśród legitymnych użytkowników, można to również wykorzystać do spowodowania DoS na serwerze.
Organizacja Exploitów
Jak wyjaśniono wcześniej, aby wykorzystać tę technikę, konieczne jest, aby pierwsza podrzucona 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 zawartość 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 zawartości zostanie wysłana do niego.
Desynchronizacja Odpowiedzi
Do tej pory nauczyliśmy się, jak wykorzystać ataki Desynchronizacji Żądań HTTP, aby kontrolować żądanie, którego odpowiedź klient otrzyma i jak można wtedy ukraść odpowiedź, która była przeznaczona dla ofiary.
Ale nadal istnieje możliwość jeszcze bardziej desynchronizować odpowiedzi.
Istnieją interesujące żądania, takie jak HEAD, które są określone jako nieposiadające żadnej zawartości w ciele odpowiedzi i które powinny (muszą) zawierać Content-Length żądania tak, jakby to był żądanie GET.
Dlatego, jeśli atakujący wstrzykuje żądanie HEAD, jak na tych obrazach:
Wtedy, gdy niebieskie zostanie odpowiedziane atakującemu, następne żądanie ofiary zostanie wprowadzone do kolejki:
Następnie ofiara otrzyma odpowiedź na żądanie HEAD, które 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ętą przez atakującego):
Zamieszanie w treści
Po poprzednim przykładzie, wiedząc, że możesz kontrolować treść żądania, którego odpowiedź otrzyma ofiara i że odpowiedź HEAD zazwyczaj zawiera w nagłówkach Content-Type i Content-Length, możesz wysłać żądanie takie jak poniższe, 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 zostaje 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ź:
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.
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:
Rozszczepienie odpowiedzi
Celem tego ataku jest ponowne wykorzystanie desynchronizacji odpowiedzi w celu spowodowania, że serwer proxy wyśle odpowiedź w 100% wygenerowaną 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 serwer proxy przechowa odpowiedź.
Last updated
