Atak na systemy front-end-back-end, który pozwala nam włamać się do żądań stron trzecich

Ujawnił szczegóły nowego ataku na witryny korzystające z modelu front-end-back-end, takie jak te działające za pośrednictwem sieci dostarczania treści, modułów równoważenia obciążenia lub serwerów proxy. Atak umożliwia poprzez wysłanie określonych żądań wklinowanie się w treść innych żądań przetwarzanych w tym samym wątku pomiędzy frontendem a backendem. Zaproponowaną metodę udało się z powodzeniem wykorzystać do zorganizowania ataku, który umożliwił przechwycenie parametrów uwierzytelniających użytkowników serwisu PayPal, który w ramach programu informującego o obecności niezałatanych luk zapłacił badaczom około 40 tys. dolarów. Atak dotyczy także witryn korzystających z sieci dostarczania treści Akamai.

Sedno problemu polega na tym, że frontendy i backendy często zapewniają różne poziomy wsparcia dla protokołu HTTP, ale jednocześnie hermetyzują żądania od różnych użytkowników we wspólnym kanale. Aby połączyć żądania odbierające frontend i żądania przetwarzania backendu, ustanawiane jest długotrwałe połączenie TCP, przez które żądania użytkowników są przesyłane w łańcuchu jeden po drugim, oddzielane za pomocą protokołu HTTP. Aby oddzielić żądania, nagłówki „Content-Length” (określa całkowity rozmiar danych w żądaniu) i „Kodowanie transferu: podzielone"(umożliwia przesyłanie danych w częściach, określając bloki o różnych rozmiarach w formacie "{size}\r\n{block}\r\n{size}\r\n{block}\r\n0").

Problem pojawia się, jeśli frontend obsługuje tylko „Długość treści”, ale ignoruje „Kodowanie transferu: fragmentaryczne” (na przykład zrobił to Akamai CDN) lub odwrotnie. Jeśli obie strony obsługują Transfer-Encoding: fragmentaryczne, funkcje implementacji analizatorów nagłówków HTTP można wykorzystać do ataku (na przykład, gdy front-end ignoruje linie takie jak „Transfer-Encoding: xchunked”, „Transfer-Encoding: chunked ”, „Kodowanie transferu”:[tab]porcja”, „X: X[\n]Kodowanie transferu: fragmentacja”, „Kodowanie transferu[\n]: fragmentacja” lub „Kodowanie transferu: fragmentacja” oraz backend pomyślnie je przetwarza).

W takim przypadku osoba atakująca może wysłać żądanie zawierające zarówno nagłówki „Content-Length”, jak i „Transfer-Encoding: chunked”, ale rozmiar w polu „Content-Length” nie odpowiada rozmiarowi podzielonego łańcucha, który jest mniejsza od wartości rzeczywistej. Jeśli frontend przetworzy i przekaże żądanie zgodnie z „Długością treści”, a backend czeka na zakończenie bloku w oparciu o „Transfer-Encoding: chunked”, wówczas koniec danych w oparciu o „Transfer-Encoding: chunked” nastąpi zostanie określony wcześniej, a pozostały koniec żądania atakujący znajdzie się na początku kolejnego żądania, tj. atakujący będzie mógł dołączyć dowolne dane na początku przesyłanego dalej żądania innej osoby.

Aby określić problem w używanej kombinacji frontend-backend, możesz wysłać takie żądanie za pośrednictwem frontendu:

POST /o HTTP/1.1
Host: przykład.com
Kodowanie transferu: podzielone
Content-Length: 4

1
Z
Q

Problem występuje, jeśli backend nie przetwarza żądania natychmiast i czeka na przybycie ostatniego bloku fragmentarycznych danych ograniczającego zero. Aby uzyskać pełniejszą kontrolę przygotowany specjalne narzędzie, które testuje również możliwe metody ukrywania nagłówka „Transfer-Encoding: chunked” przed frontendem.

Przeprowadzenie prawdziwego ataku zależy od możliwości zaatakowanej witryny, np. atakując aplikację internetową Trello, możesz zastąpić początek żądania (zastąp dane typu „PUT /1/members/1234... x=x&csrf =1234&username=testzzz&bio=cake”) i wyślij wiadomość zawierającą oryginalne żądanie użytkownika zewnętrznego i określony w nim plik cookie uwierzytelniający. W przypadku ataku na saas-app.com okazało się, że można w odpowiedzi zastąpić kod JavaScript, podstawiając go w jednym z parametrów żądania. W przypadku ataku na redhat.com wykorzystano wewnętrzny moduł obsługi w celu przekierowania na stronę atakującego (żądanie w formie „POST /search?dest=../assets/idx?redir=//[email chroniony]/HTTP/1.1").

Zastosowanie metody dla sieci dostarczania treści umożliwiło proste zastąpienie żądanej witryny poprzez podstawienie nagłówka „Host:”. Atak może również zostać wykorzystany do zatrucia zawartości systemów buforowania zawartości i wyodrębnienia poufnych danych z pamięci podręcznej. Uwieńczeniem metody była organizacja ataku na PayPal, który umożliwił przechwycenie haseł wysyłanych przez użytkowników podczas uwierzytelniania (zmodyfikowano żądanie iframe tak, aby wykonywało JavaScript w kontekście strony paypal.com/us/gifts, m.in. w którym nie zastosowano CSP (Polityki Bezpieczeństwa Treści).

Co ciekawe, w 2005 r. tak było zaproponowane zasadniczo podobna technika fałszowania żądań, która umożliwia fałszowanie danych w buforujących serwerach proxy (Tomcat, squid, mod_proxy) lub ominięcie blokowania zapory ogniowej poprzez określenie kilku żądań „GET” lub „POST” w ramach jednej sesji HTTP.

Źródło: opennet.ru