Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-27 07:01:09 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/http-response-smuggling-desync.md
Translator workflow 5e0daf0e23 Translated to Polish
2024-02-11 01:46:25 +00:00

10 KiB
Raw Blame History

HTTP Response Smuggling / Desync

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

Technika opisana w tym poście została zaczerpnięta z filmu: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s

Desynchronizacja kolejki żądań HTTP

Przede wszystkim, ta technika wykorzystuje podatność na HTTP Request Smuggling, więc musisz wiedzieć, czym jest:

Główna różnica między tą techniką a zwykłym HTTP Request smuggling polega na tym, ż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 nie 1,5 żądania, jak w przypadku wykorzystania HTTP Request smuggling, ale 2 pełne żądania, aby dezynchronizować kolejkę odpowiedzi proxy.

Dzieje się tak, ponieważ będziemy w stanie dezynchronizować kolejkę odpowiedzi, dzięki czemu odpowiedź na legitymacyjne żądanie ofiary zostanie wysłana do atakującego, lub przez wstrzyknięcie kontrolowanej przez atakującego zawartości w odpowiedź dla 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 istnieje problem dezynchronizacji kolejki odpowiedzi. Jeśli atakujący wyśle atak HTTP Response smuggling i odpowiedzi na początkowe żądanie i wstrzyknięte żądanie zostaną natychmiast odpowiedziane, wstrzyknięta odpowiedź nie zostanie wstawiona do kolejki odpowiedzi ofiary, ale zostanie po prostu odrzucona jako błąd.

Dlatego konieczne jest, aby wstrzyknięte żądanie zajęło więcej czasu na przetworzenie w serwerze backendowym. Dzięki temu, gdy wstrzyknięte żądanie zostanie przetworzone, komunikacja z atakującym zostanie zakończona.

Jeśli w tej konkretnej sytuacji ofiara wysłała żądanie, a wstrzyknięte żądanie zostanie odpowiedziane przed legitymacyjnym żądaniem, wstrzyknięta odpowiedź zostanie wysłana do ofiary. W ten sposób atakujący kontroluje żądanie "wykonane" przez ofiarę.

Ponadto, jeśli atakujący wykonuje żądanie, a legitymacyjna 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).

Wielokrotne zagnieżdżone wstrzyknięcia

Inną ciekawą różnicą w porównaniu do zwykłego HTTP Request Smuggling jest to, że w przypadku zwykłego ataku smugglingowego celem jest modyfikacja początku żądania ofiary, aby wykonało ono nieoczekiwane działanie. W przypadku ataku HTTP Response smuggling, wysyłasz pełne żądania, więc możesz wstrzyknąć w jednym payloadzie dziesiątki odpowiedzi, które będą dezynchronizować dziesiątki użytkowników, którzy będą odbierać wstrzyknięte odpowiedzi.

Oprócz możliwości łatwiejszego rozpowszechniania dziesiątek exploitów wśród prawowitych 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 wstrzyknięta wiadomość do serwera zajmowała dużo czasu na przetworzenie.

To żądanie czasochłonne wystarczy, 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 exploitu.

Najpierw początkowe żądanie wykorzystujące HTTP Request smuggling, następnie żądanie czasochłonne i następnie 1 lub więcej żądań payloadowych, których odpowiedzi zostaną wysłane do ofiar.

Wykorzystywanie dezynchronizacji kolejki odpowiedzi HTTP

Przechwytywanie żądań innych użytkowników

Podobnie jak w przypadku znanych payloadów HTTP Request Smuggling, 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 potrzebne trwałe przechowywanie.

Najpierw atakujący wysyła payload zawierający ostateczne żądanie POST z odzwierciedlonym parametrem na końcu i dużą wartość Content-Length

Następnie, gdy początkowe żądanie (niebieskie) zostanie przetworzone, a czasochłonne żądanie (żółte) jest przetwarzane, następne żądanie, które przychodzi od ofiary, zostanie dodane do kolejki tuż po odzwierciedlonym parametrze:

Następnie, ofiara otrzyma odpowiedź na żądanie czasochłonne i jeśli w międzyczasie atakujący wyśle kolejne żądanie, **odpowiedź na ż

Zamieszanie treści

Kontrolując treść żądania, którego odpowiedź otrzyma ofiara, i wiedząc, że odpowiedź typu HEAD zwykle zawiera w nagłówkach typ zawartości (Content-Type) i długość zawartości (Content-Length), można wysłać żądanie takie jak poniższe, aby spowodować XSS w ofierze, nawet jeśli strona nie jest podatna na XSS:

Zatrucie pamięci podręcznej

Wykorzystując wcześniej omawiany atak dezynchronizacji odpowiedzi Content Confusion, 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, która zawiera nagłówek wskazujący pamięci podręcznej, aby przechować odpowiedź:

{% hint style="warning" %} Zauważ, że w tym przypadku, jeśli "ofiara" jest atakującym, może teraz przeprowadzać zatrucie pamięci podręcznej w dowolnych adresach URL, ponieważ może kontrolować URL, który zostanie zapisany w pamięci podręcznej wraz z złośliwą 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 dezynchronizacji odpowiedzi w celu spowodowania, że serwer proxy wyśle odpowiedź w 100% wygenerowaną przez atakującego.

Aby to osiągnąć, atakujący musi znaleźć punkt końcowy aplikacji internetowej, który odbija pewne wartości w odpowiedzi i zna długość zawartości odpowiedzi typu HEAD.

Wyśle on złośliwe żądanie, takie jak:

Po rozwiązaniu i odesłaniu pierwszego żądania do atakującego, żądanie ofiary zostaje dodane do kolejki:

Ofiara otrzyma jako odpowiedź odpowiedź typu HEAD + zawartość odpowiedzi drugiego żądania (zawierającą część odbijanych danych):

Zauważ jednak, że odbite dane miały rozmiar zgodny z długością zawartości odpowiedzi HEAD, co spowodowało wygenerowanie poprawnej odpowiedzi HTTP w kolejce odpowiedzi.

Dlatego następne żądanie drugiej ofiary otrzyma jako odpowiedź coś, co zostało całkowicie spreparowane przez atakującego. Ponieważ odpowiedź jest całkowicie spreparowana przez atakującego, może on również spowodować zapisanie odpowiedzi w pamięci podręcznej serwera proxy.

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks: