AWS Metadata Service Exploitation: IMDSv1 offenlegen und stehlen

Wie SSRF und Fehlkonfigurationen IMDSv1 offenlegen und Angreifern Zugriff auf IAM-Credentials und Ihr gesamtes AWS-Königreich gewähren

Die Cloud-Revolution versprach Sicherheit, Skalierbarkeit und Einfachheit. Doch in der Infrastruktur von AWS lauert ein scheinbar harmloser Dienst, der zum Skelettschlüssel für unzählige Cloud-Verletzungen geworden ist: der Instance Metadata Service (IMDS). Wenn er durch Server-Side Request Forgery (SSRF)-Angriffe und Fehlkonfigurationen ausgenutzt wird, kann IMDSv1 Angreifern die Schlüssel zu Ihrem gesamten AWS-Königreich an die Hand geben—inklusive IAM-Credentials, Instanzmetadaten und uneingeschränktem Zugriff auf sensible Ressourcen.

Das bekannteste Beispiel? Der Capital One-Breach 2019, bei dem über 100 Millionen Kundenakten offengelegt wurden, was zu einer Geldstrafe von 80 Millionen US-Dollar und unermesslichem Reputationsschaden führte. Der Angriff war nicht hochkomplex—er nutzte eine gut verstandene Schwachstelle, die viele Organisationen noch heute übersehen.

Was ist der AWS Instance Metadata Service?

Der Instance Metadata Service ist ein API-Endpunkt, der innerhalb von AWS EC2-Instanzen unter der IP-Adresse 169.254.169.254 erreichbar ist. Er liefert wichtige Informationen, die Anwendungen und Dienste auf EC2-Instanzen benötigen, um ordnungsgemäß zu funktionieren, darunter:

Instanzdetails: Hostname, Instanz-ID, Netzwerkkonfiguration
IAM-Rollen-Credentials: temporäre Zugriffsschlüssel und Sitzungstoken
Benutzerdaten: benutzerdefinierte Skripte und Konfigurationsdaten
Sicherheitsgruppen: Netzwerkzugriffsregeln

Dieser Dienst ist essenziell für AWS-Operationen. Anwendungen verwenden IMDS, um temporäre Credentials im Zusammenhang mit IAM-Rollen abzurufen, wodurch die Notwendigkeit entfällt, AWS-Zugangsschlüssel fest im Code zu verankern—eine bedeutende Sicherheitsverbesserung bei korrekter Nutzung.

IMDSv1 vs. IMDSv2: Ein kritischer Sicherheitsunterschied

AWS bietet zwei Versionen des Instance Metadata Service an, deren Unterschiede entscheidend sind:

IMDSv1 (Legacy): - Nutzt ein einfaches Request-Response-Protokoll - Erfordert nur HTTP GET-Anfragen - Keine Authentifizierung oder Sitzungsverwaltung - Anfällig für SSRF-Angriffe - Wird auf vielen Instanzen noch standardmäßig aktiviert

IMDSv2 (Sichere Version): - Sitzungsorientiert mit tokenbasierter Authentifizierung - Erfordert eine initiale PUT-Anfrage zur Generierung eines Sitzungstokens - Token muss in einem benutzerdefinierten Header (X-aws-ec2-metadata-token) enthalten sein - TTL-basierter Schutz gegen Angriffe auf der Netzwerkschicht - Wirksam gegen SSRF-Schwachstellen

Das Problem? Trotz der Umstellung von AWS, IMDSv2 seit November 2023 zur Standardoption für neue Instanzen zu machen, zeigen Untersuchungen, dass im Jahr 2022 noch etwa 93 % der EC2-Instanzen IMDSv1 nicht durchsetzen. Viele Organisationen laufen weiterhin mit IMDSv1, was sie denselben Angriffspunkten aussetzt, die den Capital One-Breach ermöglichten.

Die Anatomie eines IMDS-Exploits

Um zu verstehen, warum IMDSv1 so gefährlich ist, betrachten wir, wie Angreifer es durch SSRF-Schwachstellen ausnutzen.

Schritt 1: Reconnaissance

Angreifer beginnen mit der Suche nach verwundbaren Anwendungen auf AWS-Infrastruktur. Sie suchen nach: - Webanwendungen mit Benutzereingabefeldern - Öffentlich zugänglichen Instanzen mit exponierten Diensten - Anwendungen, die HTTP-Anfragen basierend auf vom Nutzer bereitgestellten URLs ausführen - Fehlkonfigurierten Web Application Firewalls (WAFs)

Schritt 2: Entdeckung von SSRF-Schwachstellen

Server-Side Request Forgery tritt auf, wenn eine Anwendung dazu verleitet werden kann, HTTP-Anfragen an unbeabsichtigte Ziele zu senden. Häufige Szenarien:

URL-Parameter: Anwendungen, die Inhalte von vom Nutzer bereitgestellten URLs abrufen
Bildverarbeitungsdienste: Dienste, die Bilder aus externen Quellen herunterladen und verarbeiten
Webhook-Implementierungen: Systeme, die Rückrufe an vom Nutzer angegebene Endpunkte durchführen
PDF-Generatoren: Tools, die Webinhalte in PDF umwandeln
Datei-Upload-Funktionen: Anwendungen, die hochgeladene Dateien mit externen Referenzen verarbeiten

Schritt 3: Zugriff auf den Metadata Service

Sobald eine SSRF-Schwachstelle erkannt wurde, nutzen Angreifer sie, um auf den Metadaten-Endpunkt zuzugreifen:

# Direkter Zugriff auf IMDS (funktioniert nur innerhalb der EC2-Instanz)
curl http://169.254.169.254/latest/meta-data/

# Über SSRF-Schwachstelle in der verwundbaren Anwendung
http://vulnerable-app.com/fetch?url=http://169.254.169.254/latest/meta-data/

Schritt 4: Extrahieren von IAM-Credentials

Der eigentliche Gewinn sind die IAM-Rollen-Credentials:

# Auflisten der verfügbaren IAM-Rollen
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Credentials für eine bestimmte Rolle abrufen
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/[Rollenname]

Dies liefert JSON-Daten mit: - AccessKeyId: AWS-Zugangsschlüssel - SecretAccessKey: AWS-Geheimschlüssel - Token: Sitzungstoken - Expiration: Ablaufzeit der Credentials

Schritt 5: Verwendung gestohlener Credentials

Mit diesen Credentials können Angreifer: - S3-Buckets mit sensiblen Daten auflisten und zugreifen - Neue EC2-Instanzen für Crypto-Mining oder weitere Angriffe starten - Sicherheitsgruppen und Netzwerkkonfigurationen ändern - Datenbanken und andere AWS-Dienste ansprechen - Daten exfiltrieren - Persistenzmechanismen etablieren

Reale Auswirkungen: Der Capital One-Breach

Der Capital One-Breach 2019 zeigt die verheerenden Folgen von IMDS-Exploitation. Hier die Abläufe:

Angriffszeitplan: - 22.-23. März 2019: Paige Thompson, ehemalige AWS-Mitarbeiterin, nutzte eine SSRF-Schwachstelle in Capital Ones Web Application Firewall - Ausgenutzte Schwachstelle: Eine falsch konfigurierte WAF erlaubte SSRF-Angriffe auf den Metadata Service - Gestohlene Credentials: Thompson erhielt temporäre AWS-Credentials von der IAM-Rolle der EC2-Instanz - Datenzugriff: Mit den gestohlenen Credentials listete sie über 700 S3-Buckets auf und lud ca. 30 GB Daten herunter - 19. Juli 2019: Breach wurde entdeckt, nachdem Thompson damit auf GitHub und IRC prahlte

Der Schaden: - 106 Millionen Kundenakten offengelegt (100 Mio US, 6 Mio Kanada) - 140.000 Sozialversicherungsnummern kompromittiert - 80.000 Bankkontonummern geleakt - 1 Million kanadische Sozialversicherungsnummern offengelegt - Persönliche Daten inklusive Namen, Adressen, Kredit-Score und Transaktionsdaten - 80 Mio USD Strafe durch Regulierungsbehörden - Über 150 Mio USD Gesamtkosten inklusive Behebung und Vertrauensverlust - Schwerer Reputationsschaden und Kursverlust

Ursachen: 1. SSRF-Schwachstelle in der WAF-Anwendung 2. IMDSv1 in Verwendung statt sicherer IMDSv2 3. Zu permissive IAM-Rollen mit breitem S3-Zugriff 4. Unverschlüsselte Daten in S3-Buckets 5. Unzureichendes Monitoring führte zu einer Verzögerung von vier Monaten bei der Erkennung

Das beunruhigendste? Dieser Angriff erforderte keine hochentwickelten Techniken—nur die Ausnutzung gut verstandener Schwachstellen, die hätte gemindert werden können.

Aktuelle Exploit-Kampagnen und aufkommende Bedrohungen

IMDS-Exploitation ist kein Relikt aus der Vergangenheit. Aktive Kampagnen zielen weiterhin auf verwundbare AWS-Infrastruktur:

Kampagne März 2025

Sicherheitsforscher entdeckten eine neuartige Kampagne, die Websites auf EC2-Instanzen durch SSRF-Schwachstellen angreift. Hauptangriffe:

CVE-2017-9841: PHPUnit Remote Code Execution (15x aktiver als der zweitplatzierte CVE)
CVE-2024-4577: Zeigt anhaltende Aufwärtsbewegung
CVE-2019-9082: Stetiger Anstieg bei Exploit-Versuchen

Ursprung der Kampagne sind IP-Adressen des ASN 34534 (FBW NETWORKS SAS), mit Angriffsinfrastruktur in Frankreich und Rumänien. Die Angreifer nutzten einfache SSRF-Techniken, um IMDSv1-Endpunkte abzufragen und Credentials zu extrahieren.

Pandoc CVE-2025-51591 Exploitation

Im September 2025 entdeckte die Sicherheitsfirma Wiz, dass Angreifer eine Schwachstelle in Pandoc (einem populären Dokumentenkonverter) ausnutzten, um AWS IMDS anzugreifen. Die Schwachstelle erlaubte es, iframe-Elemente mit src-Attributen einzufügen, die auf den Metadata Service zeigen.

Der Angriff scheiterte letztlich an der Durchsetzung von IMDSv2, was die entscheidende Bedeutung des Upgrades von der Legacy-Version unterstreicht. Die fortgesetzten Bemühungen zeigen jedoch, dass Angreifer aktiv nach neuen SSRF-Vektoren suchen, um IMDS-Schwachstellen auszunutzen.

UNC2903 Threat Actor

Im Juni 2021 nutzte die Bedrohungsgruppe UNC2903 eine Schwachstelle im Adminer-Datenbankmanagement-Tool mit einer cleveren Redirect-Technik. Sie richteten Relay-Server mit 301-Weiterleitungsskripten ein, um Opfer-Server zu manipulieren, Redirects zu folgen, die Fehler mit AWS API-Credentials zurückgaben. Die erbeuteten Credentials ermöglichten Zugriff auf die AWS-Konten der Opfer.

Warum IMDSv1 weiterhin ein kritisches Risiko ist

Trotz der Verfügbarkeit von IMDSv2 seit 2019 bleibt IMDSv1 ein erhebliches Risiko:

Technische Schwachstellen

Keine Authentifizierung erforderlich: IMDSv1 nutzt unautorisierte GET-Anfragen, was den Zugriff bei SSRF-Schwachstellen trivial macht.

Request-Response-Protokoll: Das einfache Request-Response-Muster macht es zu einem perfekten Ziel für SSRF-Angriffe, da Angreifer nur den Server zwingen müssen, HTTP GET-Anfragen zu senden.

Keine Header-Anforderungen: Im Gegensatz zu IMDSv2 sind keine benutzerdefinierten Header erforderlich, was die Ausnutzung auch bei einfachen SSRF-Schwachstellen ermöglicht.

Organisatorische Herausforderungen

Legacy-Systeme: Lang laufende Instanzen haben möglicherweise Anwendungen, die nur IMDSv1 unterstützen, was Migrationsherausforderungen schafft.

Unzureichendes Bewusstsein: Viele Organisationen verstehen die Sicherheitsimplikationen von IMDSv1 im Vergleich zu IMDSv2 nicht.

Standardeinstellungen: Obwohl AWS die Defaults für neue Instanzen geändert hat, behalten bestehende Infrastruktur oft IMDSv1-Kompatibilität.

Komplexe Umgebungen: Große AWS-Deployments mit Tausenden von Instanzen machen eine umfassende Migration schwierig.

Erkennung und Identifikation

Bevor Sie das Problem beheben, müssen Sie feststellen, wo IMDSv1 noch aktiv ist:

Nutzung der AWS-Konsole

Navigieren Sie zum EC2-Dashboard und prüfen Sie die Spalte “IMDSv2” für jede Instanz. Instanzen mit “Optional” haben IMDSv1 aktiviert.

AWS Config Rules

Setzen Sie die ec2-imdsv2-check AWS Config-Regel ein, die Instanzen als NON_COMPLIANT markiert, wenn HttpTokens auf “optional” gesetzt ist.

CloudWatch Metriken

Überwachen Sie die MetadataNoToken-Metrik in CloudWatch, die IMDSv1-Aufrufe verfolgt. Nullwerte bedeuten, dass die Instanz nur noch IMDSv2 erfordert.

AWS Security Hub

Konfigurieren Sie Security Hub mit Cross-Region- und Cross-Account-Aggregation, um IMDSv1-aktivierte Instanzen in Ihrer gesamten AWS-Organisation zu identifizieren.

IMDS-Paket-Analyzer

Verwenden Sie das IMDS Packet Analyzer-Tool von AWS, um genau zu bestimmen, welche Softwarekomponenten IMDSv1-Anfragen stellen, und priorisieren Sie Updates.

Umfassende Abwehrmaßnahmen

Der Schutz vor IMDS-Exploitation erfordert einen mehrschichtigen Ansatz:

1. Sofortige Durchsetzung von IMDSv2

Für neue Instanzen:

# Instanz mit IMDSv2 erzwingen
aws ec2 run-instances \
  --image-id ami-xxxxx \
  --instance-type t3.micro \
  --metadata-options HttpTokens=required,HttpPutResponseHopLimit=1

Für bestehende Instanzen:

# IMDSv2 auf bestehender Instanz erzwingen
aws ec2 modify-instance-metadata-options \
  --instance-id i-xxxxx \
  --http-tokens required \
  --http-put-response-hop-limit 1

Mit Terraform:

resource "aws_instance" "example" {
  ami           = "ami-xxxxx"
  instance_type = "t3.micro"
  
  metadata_options {
    http_tokens                 = "required"
    http_put_response_hop_limit = 1
    http_endpoint               = "enabled"
  }
}

2. Prinzip der minimalen Rechte bei IAM-Rollen

Vergeben Sie niemals IAM-Rollen mit umfangreichen Berechtigungen. Folgen Sie diesen Prinzipien:

Gewähren Sie nur die minimal erforderlichen Berechtigungen für die Funktion der Instanz
Verwenden Sie spezifische Ressourcen-ARNs statt Wildcards
Implementieren Sie IAM-Bedingungsschlüssel, um die Nutzung von Credentials einzuschränken
Überprüfen Sie regelmäßig und schränken Sie Berechtigungen mit Access Advisor ein

Verwenden Sie IAM-Bedingungsschlüssel:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::sensitive-bucket/*",
    "Condition": {
      "StringEquals": {
        "ec2:RoleDelivery": "2.0"
      }
    }
  }]
}

Dieses Policy stellt sicher, dass nur Credentials, die via IMDSv2 abgerufen wurden, Zugriff auf den S3-Bucket haben.

3. Deaktivieren von IMDS, wenn nicht benötigt

Für Instanzen, die keinen IMDS-Zugriff benötigen:

aws ec2 modify-instance-metadata-options \
  --instance-id i-xxxxx \
  --http-endpoint disabled

4. Netzwerkschutzmaßnahmen

WAF-Konfiguration: - AWS WAF mit Regeln gegen SSRF-Angriffe - Strenge Eingabekontrollen - Überwachung auf verdächtige Muster, die auf Metadaten-Endpoints zielen

VPC-Sicherheit: - Verwendung von Security Groups zur Beschränkung ausgehender Verbindungen - Netzwerksegmentierung - Einsatz von VPC-Endpunkten für AWS-Dienste, um Internet-Routing zu vermeiden

5. Sichere Anwendungsentwicklung

Eingabekontrolle: - Vertraue niemals Nutzerinput bei HTTP-Anfragen - Implementieren Sie Allowlists für erlaubte Domains - Blockieren Sie Anfragen an private IP-Bereiche (inkl. 169.254.x.x) - Validieren und bereinigen Sie alle URL-Parameter

URL-Parsing:

from urllib.parse import urlparse

def is_safe_url(url):
    parsed = urlparse(url)
    
    # Blockiere private IPs und Metadatenservice
    blocked_ips = ['169.254.169.254', '127.0.0.1', 'localhost']
    if parsed.hostname in blocked_ips:
        return False
    
    # Erlaube nur bestimmte Domains
    allowed_domains = ['trusted-domain.com']
    if parsed.hostname not in allowed_domains:
        return False
    
    return True

6. Umfassendes Monitoring

AWS GuardDuty: Aktivieren Sie GuardDuty, um ungewöhnliche Credential-Nutzung und potenziellen IMDS-Credential-Diebstahl zu erkennen.

CloudTrail-Logging: Überwachen Sie auf: - Ungewöhnliche API-Calls von EC2-Instanzen - Credential-Nutzung aus unerwarteten Quellen - Große Datenübertragungen nach extern - Änderungen an IAM-Rollen und -Policies

AWS Security Hub: Aggregieren Sie Erkenntnisse aus mehreren Konten und Regionen, um die Sicherheitslage im Blick zu behalten.

7. Service Control Policies (SCPs)

Für AWS-Organisationen: Erzwingen Sie IMDSv2 auf Organisationsebene:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Action": "ec2:RunInstances",
    "Resource": "arn:aws:ec2:*:*:instance/*",
    "Condition": {
      "StringNotEquals": {
        "ec2:MetadataHttpTokens": "required"
      }
    }
  }]
}

Dieses SCP verhindert das Starten von Instanzen ohne IMDSv2-Implementierung in der gesamten Organisation.

Der Weg nach vorn: Best Practices für Migration

Der Übergang von IMDSv1 zu IMDSv2 erfordert eine sorgfältige Planung:

Phase 1: Bewertung (Wochen 1-2)

Inventarisieren Sie alle EC2-Instanzen in Regionen und Konten
Identifizieren Sie Instanzen mit IMDSv1
Dokumentieren Sie Anwendungen und Dienste auf jeder Instanz
Prüfen Sie die Softwarekompatibilität mit IMDSv2

Phase 2: Testen (Wochen 3-4)

Aktualisieren Sie AWS SDKs, CLIs und Tools auf Versionen, die IMDSv2 unterstützen
Testen Sie Anwendungen in Nicht-Produktionsumgebungen mit IMDSv2
Überwachen Sie MetadataNoToken-Metriken während der Tests
Aktualisieren Sie eigene Skripte, die IMDSv1 aufrufen

Phase 3: Schrittweise Migration (Wochen 5-8)

Beginnen Sie mit nicht-kritischen Workloads
Aktivieren Sie IMDSv2, während IMDSv1 optional bleibt
Überwachen Sie mehrere Tage auf Probleme
Gehen Sie in den produktiven Betrieb, wenn die Kompatibilität bestätigt ist

Phase 4: Durchsetzung (Woche 9+)

Erzwingen Sie IMDSv2 auf migrierten Instanzen
Implementieren Sie SCPs, die IMDSv1 verbieten
Richten Sie kontinuierliches Monitoring ein
Dokumentieren Sie Erkenntnisse und aktualisieren Sie Runbooks

Software-Kompatibilität

Moderne AWS-Tools unterstützen IMDSv2: - AWS SDKs (alle gängigen Sprachen) - AWS CLI v2 - AWS Systems Manager Agent - Amazon ECS Agent - Amazon Linux 2023 (standardmäßig nur IMDSv2)

Für Legacy-Anwendungen: Überlegen Sie, Containerisierung oder Updates auf kompatible Versionen durchzuführen, bevor Sie IMDSv2 verpflichtend machen.

Über AWS hinaus: Multi-Cloud-Ansatz

Obwohl dieser Artikel sich auf AWS konzentriert, existieren ähnliche Metadaten-Services bei anderen Cloud-Anbietern:

Google Cloud Platform: - Metadata-Service bei 169.254.169.254 - Erfordert Metadata-Flavor: Google Header - Diese Header-Anforderung schützt vor SSRF, ähnlich wie IMDSv2

Microsoft Azure: - Metadata-Service bei 169.254.169.254 - Erfordert Metadata: true Header - API-Version muss in der URL angegeben werden

Oracle Cloud Infrastructure: - Metadaten-Service mit erweiterten Authentifizierungsmechanismen - Mehrschichtige Zugriffskontrollen

Diese Anbieter implementierten headerbasierte Schutzmaßnahmen früher als AWS, was die Bedeutung eines mehrschichtigen Verteidigungsansatzes unterstreicht.

Fazit: Zeit zum Handeln

Der AWS Instance Metadata Service bleibt eine kritische Angriffsfläche, die Organisationen nicht ignorieren dürfen. Während IMDSv1 bei der Einführung 2012 eine Grundlage für sichere Cloud-Operationen bot, macht die sich entwickelnde Bedrohungslage es obsolet und gefährlich.

Der Capital One-Breach zeigte, dass SSRF-Schwachstellen in Kombination mit IMDSv1 einen perfekten Sturm für Angreifer erzeugen—mit Schäden von über 150 Mio USD und 106 Millionen Kundenakten, die offengelegt wurden. Aktuelle Kampagnen zeigen, dass Angreifer aktiv nach SSRF-Vektoren suchen, um IMDS auszunutzen, und neue Angriffspunkte entstehen regelmäßig.

Gute Nachrichten: AWS bietet robuste Abwehrtools mit IMDSv2, und umfassende Sicherheitskontrollen sind verfügbar, um Ihre Cloud-Infrastruktur zu schützen.

Schlechte Nachrichten: Die Mehrheit der Organisationen hat diese Schutzmaßnahmen noch nicht umgesetzt, was sie denselben Angriffen aussetzt, die andere bereits schwer getroffen haben.

Der Imperativ: Jeder Tag, an dem Sie IMDSv1 laufen lassen, ist ein Tag, an dem potenzielle Angreifer einen Skelettschlüssel zu Ihrem Cloud-Reich in den Händen halten. Der Breach bei Capital One passierte 2019—sechs Jahre später gibt es keinen Grund, IMDSv2 nicht umzusetzen.

Sofortmaßnahmen

Diese Woche: Inventarisieren Sie alle EC2-Instanzen und identifizieren Sie IMDSv1
Diesen Monat: Implementieren Sie AWS Config-Regeln und Security Hub für kontinuierliches Monitoring
Dieses Quartal: Abschließen Sie die Migration auf IMDSv2 für alle Instanzen
Laufend: Erzwingen Sie IMDSv2 für alle neuen Instanzen via SCPs
Ständig: Überwachen, auditieren und verbessern Sie IAM-Rollen-Berechtigungen

Der Skelettschlüssel zu Ihrem AWS-Reich liegt offen. Werden Sie ihn sichern, bevor Angreifer ihn finden, oder wird Ihre Organisation die nächste Warnung sein?

Weitere Ressourcen

Keywords: AWS IMDS, IMDSv1, IMDSv2, SSRF-Angriffe, EC2-Sicherheit, AWS Metadata Service, Capital One-Breach, Cloud-Sicherheit, IAM-Credentials, Instanzmetadaten, AWS Best Practices, serverseitige Request Forgery, Cloud-Exploitation, AWS-Schwachstelle, EC2-Credential-Diebstahl