Am 19. Juli 2019 erhielt die Capital One Bank eine Nachricht, vor der jedes moderne Unternehmen Angst hat - ein Datenleck ist aufgetreten. Es betraf mehr als 106 Millionen Menschen. 140.000 US-Sozialversicherungsnummern, eine Million kanadische Sozialversicherungsnummern. 80.000 Bankkonten. Unangenehm, stimme zu?
Leider hat das Hacken am 19. Juli überhaupt nicht stattgefunden. Wie sich herausstellte, führte Paige Thompson, auch bekannt als
Erratic , es zwischen dem 22. und 23. März 2019 auf. Das ist
fast vier Monate her . Tatsächlich wusste Capital One nur mit Hilfe externer Berater, dass etwas passiert war.
Ehemalige Amazon-Mitarbeiterin verhaftet, droht ihr eine Geldstrafe von 250.000 US-Dollar und fünf Jahre Gefängnis ... aber es gibt viel Negativität. Warum? Weil viele Unternehmen, die gehackt wurden, versuchen, die Verantwortung für die Stärkung ihrer Infrastruktur und Anwendungen angesichts der zunehmenden Internetkriminalität beiseite zu schieben.
In jedem Fall können Sie diese Geschichte einfach googeln. Wir werden nicht ins Drama gehen, sondern über die
technische Seite der Dinge sprechen.
Was ist zuerst passiert?
Bei Capital One gab es ungefähr 700 S3-Eimer, die Paige Thompson kopierte und entleerte.
Ist dies zweitens ein weiterer Fall einer falsch konfigurierten S3-Bucket-Richtlinie?
Nein, diesmal nicht. Hier erhielt sie Zugriff auf einen Server mit einer falsch konfigurierten Firewall und führte von dort aus den gesamten Vorgang durch.
Warten Sie, wie ist das möglich?
Beginnen wir mit der Anmeldung am Server, obwohl wir nur wenige Details haben. Uns wurde nur gesagt, dass dies durch eine „falsch konfigurierte Firewall“ geschehen ist. Etwas so Einfaches wie die falschen Sicherheitsgruppeneinstellungen oder die Konfiguration der Webanwendungsfirewall (Imperva) oder der Netzwerkfirewall (iptables, ufw, shorewall usw.). Capital One bekannte sich nur schuldig und sagte, dass es das Loch schloss.
Stone sagte, dass Capital One die Sicherheitslücke der Firewall zunächst nicht bemerkte, aber schnell reagierte, sobald es davon erfuhr. Dies wurde natürlich durch die Tatsache unterstützt, dass der Hacker den Schlüssel zur Identifizierung der Informationen angeblich öffentlich zugänglich gemacht habe, sagte Stone.
Wenn Sie daran interessiert sind, warum wir uns nicht mit diesem Teil befassen, verstehen Sie, dass wir aufgrund begrenzter Informationen nur spekulieren können. Dies ist sinnlos, da der Hack von der Lücke abhängt, die Capital One hinterlassen hat. Und wenn sie uns nicht mehr erzählen, listen wir nur alle möglichen Möglichkeiten auf, wie Capital One seinen Server offen gelassen hat, in Kombination mit allen möglichen Möglichkeiten, wie jemand eine dieser verschiedenen Optionen nutzen kann. Diese Lücken und Methoden können von wild dummen Versehen bis zu unglaublich komplexen Mustern reichen. Angesichts der Vielzahl von Möglichkeiten wird dies zu einer langen Saga ohne wirklichen Abschluss. Daher konzentrieren wir uns auf die Analyse des Teils, in dem wir die Fakten haben.Also die erste Schlussfolgerung: Wissen Sie, was Ihre Firewalls erlauben
Richten Sie eine Richtlinie oder einen Prozess ein, um sicherzustellen, dass NUR das, was offen ist, offen ist. Wenn Sie AWS-Ressourcen wie Sicherheitsgruppen oder Netzwerk-ACLs verwenden, kann die Checkliste für die Überprüfung natürlich lang sein. Da jedoch viele Ressourcen automatisch erstellt werden (d. H. CloudFormation), können Sie auch deren Prüfung automatisieren. Ob es sich um ein provisorisches Skript handelt, das nach neuen Objekten auf Fehler sucht, oder um eine Sicherheitsüberprüfung in einem CI / CD-Prozess ... es gibt viele einfache Optionen, um dies zu vermeiden.
Der „lustige“ Teil der Geschichte ist, dass nichts passiert wäre, wenn Capital One das Loch von Anfang an geschlossen hätte. Und deshalb ist es ehrlich gesagt immer schockierend zu sehen, wie wirklich etwas
ganz Einfaches der einzige Grund für eine Hacking-Firma wird. Besonders so groß wie Capital One.
Also, der Hacker drinnen - was ist als nächstes passiert?
Nun, nach dem Einbruch in die EC2-Instanz ... kann viel schief gehen. Sie gehen fast am Rand eines Messers entlang, wenn Sie jemandem erlauben, so weit zu gehen. Aber wie ist sie in den S3-Eimer gekommen? Um dies zu verstehen, diskutieren wir die Rollen von IAM (IAM-Rollen).
Eine Möglichkeit, auf AWS-Services zuzugreifen, besteht darin, Benutzer zu sein. Okay, das ist ziemlich offensichtlich. Was aber, wenn Sie anderen AWS-Diensten, z. B. Ihren Anwendungsservern, Zugriff auf Ihre S3-Buckets gewähren möchten? Dafür gibt es IAM-Rollen. Sie bestehen aus zwei Komponenten:
- Vertrauensrichtlinie - Welche Dienste oder welche Personen können diese Rolle nutzen?
- Berechtigungsrichtlinie - Was ermöglicht diese Rolle?
Sie möchten beispielsweise eine IAM-Rolle erstellen, mit der EC2-Instanzen auf den S3-Bucket zugreifen können: Zunächst wird eine Vertrauensrichtlinie für die Rolle eingerichtet, die EC2 (der gesamte Dienst) oder bestimmte Instanzen die Rolle übernehmen können. Das Annehmen einer Rolle bedeutet, dass sie Rollenberechtigungen verwenden können, um Aktionen auszuführen. Zweitens ermöglicht die Berechtigungsrichtlinie dem Dienst / der Person / der Ressource, die / die die Rolle übernommen hat, etwas in S3 zu tun, sei es Zugriff auf einen bestimmten Bucket ... oder auf mehr als 700, wie im Fall von Capital One.
Sobald Sie sich in einer EC2-Instanz mit der IAM-Rolle befinden, können Sie Anmeldeinformationen auf verschiedene Arten abrufen:
- Sie können Instanzmetadaten unter
http://169.254.169.254/latest/meta-data anfordern
Unter dieser Adresse finden Sie unter anderem die IAM-Rolle mit einem der Zugriffsschlüssel. Natürlich nur, wenn Sie sich in einer Instanz befinden.
- Verwenden Sie AWS CLI ...
Wenn die AWS-Befehlszeilenschnittstelle installiert ist, werden sie gegebenenfalls mit den Anmeldeinformationen der IAM-Rollen geladen. Es bleibt nur die Instanz durchzuarbeiten. Wenn ihre Vertrauensrichtlinie offen wäre, könnte Page dies natürlich direkt tun.
Das Wesentliche an den IAM-Rollen ist daher, dass eine Ressource von IHREM NAMEN auf ANDERE RESSOURCEN reagieren kann.
Nachdem Sie die Rollen von IAM verstanden haben, können wir darüber sprechen, was Page Thompson getan hat:
- Sie erhielt Zugriff auf den Server (EC2-Instanz) durch ein Loch in der Firewall
Unabhängig davon, ob es sich um Sicherheitsgruppen / ACLs oder um eigene Webanwendungs-Firewalls handelt, war die Lücke wahrscheinlich recht einfach zu schließen, wie in den offiziellen Aufzeichnungen angegeben.
- Sobald sie auf dem Server war, konnte sie so tun, als wäre sie der Server
- Da die IAM-Serverrolle S3 den Zugriff auf diese über 700 Buckets ermöglichte, konnte sie darauf zugreifen
Von nun an konnte sie nur noch den Befehl
List Buckets und dann den Befehl
Sync über die AWS CLI ausführen ...
Die Capital One Bank schätzt den Schaden durch Hacking auf 100 bis 150 MILLIONEN Dollar . Um solche Schäden zu vermeiden, investieren Unternehmen so viel in den Schutz der Cloud-Infrastruktur, von DevOps und Sicherheitsexperten. Und wie wertvoll und kostengünstig ist der Übergang zur Cloud? So sehr, dass der
öffentliche Cloud-Markt trotz immer mehr Cybersicherheitsproblemen
im ersten Quartal 2019 um 42% wuchs !
Die Moral dieser Geschichte: Überprüfen Sie Ihre Sicherheit; regelmäßige Audits durchführen; Respektieren Sie das Prinzip des geringsten Privilegs für Sicherheitsrichtlinien.
(Den vollständigen Rechtsbericht finden Sie hier).