Metadaten und SSRF

Jede Cloud-VM kann einen speziellen internen Endpunkt abfragen, um Informationen über sich selbst zu erhalten: den Instance Metadata Service (IMDS). Entscheidend ist, dass dieser Dienst auch die temporären Zugangsdaten der Rolle ausgeben kann, die der Instanz zugewiesen ist.

• AWS / GCP / Azure stellen Metadaten unter 169.254.169.254 bereit
• Der Dienst ist nur innerhalb der Instanz erreichbar
• Lokale Prozesse benötigen dafür keine Authentifizierung

Diese praktische Funktion wird in Kombination mit SSRF zur Waffe.

Bei der älteren Version IMDSv1 liefert eine einzige GET-Anfrage Metadaten, einschließlich der Zugangsdaten der Rolle. Es wird kein Token benötigt.

Genau das macht IMDSv1 gefährlich, wenn eine Anwendung für SSRF anfällig ist.

Server-Side Request Forgery (SSRF) ist eine Schwachstelle, bei der ein Angreifer einen Server dazu bringt, HTTP-Anfragen in seinem Namen zu stellen. Der Server wird dadurch zu einem Proxy in Bereiche, die der Angreifer nicht direkt erreichen kann.

• Ein URL-Parameter, den der Server abruft
• Ein Webhook, ein PDF-Generator oder eine Funktion zur Bildgrößenanpassung
• Alles, was eine vom Benutzer angegebene URL verarbeitet

Das klassische SSRF-Ziel in der Cloud ist der Metadaten-Endpunkt.

Die gefährliche Kombination: Eine Anwendung mit SSRF ermöglicht es dem Angreifer, den Server auf 169.254.169.254 zu verweisen. Der Server ruft die IAM-Zugangsdaten der Instanz ab und gibt sie zurück.

Der Angreifer verfügt nun über Cloud-Zugangsdaten – oft ist das der Beginn einer vollständigen Übernahme des Kontos.

Die Metadatenantwort enthält einen Zugriffsschlüssel, einen geheimen Schlüssel und ein Sitzungstoken. Der Angreifer exportiert diese Daten und handelt sofort als Rolle der Instanz.

Anschließend ermittelt er die Berechtigungen und sucht nach Wegen zur Rechteausweitung.

AWS hat IMDSv2 eingeführt, um SSRF-Angriffe abzumildern. Zuerst muss ein Sitzungstoken über eine HTTP-PUT-Anfrage abgerufen werden. Die meisten SSRF-Möglichkeiten können das nicht – sie unterstützen nur GET.

Die Erzwingung von IMDSv2 und ein niedriges Hop-Limit verringern den Diebstahl von Metadaten über SSRF erheblich.

Auch die anderen Anbieter stellen Metadaten bereit, jeweils mit eigenen Besonderheiten. Beide erfordern einen speziellen Header, was bereits eine kleine SSRF-Abwehr darstellt.

• Azure erfordert Metadata: true
• GCP erfordert Metadata-Flavor: Google

Verteidiger blockieren häufig 169.254.169.254. Angreifer umgehen naive Filter mit alternativen IP-Darstellungen und Weiterleitungen.

• Dezimale IP-Adresse: 2852039166
• Oktale oder hexadezimale Darstellungen derselben Adresse
• DNS-Rebinding auf einen Namen, der zur Metadaten-IP aufgelöst wird
• Offene Weiterleitungen, die die Anfrage an die Metadaten-URL umleiten

Robuste Schutzmaßnahmen müssen die aufgelöste IP-Adresse überprüfen, nicht die ursprüngliche Zeichenkette.

Metadaten sind das bekannteste Ziel, aber SSRF ermöglicht auch den Zugriff auf weitere interne Ressourcen:

• Interne Admin-Oberflächen und Dashboards, die an localhost gebunden sind
• Interne Datenbanken und Caches (Redis, Elasticsearch)
• Kubernetes-API-Server und kubelet-Endpunkte
• Andere Microservices, die nicht extern verfügbar sind

SSRF durchdringt den Netzwerkperimeter effektiv aus einer vertrauenswürdigen Position heraus.

Um die Kette von SSRF zu Metadaten zu unterbrechen, ist ein mehrschichtiger Schutz erforderlich:

• IMDSv2 erzwingen und das Hop-Limit für Metadaten auf 1 setzen
• Ausgehende URLs in Abruffunktionen überprüfen und anhand einer Allowlist zulassen
• Anfragen an Link-Local- und private IP-Bereiche nach der DNS-Auflösung blockieren
• Das Prinzip der geringsten Rechte auf Instanzrollen anwenden, damit gestohlene Zugangsdaten nur begrenzten Schaden anrichten können

Rollen mit minimalen Berechtigungen stellen sicher, dass selbst ein erfolgreicher Diebstahl nur wenig bewirkt.

SSRF-Tests können konstruktionsbedingt sensible interne Systeme erreichen. Gehen Sie diszipliniert vor:

• Bestätigen Sie, dass der Zielhost und das Cloud-Konto zum Testumfang gehören
• Greifen Sie nicht auf Systeme außerhalb des Auftrags über
• Beenden Sie den Test und melden Sie das Ergebnis, sobald Sie den Zugriff auf Zugangsdaten nachgewiesen haben

Der Zugriff auf Metadaten hat erhebliche Auswirkungen. Weisen Sie ihn sorgfältig nach und gehen Sie mit gestohlenen Schlüsseln nicht weiter vor.

Warum hilft die Erzwingung von IMDSv2 beim Schutz vor dem Diebstahl von Zugangsdaten über SSRF?

Sie haben die wirkungsvollste Cloud-spezifische Angriffskette kennengelernt.

• Der Metadaten-Service unter 169.254.169.254 gibt die Zugangsdaten der Instanzrolle aus
• SSRF ermöglicht es einem Angreifer, den Server diesen Endpunkt abrufen zu lassen
• Gestohlene temporäre Zugangsdaten ermöglichen die Übernahme eines Kontos
• IMDSv2 blockiert die meisten SSRF-Angriffe, da ein tokenbasiertes PUT erforderlich ist
• Schützen Sie sich mit URL-Allowlists, IP-Validierung und Rollen mit minimalen Berechtigungen

Damit ist Cloud Pentesting abgeschlossen. Der nächste Kurs ist Bug Bounty Hunting.