SSRF i metadane chmury: jak jedno żądanie serwera wykrada Twoje poświadczenia

Server-Side Request Forgery (SSRF) nieprzypadkowo trafiło na osobne miejsce jako A10:2021 w OWASP Top 10: to jedna z niewielu podatności, która pozwala zewnętrznemu atakującemu wykonywać żądania z wnętrza Twojej infrastruktury, korzystając z zaufania, jakim już cieszą się Twoje serwery. Pojedynczy niezweryfikowany parametr URL może stać się mostem z publicznego internetu wprost do usług wewnętrznych, prywatnych API oraz — co najgroźniejsze — do endpointu metadanych chmury, który wydaje tymczasowe poświadczenia.

Czym właściwie jest SSRF

SSRF pojawia się wtedy, gdy aplikacja pobiera zdalny zasób na podstawie URL (lub hosta czy adresu IP), na który wpływ ma użytkownik, bez sprawdzenia, dokąd takie żądanie w ogóle wolno skierować. Klasyczne miejsca to proxy obrazków, walidatory webhooków, generatory podglądu linków, renderery PDF, importery dokumentów i każda funkcja typu „import z adresu URL”. Serwer aplikacji posłusznie wykonuje żądanie w imieniu atakującego, a ponieważ znajduje się za firewallem, sięga tam, gdzie atakujący nigdy nie dotarłby bezpośrednio.

Kanoniczne odwzorowanie to CWE-918: Server-Side Request Forgery. Nieuwierzytelniony, zdalnie wykorzystywalny SSRF odczytujący poświadczenia chmury zwykle uzyskuje ocenę w przedziale CVSS 9.1–9.9 — na przykład AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N, gdzie flaga Scope: Changed odzwierciedla skok z warstwy webowej w płaszczyznę tożsamości chmury.

Łańcuch ataku krok po kroku

Rozważmy endpoint generujący podgląd linków:

• 1. Wykrycie. Atakujący znajduje POST /api/preview {"url":"https://example.com/article"} i zauważa, że odpowiedź osadza pobraną treść. Podmienia URL na http://127.0.0.1:8080/ i otrzymuje wewnętrzną stronę administracyjną — SSRF potwierdzone.
• 2. Rekonesans wewnętrzny. Sonduje http://169.254.169.254/, zakresy 10.0.0.0/8 oraz typowe porty (Redis 6379, Elasticsearch 9200, Consul 8500), by ustalić, co serwer jest w stanie osiągnąć.
• 3. Uderzenie w usługę metadanych. W AWS ze starszym IMDSv1 zwykły GET na http://169.254.169.254/latest/meta-data/iam/security-credentials/ zwraca nazwę przypisanej roli IAM, a jej dopisanie zwraca JSON z AccessKeyId, SecretAccessKey i Token.
• 4. Kradzież poświadczeń i ruch boczny. Atakujący eksportuje tymczasowe klucze, uruchamia aws sts get-caller-identity i działa już jako rola instancji EC2 — czyta zasobniki S3, tabele DynamoDB, a przy nadmiarowych uprawnieniach eskaluje w obrębie całego konta.

Naruszenie Capital One z 2019 roku — ponad 100 milionów rekordów — przebiegło dokładnie tym schematem: SSRF przeciwko źle skonfigurowanemu komponentowi sięgnął endpointu metadanych, pobrał poświadczenia roli i posłużył do wykradzenia danych z S3.

Dlaczego 169.254.169.254 jest tak groźne

Blok 169.254.0.0/16 to zakres IPv4 link-local (RFC 3927). Każda duża chmura przypina swój Instance Metadata Service (IMDS) do 169.254.169.254 — AWS, Google Cloud (przez metadata.google.internal) i Azure. Z założenia jest nieuwierzytelniony: dowolny proces na hoście, w tym Twoja aplikacja wykonująca żądanie wychodzące, może go odczytać. Nie stanowi to problemu, dopóki to nie atakujący wybiera cel żądania.

Obejścia, które umykają obrońcom

Naiwne blocklisty dopasowujące jedynie ciąg „169.254.169.254” czy „localhost” zawodzą wobec:

• Alternatywnych kodowań IP: http://2852039166/ (dziesiętne), http://0xA9FEA9FE/ (heks) lub http://[::ffff:169.254.169.254]/ (IPv6-mapped).
• DNS rebinding: nazwa hosta, która przy walidacji rozwiązuje się na bezpieczny adres, a przy właściwym pobraniu na 169.254.169.254 (TOCTOU między sprawdzeniem a użyciem).
• Przekierowań: podany URL zwraca 302 na adres wewnętrzny, za którym podąża klient HTTP.
• Alternatywnych schematów: file://, gopher:// lub dict://, by dosięgnąć wewnętrznych usług spoza HTTP.

Obrona, która naprawdę działa

Stosuj te warstwy łącznie — żadna pojedyncza kontrola nie wystarczy:

• Wymuś IMDSv2 i hop-limit 1. IMDSv2 wymaga tokenu sesji uzyskanego żądaniem PUT z nagłówkiem X-aws-ec2-metadata-token-ttl-seconds; SSRF przez zwykły GET (najczęstszy przypadek) nie jest w stanie takiego tokenu wytworzyć. Ustaw instancję na HttpTokens=required oraz HttpPutResponseHopLimit=1, by kontenery nie sięgały metadanych. To pojedyncza poprawka o najwyższej wartości.
• Allowlista, nie blocklista. Weryfikuj cel względem jawnej allowlisty schematów (tylko https), hostów i portów. Wszystko inne odrzucaj domyślnie.
• Rozwiąż, potem przypnij. Rozwiąż nazwę hosta do adresu IP, sprawdź, że jest publiczny (odrzuć prywatne RFC 1918, loopback, link-local 169.254.0.0/16 i odpowiedniki IPv6), a następnie połącz się z dokładnie tym IP — zamykając okno DNS rebindingu. Waliduj ponownie po każdym przekierowaniu i tam, gdzie się da, wyłącz automatyczne podążanie.
• Kontrola ruchu wychodzącego. Umieść komponent pobierający w podsieci z grupą bezpieczeństwa / firewallem blokującym ruch wychodzący do IP metadanych i zakresów wewnętrznych. Głęboka obrona na wypadek obejścia walidacji w warstwie aplikacji.
• Najmniejsze uprawnienia IAM. Zakładaj, że poświadczenia wyciekną; ogranicz rolę instancji do minimum i stosuj krótkie TTL, aby skradzione tokeny szybko wygasały.

SSRF jest tani w wykorzystaniu i katastrofalny, gdy trafi na usługę metadanych. Traktuj każdy URL kontrolowany przez użytkownika jak wrogi, waliduj na poziomie rozwiązanego IP i włącz IMDSv2 już dziś — to darmowa zmiana konfiguracji, która neutralizuje najczęstszą ścieżkę ataku.