Das Offenlegen einer AWS-Konto-ID mag harmlos erscheinen, kann aber eine Sicherheitsbedrohung darstellen, die zu unterschiedlichen Angriffswegen führt. Aufgrund des Risikos wird dringend empfohlen, Ihre AWS-Konto-ID aus Dienstnamen, Infrastruktur oder öffentlich zugänglichen Ressourcen herauszuhalten.
Die Offenlegung einer Konto-ID bietet zwar keinen direkten Angriffspfad, aber sie kann Angreifern dennoch dabei helfen, anfällige Fehlkonfigurationen zu identifizieren, Eskalieren von Berechtigungen, IAM-Benutzernamen zu erzwingen und ihre Existenz anhand von Unterschieden in AWS-Fehlermeldungen zu überprüfen.
Obwohl AWS mehrere bekannte Aufzählungstechniken angegangen ist, hat Varonis Threat Labs kürzlich eine neue, einfache und effektive Methode entdeckt, um die AWS-Konto-ID eines beliebigen S3-Buckets abzurufen, da CloudTrail Network Activity-Ereignisse nicht ordnungsgemäß bereinigt wurden.
Während Forscher wie Sam Cox auch Simple Storage Service (S3)-Buckets nutzten, um Konto-IDs aufzudecken, ist diese Schwachstelle schneller, einfacher und diskreter – sie erzeugt keine Logs auf dem Zielkonto.
Wir haben diese Erkenntnis verantwortungsvoll über das AWS Vulnerability Disclosure Program (VDP) offengelegt, das die Sicherheit der AWS-Infrastruktur verbessert und die unnötige Exposition von Konto-IDs verhindert. AWS veröffentlichte folgende Erklärung:
„AWS ist sich einer Veröffentlichung mit dem Titel „The Silent Attackers: Exploiting VPC Endpoints to Expose AWS Accounts of S3 Buckets Without a Trace“ bewusst, die ein Problem beschreibt, bei dem kontoübergreifende Aufrufe für CloudTrail Network Activity Events die Konto-ID des Ressourcenbesitzers im an den API-Aufrufer gelieferten Ereignis zurückgeben könnten. Dieses Problem trat nur dann auf, wenn sich die Konten des API-Aufrufers und des Ressourceninhabers unterschieden und der Aufruf aufgrund verweigerten Zugriffs fehlschlug.
„Am 20. Juni 2025 haben wir eine Defense-in-Depth-Feature-Erweiterung veröffentlicht, um das Problem zu beheben. Diese Verbesserung entfernt die Eigentümer-Konto-ID für dieses Szenario. Keine Kundenaktion erforderlich.
„Obwohl Konto-IDs, wie alle identifizierenden Informationen, sorgfältig verwendet und geteilt werden sollten, gelten sie nicht als geheime, sensible oder vertrauliche Informationen.“ Da die Angabe von Konto-IDs in diesem Fall weder notwendig noch angemessen ist, haben wir uns entschieden, sie aus großer Vorsicht für Kunden zu redigieren, die möglicherweise Buckets mit vertraulichen oder identifizierbaren Informationen in ihrem Namen erstellt haben, entgegen den Best Practices.
Wir möchten Varonis dafür danken, dass sie dieses Anliegen an AWS gemeldet haben.“
Während wir die neueste Ergänzung von CloudTrail, „Netzwerkaktivitätsereignisse“, erkundeten, entdeckten wir eine einfache Technik, die die Konto-ID eines jeden gültigen S3-Buckets offenlegt, unabhängig von den Datenschutzeinstellungen. Diese Methode hinterlässt keine Spuren in den logs des Zielkontos und ist daher eine unauffällige und effektive Methode zur Aufzählung.
Der Prozess beinhaltet die Konfiguration der AWS-Umgebung des Angreifers und einen einzigen API-Aufruf:
Dadurch wird ein Netzwerkaktivitätsereignis erstellt und in der Netzwerkaktivitätsspur des Angreifers erfasst, und die Konto-ID des S3-Buckets wird offengelegt. Da die Anfrage auf VPC-Ebene im Konto des Angreifers abgelehnt wird, werden im Zielkonto keine Logs erstellt.
Um das vollständig zu verstehen, schauen wir uns einige AWS-Dienste an: CloudTrail, VPC-Endpoint und S3.
AWS CloudTrail ist der Protokollierungs- und Überwachungsdienst in AWS. Es zeichnet API-Aufrufe und Konsolenanfragen (wie Anmeldungen) in einem AWS-Konto auf. Vier Arten von Ereignissen können aufgezeichnet werden:
Managementereignisse werden automatisch in CloudTrail aufgezeichnet, während die Aufzeichnung anderer Ereignistypen explizit in einem Trail konfiguriert werden muss. Wann immer eine Identität eine Aktion auf einem in einem Trail konfigurierten Dienst anfordert, wird ein Ereignis erstellt, das die Anfrage und Antwort beschreibt und Details zur Identität, zur Zielressource, zur Antwort usw. bereitstellt.
Das Protokollieren von Netzwerkaktivitätsereignissen ist eine kürzlich hinzugefügte Funktion, die Einblick in API-Aufrufe innerhalb einer Virtual Private Cloud (VPC) mithilfe eines VPC-endpoint bietet. Konkret wurden nur die Ereignis-Logs für Netzwerkaktivitäten von VPC-Endpoints verweigert. Netzwerkaktivitäten unterstützen mehrere Dienste, darunter S3-Buckets, die aufgrund fehlender Berechtigungen für einen privaten S3-Bucket von einem externen AWS-Konto generiert werden. Es wird ein neues Ereignis im Protokoll erstellt, das die fehlgeschlagene Anfrage erfasst. Zusätzlich wird ein Ereignis am Zielkonto erstellt, um den fehlgeschlagenen Versuch zu beschreiben. Zugriffsversuche wurden jedoch aufgrund der VPC-Endpoint-Richtlinie verweigert. Wenn ein Logs so konfiguriert ist, dass Management- oder Datenereignisse für S3-Buckets protokolliert werden, werden bei einem verweigerten Zugriffsversuch keine Ereignisse im Management- oder Daten-Logs aufgezeichnet.
Bei einem fehlerhaften Verwaltungs- oder Datenereignis wird die Eigenschaft „Konto-ID“ unter dem Ressourcenobjekt, das die Ziel-Bucket-Konto-ID enthält, durch den Text „HIDDEN_DUE_TO_SECURITY_REASONS“ überschrieben. Dies geschieht, weil der Identität, die den Zugriff auf die Zielressource beantragt, der Zugriff verweigert wird. Da die Zielressource außerhalb des AWS-Kontos liegt, sollte die Ziel-AWS-Konto-ID nicht offengelegt werden.
Es sollte so aussehen:
AWS VPC Endpoint ermöglicht eine private Verbindung zwischen Ihrem VPC und den unterstützten AWS-Diensten, ohne dass ein Internet-Gateway, ein NAT-Gerät oder eine VPN-Verbindung erforderlich ist.
Ein VPC-Endpoint für den S3-Dienst funktioniert, indem er eine Route zur Routingtabelle Ihrer VPC hinzufügt, wodurch der Datenverkehr direkt über das AWS-Netzwerk zu den S3-Buckets fließen kann. Wenn ein Prinzipal (wie eine EC2-Instanz, eine Lambda-Funktion oder ein IAM-Benutzer) eine API-Anfrage sendet, um eine S3-Aktion innerhalb des VPC auszuführen, wird der Datenverkehr automatisch über den VPC-Endpoint geleitet.
Richtlinien können einem VPC Endpoint zugeordnet werden, um den Zugriff auf den verbundenen Dienst zu steuern. Diese Richtlinien verwenden die gleiche JSON-basierte Syntax wie die Standard-IAM-Richtlinien von AWS. Ein Beispiel für eine VPC Endpoint-Richtlinie erlaubt es dem Datenverkehr von allen Prinzipalen, alle S3-Aktionen auf allen Ressourcen auszuführen.
Diese Richtlinie wird nicht empfohlen, da sie den gesamten S3-Datenverkehr über die VPC für alle Ressourcen und alle Prinzipale zulässt.
Wichtig zu beachten ist, dass eine VPC-Endpoint-Richtlinie, die den Zugriff erlaubt, nicht automatisch der anfragenden Identität die Berechtigung erteilt. Die Identität muss auch über die erforderlichen Berechtigungen durch eine ressourcenbasierte oder identitätsbasierte Richtlinie verfügen. In solchen Fällen geht die Anfrage auf die Ressourcenebene und erzeugt ein Netzwerkaktivitätsereignis im Trail sowie ein Management- oder Datenereignis – sowohl im Anfordererkonto als auch im Zielkonto, falls Trails konfiguriert sind.
Wenn die VPC-Endpoint-Richtlinie den Zugriff jedoch explizit verweigert, wird die Anfrage auf der Netzwerkschicht blockiert und erreicht die Ressource nie. Dies führt zu einem einzelnen Netzwerkaktivitätsereignis mit der Fehlermeldung „VpceAccessDenied“ im Anfordererkonto.
Es werden keine Verwaltungs- oder Datenereignisse in einem der Konten erstellt, sodass das Zielkonto von dem Versuch völlig unberührt bleibt.
Die Verweigerung des Zugriffs auf alle Ressourcen in der VPC-Endpoint-Richtlinie war der wichtigste Schritt, um Bucket-Konto-IDs aufzudecken, auf die die Identität keinen Zugriff hat.
AWS überschreibt immer die Konto-ID eines Ziel-Buckets, wenn der Zugriff aufgrund fehlender Berechtigungen, wie z. B. eines „DeniedAccess“-Fehlers, verweigert wird. Als jedoch der Fehler „VpceAccessDenied“ hinzugefügt wurde, stellten wir fest, dass die Konto-IDs nicht überschrieben wurden, wodurch die Konto-ID eines beliebigen Buckets offengelegt wurde, sofern der Bucket-Name dem Angreifer bekannt ist.
Die VPC-endpoint-Richtlinie, die allen Zugriff verweigert, sieht wie folgt aus:
Amazon S3 speichert Daten in Containern, die Buckets genannt werden, und jede Datei innerhalb eines Buckets wird als Objekt bezeichnet. S3 unterstützt ressourcenbasierte Richtlinien (Bucket Policies) zur Kontrolle des Zugriffs auf Bucket-Ebene sowie zusätzliche Sicherheitsfunktionen wie Block Public Access und Eigentumskontrollen.
Da der VPC an den VPC-endpoint angeschlossen ist, werden alle innerhalb der VPC ausgeführten S3-API-Aufrufe von der Endpoint-Richtlinie abgelehnt. Zum Beispiel sollte die Ausgabe von 'aws s3 ls s3://target-bucket' folgendermaßen aussehen:
Da wir einen Protokollierungspfad konfiguriert hatten, um Netzwerkaktivitätsereignisse zu erfassen, erschien dieses Ereignis innerhalb weniger Minuten im Protokoll. Es sah so aus:
Die Zielkonto-ID wurde im Objekt „Ressourcen“ im obigen Ereignis offengelegt. Wie bereits erwähnt, wurden die Logs nirgendwo anders protokolliert, da die Anfrage aufgrund des VPC-Endpunkts auf Netzwerkebene abgelehnt wurde.
Da AWS die Schwärzung von Konto-IDs zu diesen Netzwerkaktivitäten hinzugefügt hat, sieht das Ereignis nun folgendermaßen aus:
Es ist wichtig anzumerken, dass diese Technik nicht direkt zur Entdeckung oder Auflistung von S3-Buckets beigetragen hat. Es funktionierte nur, wenn der Angreifer den Namen des Ziel-Buckets kannte. Mit dieser Technik konnte man die Konto-ID ermitteln, unter der der Bucket erstellt wurde.
Dieser Blogbeitrag beschreibt eine Sicherheitslücke, die ich bei der Recherche zu einer neu eingeführten AWS-Funktion entdeckt habe. Die exposure von Konto-IDs durch Netzwerkaktivitätsereignisse – selbst wenn der Zugriff auf private S3-Buckets verweigert wird – erinnert uns daran, dass selbst mit starken Prinzipien wie dem Least-Privilege-Prinzip und externem Datenschutz neue Funktionen unerwartete Verhaltensweisen einführen können, die leicht zu übersehen sind.
Um das Risiko zu reduzieren:
In Verbindung mit einer proaktiven Sicherheitseinstellung können diese Praktiken Teams dabei helfen, einflussreiche Risiken zu antizipieren und zu mindern, die möglicherweise auftreten, wenn sich Cloud-Plattformen weiterentwickeln und neue Fähigkeiten einführen.
Wir sind dem AWS Vulnerability Disclosure Program Team für seine schnelle und durchdachte Reaktion während des gesamten Offenlegungsprozesses sehr dankbar.
Man kann nicht absichern, was man nicht sieht. Holen Sie sich eine kostenlose Cloud Data Risk Assessment, um freiliegende Konto-IDs, falsch konfigurierte Buckets und andere stille Risiken in Ihrer Cloud aufzudecken.