Mitteilungs-ID: AWS-2025-021
Geltungsbereich: AWS
Inhaltstyp: Wichtig (erfordert Beachtung)
Datum der Veröffentlichung: 08.10.2025, 11:15 Uhr PDT

Beschreibung:

AWS ist über einen potenziellen IMDS-Identitätswechsel (Instance Metadata Service) informiert, der dazu führen würde, dass Kunden mit unerwarteten AWS-Konten interagieren. IMDS läuft auf einer EC2-Instance über eine Loopback-Netzwerkschnittstelle und gibt Instance-Metadaten-Anmeldedaten aus, welche Kunden für die Interaktion mit AWS-Services verwenden. Diese Netzwerkaufrufe verlassen niemals die EC2-Instance, und Kunden können darauf vertrauen, dass sich die IMDS-Netzwerkschnittstelle innerhalb des AWS-Datenperimeters befindet.

Wenn AWS-Tools (wie das AWS-CLI/-SDK oder SSM Agent) von Nicht-EC2-Rechenknoten aus verwendet werden, besteht die Möglichkeit, dass ein von einem Drittanbieter kontrolliertes IMDS unerwartete AWS-Anmeldeinformationen bereitstellt. Dies erfordert, dass der Rechenknoten in einem Netzwerk läuft, in dem der Drittanbieter eine privilegierte Netzwerkposition hat. AWS empfiehlt, dass Kunden, wenn sie AWS-Tools außerhalb des AWS-Datenperimeters verwenden, die Installations- und Konfigurationsleitfäden (AWS-CLI/SDK oder SSM Agent) befolgen, um sicherzustellen, dass dieses Problem behoben wird. Wir empfehlen außerdem, dass Sie nach IMDS-Endpunkten Ausschau halten, die möglicherweise in Ihrer lokalen Umgebung laufen, um solche Identitätsmissbrauchsprobleme durch Dritte proaktiv zu verhindern.

Betroffene Versionen:  IMDSv1 und IMDSv2

Behebung:

AWS empfiehlt, dass Kunden, wenn sie AWS-Tools außerhalb des AWS-Datenperimeters verwenden, die Installations- und Konfigurationsleitfäden (AWS-CLI/SDK oder SSM Agent) befolgen, um sicherzustellen, dass dieses Problem behoben wird.

Überwachung:

Unternehmen sollten in lokalen Umgebungen auf unerwarteten AWS Instance Metadata Service (IMDS)-Datenverkehr achten, weil dies auf potenzielle Fehlkonfigurationen, lokal ausgeführte Cloud-Anwendungen oder Sicherheitsbedenken hinweist.

Überwachen Sie Verbindungen zu 169.254.169.254 (AWS IPv4 Link-Local-Metadatenendpunkt) und fd00:ec2: :254 (AWS IPv6-Metadatenendpunkt), HTTP-Anfragen an AWS-spezifische Pfade wie /latest/meta-data oder /latest/api/token und das Vorhandensein von AWS-Metadaten-Headern wie X-AWS-EC2-Metadata-Token. Diese Endpunkte sollten niemals in rein lokalen Netzwerken erscheinen, da sie für AWS-EC2-Instances reserviert sind, um Konfigurationsdaten, IAM-Anmeldeinformationen und Instance-Informationen abzurufen.

Kunden erhalten diese Übersicht über Erkennungsrichtlinien in SIGMA, einem generischen Regelformat, das in bestimmte SIEM-Abfragesprachen übersetzt wird und so den Einsatz einer universellen Erkennung ermöglicht. Um diese Regel zu erstellen, definieren Sie logsource: category: network, um verschiedene Netzwerktelemetrie zu korrelieren, und erstellen Sie dann mehrere Auswahlblöcke. ip_aws_dst: dst_ip: 169.254.169.254 erfasst direkte Verbindungen, während http_url_paths: url|contains: ['/latest/meta-data', '/latest/api/token'] Metadatenanfragen anhand der Listensyntax von SIGMA erkennt. Verwenden Sie Feldvarianten wie destination.ip, c-ip und request_url|contains in separaten Auswahlblöcken, um unterschiedlichen Protokollschemas verschiedener Anbieter gerecht zu werden. Implementieren Sie die Bedingungslogik so, dass alle Auswahlblöcke mit ihren angegebenen Präfixen übereinstimmen (z. B. Bedingung: 1 von ip_* oder 1 von http_*, wobei der Platzhalter * allen Auswahlblöcken entspricht, die mit diesen Präfixen beginnen). Die Erkennung kann präzisiert werden, indem der contains-Modifikator von SIGMA verwendet wird: request_headers|contains: 'X-aws-ec2-metadata-token' für IMDSv2-Token-Anfragen. Bei der Bereitstellung konvertiert SIGMA diese universelle Syntax in die nativen Abfragesprachen Ihres SIEM – SPL von Splunk, AQL von QRadar, KQL von Sentinel oder KQL von Elastic – und behält dabei dieselbe Erkennungslogik bei und passt sich gleichzeitig an plattformspezifische Feldnamen und Operatoren an.

Um die Regeltreue zu verbessern, können Kunden erwägen, die Warnung nur für den lokalen Netzwerkverkehr auszulösen, indem sie eine Unterdrückungslogik anwenden, die auf Quellsubnetzen oder VLANs basiert.

Bei Sicherheitsfragen oder -bedenken wenden Sie sich bitte per E-Mail an aws-security@amazon.com.