Penetration Testing in die Cloud skalieren mit axiom

01 Jul 2020 - mrtn

Dieser Artikel wurde als erstes auf dem codecentric blog veroeffentlicht.

Beim Thema Penetration Testing und Cloud koennen Pentester*innen meistens frustrierte Geschichten von Rate Limiting, IP bans und aehnlichen unannehmlichkeiten erzaehlen. Will man keinen Bann bei AWS, Azure und Co riskieren, so muss die Rate an Requests den automatisierte Tools gerne mal ausspucken deutlich reduziert werden.

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

Besonders unangenehm sind natuerlich hier - zumindest fuer Pentester und Cyber-kriminelle, die automatisierten und hinreichend aggressiven Antworten der grossen Cloud Provider auf etwaige Angriffe.

Fuer die Loesung dieser Problematik - und noch weitere Benefits wie Hardware- und Ortsunabhaengigkeit, (a)synchrones Zusammenarbeiten - gibt es gute Ansaetze.

Zum einen gibt es die moeglichkeit, Pentest-Infrastruktur direkt in der Cloud aufzusetzen. Schnelles rotieren von IPs, Horizontal skalieren und so die anfallende Workload auf mehrere Maschinen und vor allem IP Addressen zu verteilen.

Ausserdem: Gibt es diverse Linux-Bordmittel, mit denen das wackelige Neuland-Netz hinreichend resilient genutzt werden kann. Zum Beispiel tmux, screen und rsync, um konkret zu werden.

Doch wie baut man sich diese Infrastruktur am besten, schnellsten und effektivsten auf? Setzt man auf IaC (link zu iac blogpost) Tools wie Terraform, Ansible oder Cloud Formation (oder deren Pendants anderer Cloud Provider)?

Setzt man auf VM Templates in der Cloud um moeglichst einfach mehrere identische Maschinen zu spawnen?

Und realisiert man rotierende IP Adressen vielleicht einfach ueber extra VMs als SOCKS Proxy?

Alternativ zu diesen aus der Cloud Native Software Entwicklung bekannten Tools ist axiom (link). Ein Framework aus bash-skripten um durch die API von digital-ocean (initial, voll supported), 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 koennen.

Der einfachheit halber orientieren wir uns dazu an der offiziellen Installationsanleitung (https://github.com/pry0cc/axiom/wiki/0-Installation)

Diese fordert folgende Installierten Tools:

git
curl
ruby
jq
packer
doctl (Zur Steuerung von Digital Ocean via API) → https://github.com/digitalocean/doctl
Interlace (https://github.com/codingo/Interlace)
rsync
lsb_release
fzf

Zusaetzlich wird noch ein API Key fuer Digital Ocean benoetigt und ein SSH Schluesselpaar zur Verbindung zu den Maschinen.

Sobald alle Anforderungen erfuellt 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)

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

Alternativ koennen wir das Projekt auch einfach in ~/.axiom/ clonen und dann axiom-configure ausfuehren.

Das Skript fuehrt insgesamt sehr angenehm durch den Installations-Prozess. Quality of Life Features wie die golang Installation sind dabei natuerlich besonders angenehm!

Wenn saemtliche Abhaengigkeiten erfolgreich installiert worden sind, folgt als naechstes die Einrichtung eines digital ocean accounts fuer Axiom.

Alles was dazu noetig ist, ist ein API token - der kann im digitalocean Interface in den Account Settings unter Tokens/Keys ein neuer angelegt werden.

Wenn das alles funktioniert wie gedacht, sollte euer Terminal irgendwann so aussehen:

Der erste Schritt zum verteilten Pentesten ist geschafft - wie geht’s jetzt weiter?

Erste Schritte

Bevor wir Anfangen koennen, muessen wir als erstes eine neue Axiom-Instanz erzeugen. Das passiert ganz einfach via axiom-init <instanzname>. Nach einigen Sekunden warten, ist die erste Instanz gestartet und wir koennen tiefer eintauchen.

Von dieser Instanz aus, koennen wir - ohne einen weiteren manuellen Schritt auf diverse Tools wie amass, assetfinder, dnsx, ffuf, gobuster, etc zugreifen - und haben bereits Zugriff auf einige gute Word-lists, beispielsweise das gesamte SecLists Projekt (github.com/DanielMiessler/SecLists).

Ansonsten koennen wir mit dieser Maschine quasi genau so arbeiten, wie mit jeder anderen Pentest-VM.

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 regulaerem scp. Geht flott von der Hand.

Bisher war alles recht bekannt und einfach - alles wie gewohnt, alles von einem Rechner aus. Das soll sich im naechsten Schritt aendern.

Hoeher, schneller, breiter - axiom-fleet

Mit axiom-fleet beginnen wir, uns ein grosses Stueck der Power von axiom zu bedienen. Dem verteilten bzw. skalierten Arbeiten. Mit axiom-fleet koennen wir mehrere Instanzen gleichzeitig auf- und abbauen und orchestrieren.

Um eine Flotte gleicher Rechner zu spawnen, funktioniert mit folgendem 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. Je nach Zweck bietet sich hier an. Fuenf Instanzen haben sich bisher immer als recht passabler Kompromiss zwischen Preis und Leistung herausgestellt.

Nach ungefaehr fuenf Minuten stehen unserer 5 acid burns dann bereit.

Jetzt noch alle selektieren mit axiom-select "acidburn*" und wir koennen auf allen 5 Rechnern gleichzeitig arbeiten - zum Beispiel via axiom-exec.

Mit axiom-exec lassen sich shell Kommandos auf der ausgewaehlten Maschine ausfuehren - oder eben auf allen ausgewaehlten.

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 wuerde ja von einer verteilten Workload profitieren. Man will ja nicht 5x dieselben Requests auf eine Seite schiessen, sondern das moeglichst effektiv parallelisieren.

Die Loesung dafuer 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, das die Ergebnisse am Ende wieder zusammengefuehrt werden muessen, wird hier bereits erledigt. Keine doppelten Treffer und dadurch unnoetig lange Listen.

Angenehmer Nebeneffekt des ganzen ist natuerlich, dass die einzelnen Requests nicht von der Angreiffer-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 & nutzen.

Sonstige Features

Neben diesen Kern-Features gibt es noch einige weitere Features, die die Arbeit mit axiom sehr angenehm machen. Das koennen Kleinigkeiten sein wie eine fertige golang Umgebung mit gesetzen Umgebungsvariablen - oder dass das grossartige SecLists Reporitory bereits ausgecheckt ist und wordlists fuer alle moeglichen Verwendungszwecke mitbringt.

Beispielworkflow

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

Recon

Waehrend der Recon Phase des Engagements ist es unser Ziel, moeglichst viel ueber unser Target herauszufinden.

Gehen wir von einer Web-App aus, die unter [acme.com](http://acme.com) erreichbar ist. Nun gilt es, sich einen Ueberblick zu verschaffen, welche aktiven Subdomains wir erreichen koennen und natuerlich auch generell den Aufbau der Webseite.

Hierfuer starten wir mit amass und suchen nach DNS eintraegen fuer acme.com. Je nach dem bekommt man es hier schnell mit einer grossen Menge an unterschiedlichen Subdomains zu tun.

Die Validitaet und Erreichbarkeit der einzelnen Subdomains (fuer http-Requests) pruefen wir nun mit httprobe, was uns eine Liste an erreichbaren Webseiten liefert.

Ab hier koennten wir uns natuerlich von Hand durchklicken - oder wir nutzen axiom-scan mit dem hakrawler um den Aufbau der einzelnen Webseiten zu extrahieren.

So bekommen wir Stueck fuer Stuck mehr und mehr Informationen ueber unser Angriffsziel. Und dank der moeglichen Parallelisierung geht das ganze auch noch deutlich schneller wie mit einer einzigen Maschine!

Exploit

Wenn wir einen moeglichen Angriffsvektor gefunden haben, koennen wir allerdings trotzdem unsere voll eingerichtet Maschine nutzen - um unsere IP dabei vor dem Bannhammer zu schuetzen, starten wir eine neue axiom Instanz und nutzen diese als axiom-vpn, um im Fall der Faelle ganz einfach eine neue IP bekommen zu koennen.

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

Besonders Charmant ist hier natuerlich vor allem, dass 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 Software Entwicklung eine grossartige Sache! Auch wir Angreifer koennen 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 und einer schnellen Einarbeitung - wenn man bereits eine solide Basis im Umgang mit Linux Kommandozeilen-Tools hat.

Sollte man noch keine dynamische Infrastruktur zur Verfuegung haben, um Pentests skalieren zu koennen, schnell VPN Server zu deployen, ist das eine super Alternative zu terraform, ansible und co - auch wenn man mit diesen IaC Tools natuerlich deutlich mehr Moeglichkeiten hat - der Fokus auf Penetration Testing fehlt ihnen.