Am 19. Juli 2019 erhielt Capital One die Nachricht, die jedes moderne Unternehmen fürchtet: Es kam zu einem Datenverstoß. Mehr als 106 Millionen Menschen waren davon betroffen. 140 US-amerikanische Sozialversicherungsnummern, eine Million kanadische Sozialversicherungsnummern. 000 Bankkonten. Unangenehm, finden Sie nicht auch?
Leider kam es am 19. Juli nicht zu dem Hack. Wie sich herausstellt, ist Paige Thompson, alias Erratisch, hat es zwischen dem 22. und 23. März 2019 begangen. Also vor fast vier Monaten. Tatsächlich konnte Capital One nur mithilfe externer Berater herausfinden, dass etwas passiert war.
Ein ehemaliger Amazon-Mitarbeiter wurde verhaftet und ihm drohen eine Geldstrafe von 250 US-Dollar und fünf Jahre Gefängnis … aber es gibt immer noch viel Negativität. Warum? Denn viele Unternehmen, die unter Hacks gelitten haben, versuchen angesichts der zunehmenden Cyberkriminalität, die Verantwortung für die Stärkung ihrer Infrastruktur und Anwendungen abzuschütteln.
Wie auch immer, Sie können diese Geschichte ganz einfach googeln. Wir werden nicht aufs Drama eingehen, sondern darüber reden technisch Seite der Sache.
Zunächst einmal: Was ist passiert?
Bei Capital One waren etwa 700 S3-Eimer im Einsatz, die Paige Thompson kopierte und abschöpfte.
Zweitens: Ist dies ein weiterer Fall einer falsch konfigurierten S3-Bucket-Richtlinie?
Nein, dieses Mal nicht. Hier verschaffte sie sich Zugang zu einem Server mit falsch konfigurierter Firewall und führte von dort aus den gesamten Vorgang durch.
Warte, wie ist das möglich?
Nun, beginnen wir mit der Anmeldung beim Server, obwohl wir noch nicht viele Details haben. Uns wurde lediglich mitgeteilt, dass dies durch eine „falsch konfigurierte Firewall“ geschehen sei. Also etwas so Einfaches wie falsche Sicherheitsgruppeneinstellungen oder Konfiguration der Webanwendungs-Firewall (Imperva) oder Netzwerk-Firewall (iptables, ufw, Shorewall usw.). Capital One gab lediglich seine Schuld zu und sagte, es habe das Loch geschlossen.
Stone sagte, Capital One habe die Sicherheitslücke in der Firewall zunächst nicht bemerkt, aber schnell gehandelt, als es davon Kenntnis erlangte. Dies sei sicherlich dadurch begünstigt worden, dass der Hacker angeblich wichtige Identifizierungsinformationen öffentlich zugänglich gemacht habe, sagte Stone.
Wenn Sie sich fragen, warum wir nicht tiefer auf diesen Teil eingehen, haben Sie bitte Verständnis dafür, dass wir aufgrund begrenzter Informationen nur spekulieren können. Dies macht keinen Sinn, wenn man bedenkt, dass der Hack auf einer von Capital One hinterlassenen Lücke beruhte. Und sofern sie uns nicht mehr verraten, listen wir einfach alle Möglichkeiten auf, wie Capital One seinen Server offen gelassen hat, in Kombination mit allen Möglichkeiten, wie jemand eine dieser verschiedenen Optionen nutzen könnte. Diese Fehler und Techniken können von völlig dummen Versäumnissen bis hin zu unglaublich komplexen Mustern reichen. Angesichts der Bandbreite an Möglichkeiten wird dies eine lange Saga ohne wirklichen Abschluss werden. Konzentrieren wir uns daher auf die Analyse des Teils, in dem wir Fakten haben.
Die erste Erkenntnis lautet also: Informieren Sie sich darüber, was Ihre Firewalls zulassen.
Legen Sie eine Richtlinie oder einen geeigneten Prozess fest, um sicherzustellen, dass NUR das geöffnet wird, was geöffnet werden muss. Wenn Sie AWS-Ressourcen wie Sicherheitsgruppen oder Netzwerk-ACLs verwenden, kann die zu prüfende Checkliste natürlich lang sein ... aber genau wie viele Ressourcen automatisch erstellt werden (z. B. CloudFormation), ist es auch möglich, ihre Prüfung zu automatisieren. Ob es sich um ein selbst erstelltes Skript handelt, das neue Objekte auf Fehler überprüft, oder um etwas wie eine Sicherheitsüberprüfung in einem CI/CD-Prozess … es gibt viele einfache Möglichkeiten, dies zu vermeiden.
Der „lustige“ Teil der Geschichte ist, dass nichts passiert wäre, wenn Capital One das Loch überhaupt gestopft hätte. Und ehrlich gesagt ist es immer wieder schockierend zu sehen, wie etwas wirklich ist ziemlich einfach wird der einzige Grund dafür, dass ein Unternehmen gehackt wird. Vor allem eines, das so groß ist wie Capital One.
Also, Hacker drinnen – was geschah als nächstes?
Nun ja, nach dem Einbruch in eine EC2-Instanz ... kann viel schiefgehen. Man steht praktisch auf Messers Schneide, wenn man jemanden so weit gehen lässt. Aber wie gelangte es in die S3-Buckets? Um dies zu verstehen, besprechen wir IAM-Rollen.
Eine Möglichkeit, auf AWS-Dienste zuzugreifen, besteht also darin, ein Benutzer zu sein. Okay, das ist ziemlich offensichtlich. Was aber, wenn Sie anderen AWS-Diensten, beispielsweise 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 Personen können diese Rolle nutzen?
- Berechtigungsrichtlinie – was erlaubt diese Rolle?
Sie möchten beispielsweise eine IAM-Rolle erstellen, die EC2-Instanzen den Zugriff auf einen S3-Bucket ermöglicht: Zunächst wird die Rolle so eingestellt, dass sie über eine Vertrauensrichtlinie verfügt, die EC2 (der gesamte Dienst) oder bestimmte Instanzen die Rolle „übernehmen“ kann. Das Akzeptieren einer Rolle bedeutet, dass sie die Berechtigungen der Rolle zum Ausführen von Aktionen nutzen können. Zweitens erlaubt die Berechtigungsrichtlinie dem Dienst/der Person/der Ressource, die „die Rolle übernommen“ hat, alles auf S3 zu tun, sei es der Zugriff auf einen bestimmten Bucket … oder auf über 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 erhalten:
- Sie können Instanzmetadaten unter anfordern
http://169.254.169.254/latest/meta-dataUnter dieser Adresse finden Sie unter anderem die IAM-Rolle mit allen Zugriffsschlüsseln. Natürlich nur, wenn Sie sich in einer Instanz befinden.
- Verwenden Sie AWS CLI...
Wenn die AWS CLI installiert ist, wird sie mit Anmeldeinformationen aus den IAM-Rollen geladen, sofern vorhanden. Es bleibt nur noch, DURCH die Instanz zu arbeiten. Wenn ihre Vertrauensrichtlinie offen wäre, könnte Paige natürlich alles direkt erledigen.
Das Wesentliche an IAM-Rollen ist also, dass sie einigen Ressourcen ermöglichen, IN IHREM NAMEN auf ANDERE RESSOURCEN zu agieren.
Nachdem Sie nun die Rollen von IAM verstanden haben, können wir darüber sprechen, was Paige Thompson getan hat:
- Durch eine Lücke in der Firewall verschaffte sie sich Zugriff auf den Server (EC2-Instanz).
Unabhängig davon, ob es sich um Sicherheitsgruppen/ACLs oder eigene Webanwendungs-Firewalls handelte, ließ sich die Lücke vermutlich recht einfach schließen, wie aus den offiziellen Aufzeichnungen hervorgeht.
- Sobald sie auf dem Server war, konnte sie so tun, als ob sie selbst der Server wäre
- Da die IAM-Serverrolle S3 den Zugriff auf diese über 700 Buckets ermöglichte, war es möglich, darauf zuzugreifen
Von diesem Moment an musste sie nur noch den Befehl ausführen List Bucketsund dann der Befehl Sync von AWS CLI...
. Um solche Schäden zu verhindern, investieren Unternehmen so viel in den Schutz der Cloud-Infrastruktur, DevOps und Sicherheitsexperten. Und wie wertvoll und kosteneffektiv ist der Wechsel in die Cloud? Und das sogar angesichts immer größerer Herausforderungen im Bereich der Cybersicherheit !
Moral der Geschichte: Überprüfen Sie Ihre Sicherheit; Führen Sie regelmäßige Audits durch. Beachten Sie bei Sicherheitsrichtlinien das Prinzip der geringsten Privilegien.
( Den vollständigen Rechtsbericht können Sie hier einsehen.
Source: habr.com