Einführung
Im Jahr 2017 hat ein Partner von Verizon Wireless versehentlich die Zugriffskontrollen für einen Amazon S3-Dienst falsch konfiguriert, wodurch ca. 6 Millionen Datensätze mit Kundennamen, Kontaktinformationen, Privatadressen, Kontofinanzdaten und sogar Kontopins offengelegt wurden. Verizon wurde am 13. Juni 2017 privat über die Aufdeckung informiert, und die Fehlkonfiguration wurde am 22. Juni behoben. Solange der Dienst falsch konfiguriert war, konnte jeder, der über eine Internetverbindung verfügte, problemlos einen Teil oder alle diese Daten einsehen.
Im Zeitalter des massiven Einsatzes von Cloud-Speicherlösungen sehen wir leider nur allzu oft derartige Risiken. Cloud-Dienste scheinen einfach zu konfigurieren zu sein, aber ein kleiner Fehler kann ganze Datensätze im öffentlichen Internet preisgeben. Möglicherweise verwalten Sie viele Speicherbereiche mit unterschiedlichen Zugriffsebenen für die interne und externe Nutzung, und es kann schnell schwierig werden, Ihre Konfigurationen zu verwalten. Die Offenlegung von Cloud-Speichern ist besonders problematisch, da ein Angreifer leicht auf Daten zugreifen oder diese ändern kann, während ein Speicher-Bucket falsch konfiguriert ist. Aufsehen erregende Verletzungen von S3-Buckets und anderen Cloud-Speicherressourcen gab es bereits beim US-Verteidigungsministerium, bei Dow Jones & Co und bei Booz Allen Hamilton.
In diesem Blog wird anhand einer Schritt-für-Schritt-Analyse untersucht, wie eine Fehlkonfiguration des S3-Buckets zu einer Sicherheitsverletzung führen kann:
- Erstellen eines neuen Amazon S3-Speicher-Buckets
- Konfigurieren der Zugriffskontrollliste (ACL) für diesen Amazon S3-Bucket
- Gängige Angreifervektoren für den Zugriff auf Daten, sobald die Berechtigungen für den Bucket konfiguriert sind
- So überprüfen Sie mit der Censys ASM-Plattform, ob Amazon S3-Buckets unbeabsichtigt offengelegt werden können
Analyse
Um die Komplexität der Konfiguration des Cloud-Speicherzugriffs zu veranschaulichen, betrachten Sie die Zugriffsgruppe "Authentifizierter Benutzer" für Buckets von Amazon. Das mag zunächst nicht so beängstigend klingen, oder? In der Nomenklatur von Amazon ist ein "authentifizierter Benutzer" jedoch jeder, der mindestens ein AWS-Konto der kostenlosen Stufe besitzt. Mit anderen Worten: Wenn Ihr S3-Bucket mit dem Gruppenzugriff "Authentifizierter Benutzer" konfiguriert ist, hat jeder, der sich für ein AWS-Konto anmeldet, vollen Zugriff auf Ihre Daten. Es gibt dokumentierte, groß angelegte Sicherheitslücken, die darauf zurückzuführen sind, dass ein Anwender einen Speicher-Bucket mit dieser Zugriffsgruppe falsch konfiguriert hat.
Um zu veranschaulichen, wie ein Angreifer Daten aus einem Speicher-Bucket kompromittieren und exfiltrieren könnte, gehen wir ein Beispiel mit dem AWS CLI-Tool durch.
Mit einem privaten Konto erstellen wir einen neuen Speicher-Bucket.
Nun ist es an der Zeit, die ACL-Richtlinie für diesen Bucket zu konfigurieren. Wir geben der Gruppe "Authentifizierte Benutzer" Lesezugriff, da wir möchten, dass unsere Kollegen alle im Bucket gespeicherten Dokumente sehen können.
Nachdem unser Bucket erstellt wurde, ist es an der Zeit, einige Daten hochzuladen. Die Datei "ohno.txt" ist die Datei, die unsere Kollegen mit AWS-Konten lesen können sollen.
Nehmen wir an, es sind ein paar Wochen vergangen und unser internes Team hat diesen Eimer mit großem Erfolg eingesetzt.
Leider hat ein Angreifer herausgefunden, dass unser Unternehmen "my-exposed-bucket" als Projektnamen verwendet, und möchte dies ausnutzen, um potenziell exponierte Daten in unserem Speicher-Bucket aufzudecken. Er stellt fest, dass der Aufruf von "https://my-exposed-bucket.s3.us-east-2.amazonaws.com/" in seinem Browser einen "AccessDenied"-Fehlercode zurückgibt, der ihn darüber informiert, dass ein Speicherbereich unter diesem Namen existiert.
Der Angreifer weiß nun, dass er diese Informationen potenziell einsehen kann. Er konfiguriert sein persönliches AWS CLI-Tool und versucht, den Bucket mit dem Befehl "ls" aufzulisten. Er stellt fest, dass der Bucket offengelegt ist und eine "txt"-Datei namens "ohno" enthält.
Um auf die offengelegten Daten zuzugreifen, verwendet der Angreifer den Befehl "cp", um den Inhalt in ein Verzeichnis auf seinem eigenen Rechner zu kopieren. Hier kopieren wir `ohno.txt` nach `./Desktop`.
Die Informationen aus dem Bucket befinden sich nun auf dem persönlichen Rechner des Angreifers. Glücklicherweise ist unser offengelegtes Dokument vom Inhalt her harmlos!
Von allen Speicher-Buckets, die von Censys ASM verwaltet werden, sind ~8,5 % als öffentlich lesbar, beschreibbar oder mit editierbaren Konfigurationseinstellungen ausgesetzt. Bei allen Ihren Cloud-Speicheranbietern kann dies bedeuten, dass ein beträchtlicher Teil Ihrer Speicher-Buckets falsch konfiguriert ist und zu Angriffen wie oben beschrieben führen kann.
Was kann ich tun?
Die gute Nachricht ist, dass die Fehlkonfiguration von Eimern ein lösbares Problem ist. Durch die Implementierung von Best Practices innerhalb Ihres Teams und die Einführung automatisierter Lösungen zur Aufdeckung von Risiken können Sie sich besser vor Risiken schützen.
- Stellen Sie sicher, dass für Ihre Cloud-Speicherdienste geeignete IAM-Richtlinien konfiguriert sind.
- Erstellen und kommunizieren Sie strenge Sicherheitsrichtlinien innerhalb Ihres Teams. Das NIST bietet umfassende Sicherheitsrichtlinien für Speicherinfrastrukturen.
- Erwägen Sie die Implementierung einer automatisierten ASM-Lösung zur Identifizierung von Fehlkonfigurationen bei Cloud-Speichern. Censys ist der einzige ASM-Anbieter, der Risiken im Zusammenhang mit den Ihnen gehörenden Speicher-Buckets erkennt und Ihre Daten automatisch nutzt, um unbekannte Speicher-Buckets aufzudecken, die Ihre Sicherheitslage beeinträchtigen könnten.
- Aktuelle Censys ASM-Kunden können die Seite mit der Liste der Speicherbereiche aufrufen, um eine aktuelle Sammlung ihrer Speicherbereiche und aller damit verbundenen Risiken anzuzeigen. Sie sind kein Censys ASM-Kunde? Nehmen Sie über die KontaktseiteCensys Kontakt auf!
--
