Atak na systemy frontend-backend, umożliwiający wdzieranie się w zewnętrzne zapytania

Odkryto Szczegóły nowego ataku na strony korzystające z modelu frontend-backend, na przykład takie, które działają za pośrednictwem sieci dostarczania treści, load balancerów lub proxy. Atak umożliwia, poprzez wysyłanie określonych zapytań, włączanie się w zawartość innych zapytań, przetwarzanych w tym samym strumieniu między frontendem a backendem. Proponowana metoda została skutecznie zastosowana do przeprowadzenia ataku, który umożliwia przechwytywanie parametrów uwierzytelniania użytkowników serwisu PayPal, który wypłacił badaczom około 40 tysięcy dolarów w ramach programu informowania o istniejących lukach w zabezpieczeniach. Atak jest również stosowany w stronach korzystających z sieci dostarczania treści Akamai.

Istota problemu polega na tym, że frontendy i backendy często zapewniają różny poziom wsparcia dla protokołu HTTP, ale jednocześnie inkapsulują zapytania różnych użytkowników w wspólnym kanale. Dla połączenia przyjmującego zapytania frontendu i przetwarzającego zapytania backendu ustanawiane jest długotrwałe połączenie TCP, przez które transmitowane są zapytania użytkowników, przekazywane w łańcuchu jedno po drugim z podziałem środkami protokołu HTTP. Do rozdzielenia zapytań mogą być używane nagłówki „Content-Length” (określa całkowity rozmiar danych w zapytaniu) oraz „Transfer-Encoding: chunked„ (umożliwia przesyłanie danych w częściach, wskazując bloki różnej wielkości w formacie „{rozmiar}\r\n{blok}\r\n{rozmiar}\r\n{blok}\r\n0”).

Problem pojawia się, jeśli frontend obsługuje tylko „Content-Length”, ale ignoruje „Transfer-Encoding: chunked” (na przykład w taki sposób postępował CDN Akamai) lub odwrotnie. W przypadku obsługi „Transfer-Encoding: chunked” po obu stronach dla ataku mogą być wykorzystane cechy implementacji parserów nagłówków HTTP (na przykład, gdy frontend ignoruje linie typu „Transfer-Encoding: xchunked”, „Transfer-Encoding: chunked”, „Transfer-Encoding:[tab]chunked”, „X: X[\n]Transfer-Encoding: chunked”, „Transfer-Encoding[\n]: chunked” lub „Transfer-Encoding : chunked”, a backend je pomyślnie przetwarza).

W takim przypadku atakujący może wysłać żądanie, w którym jednocześnie wskazane są nagłówki „Content-Length” oraz „Transfer-Encoding: chunked”, ale rozmiar w „Content-Length” nie odpowiada rozmiarowi łańcucha chunked, który jest mniejszy od faktycznej wartości. Jeśli frontend przetworzy i przekieruje żądanie zgodnie z „Content-Length”, a backend będzie oczekiwał zakończenia bloku na podstawie „Transfer-Encoding: chunked”, to koniec danych na podstawie „Transfer-Encoding: chunked” zostanie określony wcześniej, a pozostały ogon żądania atakującego znajdzie się na początku następnego żądania, tzn. atakujący uzyska możliwość przyłączenia dowolnych danych do początku obcego żądania przesłanego później.

Aby zdiagnozować problem w używanej parze frontend-backend, można wysłać z frontendu żądanie w następującym formacie:

POST /about HTTP/1.1
Host: example.com
Transfer-Encoding: chunked
Content-Length: 4

1
Z
Q

Problem występuje, jeśli backend nie przetwarza natychmiast żądania i oczekuje na przybycie końcowego zerowego bloku ograniczającego chunked-danych. Aby przeprowadzić pełniejszą weryfikację, przygotowano specjalne narzędzie, które również testuje możliwe metody ukrywania nagłówka „Transfer-Encoding: chunked” przed frontendem.

Przeprowadzenie rzeczywistego ataku zależy od możliwości atakowanej witryny, na przykład podczas ataku na aplikację webową Trello można zmienić początek żądania (podstawiając dane w formacie „PUT /1/members/1234… x=x&csrf=1234&username=testzzz&bio=cake”) i wysłać wiadomość zawierającą oryginalne żądanie innego użytkownika oraz określone w nim pliki cookie uwierzytelniające. Podczas ataku na saas-app.com udało się podstawić kod JavaScript w odpowiedzi, poprzez jego podstawienie w jeden z parametrów żądania. W ataku na redhat.com wykorzystano wewnętrzny przetwornik do przekierowania na stronę atakującego (podstawiono żądanie w formacie „POST /search?dest=..../assets/idx?redir=//redhat.com@evil.net/ HTTP/1.1”).

Zastosowanie metody w sieciach dostarczania treści pozwalało na łatwą zamianę żądanego serwisu poprzez podstawienie nagłówka „Host:”. Atak ten można również zastosować do organizacji zarażania treści systemów pamięci podręcznej oraz wydobywania przechowywanych danych poufnych. Kulminacją zastosowania metody był atak na PayPal, który umożliwił przechwytywanie haseł wysyłanych przez użytkowników podczas uwierzytelniania (przeprowadzono zmianę zapytania iframe, aby wykonać JavaScript w kontekście strony paypal.com/us/gifts, dla której nie zastosowano CSP (Content Security Policy)).

Ciekawe, że w 2005 roku miała miejsce zaproponowana podobna technika zamiany zapytań, która pozwalała na modyfikację danych w pamięciach podręcznych (Tomcat, squid, mod_proxy) lub ominięcie blokad zapór sieciowych poprzez podanie kilku zapytań „GET” lub „POST” w ramach jednej sesji HTTP.

Źródło: opennet.ru