Penetration Testing in die Cloud skalieren mit Axiom

Beim Thema Penetration Testing und Cloud können Pentester*innen meistens Frust-Geschichten von Rate Limiting, IP bans und ähnlichen Unannehmlichkeiten erzählen. Will man keinen Bann bei AWS, Azure und Co. riskieren, so muss die Rate an Requests, die automatisierte Tools gerne mal ausspucken, deutlich reduziert werden.

Problematisch ist dabei allerdings, dass es besonders bei größeren Web-Applikationen dann sehr, sehr lange dauern kann, bis man als Pentester*in erste Ergebnisse sieht – auf Basis derer man sich dann weiter durch die Anwendung analysiert.

Besonders unangenehm sind natürlich hier – zumindest für Pentester*innen und Cyber-Kriminelle – die automatisierten und hinreichend aggressiven Antworten der großen Cloud-Provider auf etwaige Angriffe.

Für die Lösung dieser Problematik – und noch weitere Benefits wie Hardware- und Ortsunabhängigkeit, (a)synchrones Zusammenarbeiten – gibt es gute Ansätze:

Zum einen gibt es die Möglichkeit, Pentest-Infrastruktur direkt in der Cloud aufzusetzen. Einerseits das Rotieren von IPs, andererseits horizontales Skalieren, um so die anfallende Workload auf mehrere Maschinen und vor allem IP-Adressen zu verteilen.

Zum anderen gibt es diverse Linux-Bordmittel, mit denen das wackelige Neuland-Netz hinreichend resilient genutzt werden kann. tmux, screen und rsync sind hier die zentralen Bausteine.

Doch wie baut man sich diese Infrastruktur am besten, schnellsten und effektivsten auf? Setzt man auf Infrastructure-as-Code-(IaC-)Tools wie Terraform, Ansible oder Cloud Formation?

Setzt man auf VM Templates in der Cloud, um möglichst einfach mehrere identische Maschinen zu spawnen?

Und realisiert man rotierende IP-Adressen vielleicht einfach über extra VMs als SOCKS Proxy?

Alternativ zu diesen aus der Cloud-Native-Software-Entwicklung bekannten Tools ist Axiom (GitHub ). Ein Framework aus bash-Skripten, um durch das API von Digital Ocean (initial, voll unterstützt), IBM Cloud und Linode (beide recht neu) dynamisch Infrastruktur on demand zu starten und zu nutzen.

Sehen wir uns axiom doch einmal zusammen an!

Setup

First things first – was muss installiert werden bzw. vorhanden sein, um mit axiom loslegen zu können?

Der Einfachheit halber orientieren wir uns dazu an der offiziellen Installationsanleitung . Diese fordert folgende installierten Tools:
– git
– curl
– ruby
– jq
– packer
– doctl (zur Steuerung von Digital Ocean via API) → [https://github.com/digitalocean/doctl](https://github.com/digitalocean/doctl)
– Interlace ([https://github.com/codingo/Interlace](https://github.com/codingo/Interlace))
– rsync
– lsb_release
– fzf

Zusätzlich wird noch ein API Key für Digital Ocean benötigt, sowie ein SSH-Schlüsselpaar zur Verbindung zu den Maschinen. Sobald alle Anforderungen erfüllt sind, kann axiom installiert werden. Die einfachste Variante ist der allseits beliebte curl-bash: bash <(curl -s https://raw.githubusercontent.com/pry0cc/axiom/master/interact/axiom-configure)

Natürlich sollte man das erst tun, nachdem man sich das Skript angesehen hat und versteht, was passiert.

Alternativ können wir das Projekt auch einfach in ~/.axiom/ klonen und dann axiom-configure ausführen. Egal wie – am Ende führt das Skript die Nutzer*innen sehr angenehm durch den Installations-Prozess. Quality-of-Life-Features wie die Golang-Installation inklusive Setzen der benötigten Umgebungsvariablen sind dabei natürlich besonders angenehm!

Wenn sämtliche Abhängigkeiten erfolgreich installiert worden sind, folgt als nächstes die Einrichtung eines Digital-Ocean-Accounts für axiom.

Alles, was dazu nötig ist, ist ein API-Token – dieses kann im Digital-Ocean-Web-Interface (in den Account Settings unter Tokens/Keys) neu angelegt werden.

Der Rest des Skripts läuft dann ohne weitere Nutzerinteraktion durch. Das Endergebnis sollte dann ungefähr folgendermaßen aussehen:

Der erste Schritt zum verteilten Penetration Testing mit Axiom ist geschafft – wie geht’s jetzt weiter?

Erste Schritte mit Axiom

Bevor wir anfangen können, müssen wir eine neue Axiom-Instanz erzeugen. Das passiert ganz einfach via axiom-init . Nach einer kurzen Wartezeit ist die erste Instanz gestartet und wir können tiefer eintauchen.

Von dieser frisch gestarteten Instanz aus können wir nun – ohne einen weiteren manuellen Schritt – auf diverse Tools wie amass, assetfinder, dnsx, ffuf, gobuster, etc. zugreifen und haben des Weiteren bereits Zugriff auf einige installierte Wortlisten, beispielsweise das gesamte SecLists-Projekt .

Ansonsten können wir mit dieser Maschine quasi genau so arbeiten wie mit jeder anderen Kali Linux, Blackarch Linux oder Parrot OS.

Aber was passiert mit den ggf. extrahierten Daten sowie den Log- und Ergebnissfiles? Die sind ja nun auf dieser Cloud-Maschine.

Hier gibt es auch ein tolles Feature – axiom-scp – um Dateien von und zu der Cloud-Kiste zu verschieben! Die Benutzung ist quasi deckungsgleich mit dem regulären scp. Das geht dann auch dementsprechend flott von der Hand.

Bisher war alles recht bekannt und einfach – alles wie gewohnt, alles von einem Rechner aus. Das soll sich im nächsten Schritt ändern.

Höher, schneller, breiter – axiom-fleet

Mit axiom-fleet beginnen wir, ein großes Stück der Power von axiom zu nutzen: das verteilte bzw. skalierte Arbeiten. Mit axiom-fleet können wir mehrere Instanzen gleichzeitig auf-, abbauen und orchestrieren.

Um eine Flotte identischer Rechner zu spawnen, benötigen wir lediglich folgendes Kommando:

axiom-fleet acidburn -i=5

*acidburn* ist hier der Name unserer Flotte, mit dem Parameter =i=5 geben wir die Anzahl der Instanzen an. Fünf Instanzen haben sich bisher immer als recht passabler Kompromiss zwischen Preis und Leistung herausgestellt.

Nach ungefähr fünf Minuten stehen unsere fünf acid burns dann bereit.

Jetzt noch alle selektieren mit axiom-select "acidburn*" und wir können auf allen fünf Rechnern gleichzeitig arbeiten – zum Beispiel via axiom-exec.

Mit axiom-exec lassen sich Shell-Kommandos auf der ausgewählten Maschine ausführen – oder eben auf allen ausgewählten.

Skaliert scannen

Das ist an sich auch ganz nett – allerdings stellt sich dann noch die Frage, wie man eine Workload z. B. zum Directory Brute Force (gobuster), Screenshots (gowitness) oder Scanning auf XSS (dalfox) jetzt am besten auf die ganzen verschiedenen Instanzen aufteilt. Auch Crawling durch Webseiten, z. B. mit hakrawler oder Fuzzing via ffuf, würde von einer verteilten Workload profitieren. Man will ja nicht die fünf selben Requests auf eine Seite schießen, sondern das möglichst effektiv parallelisieren.

Die Lösung dafür ist axiom-scan. Hier werden unter anderem die bereits genannten Tools sowie viele weitere bereits implementiert. Dieses Modul verteilt die Input-Datei dann auf die aktiven Instanzen und parallelisiert so die Workloads.

Auch die Problematik, dass die Ergebnisse am Ende wieder zusammengeführt werden müssen, wird hier bereits erledigt. Keine doppelten Treffer und dadurch unnötig lange Listen.

Angenehmer Nebeneffekt des Ganzen ist natürlich, dass die einzelnen Requests nicht von der Angreifer-Maschine ausgehen, sondern von n Instanzen verteilt auf das Ziel eingehen.

Solltet ihr ein Lieblingstool haben oder sonst irgend eines vermissen, ist es auch recht intuitiv, wie axiom-scan funktioniert und anhand der bereits vorhandenen Module kann man schnell neue Module erstellen und nutzen.

Sonstige Features

Neben diesen Kern-Features gibt es noch einige weitere Features, die die Arbeit mit axiom sehr angenehm machen. Das können Kleinigkeiten sein, wie eine fertige golang-Umgebung mit gesetzen Umgebungsvariablen – oder dass das großartige SecLists Repository bereits ausgecheckt ist und Word Lists für alle möglichen Verwendungszwecke mitbringt.

Penetration Testing mit Axiom: Beispiel-Workflow

Nach all der Theorie und der Vorschusslorbeeren wollen wir uns jetzt noch einmal einen Beispiel-Workflow ansehen und durchdenken, wie Axiom während eines Penetrations-Tests eingesetzt werden kann.

Recon

Während der Recon-Phase des Engagements ist es unser Ziel, möglichst viel über unser Target herauszufinden.

Gehen wir von einer Web-App aus, die unter acme.com erreichbar ist. Nun gilt es, sich einen Überblick zu verschaffen, welche aktiven Subdomains wir erreichen können und natürlich auch generell den Aufbau der Webseite zu untersuchen.

Hierfür starten wir mit amass und suchen nach DNS-Einträgen für acme.com. Je nachdem bekommt man es hier schnell mit einer großen Menge an unterschiedlichen Subdomains zu tun.

Die Validität und Erreichbarkeit der einzelnen Subdomains (für http-Requests) prüfen wir nun mit httprobe, was uns eine Liste an erreichbaren Webseiten liefert.

Ab hier könnten wir uns natürlich von Hand durchklicken – oder wir nutzen axiom-scan mit dem hakrawler um den Aufbau der einzelnen Webseiten zu extrahieren.

So bekommen wir Stück für Stück mehr und mehr Informationen über unser Angriffsziel. Und dank der möglichen Parallelisierung geht das Ganze auch noch deutlich schneller als mit einer einzigen Maschine!

Exploit

Wenn wir einen möglichen Angriffsvektor gefunden haben, können wir allerdings trotzdem unsere voll eingerichtete Maschine nutzen – um unsere IP dabei vor dem Bannhammer zu schützen, starten wir eine neue axiom-Instanz und nutzen diese als axiom-vpn, um im Fall der Fälle ganz einfach eine neue IP bekommen zu können.

Alternativ kann die Instanz auch einfach via axiom-ssh genutzt werden und der Angriff startet direkt von dort aus.

Besonders charmant ist hier natürlich vor allem, dass der Auf- und Abbau neuer Instanzen relativ einfach und schnell geht. Neue Instanzen zu starten dauert ca. 5 Minuten. Automatisierung ist eben nicht nur in der Softwareentwicklung eine großartige Sache! Auch wir Angreifer können hier profitieren und die langweiligen Sachen einfach weg-automatisieren. Die gesparte Zeit stecken wir lieber in die Validierung oder Entwicklung von Exploits!

Fazit

Alles in allem ist axiom ein sehr cooles Projekt, mit dem man mit wenig Overhead eine schnelle Einarbeitung hat – wenn man bereits eine solide Basis im Umgang mit Linux-Kommandozeilen-Tools hat.

Sollte man noch keine dynamische Infrastruktur zur Verfügung haben, um Pentests skalieren zu können und/oder schnell VPN Server zu deployen, ist das eine super Alternative zu terraform, ansible und Co. Auch, wenn man mit diesen IaC-Tools natürlich deutlich mehr Möglichkeiten hat – der Fokus auf Penetration Testing fehlt ihnen.