Nachdem ich mir in Teil 2 unserer AWS-Hacking-Serie Jenkins angesehen habe, wende ich mich nun Kubernetes zu.
Ich freue mich darauf, mich mit diesem Thema zu befassen, denn es ist ein heißes Eisen, mit dem so viele Unternehmen in Verbindung mit ihren AWS-Konten zu arbeiten beginnen!
In dieser Folge gebe ich Ihnen also einen Überblick über die potenziellen Schwachstellen von Kubernetes und zeige Ihnen, wie ich bei meiner letzten Recherche reale AWS-Zugangsdaten aufgedeckt habe.
Moment mal Dawg - Was ist Kubernetes nochmal?
Das Wichtigste zuerst: ein kurzer Überblick darüber, was Kubernetes ist und wie Sie es normalerweise in Verbindung mit AWS-Konten verwenden. Wenn Sie diesen Teil kennen, können Sie gleich zum nächsten Kapitel übergehen.
Kubernetes (k8s) ist eine Anwendung, die die Bereitstellung, Skalierung und Verwaltung von containerisierten Anwendungen automatisieren kann. Ein Container ist eine Reihe von Prozessen, die vom Rest des Systems isoliert sind. Während die Bereitstellung keine Raketenwissenschaft ist, kann der Betrieb und die Skalierbarkeit ziemlich kompliziert sein!
Hier kommen Orchestrierungstools wie Kubernetes ins Spiel - sie helfen Ihnen dabei, Ihre Container im Zusammenspiel mit Microservices und Cloud-Anbietern zu nutzen. Bei AWS zum Beispiel verwenden wir häufig EKS (Elastic Kubernetes Service) für unsere komplexen Microservice-Architekturen.
Wussten Sie das? Kubernetes (/koo-ber-nay'-tace/) kommt aus dem Griechischen und bedeutet "Segelmeister".
Jetzt, da die Klartext-Definition aus dem Weg geräumt ist und wir alle auf derselben Seite stehen, setze ich meinen weißen Hut auf und schaue mir an, wo die gemeinsamen Schwachpunkte dieser Sache liegen.
Am Anfang war die Konfiguration
Verwaltete Kubernetes wie EKS verfügen in der Regel über APIs, die mit gegenseitigem TLS, IAM-Rollen und RBAC (Role-based Access Control) auf API-Ebene gesichert sind. Dies ist im Allgemeinen eine ziemlich sichere Einrichtung.
Aber wenn Entwickler Kubernetes konfigurieren, kann es passieren, dass diese Sicherheitseinstellungen zugunsten einer weniger komplizierten Einrichtung außer Kraft gesetzt werden. Das Ergebnis ist, dass die API offengelegt wird.
Die Arbeit mit öffentlichen Cloud-Anbietern bedeutet nicht, dass Sie öffentliche APIs haben sollten. Und doch ist dies eines der häufigsten Probleme, wenn es um Kubernetes geht.
Diese k8s-APIs geben jedem, der Zugang hat, die Möglichkeit, verschiedene Teile der Umgebungskonfiguration einzusehen.
Aller guten (und potenziell verletzlichen) Dinge sind drei
Eine Kubernetes-API ist der Spiegel, durch den wir eine Fülle von Informationen entdecken können, von denen einige für einen Hacker von Interesse sein könnten. Im Folgenden finden Sie drei Möglichkeiten, um an das saftige Fleisch zu gelangen.
1. /api/v1/geheimnisse
Sensible Informationen, wie Kennwörter und Schlüssel, werden in der treffend benannten Secrets gespeichert.
Diese sind mit base64 kodiert, was nicht wirklich etwas mit Sicherheit zu tun hat, sondern eher dazu dient, das Escaping von Zeichen in Anfragen/Yaml-Dateien zu vermeiden.
$ echo ZXhhbXBsZQo= | base64 -d
Wenn sie richtig eingerichtet sind, werden sie mit AES verschlüsselt. Die Verschlüsselung wird jedoch transparent von der API gehandhabt. Wenn Sie also über die entsprechenden Berechtigungen in RBAC verfügen, können Sie die Geheimnisse entschlüsseln und lesen.
Sie könnten hier zum Beispiel GIT-Repository- oder Datenbank-Anmeldeinformationen, .dockerconfig-Dateien und AWS-Zugangsschlüssel gespeichert finden. Das sollte nicht möglich sein, aber ich habe es bei meinen Recherchen gesehen.
2. /api/v1/configmaps
ConfigMaps ist im Grunde der Inhalt verschiedener Konfigurationsdateien, die in Ihrer Anwendung verwendet werden - anstatt sie in Ihrem Repository aufzubewahren.
Die Teile der "Anmerkungen" können Ihnen Zugang zu E-Mail-Adressen und Projektnamen verschaffen, während die "Inhalte der Konfigurationsdatei" sogar Geheimnisse im Klartext enthalten können!
3. /api/v1/pods
Über "arguments" und den Einstiegspunkt "command" erhalten Sie Zugriff auf Klartextgeheimnisse.
Über die Theorie zu lesen kann Spaß machen und gut sein, aber sie hält einem soliden Beispiel aus dem wirklichen Leben nicht stand.
Showtime!
Wie ich ganz einfach auf das AWS-Konto eines riesigen multinationalen Unternehmens zugreifen konnte
Ich werde Sie Schritt für Schritt durch meine letzte Recherche führen - von der Art und Weise, wie ich ein "Opfer" gefunden habe, über die Aufdeckung seiner AWS-Zugangsdaten durch /api/v1/secrets bis hin zur Suche nach der Kontakt-E-Mail der Person, die für das AWS-Konto verantwortlich ist.
Alle tatsächlichen Verweise auf den Kontoinhaber werden zu seinem eigenen Schutz anonymisiert.
1. Die Suche nach dem Opfer
In meinem ersten Blog-Beitrag über das Hacken von AWS-Konten über Atlassian Apps habe ich eines der Tools erwähnt, das mir hilft, exponierte Daten zu finden: Binaryedge.io. Es scannt das gesamte öffentliche Internet, um Schwachstellen aufzudecken und Ihnen zu helfen, sie zu sichern.
Als ersten Schritt schalte ich also das VPN ein und suche einfach nach einem ungesicherten Rechner.
Mein Blick fällt auf einige AWS EC2, die in den USA betrieben werden, also gehe ich in diese Liste und wähle einfach einen zufällig aus.
2. Geheimnisse aufdecken
Der einfachste Weg kann der effektivste sein, also beginne ich mit diesem. Ich gehe einfach zu:
/api/v1/secrets
Jetzt kann ich die gesamten Konfigurationsdetails von Kubernetes sehen - und das nach nur ein paar Klicks. Es gibt keine Zaubertricks!
Ich sehe ein paar Jetons, Zertifikate... und plötzlich habe ich den Jackpot geknackt!
Die Anmeldedaten sind da und warten nur darauf, base64-dekodiert zu werden. Und siehe da! Ich bin jetzt im Besitz der aws_access_key_id und des aws_secret_access_key.
3. Streikendes Gold
Und jetzt beginnt der lukrative Teil. Ich öffne mein Terminal und konfiguriere ein neues AWS-Profil mit den Zugangsschlüsseln.
Dann lasse ich mein Skript laufen, um die Zugriffsebene des Kontos zu überprüfen, indem ich nach IAM-Benutzern, S3-Buckets, den Kosten des letzten Monats usw. frage.
Nach ein paar Sekunden Wartezeit bin ich drin - und kann alle Details zum AWS-Konto sehen, einschließlich der Anzahl der Benutzer, der damit verbundenen Kosten, der S3-Buckets und der E-Mail an die AWS-Organisation des Hauptkontos!
In der Kontoübersicht sehe ich, dass es 11 Benutzer, 57 Richtlinien und 91 Rollen hat, also nicht riesig, aber auch nicht klein ist. Und hier sind die Gesamtkosten für diese Infrastruktur für den letzten Monat.
4. Den Eigentümer finden
Jetzt, da ich all diese Informationen habe, möchte ich den Eigentümer ausfindig machen, um ihn über die Aufdeckung zu informieren.
Ich habe bereits das Master-E-Mail-Konto der AWS-Organisation (das einige verräterische Informationen im Domänennamen enthält), aber ich möchte sicherheitshalber noch ein weiteres Konto einrichten.
Mithilfe desselben AWS-Profils kann ich eine Stamm-E-Mail aus einem aktuellen AWS-Supportfall extrahieren - falls es einen solchen gibt. Die E-Mail-Domäne des Kontobesitzers war die gleiche wie die zuvor gefundene, also weiß ich, dass ich den Besitzer habe.
Freies Haus
Wie Sie anhand des obigen Beispiels sehen können, kann es sehr einfach sein, über Kubernetes in ein AWS-Konto zu gelangen. Aber es sollte nie so einfach sein.
Das gefährdete Konto gehörte zu einem großen multinationalen Unternehmen. Nachdem ich mich mit den Informationen an sie gewandt hatte, konnten sie innerhalb weniger Stunden alles in Ordnung bringen.
Das hätte von Anfang an vermieden werden können. Sehen wir in unserer Schlussfolgerung, wie.
Die üblichen Verdächtigen
Wie so oft bei dieser Art von Schwachstellen, können sie durch die Implementierung solider Sicherheitsmaßnahmen vermieden werden.
Hier sind drei Empfehlungen, wie Sie Ihr Kubernetes sichern können.
- Sichern Sie Ihre k8s API Deaktivieren Sie nicht die Standardeinstellungen, die RBAC und mTLS enthalten. Wenn Sie dies aus irgendeinem Grund tun müssen, beschränken Sie zumindest eingehende Verbindungen auf die IPs Ihres Büros.
- Verwenden Sie IAM-Rollen anstelle von Zugriffsschlüsseln Sie müssen für Ihre Anwendung, die auf EKS läuft, keinen Zugriffsschlüssel erstellen. Verwenden Sie Rollen für Ihre Dienstkonten, die von Ihren Pods verwendet werden.
- Beschränken Sie die Privilegien Ihrer Anwendung Wenn Ihre Anwendung mit S3 kommunizieren muss, können Sie sie auf einen einzigen Bucket beschränken. Es braucht wirklich keine admin-ähnliche Richtlinie, um zu funktionieren! Dies gilt auch für k8s RBAC. Es ist ein häufiger Fehler, Benutzern und Dienstkonten Cluster-Admin-Rollen zuzuweisen.
Bonustipp: Ein weiteres häufiges Problem ist, dass die Rechte zur Ausführung in Containern und/oder zum Debuggen von Containern zu offen sind. In Kombination mit einer fehlenden seccomp/Apparmor-Einrichtung (die standardmäßig nicht aktiviert sind) ist es dadurch möglich, aus dem Container auszubrechen und auf den Host und andere Container-Ressourcen zuzugreifen.
Cybersicherheit wird auf der Bühne des Geschäftslebens im digitalen Zeitalter immer eine wichtige Rolle spielen. Nehmen Sie das Thema nicht auf die leichte Schulter und machen Sie keine Fehler, die sich vermeiden lassen.
Wenn Sie unsicher sind, wie Sie Ihr Kubernetes konfigurieren sollen, fragen Sie Ihre Sicherheitsexperten - und hören Sie auf sie. In diesem Sinne möchte ich Sie mit einem großartigen Zitat der amerikanischen Schriftstellerin Joanna Ruocco verabschieden:
"Ohne die Meinung eines Experten gibt es keine Gewissheit. "
Mehr aus dieser Serie über das Hacken eines AWS-Kontos
Unsere Ideen
Weitere Blogs
Contact