Schwachstellen mit Google Tsunami entdecken
Bevor die Welle bricht
Veröffentlicht in Ausgabe 10/2022 - SCHWERPUNKT
Eines der größten Probleme des Administrators besteht zweifelsohne darin, dass praktisch jede Komponente seiner Infrastruktur zur Angriffsfläche für Gauner werden kann. Die denkbaren Szenarien sind praktisch grenzenlos: Webanwendungen mit dem Füllhorn von XSS- und anderen Injektionsangriffen sind ebenso ein Problem wie Systeme mit ungepatchter Software, unsicheren Benutzeraccounts, falsch konfigurierten Firewalls, schlecht geschützten Netzwerkgeräten und so weiter. Gleichzeitig werden IT-Setups zunehmend komplexer und bestehen aus immer mehr Komponenten. Mehr noch: Manchmal weiß der Administrator gar nicht so genau, mit welchen Komponenten er es lokal nun eigentlich zu tun hat. Und wer Infrastrukturen im Kundenauftrag betreibt, sollte deren Funktions- und Softwareumfang kennen – und oft genug ist selbst das mangels Automation nicht der Fall. Ist eine Firma aber ein Plattformbetreiber und irgendjemand knackt den Webserver von Kunde XYZ, zieht das im schlimmsten Falle Konsequenzen für andere Kunden und die Firma nach sich. Und das ganz ohne, dass der Admin ein aufziehendes Unheil auch nur hätte erahnen können.
Scanner mit Plug-in-Architektur
Ein Schlüssel beim erfolgreichen Abwehren von Angriffen besteht darin, möglichst schnell zu merken, falls einmal etwas nicht stimmt. Und am besten lassen sich Attacken dadurch vermeiden, dass IT-Verantwortliche Risiken in Sachen Sicherheit noch vor einem erfolgreichen Angriff identifizieren und beseitigen. Händisch ist das allerdings nicht zu leisten, wenn im eigenen RZ Tausende oder noch mehr virtuelle Instanzen mit dem buntesten denkbaren Softwarezoo laufen. Hier helfen nur Tools weiter, die ganze Netze oder Hosts automatisiert abfragen und nach spezifischen Schwachstellen suchen. Google springt Admins hier zur Seite und liefert Tsunami [1]. Zwar handelt es sich dabei um kein offizielles Google- Projekt, der Anbieter leistet also keinen Support dafür. Doch steht Tsunami mittlerweile unter der Apache-Lizenz auf GitHub bereit und das Werkzeug ist ohne weiteres Google-Involvement zu nutzen.
Tsunami besteht aus zwei Komponenten: Google geht geschickt vor und hat das Programm als Framework konzipiert, in das sich bei Bedarf beliebige Funktionen per Plug-in integrieren lassen. Grundlegende Funktionen wie den Aufbau einer Verbindung implementiert Tsunami, das in Java verfasst und damit plattformunabhängig ist, selbst. Die Plug-ins enthalten dann "nur" die spezifischen Kommandos und Aufrufe, die notwendig sind, um entfernte Dienste auf spezifische Verwundbarkeiten hin zu überprüfen.
Eines der größten Probleme des Administrators besteht zweifelsohne darin, dass praktisch jede Komponente seiner Infrastruktur zur Angriffsfläche für Gauner werden kann. Die denkbaren Szenarien sind praktisch grenzenlos: Webanwendungen mit dem Füllhorn von XSS- und anderen Injektionsangriffen sind ebenso ein Problem wie Systeme mit ungepatchter Software, unsicheren Benutzeraccounts, falsch konfigurierten Firewalls, schlecht geschützten Netzwerkgeräten und so weiter. Gleichzeitig werden IT-Setups zunehmend komplexer und bestehen aus immer mehr Komponenten. Mehr noch: Manchmal weiß der Administrator gar nicht so genau, mit welchen Komponenten er es lokal nun eigentlich zu tun hat. Und wer Infrastrukturen im Kundenauftrag betreibt, sollte deren Funktions- und Softwareumfang kennen – und oft genug ist selbst das mangels Automation nicht der Fall. Ist eine Firma aber ein Plattformbetreiber und irgendjemand knackt den Webserver von Kunde XYZ, zieht das im schlimmsten Falle Konsequenzen für andere Kunden und die Firma nach sich. Und das ganz ohne, dass der Admin ein aufziehendes Unheil auch nur hätte erahnen können.
Scanner mit Plug-in-Architektur
Ein Schlüssel beim erfolgreichen Abwehren von Angriffen besteht darin, möglichst schnell zu merken, falls einmal etwas nicht stimmt. Und am besten lassen sich Attacken dadurch vermeiden, dass IT-Verantwortliche Risiken in Sachen Sicherheit noch vor einem erfolgreichen Angriff identifizieren und beseitigen. Händisch ist das allerdings nicht zu leisten, wenn im eigenen RZ Tausende oder noch mehr virtuelle Instanzen mit dem buntesten denkbaren Softwarezoo laufen. Hier helfen nur Tools weiter, die ganze Netze oder Hosts automatisiert abfragen und nach spezifischen Schwachstellen suchen. Google springt Admins hier zur Seite und liefert Tsunami [1]. Zwar handelt es sich dabei um kein offizielles Google- Projekt, der Anbieter leistet also keinen Support dafür. Doch steht Tsunami mittlerweile unter der Apache-Lizenz auf GitHub bereit und das Werkzeug ist ohne weiteres Google-Involvement zu nutzen.
Tsunami besteht aus zwei Komponenten: Google geht geschickt vor und hat das Programm als Framework konzipiert, in das sich bei Bedarf beliebige Funktionen per Plug-in integrieren lassen. Grundlegende Funktionen wie den Aufbau einer Verbindung implementiert Tsunami, das in Java verfasst und damit plattformunabhängig ist, selbst. Die Plug-ins enthalten dann "nur" die spezifischen Kommandos und Aufrufe, die notwendig sind, um entfernte Dienste auf spezifische Verwundbarkeiten hin zu überprüfen.
Entsprechend teilt sich auch der Tsunami- Quelltext in mehrere Abschnitte auf. Einerseits besteht er aus dem Hauptprogramm, also der Tsunami-Engine und ihrer Schnittstelle zum Laden von Plugins. Andererseits gehört zu Tsunami auch eine Plug-in-Sammlung, die zum Teil von Google und zum Teil aus der Community gespeist wird und bereits eine ganze Reihe von Detektoren für gängige Angriffsszenarien enthält. Eher unschön ist allerdings der Umstand, dass die Inbetriebnahme von Tsunami nicht so trivial ist, wie es der Administrator eigentlich erwarten würde.
Tsunami nutzen: Docker oder Shell
Denn Google sieht grundsätzlich zwei Wege vor, mit Tsunami an den Start zu gehen. Die erste Variante besteht darin, ein von Google bereitgestelltes Shell-Skript zu nutzen, das Tsunami lokal aufbaut. Option 2 verpackt Tsunami in einen Docker-Container, der sich anschließend beliebig ausrollen lässt. Die Krux an der Sache: Tsunami erwartet beim Start die Konfiguration entweder in Form einer Datei namens "tsunami. yml" – diese ist allerdings im GitHub- Verzeichnis des Tools nur ein leerer Platzhalter ohne jede Dokumentation.
Alternativ lässt Tsunami sich auch in Form von Kommandozeilenparametern beim Aufruf steuern, doch dieser Parameter ist beim Einsatz mit Docker Bestandteil des Dockerfile. Für jeden zu prüfenden Host wäre es in diesem Szenario nötig, einen eigenen Docker-Container zu bauen, was kaum effizient oder sinnvoll ist. Wir stellen beide Ansätze vor, denn in der Praxis haben beide ihre Daseinsberechtigung.
Der Shell-basierte Ansatz
Das folgende Beispiel setzt einen Host mit Ubuntu Linux 22.04 voraus, auf dem Java installiert ist. Zusätzlich zu Java sind der Netzwerkscanner Nmap in einer Version höher als 7.80 sowie der Passwortcracker ncrack höher als 0.7 nötig. Tsunami ruft diese Komponenten bei diversen seiner eigenen Aktionen auf, ohne die entsprechenden Programme liefen jene Aufrufe folglich ins Leere. Obendrein ist für die Simulation eines falsch konfigurierten Diensts eine Laufzeitumgebung für Docker-Container nötig, wahlweise also Docker in der Community-Edition oder ein aktuelles Podman.
Wie üblich bietet Google seinen Nutzern im Beispiel eine Art Rundumpaket und zeigt in der Dokumentation gleich auch, wie ein fehlerhaft konfigurierter Dienst zu starten ist, den Tsunami anschließend erkennt. Hierfür reicht der Befehl
docker run --name unauthenticatedjupyter-notebook -p 8888:8888 -d jupyter/base-notebook start-notebook.sh --NotebookApp.token=''
Dies startet eine Instanz von "Jupyter Notebook", einer Art Online-Computing- Plattform für verschiedene Programmiersprachen. Im Normalfall sollte eine Jupyter- Instanz stets mit einem Passwort versehen sein, weil sie ansonsten jedem Besucher das Ausführen beliebigen Codes ermöglicht. Genau solch ein Setup simuliert das von Google vorgeschlagene Beispiel, um Tsunami und seine Funktionen vorzustellen.
Weiter geht es dann mit dem wenig intuitiven Befehl
bash -c "$(curl -sfL https://raw.githubusercontent.com/google/tsunami-security-scanner/master/quick_start.sh)"
Damit laden Sie ein Skript aus dem Tsunami- Quelltext herunter. Jenes wiederum holt sich den kompletten Tsunami- Quelltext und den der verfügbaren Plug-ins, baut das Tsunami-Binary und führt es schließlich auf die IP-Adresse "127.0.0.1" aus. Praktisch: Im Anschluss an den Aufruf befindet sich das "tsunami"- Binary im Ordner "$HOME/tsunami" des ausführenden Benutzers und lässt sich für weitere Aufrufe nutzen, gerade auch für jene, die nicht nur den defekten Beispiel-Container auf dem lokalen Host erkennen.
Tsunami im Container
Der alternative Weg über Docker-Container hat Vor- und Nachteile. Einerseits ist es nicht nötig, das eigene System mit einer Java-Umgebung zu versehen, Nmap und ncrack zu installieren oder hinterher mit Dateien im Dateisystem zu hantieren. Das lokale System bleibt stattdessen sauber. Andererseits ist es bei diesem Ansatz notwendig, in Abhängigkeit des zu prüfenden Hosts eigene "Dockerfile"-Dateien für jeden Ziel-Host zu pflegen. Denn Tsunami beherrscht aktuell nur den Aufruf mit einem einzelnen Host als Zielangabe, das Scannen gesamter Netzwerke steht explizit nicht auf der Liste der unterstützten Funktionen.
Was wie eine lästige Einschränkung klingt, kann sich im Alltag allerdings als praktischer Ansatz entpuppen. Wer etwa seine Docker-Abbilder für Tsunami unmittelbar aus einer CI/CD-Pipeline generiert, kann dort automatisch für sämtliche benötigten Zielsysteme entsprechende Images erstellen und in einer lokalen Registry zur Verfügung stellen. Der Betrieb der Scanner lässt sich danach auf der Systemseite etwa per Ansible oder Systemd gut automatisieren, indem einer der Dienste beispielsweise die Container automatisch alle sechs Stunden startet und die Ausgabe per E-Mail an eine festgelegte Adresse schickt. Praktisch ist auch, dass die Container mit Tsunami ab Werk darauf ausgelegt sind, nur den Tsunami- Befehl selbst auszuführen und sich im Anschluss zu beenden.
Sie benötigen auf einem System zumindest "git", um die Docker-Quellen aus dem Quelltext auszuchecken. Das geht dann per
git checkout https://github.com/ google/tsunami-security-scanner
Danach sorgen die Kommandos
ce tsunami-security-scanner
docker build -t tsunami
dafür, dass das Abbild auf Basis der Daten des Dockerfiles gebaut wird. Im Dockerfile ist in der letzten Zeile die IP-Adresse des Zielsystems anzupassen, als Default steht diese auf "127.0.0.1". Im Anschluss lässt sich der Container mit Tsunami starten:
docker run --network="host" -v "$(pwd)/logs":/usr/tsunami/logs tsunami
Dafür muss der aktuelle Ordner einen Unterordner "logs" haben, in dem sich im Anschluss an den Lauf des Containers dessen Logdateien finden.
An dieser Stelle sei angemerkt, dass unser Beispiel der Komplexität eines Aufbaus mit automatisch generierten Abbildern kaum gerecht wird. Wer Tsunami automatisiert in Form von Docker-Containern betreiben möchte, sollte sich dafür zunächst einen Host heraussuchen, der netzwerktechnisch an alle zu prüfenden Instanzen herankommt. Es empfiehlt sich, unter Umständen einen eigenen Docker-Host zu erstellen, dessen einzige Aufgabe im Betrieb von Tsunami- Containern besteht. Darüber hinaus ist Dockerfile wie beschrieben idealerweise im Rahmen einer CI/CD-Umgebung so dynamisch zu gestalten, dass ein lokales Git- Verzeichnis Docker-Container für alle Zielsysteme automatisch erstellen kann.
Einsatz der Tests
Die Behauptung, Tsunami sei ausschließlich in Java verfasst, ist nicht ganz zutreffend, denn Teile der Software kommen in Go daher. Für die Tests gilt das allerdings nicht, denn diese sind komplett in Java geschrieben. Wer einmal mit dem Tool und seiner Nutzung vertraut ist, verschafft sich idealerweise zunächst einen Überblick über die bereits bestehenden Tests. Aktuell liegen Tsunami-Scans aus vier verschiedenen Quellen vor: von Google, aus der Community, von Facebook und einer von einer Firma namens GovTech, der sich auf eine Schwachstelle in Netzwerkgeräten von Cisco bezieht. Wohlbemerkt: Alle diese Checks geht die Software automatisch durch, wenn Sie sie mit den Standardoptionen aufrufen. Es ist also explizit nicht notwendig, einzelne Tests zu aktivieren oder zu deaktivieren. Denn wenn Tsunami feststellt, dass ein Test auf einem bestimmten System etwa mangels eines laufenden Diensts gar nicht anwendbar ist, erklärt die Software das System folgerichtig für "nicht verwundbar" statt mit einer Fehlermeldung den Dienst zu quittieren.
Im "community"-Verzeichnis der Tests finden sich etliche Checks für Bugs in bekannten Webanwendungen und Web- Frameworks. So erkennt Tsunami hier automatisch, falls eine ältere Apache-Version installiert ist, die in der Rewrite-Engine den Bug hat, der unautorisierten Zugriff auf beliebige Pfade im Dateisystem ermöglicht (CVE-2021-41773). Ebenso erkennt Tsunami einen Fehler in Apache Solr, der das Lesen beliebiger Files ermöglicht. Der Datenvisualisierer Grafana hatte in Form von CVE-2021-43798 einen unschönen Fehler, der das Austricksen seiner Benutzerverwaltung ermöglichte.
Kritischer als Probleme des Typs "File Traversal" sind aber ohnehin solche, die das Ausführen beliebigen Codes ermöglichen. Auch hier steuert die Community bei: Einen entsprechenden Fehler in Apache (CVE-2021-25646) erkennt Tsunami nämlich ebenso wie in GitLab (CVE-2021-29441) oder Confluence (CVE-2021-26084). Anhand der Jahreszahlen der CVE-Einträge mag mancher Admin dabei denken, Tsunami kümmere sich nur um olle Kamellen, doch das stimmt nicht. Auch für aktuelle Probleme liegen Tsunami bereits etliche Checks bei. Hinzu kommt zudem, dass der administrative Alltag vielerorts das Patchen von Problemen in zentraler Software kaum zulässt. Dass für Confluence vor über einem Jahr ein Patch erschienen ist, der eine kritische Sicherheitslücke stopft, ist längst nicht jedem Admin klar. Da nützt es, wenn eine Software wie Tsunami den Finger in die Wunde legt.
Vielseitige Checks von Google
Die von Google beigesteuerten Tests machen den Großteil der Tsunami-Scans aus. Und hier gibt es für jeden Zweck etwas: Mit geladenen Google-Plug-ins überprüft Tsunami etwa die Ports eines Systems generell auf unnötige Freizügigkeit und verschiedene Passwörter per ncrack auf ihre Sicherheit, was Wörterbuchattacken verhindert. Darüber hinaus liefert Google viele Plug-ins, die erkennen, ob spezifische Dienste exponiert sind, obwohl sie das eigentlich nicht sein sollten. Administratoren kennen das Problem vielleicht aus eigener Erfahrung: Viele Programme kommen heute mit Komponenten daher, die nur intern erreichbar sein müssen, exponieren diese aber aus Versehen ins Netz. Die Krux ist dabei, dass die Entwickler der jeweiligen Software dieses Problem gar nicht auf dem Schirm haben und daher diese Einsatzart auch nicht aktiv auf Sicherheitsprobleme hin abklopfen. Administratoren fallen dann oft aus allen Wolken, wenn sie merken, dass ein Einbruch über einen Dienst stattgefunden hat, der eigentlich gar nicht ins Internet hätte zeigen sollen.
Beispielhaft erwähnt seien hier die ElasticSearch-API oder die API von Kubernetes. Auch Jenkins und Jupyter werden regelmäßig so konfiguriert, dass beispielsweise ihre administrative Oberfläche aus dem Netz erreichbar ist, obwohl sie das nicht sein soll. Obendrein fängt Tsunami dank der Google-Plug-ins offene WordPress-Setups ab, bei denen die initiale Konfigurationsseite noch erreichbar ist und die folglich mangels eines nicht gesetzten Passworts aus dem Netz leicht zu übernehmen und mithin zu missbrauchen sind.
Zusätzlich liefert Google etliche Plug-ins, die Tsunami die Erkennung typischer Schwachstellen in Websoftware wie Joomla ermöglichen. Hier kommt der Faktor zum Tragen, den wir eingangs bereits erwähnten: Ein Plattformanbieter wird kaum einen Überblick über sämtliche Dienste haben, die in seiner Umgebung laufen. Tsunami findet aber zum Beispiel Installationen von Joomla mit ungepatchten Sicherheitslücken. Meist besteht die Idee hinter der Ausnutzung solcher Lücken gar nicht darin, die Joomla-Instanz komplett zu übernehmen. Viel eher geht es darum, basale Dienste wie die E-Mail-Konfiguration einer Jira-Instanz zu nutzen, um über einen E-Mail- Server mit eigentlich guter Reputation effektiv Spam zu versenden. Das fällt indsirekt aber auf den Anbieter zurück, denn der hat am Ende nicht nur massenhaften Datenverkehr, sondern muss sich auch damit abfinden, dass sein gesamtes IPv4-Netz in diversen Blacklists landet. Gut also, wenn der Betreiber einer Plattform hier zeitnah eingreift oder – noch besser – entsprechende Vorsichtsmaßnahmen vornimmt.
Was Google plant
Die Website der Tsunami-Plug-ins enthält eine Liste der Plug-ins, auf die Administratoren sich in absehbarer Zeit freuen dürfen. Hier sind durchaus ein paar Kracher dabei, die im Alltag sehr hilfreich sein dürften. So soll Tsunami in Zukunft einen ungeschützten Hashicorp- Consul-Server, der ins Netz exponiert ist, automatisch erkennen können. Allzu kommunikationsfreudige Docker-API-Server stehen ebenso auf der Wunschliste der Tsunami-Entwickler wie nicht konfigurierte Drupal- und phpMyAdmin-Instanzen oder komplett offene Kubernetes-Instanzen.
Gerade Letztere haben sich in den vergangenen Monaten zum Problem entwickelt, weil vielen Admins nicht klar ist, dass sie an der Stelle überhaupt ein Problem haben. Sobald die passenden Plug-ins in Tsunami vorhanden sind, dürfte das aber eher kein Problem mehr sein. Denn das Tool gibt in der Ausgabe seiner Befehle klare Anweisungen hinsichtlich der durch den Admin zu ergreifenden Schritte.
Eigene Tests schreiben
Tsunami erlaubt Ihnen auch das Verfassen eigener Checks. Es würde allerdings den Rahmen dieses Artikels sprengen, im Detail darauf einzugehen. Dennoch möchten wir Ihnen auch dazu etwas Know-how an die Hand geben.
Im Quelltext der Tsunami-Plug-ins selbst (also nicht in jenem des Scanners) findet sich das Verzeichnis "examples". Und dieses wiederum enthält drei Beispiele, die sich auf unterschiedliche Probleme beziehen: auf ein ungefixtes Sicherheitsloch, auf eine versehentlich ohne Schutz exponierte API sowie auf ein generisches Beispiel, das einen externen Prüfbefehl aufruft. Wer nicht sattelfest in Java ist, kann mit diesen Beispielen vermutlich nicht viel anfangen. Doch mit etwas Kenntnis einer Programmiersprache steigen Sie relativ schnell dahinter, wie Tsunami im Kern funktioniert und welche Features es bietet. Gleich zu Beginn eines Plug-ins importiert der Administrator etliche Tsunami-Module, über die sich verschiedene Tests mit generischen Parametern durchführen lassen. Funktionen wie das Ausgeben eines Reports, nachdem dieser generiert ist, sind standardisiert und führen dazu, dass die Ausgaben einzelner Plugins zuverlässig in der Gesamtausgabe des Tools erscheinen.
Die Beispiele im Tsunami-Quelltext zusammen mit den bestehenden Modulen im anderen GitHub-Verzeichnis sollten es erfahrenen Jana-Entwicklern jedenfalls nicht besonders schwer machen, den Einstieg zu finden. Darüber hinaus findet sich unter [2] eine allerdings eher rudimentäre Dokumentation, die die wesentlichen Fragen beantwortet und anhand von Beispielen erläutert.
Fazit
Tsunami hilft dem Administrator dabei, eine sehr drängende Frage zu beantworten: Wo in meiner Umgebung schlummern Gefahren, von denen ich im Augenblick noch gar nichts weiß? Frei nach dem Motto "Agieren statt reagieren" versetzt es Systemverwalter in die Lage, Probleme zu beheben, bevor diese zu einer Sicherheitslücke werden. Im Kern unterscheidet Tsunami sich dabei von anderen Werkzeugen wie Chef dadurch, dass es durch Plug-ins beliebig erweiterbar ist, wofür allerdings Java- Kenntnisse unumgänglich sind.
Einziger Wermutstropfen ist die Art und Weise des Deployments, das aktuell nur die Angabe eines einzelnen Hosts als Ziel unterstützt, und so den Administrator zu Verrenkungen zwingt. Die Installation kann grundsätzlich auf der Kommandozeile oder per Docker und entsprechender Infrastruktur geschehen, wobei in produktiven Umgebungen Docker in den meisten Fällen die bessere Wahl sein dürfte. Wer aber keine CI/CD-Umgebung hat, um eigene Docker-Container zu bauen, hat etwas mehr Arbeit vor sich.
(jp)
Link-Codes
[1] Tsunami auf GitHub: https://github.com/google/tsunami-security-scanner
[2] Dokumentation für eigene Plug-ins: https://github.com/google/tsunami-security-scanner/blob/master/docs/howto.md#create_plugins