Firma PortSwigger, znana przede wszystkim z programu BurpSuite stanowiącego podstawę wielu testów penetracyjnych, początkiem sierpnia wyszła z inicjatywą HTTP/1.1 Must Die. Można sądzić, iż tak dosadna nazwa zastosowana przez jednego z kluczowych graczy w świecie bezpieczeństwa IT oznacza poważne problemy i możliwe masowe ataki z wykorzystaniem pewnej podatności. Warto więc od razu wyraźnie zaznaczyć, iż HTTP request smuggling, będącym przedmiotem opisywanej inicjatywy, jest znany od roku 2005 i dotyczy wyłącznie aplikacji korzystających z różnych load balancerów czy „ukrytych” za reverse proxy, a przy tym dostępnych z użyciem starszego protokołu HTTP/1.1.
Dlatego teoretycznie można założyć, iż w tym wypadku bardziej zagrożone są większe serwisy internetowe, bo z reguły load balancing jest stosowany do „rozłożenia” ruchu pomiędzy kilka serwerów aplikacyjnych – taka potrzeba rzadko występuje dla pojedynczych, prostych stron internetowych. Nie można jednak zapomnieć o hostingach, bo niektórzy operatorzy także korzystają z reverse proxy. Standardem jest serwer HTTP NGINX dostępny publicznie i przekierowujący ruch do lokalnie działającego serwera Apache, który z kolei odpowiada za adekwatną obsługę aplikacji (głównie pisanych w języku PHP). Jest to uzasadnione podejście z powodów stricte praktycznych – Apache obsługuje reguły rewrite w pliku .htaccess, więc użytkownik może dodawać własne reguły (m.in. dla systemów CMS, takich jak WordPress czy Drupal), bez potrzeby każdorazowego podejmowania jakichkolwiek czynności po stronie administratorów.
Na czym więc polega atak HTTP request smuggling? Głównym źródłem problemu są dwa nagłówki HTTP (Content-Length i Transfer-Encoding) oraz ewentualne różnice w ich obsłudze przez serwer „frontend” (z reguły load balancer) i często działający w ramach sieci wewnętrznej dany serwer aplikacyjny („backend”).
Specyfikacja protokołu HTTP sugeruje, aby w sytuacji użycia Content-Length i Transfer-Encoding w ramach jednego żądania, serwer brał pod uwagę wyłącznie wartość Transfer-Encoding. Jednak nie wszystkie serwery HTTP ściśle obsługują takowe wytyczne. Na stronie z opisem tego ataku podano interesujące przykłady.
W pewnej konfiguracji złośliwy request HTTP wystarczy ograniczyć do:
Dla takiego scenariusza serwer frontend uwzględniający Content-Length przekaże całość powyższego żądania do serwera backend, który jednak w większym stopniu przestrzega reguł zawartych w specyfikacji i w związku z tym kończy przetwarzanie żądania na pierwszym „fragmencie” (chunk). Pozostała część, czyli SMUGGLED, jest uznawana jako początek kolejnego żądania. Z innymi przykładami warto zapoznać się na podanej wyżej stronie.
Skutkiem udanego ataku może być przykładowo uzyskanie nieautoryzowanego dostępu do aplikacji czy przygotowanie kolejnego ataku, jakim jest reflected XSS. Wszystko zależy tak naprawdę od specyfiki aplikacji i konkretnego środowiska, dlatego też trudno wskazać konkretne zagrożenia.
Skutecznym i najlepszym zabezpieczeniem jest wymuszenie HTTP/2 na poziomie load balancera/reverse proxy, ale również w konfiguracji serwera backend. Niestety nie zawsze jest to możliwe rozwiązanie, ponieważ wciąż niektóre aplikacje mogą nie obsługiwać nowszej wersji protokołu HTTP. Inne podejście zakłada rozwiązanie bardziej programistyczne – odrzucenie żądań HTTP zawierających oba wspomniane nagłówki czy ogólnie bardziej rygorystyczne przestrzeganie specyfikacji.
W celu zapobiegania podobnym atakom zalecane mogłoby być wdrożenie wybranego rozwiązania WAF. Problem w tym, iż według autorów HTTP/1.1 Must Die niektóre WAF wprowadzają tę podatność do środowisk, w których wcześniej HTTP request smuggling nie występował.
Can I fix this with a WAF? Not reliably. In fact, we have observed some WAFs that introduce desync vulnerabilities to otherwise secure systems.
Znakomita większość serwisów, z których codziennie korzystamy, jak zaprojektowana w celu utrzymania high availability (wysokiej dostępności) i używa kilku load balancerów (aby awaria jednego nie spowodowała niedostępności środowiska). Absolutnie nie oznacza to, iż HTTP request smuggling jest globalnie występującym zagrożeniem i choćby ciężko określić ten rodzaj ataku jako najważniejszy element testów penetracyjnych – raczej jako podatność, która może wystąpić „przy okazji”.
