So findet man die AWS-Konto-ID eines beliebigen S3-Buckets

Die AWS-Konto-ID eines S3-Buckets finden

• 2021 stellte Ben Bridts eine originelle Methode vor, um die AWS-Konto-ID eines offengelegten S3-Buckets zu ermitteln.
• Dieser Artikel beschreibt Techniken, um die Konto-ID sowohl privater als auch öffentlicher S3-Buckets herauszufinden.

Vom S3-Bucket zur AWS-Konto-ID

• Anhand von Shell-Ausgaben wird eine Technik gezeigt, mit der sich die zuvor unbekannte AWS-Konto-ID eines Buckets namens bucket-alpha ermitteln lässt.

Wie funktioniert diese Technik genau?

• Es wird analysiert, warum Bens Technik funktioniert, und drei Kernelemente werden kombiniert:
  • die Fähigkeit, IAM-Richtlinien auf Anfragen anzuwenden
  • die Fähigkeit, daraus abzuleiten, ob eine IAM-Richtlinie eine Anfrage erlaubt hat
  • die Fähigkeit, Wildcard-Matching auf den Bedingungsschlüssel s3:ResourceAccount anzuwenden

Die Lösung

• Es wurde eine Lösung gefunden, die einen VPC-Endpunkt für S3 nutzt und Unterschiede im Verhalten ausnutzt, wenn Anfragen in CloudTrail abgelehnt werden.

Schritt für Schritt

• Das schrittweise Vorgehen, wenn man die Konto-ID des Buckets bucket-alpha ermitteln möchte:
  • Region des Buckets bestimmen
  • VPC und VPC-Endpunkt in derselben Region bereitstellen
  • EC2-Instanz innerhalb der VPC starten und prüfen, dass sie den VPC-Endpunkt für S3 verwendet
  • die VPC-Endpunkt-Richtlinie anpassen, um festzustellen, ob die Konto-ID des Ziel-Buckets mit „0“ beginnt
  • eine Anfrage an den Ziel-Bucket senden
  • prüfen, ob die Anfrage in CloudTrail erscheint
  • abhängig vom Ergebnis die VPC-Endpunkt-Richtlinie anpassen, um weitere Informationen über die Konto-ID zu gewinnen

Das Ergebnis

• Es wurde ein Skript geschrieben, das diesen Prozess automatisiert und die Konto-ID eines Buckets zuverlässig ermitteln kann.
• Für jede Ziffer wird eine binäre Suche durchgeführt, um die Anzahl der nötigen Tests zu reduzieren.

Beschleunigung

• Die VPC-Endpunkt-Richtlinie wurde angepasst, um die Zeit zu verkürzen, bis sie wirksam wird und bis man in CloudTrail jeweils auf einzelne Ergebnisse warten muss.
• Dadurch konnte die Zeit zum Ermitteln der Konto-ID auf unter 10 Minuten verkürzt werden.

Anmerkungen

• Dieser Blogbeitrag wurde nach Rücksprache mit dem AWS-Sicherheitsteam veröffentlicht.
• Es gab eine interessante Diskussion darüber, ob AWS-Konto-IDs als sensible Informationen betrachtet werden sollten.
• Diese Technik könnte auch auf andere Services außer S3 anwendbar sein.
• Möglich ist sie, weil sich für s3:ResourceAccount die Bedingung StringLike verwenden lässt.
• Es könnte hilfreich sein, wenn Ereignisse, die durch VPC-Endpunkt-Richtlinien abgelehnt werden, in CloudTrail protokolliert würden.

Danksagung

• Ben Bridts ursprüngliche Technik war die Inspiration für diese Arbeit.
• Vielen Dank an Chris Farris für Hilfe und Beratung.

Meinung von GN⁺

• Diese Technik kann für Sicherheitsprüfungen in Cloud-Umgebungen sehr nützlich sein und insbesondere helfen, die Eigentümerschaft von AWS-S3-Buckets zu verifizieren.
• Die Diskussion über die Sensibilität der dadurch gewonnenen Informationen spiegelt die fortlaufende Debatte über Datensicherheit und Privatsphäre zwischen Cloud-Anbietern und Nutzern wider.
• Ein anderes Tool mit ähnlicher Funktionalität ist AWSs eigener Service CloudTrail, der zum Protokollieren und Überwachen aller Aktivitäten in einer AWS-Umgebung verwendet wird.
• Vor dem Einsatz dieser Technik sollten Nutzer sicherstellen, dass sie mit den Richtlinien von AWS und den bewährten Sicherheitspraktiken übereinstimmt.
• Zu den Vorteilen zählen effiziente Sicherheitsprüfungen und die schnelle Verifikation von Dateneigentümerschaft, zugleich sollten aber auch Risiken wie mögliche Offenlegung sensibler Informationen berücksichtigt werden.

[GN⁺]

Hacker-News-Kommentare

• Die Möglichkeit, Wildcard-Matches auf den AWS-Condition-Key s3:ResourceAccount anzuwenden

  • Das Überraschende an dieser Funktion ist, dass es keinen legitimen Grund gibt, Berechtigungen auf Basis teilweiser Account-ID-Übereinstimmungen zu gewähren oder zu verweigern. AWS-Account-IDs können sensibel sein wie IP-Adressen, aber um Arbeit zu erledigen, muss sie jemand kennen.

• AWS-Account-ID == Ihre IP-Adresse. Sie kann sensibel sein, aber damit Dinge erledigt werden können, muss jemand sie kennen.

  • Beispiel: Der Autor wollte bei einer Integration mit einem Drittanbieter, die wegen Anti-Geldwäsche-Verfahren erforderlich war, eine PrivateLink-Konfiguration, die im Allgemeinen sicherer ist als ein offener SFTP-Port. Das betreffende Unternehmen lehnte dies jedoch aus Sicherheitsgründen ab, um seine Account-ID zu verbergen. Infolgedessen setzte das Team des Autors deren öffentliche IP-Bereiche für Port 22 auf die Whitelist.
  • Die Lehre daraus: Das Verbergen einer ID mag klug erscheinen, aber wenn es keine Adresse gibt, unter der man Sie erreichen kann, kann man in der Praxis kein Geschäft betreiben.

• Normalerweise würde man Account-IDs nicht öffentlich verbreiten, aber man sollte damit rechnen, dass irgendwann ein Teil davon offengelegt wird.

  • Da Drittanbieter und SaaS-Plattformen bei Integrationen IAM-Benutzer und Access Keys zugunsten von Role Assumption zunehmend vermeiden, wird die Account-ID des als Integrationspunkt verwendeten Accounts anderen Parteien bekannt, und diese haben wiederum ihre eigenen Abhängigkeiten und Schwachstellen.

• Auch andere öffentliche AWS-Ressourcen mit globalem Namespace legen die AWS-Account-ID offen.

  • Für Interessierte: Ich habe den entsprechenden Code hier online veröffentlicht: find-s3-account

• Verwandt: AWS-Key-IDs (nicht der Secret-Key-Teil) enthalten die Account-ID, um ein Bit verschoben.

  • Diese Key-ID ist in der URL von presigned Links für S3 enthalten, daher legen Sie Ihre Account-ID wahrscheinlich bereits offen.

• Interessante Entdeckung, aber beim Titel hatte ich eine einfachere Methode erwartet.

  • Ich wünschte, es gäbe in AWS eine einfache Möglichkeit, als Admin-Account zu fragen: „Wo befindet sich Ressource X?“ Insbesondere wäre eine Funktion hilfreich, die schnell angibt, in welchem Account sich ein bestimmter S3-Bucket befindet. Das betrifft vor allem Legacy-Buckets, die schon existierten, bevor sie als Code definiert wurden. Wenn man viele AWS-Accounts hat, kann es mühsam sein, Ressourcen in unbekannten Accounts und möglichen Regionen zu finden.

• Es ist immer cool, wenn echtes Hacking ein Szenario liefert, das das alte Klischee oder Missverständnis vom „Hacken“ eines Passworts „ein Zeichen nach dem anderen“ aufgreift.

• Der beunruhigendere Angriffsvektor ist jetzt, dass man mit der Account-Nummer versuchen kann, Principals aus anderen Accounts in die Allowlist der eigenen Account-Policy aufzunehmen.

  • Falls der Principal im anderen Account nicht existiert, erhält man einen Fehler, dass die Rolle bzw. der Benutzer nicht gefunden werden kann. Damit lassen sich reale Principals in anderen Accounts aufspüren.

• Warum ist das wichtig? Ein offensichtlicher Punkt: Wenn ein Produktions-Bucket gegeben ist, kann man Entwicklungs-Buckets derselben Organisation finden, was ein unerwartetes Verhalten ist.