S3-Bucketsquatting ist (endlich) verschwunden

 (onecloudplease.com)
2 Punkte von GN⁺ 2026-03-14 | 1 Kommentare | Auf WhatsApp teilen
  • AWS hat eine neue kontobasierte Namespace-Schutzfunktion eingeführt, um das Problem des S3-Bucketsquatting zu lösen
  • Der neue Namespace hat das Format <prefix>-<accountid>-<region>-an; nur dasselbe Konto kann einen Bucket mit diesem Namen erstellen
  • Wenn ein anderes Konto versucht, denselben Namen zu verwenden, tritt der Fehler InvalidBucketNamespace auf; derselbe Fehler wird auch zurückgegeben, wenn eine falsche Region angegeben wird
  • Die Verwendung dieses Namespace wird standardmäßig empfohlen und kann in Organisationsrichtlinien (SCP) mit dem Condition Key s3:x-amz-bucket-namespace erzwungen werden
  • Er gilt nicht rückwirkend für bestehende Buckets, bietet aber für neue Buckets starken Schutz und bedeutet damit eine grundlegende Verbesserung der S3-Sicherheitsarchitektur

Überblick über das Bucketsquatting-Problem

  • Bucketsquatting (oder Bucketsniping) ist eine Angriffsform in AWS S3, die ausnutzt, dass Bucket-Namen global eindeutig sein müssen
    • Wird ein Bucket gelöscht, ist der Name wieder verfügbar, sodass ein Angreifer einen neuen Bucket mit demselben Namen registrieren kann
    • Dadurch können Risiken wie Zugriff auf sensible Daten oder Dienstunterbrechungen entstehen
  • Organisationen verwendeten häufig vorhersehbare Benennungsschemata wie myapp-us-east-1, was die Angriffsfläche erhöhte
  • Auch interne AWS-Teams waren von diesem Problem betroffen und suchten etwa zehn Jahre lang gemeinsam mit dem AWS-Sicherheitsteam nach einer Lösung

Einführung des neuen S3-Namespace

  • AWS hat zur Lösung des Problems das Konzept eines kontoeigenen Namespace (account namespace) eingeführt
    • Format: <prefix>-<accountid>-<region>-an
    • Beispiel: myapp-123456789012-us-west-2-an
  • Dieser Namespace beschränkt die Erstellung eines Buckets mit diesem Namen auf genau dieses Konto
    • Wenn ein anderes Konto denselben Namen erstellt, tritt der Fehler InvalidBucketNamespace auf
    • Derselbe Fehler wird auch zurückgegeben, wenn die im Bucket-Namen angegebene Region nicht mit der tatsächlichen Region übereinstimmt
  • AWS empfiehlt, diesen Namespace für alle neuen Buckets standardmäßig zu verwenden
    • Anders als bestehende Namespaces wie .mrap, --x-s3 und -s3alias wurde dieser diesmal als sicherheitsbezogener Namespace für allgemeine Nutzer eingeführt

Richtliniendurchsetzung und Verwaltung

  • Sicherheitsverantwortliche können mit dem Condition Key s3:x-amz-bucket-namespace die Verwendung des Namespace per organisationsweiter Richtlinie (SCP) erzwingen
  • Auf bestehende Buckets oder Templates ohne Namespace wird dies nicht automatisch angewendet
    • Um bestehende Buckets zu schützen, müssen Buckets im neuen Namespace-Format erstellt und die Daten migriert werden
  • Dadurch ist Bucketsquatting praktisch „auf dem Weg zu verschwinden“, und neue Buckets erhalten vollständigen Schutz

Ansätze anderer Cloud-Anbieter

  • Google Cloud Storage (GCS) verwendet bereits einen domainvalidierungsbasierten Namespace
    • Buckets im Domainformat wie myapp.com können nur vom Eigentümer der Domain erstellt werden
    • Bei Buckets ohne Domainformat besteht weiterhin die Möglichkeit von Bucketsquatting
  • Azure Blob Storage verwendet eine Struktur aus Speicherkontoname + Containername
    • Durch die Begrenzung auf maximal 24 Zeichen ist der Namespace enger und potenziell anfälliger für dasselbe Problem

Fazit (tl;dr)

  • AWS S3 führt einen neuen konto- und regionsbasierten Namespace ein
  • Dieser Namespace verhindert Bucketsquatting-Angriffe und sollte beim Erstellen neuer Buckets unbedingt verwendet werden
  • Bestehende Buckets sind nicht automatisch geschützt; falls nötig, sollte der Schutz durch Datenmigration verbessert werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-03-14
Hacker-News-Kommentare

  • Kürzlich habe ich erfahren, dass man die E-Mail-Adresse des Root-Users nach dem Löschen eines AWS-Kontos nicht wiederverwenden kann
    Jemand in unserer Organisation hatte den Root-User eines inzwischen geschlossenen Kontos mit der Haupt-E-Mail-Firma angelegt und danach ein neues Konto mit einer anderen E-Mail erstellt, aber inzwischen ist auch die Frist für die Wiederherstellung nach der Löschung abgelaufen
    Dadurch ist diese E-Mail dauerhaft an das gelöschte Root-Konto gebunden, sodass SSO-Login über einen externen IdP unmöglich geworden ist
    Wir haben den AWS-Support kontaktiert, aber kaum Hilfe bekommen

    • Als ich kürzlich den Kundensupport unterstützt habe, hatten wir einen Fall, bei dem nach dem Weggang eines früheren leitenden Engineers MFA des Root-Kontos weiterhin mit seinem Handy verknüpft war
      Das Passwort war dokumentiert, aber es gab keine Möglichkeit, MFA zu entfernen; wir haben AWS-Support, Account-Manager und andere kontaktiert, aber nichts ließ sich lösen
      Am Ende ist der Zugriff auf das Root-Konto blockiert, und möglicherweise müssen wir eine komplexe Umgebung vollständig in ein neues Konto migrieren
    • Wenn der E-Mail-Anbieter es unterstützt, kann man Plus-Addressing nutzen
      AWS behandelt E-Mails mit Plus-Zusatz als eigene Adressen
    • Das Root-Konto sollte nicht für Personen verwendet werden, sondern als spezielles Notfallkonto, dessen Zugangsdaten sicher aufbewahrt werden
      Am besten nutzt man es nur, wenn wirklich ein schwerwiegendes Problem auftritt
    • Es zeigt wieder einmal, wie unerquicklich Sicherheit sein kann
      Wenn am Ende irgendein Phisher den Kundensupport täuscht und dafür eine Bewertung mit 10 Punkten bekommt, kann trotzdem alles zusammenbrechen
    • Wenn die E-Mail des IdP auf eine Rolle gemappt wird, frage ich mich, was „dauerhaft an das gelöschte Root-Konto gebunden“ konkret bedeutet
      Ich würde gern verstehen, welcher Mechanismus die tatsächliche Nutzung blockiert

  • Der Autor scheint das Konzept des account name bei Azure Blob Storage missverstanden zu haben
    Praktisch entspricht es dem Namen eines S3-Buckets, muss global eindeutig sein und ist daher weiterhin sehr unpraktisch
    Besonders frustrierend ist die Begrenzung auf 24 Zeichen
    Ich wünschte, Microsoft würde wie AWS einen kundenspezifischen Namespace einführen

    • Schon vor etwa 10 Jahren war sich das S3-Team dieses Problems bewusst
      Wegen der Einschränkungen des ursprünglichen Designs konnte es aber nicht geändert werden
      Ich persönlich verstehe nicht, warum man bis heute keine S3-v2-API gebaut hat
      Man hätte mit einer neuen API schrittweise Migrationen anstoßen können, aber stattdessen leiden Kunden und Engineers bis heute unnötig darunter
    • Als ich Azure zum ersten Mal benutzt habe, wirkte es auf mich wie ein wirklich seltsames Design, dass Ressourcen nicht auf Kontoebene namespacet sind
    • Der Autor des Beitrags meldet sich selbst zu Wort und erklärt, dass er den Artikel anhand des Feedbacks aktualisiert hat
    • Nicht nur die Begrenzung auf 24 Zeichen ist problematisch, auch Bindestriche, Unterstriche und Punkte sind nicht erlaubt,
      man darf also nur Zahlen und Kleinbuchstaben verwenden, was extrem unpraktisch ist
      Schön wäre es, wenn wie bei S3 oder GCS wenigstens Bindestriche erlaubt wären
    • Dass man im Namen eines Storage-Accounts nicht einmal Bindestriche verwenden darf, ist meiner Meinung nach ein wirklich miserables Design
      Dasselbe gilt auch für andere Ressourcen wie Container Registries

  • Bei Paketnamen, Bucket-Namen, GitHub-Accountnamen usw. frage ich mich, ob ein Format wie bei Discord mit @name-zufällige4ziffern sinnvoll wäre
    Damit könnte man den Namensraum demokratisieren und Squatting oder Angriffe durch Wiederverwendung verhindern
    Wenn ein Konto gelöscht wird, kann man den vollständigen Namen einfach stilllegen, was sauber wirkt

    • Discord hat dieses Format allerdings vor zwei Jahren abgeschafft und auf ein global eindeutiges Namensschema umgestellt
      Der Grund wird in der offiziellen Ankündigung erklärt: Die vier Ziffern mussten gemerkt werden, dazu kam die Unterscheidung von Groß- und Kleinschreibung, was unpraktisch war
    • Ich persönlich halte ein UUID- + Petname-System für besser
      Besonders in Chat-Apps ist es sauberer, intern IDs zu verwenden und Nutzer nur mit Aliasen arbeiten zu lassen
      Bei Buckets ist ein für Menschen lesbarer Name dagegen zentral, daher wäre es meiner Meinung nach besser, einfach die eigene Domain zu verwenden
    • Für Buckets mag das funktionieren, zur Verhinderung von Package-Hijacking helfen vier Ziffern aber kaum
      Stattdessen steigt nur das Risiko von Tippfehlern
    • Schön wäre, wenn man einfach namen auf Basis verifizierter Domains (@example.com) überall verwenden könnte
    • Wenn ich interne Tools gebaut habe, habe ich Nutzern immer undurchsichtige interne IDs gegeben und ihnen erlaubt, ihre Namen frei zu ändern
      Dass sich Namen in Online-Communitys überschneiden, ist völlig normal,
      daher frage ich mich, warum man globale Eindeutigkeit unbedingt erzwingen muss

  • Vielen Dank an Ian Mckay für den Beitrag
    Dass AWS offiziell Namespaces auf Konto- und Regionenebene eingeführt hat, ist eine gute Veränderung
    Noch besser wäre es, wenn IaC-Tools wie Terraform diese Regel standardmäßig übernehmen würden
    Terraform hängt bereits einen zufälligen Hash-Suffix an Bucket-Namen an, um Kollisionen zu vermeiden
    Im offiziellen AWS-Blog steht mehr dazu

  • Interessant sind auch Bucket-Squatting-Angriffe, die entstehen, wenn Cloud-Anbieter vorhersehbare Bucket-Namen für internen Scratch-Speicher verwenden
    Bei AWS war ein echter Angriff wegen des Hashes schwierig, aber GCP hatte selbst kürzlich noch mit solchen Problemen zu tun
    Zugehörige Vorträge: DC32 AWS Bucket Squatting Talk,
    GCP-Schwachstelle: CVE-2026-1727

    • Der Vortrag war wirklich beeindruckend
      In dem Moment, als ich sah, dass Bucket-Namen vorhersagbar sind, war das Risiko sofort klar
      Die Kombination aus Bucket Squatting + öffentlichem Bucket + TOCTOU-Problem in CloudFormation
      hätte ausgereicht, um Ressourcen in andere Konten auszurollen
      Überraschend, dass das AWS-Sicherheitsteam das nicht früher entdeckt hat

  • DNS-Namen haben ein ähnliches Problem
    Wenn eine Domain nicht verlängert wird, kann sie neu registriert werden,
    und jemand könnte per MX-Record Passwort-Reset-E-Mails oder Ähnliches abfangen

    • Auf diese Weise bekommt man manchmal auch Vermögenswerte wie Legacy-IPv4-Blöcke zurück

  • AWS-Buckets bieten weiterhin nur dann spezielle Funktionen, wenn sie denselben Namen wie der Hostname haben
    Relevante Dokumentation: Virtual Hosting in S3

  • Ein Name sollte nicht mit dem Objekt identisch sein, auf das er verweist
    Wenn ein Name wiederverwendet wird, verweist er auf ein völlig anderes Objekt,
    und seine Bedeutung hängt vom Kontext ab
    Nur wenn man den Namen selbst neu zuweist, kann man ihn als dasselbe betrachten

  • Ich habe mich gefragt, ob es ein Sicherheitsrisiko ist, die Account-ID offenzulegen

    • AWS erklärt offiziell, dass die Account-ID keine geheime Information ist
      Laut der offiziellen Dokumentation sollte man sorgfältig damit umgehen, sie gilt aber nicht als sensible Information
    • Meiner persönlichen Ansicht nach ist sie wie eine E-Mail-Adresse ein Identifikator, aber kein Authentifizierungsmittel
      Solange man sie nicht unnötig breit streut, ist das in Ordnung
    • Hygienisch ist das nicht ideal, aber mit der Account-ID allein ist kein Angriff möglich
      In IAM-Regeln kann ein Angreifer ohnehin * verwenden, daher ist letztlich die Richtlinienkonfiguration der Verteidiger entscheidend
    • Wenn man eine signierte S3-URL teilt, ist darin die Access Key ID enthalten
      Wenn man sie base32-dekodiert, lässt sich daraus die Account-ID extrahieren
      Siehe dazu: entsprechende Analyse

  • Dass S3 nur den Bucket-Namen als Zugriffsschlüssel verwendet, war eine der nervigsten Designentscheidungen überhaupt