Viel beachtete AWS-Datenpannen und wie Sie sie vermeiden

Wenige Tage vor Weihnachten 2021 stellten Mitarbeitende und Kunden des Terminplanungsdienstes Flexbooker fest, dass Angreifer zehn Millionen Datensätze mit Kundenidentifikationsdaten erbeutet hatten – darunter Fotos, Führerscheine und gehashte Passwörter. 

Angreifer erbeuteten Millionen personenbezogener Daten (PII), weil Flexbooker sein AWS-Konto falsch konfiguriert hatte. Konkret war ein AWS-S3-Bucket so eingerichtet, dass dessen Inhalte öffentlich zugänglich waren. Diese AWS-Datenpanne sorgte für Schlagzeilen – aber nicht, weil sie neuartig war.  Auch Capital One, Twilio, Uber und weitere Unternehmen waren von AWS-Datenpannen betroffen. In diesen Fällen drangen die Angreifer nicht in AWS selbst ein, sondern gelangten über eine Fehlkonfiguration von AWS in ein Unternehmen.

Trotz des Ausmaßes dieser Datenpannen liegt die Ursache von Problemen mit der Cloud-Sicherheit meist auf der Hand: Fehlkonfigurationen. Cloud-Sicherheit basiert auf einem Modell geteilter Verantwortung. Das bedeutet: Der Anbieter sichert die Infrastruktur, aber der Kunde muss seine Anwendungen sicher bereitstellen – in allen Umgebungen, nicht nur in der Produktionsumgebung. In den meisten Fällen entstehen durch einfache Fehlkonfigurationen bereitgestellter Anwendungen oder Dienste Sicherheitslücken, die groß genug für einen Angriff sind.

In diesem Artikel stellen wir einige der viel beachteten AWS-Sicherheitsvorfälle vor, die in den vergangenen Jahren durch Fehlkonfigurationen verursacht wurden, und zeigen, wie Sie Datenpannen verhindern können – mit besseren Sicherheitspraktiken. 

Capital One: Eine falsch konfigurierte Firewall betrifft 100 Millionen Kunden 

Im Juli 2019 gab die Großbank und der Finanzdienstleister Capital One bekannt, dass ein ehemaliger Amazon-Mitarbeiter die AWS-Server des Unternehmens gehackt hatte. 

Der Angriff betraf mehr als 100 Millionen Kunden und legte personenbezogene Daten offen, darunter Sozialversicherungsnummern, Bankkontonummern, Bonitätsbewertungen und weitere Informationen. Amazon stellte klar, dass AWS keine Schuld traf und die zugrunde liegenden Cloud-Dienste nicht kompromittiert worden waren. Stattdessen verschaffte sich der Hacker, wie Capital One einräumte, über eine falsch konfigurierte Open-Source-Web Application Firewall (WAF) Zugriff. 

Kunden reichten eine Sammelklage ein, die Capital One beilegte. Die Kunden erhielten dabei bis zu 25.000 US-Dollar pro Anspruch. Die Kläger argumentierten, Capital One habe „von den konkreten Sicherheitslücken gewusst, die den Datenverstoß ermöglichten“, diese jedoch nicht behoben. Capital One stimmte der Klage weder zu noch widersprach das Unternehmen ihr. Stattdessen erklärte es, die Einigung erfolge „im Interesse, Zeit, Kosten und Unsicherheit eines fortgesetzten Rechtsstreits zu vermeiden“.

Pegasus Airlines: Ein ungeschützter S3-Bucket legt 6,5 Terabyte Daten offen

Im Mai 2022 entdeckte die türkische Fluggesellschaft Pegasus Airlines dank der Arbeit eines Sicherheitsunternehmens, dass sie einen AWS-S3-Bucket falsch konfiguriert hatte. Der Bucket enthielt sensible Flugdaten, darunter Flugkarten, Navigationsunterlagen und personenbezogene Daten zahlreicher Mitarbeitender. 

Der offene S3-Bucket gab außerdem Teile des Quellcodes des Unternehmens preis. Darin fanden sich Passwörter im Klartext und geheime Schlüssel, mit denen potenzielle Angreifer auf noch sensiblere Daten hätten zugreifen können. 

Insgesamt entdeckte das Sicherheitsunternehmen fast 23 Millionen offengelegte Dateien – etwa 6,5 Terabyte an Daten. Es merkte an: „Diese Offenlegung könnte die Sicherheit jedes Pegasus-Passagiers und jedes Besatzungsmitglieds weltweit beeinträchtigen.“

Das Sicherheitsunternehmen informierte Pegasus Airlines. Laut dem Unternehmen wurde „der AWS-S3-Bucket umgehend gesichert, und PegasusEFB antwortete später mit einem Dank für den Hinweis“.

Twilio: Ein offener S3-Bucket ermöglicht es Angreifern, schädlichen Code einzuschleusen

Im Juli 2020 bestätigte der Cloud-Kommunikationsanbieter Twilio, dass Angreifer auf einen falsch konfigurierten S3-Bucket zugegriffen und das JavaScript-SDK für das Tool TaskRouter verändert hatten. 

Die Angreifer nutzten eine Fehlkonfiguration des S3-Buckets aus, in dem die Bibliothek für Twilios TaskRouter-JS-SDK gehostet wurde (TaskRouter ist ein Tool, mit dem Twilio-Kunden Aufgaben weiterleiten können). Nach dem Angriff lud die veränderte Bibliothek Browser dazu, eine zusätzliche URL aufzurufen – eine URL, die später mit den berüchtigten Magecart-Angriffen in Verbindung gebracht wurde. 

Twilio erklärte in einer Mitteilung, das Unternehmen habe den Vorfall innerhalb von 15 Minuten behoben und den S3-Bucket eine Stunde später neu konfiguriert. Außerdem erklärte Twilio, die Angreifer hätten weder Zugriff auf Kundendaten noch auf interne Systeme erlangt. 

Twilio ging offen mit dem Vorfall um und erklärte: „Wir hatten die Zugriffsrichtlinie für einen unserer AWS-S3-Buckets nicht ordnungsgemäß konfiguriert.“ Twilio hatte diesen Zugriffsweg 2015 eingerichtet; damals war er nicht anfällig. Einige Monate später, so erklärte Twilio, setzte das Unternehmen nach der Behebung eines Problems die Berechtigungen jedoch nicht „ordnungsgemäß zurück“. 

Uber: Schwache Authentifizierung legt geheime Schlüssel offen, mit denen Hacker auf AWS-S3-Datenspeicher mit 600.000 Datensätzen von US-Fahrern zugreifen

Im November 2017 gab der Fahrdienstvermittler Uber bekannt, dass Angreifer bereits 2016 die personenbezogenen Daten von mehr als 50 Millionen Fahrgästen und Fahrern sowie 600.000 Datensätze von US-Fahrern einschließlich Führerscheinnummern gestohlen hatten.

Angreifer konnten auf das GitHub-Repository von Uber zugreifen, weil das Unternehmen die Multi-Faktor-Authentifizierung nicht aktiviert hatte. Trotz der mangelnden Sicherheit enthielten diese Repositories wichtige AWS-Zugangsdaten. Damit konnten die Angreifer auf die AWS-S3-Datenspeicher von Uber zugreifen. 

Uber erklärte, das Unternehmen habe die Daten gesichert, den unbefugten Zugriff beendet, die Angreifer dazu gebracht, die Daten zu löschen, und die Kontrollen für seine Cloud-Speicherkonten verstärkt. Spätere Berichte enthüllten jedoch, dass Uber den ursprünglichen Hack als erfolgreichen Bug-Bounty-Fund getarnt und den Angreifern 100.000 US-Dollar für ihr Schweigen gezahlt hatte. 

Imperva: Ein offener AWS-API-Schlüssel verschafft Angreifern Zugriff auf eine Datenbank mit Kunden-E-Mail-Adressen und Passwörtern

Im Oktober 2019 gab der Cybersicherheitsanbieter Imperva bekannt, dass Angreifer durch Ausnutzung einer falsch konfigurierten AWS-Instanz Kundendaten gestohlen hatten.

Der CEO von Imperva erklärte, die Angreifer hätten einen administrativen API-Schlüssel aus einem AWS-Konto des Unternehmens verwendet, um auf einen Datenbank-Snapshot mit E-Mail-Adressen und Passwörtern zuzugreifen. 

Imperva legte die Fehler offen, die zu der AWS-Sicherheitslücke geführt hatten, und erklärte, dass letztlich vier zentrale Schritte zur Offenlegung von Kundendaten führten:

1. Imperva erstellte beim Testen von AWS einen Datenbank-Snapshot zu Testzwecken.

2. Imperva machte eine interne Compute-Instanz öffentlich zugänglich, obwohl sie einen AWS-API-Schlüssel enthielt.

3. Angreifer kompromittierten die Compute-Instanz und stahlen den AWS-API-Schlüssel.

4. Die Angreifer nutzten den AWS-API-Schlüssel, um auf den Datenbank-Snapshot und alle darin enthaltenen Daten zuzugreifen. 

Seitdem hat das Unternehmen zahlreiche Korrekturmaßnahmen ergriffen, darunter strengere Zugriffskontrollen und die Einführung von Zugriffsaudits. 

Drei Erkenntnisse aus AWS-Datenpannen

Aus diesen AWS-Datenpannen können Sie einige wichtige Lehren ziehen, um die AWS-Nutzung Ihres Unternehmens sicherer zu gestalten:

1. Kennen Sie Ihre Umgebung: Viele AWS-Datenpannen sind auf Konfigurationsfehler zurückzuführen. Je besser Sie Ihre Umgebung kennen und überprüfen, desto geringer ist die Wahrscheinlichkeit, dass Angreifer eine ausnutzbare Fehlkonfiguration finden. 

2. Stärken Sie Ihre Entwickler: Entwickler sind am besten in der Lage, Konfigurationsfehler zu erkennen und zu beheben. Unternehmen können AWS-Datenpannen besser verhindern, wenn sie Entwicklern die Tools und Anleitungen für den Aufbau sicherer Umgebungen an die Hand geben. 

3. Setzen Sie auf Prävention und sicheres Design: Viele dieser AWS-Datenpannen hätten verhindert werden können, wenn die betroffenen Unternehmen stärker auf sicheres Design gesetzt hätten. Mit Tools wie dem AWS-Schwachstellen-Scanning von Snyk können Unternehmen Schwachstellen erkennen, bevor Angreifer sie ausnutzen. Erfahren Sie hier, wie Snyk in AWS-Sicherheitstools integriert wird.

Wenn Sie mehr über Cloud-Sicherheit erfahren möchten, laden Sie unser E-Book „The Five Fundamentals of Cloud Security“ herunter. Und wenn Sie mehr darüber erfahren möchten, wie Snyk und AWS zusammenarbeiten, lesen Sie den AWS Quick start guide.