Badacze z uniwersytetów w Hamburgu i Kolonii
nową technikę ataków na sieci dostarczania treści i serwery proxy pamięci podręcznej — (Cache-Poisoned Denial-of-Service). Atak pozwala na uzyskanie odmowy dostępu do strony poprzez zanieczyszczenie pamięci podręcznej.
Problem wynika z faktu, że CDN nie tylko buforują pomyślnie zrealizowane zapytania, ale także sytuacje, w których serwer http zwraca błąd. Zazwyczaj, gdy występują problemy z tworzeniem zapytań, serwer zwraca błąd 400 (Bad Request), wyjątkiem jest tylko IIS, który zwraca błąd 404 (Not Found) dla zbyt dużych nagłówków. Standard zezwala na buforowanie tylko błędów z kodami 404 (Not Found), 405 (Method Not Allowed), 410 (Gone) oraz 501 (Not Implemented), jednak niektóre CDN również buforują odpowiedzi z kodem 400 (Bad Request), które zależą od wysłanego zapytania.
Napastnicy mogą spowodować, że oryginalny zasób zwróci błąd „400 Bad Request” poprzez wysłanie zapytania z określonymi nagłówkami HTTP. Te nagłówki nie są uwzględniane przez CDN, dlatego do pamięci podręcznej trafi informacja o niemożności uzyskania dostępu do strony, a wszystkie inne poprawne zapytania użytkowników przed upływem czasu mogą prowadzić do wyświetlenia błędu, mimo że oryginalna strona poprawnie zwraca zawartość.
Aby wymusić serwer HTTP do zwrócenia błędu, zaproponowano trzy warianty ataku:
- HMO (HTTP Method Override) — atakujący może nadpisać pierwotną metodę zapytania za pomocą nagłówków „X-HTTP-Method-Override”, „X-HTTP-Method” lub „X-Method-Override”, które są wspierane przez niektóre serwery, ale nie uwzględniane w CDN. Na przykład, można zmienić pierwotną metodę „GET” na zabronioną metodę „DELETE” lub metodę „POST”, która nie jest stosowana w przypadku zasobów statycznych;
- HHO (HTTP Header Oversize) — atakujący może dostosować rozmiar nagłówka w taki sposób, aby przekraczał limit oryginalnego serwera, ale nie podlegał ograniczeniom CDN. Na przykład, Apache httpd ogranicza rozmiar nagłówka do 8 KB, a CDN Amazon Cloudfront dopuszcza nagłówki do 20 KB;
- HMC (HTTP Meta Character) — atakujący może wprowadzić do zapytania znaki specjalne (\n, \r, \a), które są uznawane za niedopuszczalne na oryginalnym serwerze, ale ignorowane w CDN.
Najbardziej narażony na atak okazał się CDN CloudFront, używany w Amazon Web Services (AWS). Obecnie firma Amazon już rozwiązała problem poprzez zablokowanie buforowania błędów, ale uzyskanie dodatkowej ochrony zajęło badaczom ponad trzy miesiące. Problem dotknął również Cloudflare, Varnish, Akamai, CDN77 i
Fastly, jednak atak przez nie jest ograniczony do serwerów docelowych, na których używany jest IIS, ASP.NET, i . , co sprawia, że potencjalnie 11% domen Ministerstwa Obrony USA, 16% URL z bazy HTTP Archive oraz około 30% z 500 największych stron w rankingu Alexa mogą być narażone na atak.
Jako tymczasowe rozwiązanie blokady ataku po stronie serwisu można użyć nagłówka „Cache-Control: no-store”, który zabrania buforowania odpowiedzi. W niektórych CDN, na przykład w
CloudFront i Akamai, można na poziomie ustawień profilu wyłączyć buforowanie błędów. Aby zapewnić dodatkową ochronę, można również korzystać z zapór aplikacji internetowych (WAF, Web Application Firewall), ale muszą być one wdrażane po stronie CDN przed hostami, które realizują buforowanie.
Źródło: opennet.ru
