Wszystko, co chcieliście wiedzieć o błędach SSRF, ale baliście się zapytać

Oczywiście liczymy na to, że nie boicie się pytać, zdajemy sobie też sprawę, że całkiem możliwe, że o błędach SSRF można napisać jeszcze więcej – ale postaraliśmy się je opisać wystarczająco wyczerpująco dla większości czytelników. Zapraszamy do lektury.

Jeśli interesujecie się bezpieczeństwem aplikacji WWW, to na pewno nie musimy wam tłumaczyć, czym jest OWASP Top 10. Jeśli jednak mielibyśmy przygotować listę kandydatów do OWASP Top 10, którym niewiele punktów zabrakło do znalezienia się w finałowej dziesiątce, to bez wątpienia na tej liście znajdzie się błąd typu SSRF (server-side request forgery). Na czym polega i jakie skutki może mieć dla bezpieczeństwa waszej aplikacji? Odpowiedzi znajdziecie poniżej.

Co to jest SSRF?

Podatność SSRF, w podstawowym wydaniu polega na tym, że atakujący wykorzystuje serwer aplikacji (backend) do wysyłania zapytań HTTP do innych serwerów w organizacji (możliwe jest też wykorzystanie innych protokołów, niemniej HTTP(S) jest najczęściej spotykanym). Zasadniczym nadużyciem jest wykorzystanie zaufania, jakim obdarzony jest serwer w sieci wewnętrznej, przez inne serwery w infrastrukturze firmy. SSRF można podzielić na kilka rodzajów:

• standardowy, czyli taki gdzie atakujący od razu widzi efekt swojego działania np. w odpowiedzi jest zwracana cała treść zapytania,
• blind, czyli taki gdzie atakujący nie widzi efektu bezpośrednio, ale może się domyślać np. po statusie odpowiedzi,
• bardziej skomplikowane, czyli takie jak boolean-based (odpowiedź serwera jest różna w zależności od tego, czy zasób istnienie, czy też nie), error-based (serwer zwraca inny kod błędu, np. 500 lub 404 w zależności od występowania zasobu) czy time-based (jeżeli odpowiedzi serwera są takie same, czasem można wnioskować po czasie ich zwracania) są trudniejsze w wykorzystaniu.

Obrazowo mówiąc: możemy sobie wyobrazić SSRF jako przeglądarkę internetową albo serwer proxy uruchomione na serwerze atakowanej organizacji, dzięki której można przeglądać intranet (sieć wewnętrzna, prywatne zakresy adresów IP). W konsekwencji pozwala to na ominięcie reguł zapory sieciowej lub innych restrykcji, które są zastosowane dla ruchu przychodzącego z zewnętrznych sieci.

Jakie są sposoby wykorzystania SSRF?

Na potrzeby tego tekstu przedstawimy trzy sposoby ataku z wykorzystaniem SSRF:

• atak bezpośrednio na serwer tej aplikacji, w której jest podatność, czyli localhost;
• atak na serwer metadanych w chmurze;
• enumeracja zasobów w sieci wewnętrznej.

Serwery w sieci wewnętrznej często są traktowane jako zaufane i zautoryzowane do wykonywania takich zapytań, jakich z internetu (lub innej niezaufanej sieci) wykonać się nie da.

Atak na lokalny serwer

Pierwszy z nich polega na atakowaniu localhosta. W tym przypadku atakujący ma pewność, że taki serwer istnieje i może próbować się do niego dostać lub wyciągnąć z niego interesujące informacje. Wyobraźmy sobie zatem, że atakowana przez nas aplikacja pobiera zasób plikowy w taki sposób:

GET /blog?content=http://example.com/texts/post1.md HTTP/2
Host: www.example.com

Prosta podmiana powyższego zapytania pozwoli nam na odczytanie zawartości serwera udostępnionej w ramach portu wystawionego wyłącznie na potrzeby sieci wewnętrznej (a nie internetu):

GET /blog?content=http://127.0.0.1:8080/status/ HTTP/2
Host: www.example.com

Czasem może się okazać, że programista zabezpieczył swoją aplikację przed przyjmowaniem w parametrze wprost ciągów typu 127.0.0.1, czy też localhost. Nie jest to jednak wystarczające zabezpieczenie, ponieważ adres lokalnego hosta można zapisać na wiele sposobów, które będą interpretowane w równoważny sposób. Przykładami są: 127.1 (pominięcie wartości 0 w adresie), 2130706433 (postać numeryczna), czy też 0177.0.0.1 (postać ósemkowa). Finalnie zatem wcześniejsze zapytanie mogło by wyglądać jak jedno z poniższych, które będą mu równoważne:

GET /blog?content=http://2130706433:8080/status/ HTTP/2
Host: www.example.com

GET /blog?content=http://127.1:8080/status/ HTTP/2
Host: www.example.com

Jak widać, przy odrobinie kreatywności filtry typu “blocklist” są łatwe do ominięcia.

Atak na endpoint metadanych w chmurze

Kolejnym przykładem jest wykorzystanie SSRF do ataku na serwer metadanych. Ta sytuacja dotyczy aplikacji wykorzystujących infrastrukturę chmury (np. AWS, GCP, czy Azure). Zazwyczaj maszyny wirtualne, które są tam umieszczone, mają dostęp do metadanych serwera  o uniwersalnym adresie 169.254.169.254, z których można pobierać wrażliwe informacje na temat samej maszyny, a także pewne instrukcje działania czy skrypty. Ataki na ten punkt końcowy są szczególnie niebezpieczne, bo mogą prowadzić do przejęcia całej maszyny.

Informacje odnośnie metod dostępnych w ramach serwisów metadanych  dla poszczególnych dostawców usług chmurowych można znaleźć w ich oficjalnej dokumentacji:

• https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html#instancedata-data-categories
• https://cloud.google.com/compute/docs/storing-retrieving-metadata
• https://docs.microsoft.com/en-us/azure/virtual-machines/linux/instance-metadata-service?tabs=windows

Przeglądając dokumentację Google Cloud możemy trafić np. na możliwość zarządzania kluczami SSH:

GET http://metadata.google.internal/computeMetadata/v1/project/attributes/ssh-key        HTTP/2

czy też pobrania access token dla konta na którym uruchomiona jest usługa:

GET http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token        HTTP/2

Na szczęście dostawcy usług chmurowych są świadomi zagrożenia i wprowadzają elementy mające na celu ograniczenie ryzyka możliwości wykorzystania tych usług przez osoby nieuprawnione. Jedną z nich jest konieczność dodania odpowiedniego nagłówka do wysyłanego  zapytania. W przypadku Google jest to:

“Metadata-Flavor: Google” lub “X-Google-Metadata-Request: True”

Enumeracja sieci wewnętrznej

Inną formą ataku z wykorzystaniem SSRF może być próba skanowania prywatnych adresów IP oraz portów w celu znalezienia aplikacji tam działających i ich wykorzystaniu w dalszej fazie. Od poprzednich sposobów różni się to o tyle, że nie wiadomo z góry gdzie i jaka aplikacja jest uruchomiona. Jest to bardzo czasochłonny atak wymagający dużej wiedzy na temat technologii i narzędzi wykorzystywanych w danej firmie, aby zawęzić zakres skanów i skrócić ich czas.

Śladem poprzednich przykładów, możemy wyobrazić sobie bloga z funkcją przesyłania plików, gdzie zapytanie do serwera wygląda mniej więcej tak:

POST /upload?url=http://sampledomain.com/image.jpg HTTP/2
Host: www.example.com

Wykorzystując podatność SSRF możemy wykonać próbę enumeracji IP w sieci wewnętrznej serwera na którym utrzymywana jest aplikacja:

POST /upload?url=10.0.1.2/image.jpg HTTP/2
Host: www.example.com

POST /upload?url=10.0.1.3/image.jpg HTTP/2
Host: www.example.com

POST /upload?url=10.0.1.4/image.jpg HTTP/2
Host: www.example.com

Analiza odpowiedzi pozwala nam na identyfikację adresów IP do których badany przez nas host ma połączenie sieciowe, a czasem nawet pomoże zidentyfikować działające tam usługi.

Jaki jest impakt SSRF?

Trudno określić samodzielny wpływ błędu SSRF. Może on być bardzo różny, w zależności od tego jak podatność zostanie wykorzystana i do jakich zasobów uda się uzyskać z jej pomocą dostęp. Czasem może się ograniczyć tylko do skanowania otwartych portów w sieci wewnętrznej. W innych przypadkach może posłużyć nawet do zdalnego wykonania kodu (RCE). Doskonałe omówienie przykładu wykorzystania SSRF do przeprowadzenia RCE na przykładzie luki w Apache Solr znajdziesz w tym artykule. 

Wiele zależy od konfiguracji aplikacji, “szczęścia” osoby testującej oraz dostępnych zasobów. Niezależnie od tego, warto być świadomym występowania tej klasy podatności i projektować swoje usługi w sposób, który pozwoli się zabezpieczyć przed potencjalnymi skutkami jej wykorzystania.

Jak się zabezpieczyć przed SSRF?

Dwa podstawowe sposoby to zabezpieczenie aplikacji po stronie kodu oraz zabezpieczenie w warstwie sieciowej czyli np. poprawnie skonfigurowany firewall. Jak w przypadku wielu błędów bezpieczeństwa webaplikacji, należy bardzo skrupulatnie walidować wszystkie dane, które są wysyłane  do backendu i mieć restrykcyjne podejście do danych pochodzących z niezaufanych źródeł (w tym użytkownika naszej aplikacji). Ponadto, projektując aplikację należy pamiętać również o zabezpieczeniu na poziomie sieciowym. Jeżeli już muszą być wykonywane zapytania do zewnętrznych serwisów, to warto zadbać, aby dozwolona była wyłącznie komunikacja HTTP(S). Host, który będzie za to odpowiadał, powinien mieć maksymalnie ograniczoną możliwość komunikacji z adresacją sieci wewnętrznej. 

Dołącz do IT Security Allegro (Warszawa/Poznań/Toruń/Kraków)!

Tekst został przygotowany przez członków zespołu IT Security serwisu Allegro.pl. W swojej codziennej pracy zajmujemy się m.in. identyfikacją błędów bezpieczeństwa tej platformy, przeprowadzamy na nią kontrolowane ataki oraz w partnerski sposób współpracujemy z jej programistami.

Obecnie do naszego technicznego zespołu IT Security  poszukujemy osób, które:

• będą przeprowadzać oraz koordynować testy bezpieczeństwa,
• wesprą rozwój Allegro poprzez współtworzenie z innymi zespołami architektury usług IT pod kątem bezpieczeństwa,
• wspólnie z zespołem wezmą odpowiedzialność za nadzór nad programem Bug Bounty.

Więcej szczegółów na temat tego stanowiska znajdziesz pod linkiem https://smrtr.io/5pKhs. 

W przypadku pytań odnośnie samej oferty, zapraszamy do kontaktu: adriana.gesiarz [at] allegro.pl lub lukasz.basa [at] allegro.pl.

Dla pełnej przejrzystości – tekst to artykuł sponsorowany, za jego publikację otrzymujemy wynagrodzenie.