Znaleźli nową wersję ataku HTTP Request Smuggling

L systemy webowe, w których frontend akceptuje połączenia przez HTTP/2 i przekazuje je do backendu przez HTTP / 1.1 hzostały narażone na nową wersję ataku „HTTP Request Smuggling”, Pozwala, poprzez wysyłanie specjalnie zaprojektowanych żądań klientów, podzielić w treści żądań innych użytkowników przetwarzanych w tym samym przepływie między frontendem a backendem.

Atak może służyć do wstrzykiwania złośliwego kodu JavaScript w sesji z legalną witryną omiń systemy ograniczania dostępu i przechwyć parametry uwierzytelniania.

Autor opracowania wykazali możliwość ataku na systemy Netflix, Verizon, Bitbucket, Netlify CDN i Atlassiani otrzymał 56.000 5 dolarów w programach nagród za identyfikację luk w zabezpieczeniach. Problem został również potwierdzony w produktach FXNUMX Networks.

Problem częściowo wpływa na mod_proxy na serwerze http Apache (CVE-2021-33193), poprawki oczekiwane w wersji 2.4.49 (programiści zostali powiadomieni o problemie na początku maja i otrzymali 3 miesiące na jego naprawę). W nginx w poprzedniej wersji (1.21.1) zablokowano możliwość jednoczesnego określenia nagłówków „Content-Length” i „Transfer-Encoding”.

Zasada działania nowej metody pasujących żądań w ruchu jest podobna do luki odkrytej przez tego samego badacza dwa lata temu, ale ogranicza się do interfejsów, które akceptują żądania przez HTTP/1.1.

Klasyczny atak „HTTP Request Smuggling” opierał się na fakcie, że frontendy i backendy inaczej interpretują użycie nagłówków HTTP „Content-Length” (określa całkowity rozmiar danych w żądaniu) i „Transfer-Encoding: chunked” ( umożliwia przesyłanie danych porcjami) ...

Na przykład, jeśli interfejs obsługuje tylko „Content-Length”, ale ignoruje „Transfer-Encoding: fragmented”, osoba atakująca może wysłać żądanie zawierające nagłówki „Content-Length” i „Transfer-Encoding: fragmented”, ale rozmiar pl "Długość treści" nie odpowiada rozmiarowi podzielonego łańcucha. W takim przypadku frontend przetworzy i przekieruje żądanie zgodnie z „Długością treści”, a backend będzie czekał na zakończenie bloku w oparciu o „Kodowanie transferu: podzielone”.

W przeciwieństwie do tekstowego protokołu HTTP/1.1, który jest analizowany na poziomie linii, HTTP / 2 to protokół binarny i manipuluje blokami dane o z góry określonym rozmiarze. Jednak HTTP / 2 użyj pseudo-nagłówków które odpowiadają zwykłym nagłówkom HTTP. Podczas interakcji z backendem z wykorzystaniem protokołu HTTP/1.1, frontend tłumaczy te pseudo-nagłówki w podobnych nagłówkach HTTP/1.1 HTTP. Problem w tym, że backend podejmuje decyzje o analizie transmisji na podstawie ustawionych przez frontend nagłówków HTTP, bez znajomości parametrów pierwotnego żądania.

Nawet w postaci pseudonagłówków wartości „Długość treści” i „kodowanie transferowe” mogą być przesyłane strumieniowo, chociaż nie są używane w HTTP/2, ponieważ rozmiar wszystkich danych jest określany w osobnym polu. Jednak podczas konwertowania żądania HTTP/2 na HTTP/1.1 te nagłówki przechodzą i mogą być mylące dla zaplecza.

Istnieją dwie główne opcje ataku: H2.TE i H2.CL, w którym backend jest oszukiwany przez nieprawidłowe kodowanie transferu lub wartość długości treści, która nie odpowiada rzeczywistemu rozmiarowi treści żądania otrzymanego przez frontend za pośrednictwem protokołu HTTP/2.

Jako przykład ataku H2.CL podano niepoprawny rozmiar w pseudo-nagłówku długość treści przy składaniu wniosku HTTP / 2 do Netflix. To żądanie prowadzi do dodania nagłówka Długość treści HTTP podobnie przy dostępie do backendu przez HTTP / 1.1, ale ponieważ rozmiar w Content-Length jest mniejsza niż rzeczywista, część danych w kolejce jest przetwarzana jako początek następnego żądania.

Attack Tools zostały już dodane do Burp's Toolkit i są dostępne jako rozszerzenie Turbo Intruder. Serwery proxy sieci Web, systemy równoważenia obciążenia, akceleratory sieci Web, systemy dostarczania treści i inne konfiguracje, w których żądania są przekierowywane w schemacie frontend-backend, są podatne na ten problem.

źródło: https://portswigger.net


Bądź pierwszym który skomentuje

Zostaw swój komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

*

*

  1. Odpowiedzialny za dane: Miguel Ángel Gatón
  2. Cel danych: kontrola spamu, zarządzanie komentarzami.
  3. Legitymacja: Twoja zgoda
  4. Przekazywanie danych: Dane nie będą przekazywane stronom trzecim, z wyjątkiem obowiązku prawnego.
  5. Przechowywanie danych: baza danych hostowana przez Occentus Networks (UE)
  6. Prawa: w dowolnym momencie możesz ograniczyć, odzyskać i usunąć swoje dane.