SSRF chain to full cloud-account access

Kontext / Context

Ein Cloud-natives SaaS-Produkt mit vielen Microservice-Deployments und einer heterogenen Subdomain-Landschaft. Wir bekamen Scope auf die öffentlichen Assets und fokussierten auf eine der forwarding-Komponenten, die in der Recon auffällig wirkte.

Finding-Muster (abstrakt)

1. Offener Forwarder. Eine öffentliche Komponente leitete HTTP-Requests an beliebige Zieladressen weiter, ohne Ziel-Allowlist oder interne Adressbereiche zu blocken.
2. Erreichbarkeit der internen Metadata-Oberfläche. Aus Sicht des Forwarders war die plattform-spezifische Metadata-Endpoint erreichbar.
3. Automatisches Identity-Token. Die Runtime-Umgebung des Forwarders hatte eine Identity mit zu breitem API-Scope-Set. Ein gültiges Access-Token ließ sich ohne zusätzliche Auth ziehen.
4. Breiter Read-Impact. Mit dem Token waren große Teile des Cloud-Accounts lesbar: Storage, Secrets, Daten-Bestände, Analyse-Warehouses, Instance-Metadaten.

Weitere Findings im gleichen Engagement

Neben dem Hauptbefund kam eine Kette kleinerer Konfigurationsprobleme dazu, die ähnlich einfach zu finden waren:

• Eine öffentlich erreichbare Observability-Komponente mit offener Registration und Password-Reset-Oracle
• Datenbank-Instanzen mit leerer Allowlist und TLS auf “optional”
• Fehlende Package-Restrictions auf einem SDK-API-Key, abusable für Billing-Impact
• Öffentliche Self-Hosted-Dev-Tools mit offener Self-Signup

Methodik

• Recon über residential-IP-Rotation, keine Last auf Kunden-Infrastruktur
• Sauber dokumentierte Request/Response-Pairs pro Hop, damit ein Re-Test nach Fix ohne Tooling-Wissen wiederholbar ist
• Keine produktiven Daten gelesen oder bewegt, nur Existenz und Reachability verifiziert

Deliverable

• Critical-Report mit vollständiger SSRF-Kette, CVSS 3.1 im High/Critical-Bereich
• Separate Follow-up-Findings mit eigener CVSS-Bewertung
• IAM-Remediation-Plan: getrennte Service-Identities pro Deployment, enge Scope-Listen, VPC-interne Calls für Metadata-sensible Pfade
• Datenbank-Härtung: Netzwerk-Allowlists, TLS erzwingen, Deletion-Protection und Backup-Policies prüfen
• Vorschlag für kontinuierliches Cloud-Config-Monitoring mit alerting auf ähnliche Fehlkonfigurationen
• Re-Test nach Fix

Learnings

Plattform-SSRF-Ketten sind die am unterschätztesten Angriffe in Cloud-nativen Architekturen. Standard-Scanner finden Forwarder selten, weil der gefährliche Pfad nur aktiv wird, wenn man die Metadata-IP kennt und den spezifischen Header-Set mitschickt. Das Muster ist generisch über alle großen Cloud-Anbieter identisch, unterscheidet sich nur in Endpoint-Pfaden und Header-Namen.