Get best of the week

Warum Wolken zu Gewitterwolken werden: Fehler bei der Cloud-Bereitstellung

Bild

Eine Cloud-Implementierung in einer großen Organisation umfasst normalerweise viele Dienste von verschiedenen Anbietern, von denen jeder seine eigenen Regeln für Interaktion, Einstellungen und sogar Protokolle hat. Infolgedessen wird die Sicherheitskonfiguration so komplex, dass sie schwer zu verfolgen und noch schwerer zu verstehen ist. In unserer neuen Studie haben wir die häufigsten Fehler bei der Bereitstellung einer Cloud-Infrastruktur am Beispiel von Amazon Web Services gesammelt und einige davon in diesem Beitrag vorgestellt.

Cloud-Anbieter bieten heute Dienste an, die über die triviale „Widmung“ oder Dateispeicherung hinausgehen. Jeder Aspekt jedes Dienstes kann programmiert werden. Dies gibt Entwicklern und Betreibern mehr Kontrolle über die Sicherheit als ein herkömmliches Rechenzentrum. Die Fülle an Funktionen und deren Konfigurationstools führt jedoch dazu, dass Sie über mehrere Schnittstellen konfigurieren können und - und dies ist wichtig - die Standardparameter für verschiedene Methoden unterschiedlich sind.

Für erfahrene Benutzer ist dies kein Problem - im Gegenteil, sie verwenden das am besten geeignete Werkzeug für die Aufgabe. Für andere entspricht das Ergebnis jedoch möglicherweise nicht ihren Erwartungen.

Amazon S3-Speicher


Amazon Simple Storage Services oder Amazon S3 ist einer der gefragtesten Cloud-Dienste, die von vielen Kunden genutzt werden, von kleinen Unternehmen bis zu großen Unternehmen. Die Popularität hat S3 zu einem bevorzugten Ziel für Angreifer gemacht, die nach Fehlern bei der Implementierung von Diensten und Fehlern in ihrer Konfiguration suchen.

Die häufigsten von Cyberkriminellen verwendeten Amazon S3-Angriffsmethoden sind:

  • öffentliche Lagereinrichtungen für die Aufzeichnung;
  • Abfangen von Konten;
  • Missbrauch von Privilegien.

Freigabe aufzeichnen


Im Februar 2018 wurde der Cryptocurrency Miner Monero auf dem Gelände einer der größten amerikanischen Zeitungen entdeckt. Jeder Leser, der die Website besucht hat, hat Münzen für Kriminelle abgebaut, die den JavaScript-Dateien der Veröffentlichung bösartigen Code hinzugefügt haben.

Die Website der Zeitung wurde von Amazon gehostet und speicherte alle Bilder, Skripte und Stildateien im S3-Repository. Der Zugriff auf dieses Repository wurde nur durch Lesen eingeschränkt, sodass das Hacken für Site-Administratoren eine völlige Überraschung war. Sie konnten einfach nicht verstehen, wie sie gehackt wurden, bis die Cloud-Service-Spezialisten erklärten, dass der Grund die falschen Zugriffsrechte seien.

Amazon S3-Repositorys können über http / https verwendet werden. In diesem Teil haben Site-Administratoren alles richtig gemacht und den Zugriff nur auf das Lesen beschränkt. Auf S3 kann jedoch auch über das native AWS-Protokoll über die Befehlszeile zugegriffen werden. Die Zugriffsrechte für solche Anrufe müssen separat festgelegt werden. Standardmäßig ist der Speicherzugriff über die AWS-CLI für alle von AWS autorisierten Benutzer zulässig.

Bild
Das Ergebnis der Ausführung des Konsolenbefehls aws s3api get-Bucket-acl --bucket <BUCKET_NAME> für den Standard-Tresor

für neue Amazon S3-Benutzer. Die Notwendigkeit, ihre Tresorberechtigungen doppelt einzuschränken, ist alles andere als offensichtlich, was zu zahlreichen Vorfällen führte.

Ende 2018 definierte AWS die Sicherheitsrichtlinie neu, indem der öffentliche Zugriff von der Konsole für neue S3-Repositorys untersagt wurde. Diese Richtlinie wurde jedoch bei Verwendung der Befehlszeile nicht angewendet. Der Zugang musste immer noch auf ein separates Team beschränkt werden.

In den Jahren 2018-2019 verbreitete sich der Kompromiss beim S3-Speicher. Einige Sicherheitsexperten und freundliche Hacker suchten speziell nach AWS-Ressourcen, die zum Schreiben geöffnet waren, und hinterließen dort Warndateien.

Bild
Anonyme Warnung vor einer unsicheren Konfiguration von AWS S3

Jemand bot sogar seine Dienste zum Einrichten sicherer Speicherparameter an:

Bild
Warnung und Angebot von Diensten von Pentester Random Robbie

Random Robbie ist das Pseudonym für Robbie Wiggins Pentester, der 2018 seine Warnung zu Tausenden von S3-Speichern für die Aufzeichnung offen ließ.

Die Möglichkeit, in S3-Repositorys gehostete Websites frei zu ändern, wurde von Hackern sofort genutzt. Die Magecart-Gruppe führte massiv bösartigen Code ein, um Bankkartendaten und Benutzerkontoinformationen zu stehlen. Schließlich musste nur eine Website gefunden werden, die Zahlungen akzeptiert und AWS verwendet. Infolgedessen gelang es Kriminellen, die Daten von Hunderttausenden von Besuchern solcher Ressourcen zu stehlen.

Bild
Beispiel für Daten, die ein Skimmer an Kriminelle weitergegeben hat

Unter den Opfern der Aktionen von Magecart befinden sich Hunderte von Online-Shops, darunter bekannte Marken.

Im Verlauf der Studie haben wir festgestellt, dass trotz der zahlreichen Veröffentlichungen und Empfehlungen zur sicheren Konfiguration von AWS-Diensten mindestens fünf der gefährdeten Online-Shops weiterhin die für die Aufzeichnung verfügbaren S3-Stores verwenden. Bisher enthalten ihre Websites keine Skimmer, sie können jedoch jederzeit hinzugefügt werden, da Cyberkriminelle über praktische Tools verfügen, die die Suche nach gefährdeten Ressourcen erleichtern.

S3 Öffnen Sie die Speichersuchwerkzeuge


Mit den Tools Slurp, Bucket Stream und s3scanner finden Sie lesbaren und beschreibbaren Speicher.

Mit Slurp können Sie mögliche Speichernamen für eine bestimmte Domain finden und die Schreibberechtigungen darin überprüfen:

Bild
Beispiel für die Slurp-Ausgabe. Der Zugriff über http ist geschlossen.

Um die Verfügbarkeit des gefundenen Speichers über die AWS-CLI zu überprüfen, können Sie den Befehl get-bucket-acl verwenden: Der

Bild
Zugriff auf die Ressource über die AWS-API wird ebenfalls geschlossen.

Das in Python geschriebene Dienstprogramm s3scanner verwendet eine einfache Heuristik, um mögliche Speichernamen zu finden und den Zugriff darauf zu überprüfen.

Bild
Suchen und Überprüfen der Verfügbarkeit von S3-Speicher mit s3scanner

Das Dienstprogramm Bucket Stream sucht nach potenziell anfälligen S3-Speichern in öffentlichen Quellen, z. B. in Zertifikatstransparenz und anderen Magazinen.

Das Dienstprogramm AWSBucketDump listet die Repository-Dateien auf, deren Namen bestimmte Schlüsselwörter enthalten:

Bild
Ergebnis des Dienstprogramms AWSBucketDump

Mit diesen Dienstprogrammen haben wir von Dezember 2018 bis Januar 2019 mehr als 5200 eindeutige S3-Speicher gefunden. Etwa 4.400 davon waren für Standard-AWS-Befehlszeilenprogramme verfügbar. Nur 79 von ihnen standen zum Lesen und 40 zum Schreiben zur Verfügung. Um auf einen Teil von ihnen zugreifen zu können, mussten lediglich die erforderlichen Rechte zugewiesen werden.

Wie Konten lecken


Zugriffsrechte auf Ressourcen bereiten Entwicklern Kopfschmerzen. Und bei Cloud-Fonds wird das Problem noch akuter. Prozesse müssen authentifiziert werden, um Zugriff auf Ressourcen zu erhalten. Andernfalls besteht die Gefahr von Datendiebstahl oder Kompromissen. Die ganze Frage ist, wie dies getan werden kann, ohne die Daten beim Veröffentlichen des Codes im Repository zu gefährden, wie es der Autor des folgenden auf Pastebin veröffentlichten

Bild
Fragments
getan hat: Ein Fragment des auf Pastebin veröffentlichten Codes mit gültiger AWS-API-ID und Schlüssel
Mit diesen Daten kann der Angreifer alle Rechte erlangen die vom Konto dieser Anwendung bereitgestellt werden.

Eine weitere Ursache für Anmeldeinformationen sind die Kubernetes API-Client-Zertifikate. Einerseits erfordert dieses Container-Orchestrierungssystem in der Standardkonfiguration einen obligatorischen Schutz in Form eines Client-Zertifikats. Auf der anderen Seite veröffentlichen Entwickler mit überraschender Naivität Zertifikate zusammen mit Code auf GitHub, Pastebin und anderen Diensten.

Nur bei Pastebin konnten wir ungefähr fünfzig verschiedene Client-Zertifikate finden, die mit Konfigurationsskripten platziert wurden.

Wenn es eine schlechte Idee ist, Zertifikate irgendwo im Klartext zu veröffentlichen, ist es einfach ekelhaft, sie auf GitHub zu veröffentlichen, weil:

  • Um ein Zertifikat zu löschen, müssen Sie es aus allen gespeicherten Versionen im Repository löschen.
  • - , , ;
  • , , , .

Kompromittierte API-Schlüssel und -Zertifikate können zu ernsthaften finanziellen Schäden führen, beispielsweise wenn ein russisches Unternehmen Amazon 12.000 US-Dollar für einen Tag schuldete : Es hat eine Website auf Bitrix gehackt, die unter anderem einen API-Schlüssel für den Zugriff auf den S3-Speicher anzeigte.

Bild
Screenshot aus dem Abrechnungsfeld eines russischen Unternehmens, dessen gestohlener API-Schlüssel zum Erstellen vieler virtueller Maschinen und zum Cryptocurrency Mining verwendet wurde. Quelle: habr.com/de/post/357764

Der Verlust von Kundendaten kann nicht weniger schmerzhaft werden, wie bei Imperva im Jahr 2019 . Imperva hat auch den API-Schlüssel gestohlen und alle Client-Daten zusammengeführt.

Die gestohlenen Konten können von Cyberkriminellen verwendet werden, um illegal dedizierte AWS-Server zu handeln, die von den tatsächlichen Eigentümern bezahlt werden müssen. Im Lolzteam-Forum haben wir mehr als 250 Anzeigen gefunden, die "pure zero Dedicos" anbieten.

Bild
Ankündigung im Forum lolzteam. Wer wird Amazon am Ende bezahlen?

Eine dritte Ursache für API-Schlüssellecks sind verschiedene Schulungskurse für Programmierer.

Die Autoren versuchen, Anfängern den Prozess der Verbindung zu AWS-Diensten so einfach wie möglich zu erklären, und wiederholen schlechte Praktiken, die in Zukunft zu neuen und neuen Kompromissfällen führen.

Bild
Ein Ausschnitt aus einem Python-Kurs, in dem erklärt wird, wie Sie mit Amazon S3-Diensten arbeiten. Es werden Schlüssel zum Hardcode in das Programm angeboten

Die Autoren des Kurses über die progressive und sichere Java-Sprache zeigen eine so nachlässige Haltung gegenüber der Sicherheit von API-Schlüsseln: Die

Bild
Sprache ist unterschiedlich, aber der Rat ist der gleiche - die Schlüssel stimmen mit dem Programmtext überein.

Unsere Empfehlungen


Eine falsche Konfiguration von Cloud-Diensten birgt viele Risiken, die sich aus der illegalen Verwendung geleaster Computerressourcen für das Cryptocurrency Mining, dem Datendiebstahl und der Einführung von Online-Skimmern ergeben. In diesem Zusammenhang empfehlen wir dem Sicherheitspersonal, Cloud-Bereitstellungsszenarien zu analysieren, um potenzielle Schwachstellen zu identifizieren, bevor der Prozess abgeschlossen ist. Cloud-Validierungsskripte wie AWS CloudFormation bieten Einblicke in die Funktionsweise der resultierenden Infrastruktur, wo nach falschen oder fehlenden Sicherheitseinstellungen oder Protokollen gesucht werden kann. Unter den von Trend Micro entwickelten Sicherheitstools befindet sich ein Produkt zum Schutz von Cloud-Umgebungen - Deep Security für Amazon EC2-Instanzen.Das Cloud-Konformitätstool ermöglicht der Cloud-Umgebung des Unternehmens unsichere Einstellungen.

Für Programmierer, die AWS-API-Schlüssel für die Interaktion mit S3-Repositorys verwenden, empfehlen wir die Umstellung auf AWS Secrets Manager, Docker Secrets, Blackbox, Git-Secrets und andere ähnliche Tools, mit denen verhindert werden kann, dass die zusammen mit dem Original gespeicherten Anmeldeinformationen kompromittiert und böswillig verwendet werden Bewerbungstexte.

More articles:


All Articles