Prominenz nach dem Hafnium-Beben: Was sind eigentlich diese Webshells?

In den letzten Tagen hat die Hackergruppe Hafnium und eine Angriffsserie auf Microsoft Exchange Server für Schlagzeilen gesorgt. Die von Hafnium ausgenutzten Zero-Day-Schwachstellen ermöglichten Angreifern unter anderem

• Zugang zum Exchange-Server ohne Angabe eines Passwortes
• Rechteerweiterung bis zu den maximalen Rechten als SYSTEM
• Die Möglichkeit, Dateien an beliebige Orte auf dem Exchange-Server zu schreiben

Die Zero-Day-Lücken wurden geflickt, allerdings bleibt die Bedrohungslage weiterhin groß – was unter anderem an den vielzitierten Webshells liegt. Genau jene webbasierte Schnittstelle spielt für viele Cyberattacken eine entscheidende Rolle, um Dateien und Kommandos auszuführen, die in kompromittierte Systeme eingeschleust wurden. Die Platzierung der Webshells gestaltete sich für Hafnium & Co. im aktuellen Fall besonders einfach, da zahlreiche Exchange-Systeme aufgrund der Sicherheitslücke ohne Passwort zugänglich waren.

Natürlich nutzen viele Hacker solche Schwachstellen ganz „traditionell“ aus, indem sie Malware in die komprimierteren Systeme laden, die zu einem späteren Zeitpunkt durch den Nutzer selbst aus Versehen oder z.B. durch einen Reboot gestartet wird. Während traditionelle Schadsoftware aber nur einen limitierten Umfang an Funktionen besitzt, gibt es eine flexiblere Alternative für den Angriff auf ein Netzwerk. Und hier kommen die Shells ins Spiel – zunächst noch ohne das „Web“ davor.

Standardmäßig verwenden Skriptsprachen, eine Untergattung der Programmiersprachen für kleinere Programme, eine sogenannte „Shell“, oft auch als „REPL“ (Read-Evaluate-Print-Loop“ benannt. Anstatt ein bestehendes Programm direkt auszuführen, erstellt ein REPL typischerweise eine Eingabeaufforderung und startet erst dann, wenn der Nutzer den entsprechenden Befehl gibt. Dieser Prozess wird automatisch mit potenziell neuen Befehlen, die sich auf die vorherigen Ergebnisse beziehen, wiederholt. Unter anderem können auf diese Weise Programmierer, oder eben auch Hacker, interaktiv vorgehen, die Ergebnisse direkt verarbeiten, neue Programme im Arbeitsspeicher ausführen oder Dateien erstellen. Mit einem REPL oder einer Shell lässt sich die Programmierarbeit also im laufenden Prozess gestalten und die Nutzer sind nicht von einem starren Programm abhängig, das im Vorfeld erstellt wurde. Wenn es Hackern nun gelingt, ein solche Shell auf einem Remote-Computer zu implementieren und diese mit einzelnen Befehlszeilen zu füttern, steht eine sehr einfache Remote Shell zur Verfügung, die sehr viel programmiertechnische Freiheit gewährleistet, da sie nicht durch vordefinierte Programmfunktionen eingeschränkt ist. Ein solches Tool ist der Himmel auf Erden für Hacker, da sie nun flexibel im kompromittierten System agieren können und nicht auf eine spezielle Malware angewiesen sind.

Der Zugang über Scripting-Systeme ist attraktiv, da sehr viele Webserver ein solches Helferlein nutzen, um Inhalte zu generieren und zu bedienen. Zu den häufig genutzten Programmen zählen PHP, Perl und Python auf Linux- oder Unix-Systeme sowie PHP, VBScript, JavaScript and C# auf Windows-Systemen. Wenn Nutzer nun eine Datei mit dem Namen „index.html“ oder „image.jpg“ suchen und diese existiert, liest der Server die Datei in den Speicher und stellt sie dem Nutzer zur Verfügung.  Auch hier besteht bereits viel Potential für Hacker mit z.B. Fake News, aber gefälschte HTML-Dateien sind nicht in der Lage, den Server selbst zu kompromittieren. Aber natürlich gibt es auch hier Mittel und Wege, die Windows IIS Webservern durch Active Server Pages (ASP) eröffnet werden. Die Endung .asp in einer URL weist den Windows IIS Server automatisch an, eine Datei nicht einfach nur zu lesen und zurückzuschicken, sondern zunächst den Windows ASP Scripting Service zu durchlaufen. Während reguläre HTML-Inhalte unmodifiziert genutzt werden, werden nun bestimmte Bereiche der ASP-Datei als Script auf dem Server ausgeführt. Das Ergebnis dieses Prozesses wird wieder in die HTML-Datei eingefügt, um eine sog. dynamische Webseite zu erzeugen, bei der im Browser keinerlei Hinweise auf das Script auf dem Server bestehen.

Wenn Hacker also eine solche ASP-Erweiterung an der richtigen Stelle an einem Windows Web Sever platzieren, können sie die Dateien zu einem beliebigen späteren Zeitpunkt einfach dadurch aktivieren, indem sie die URL kontaktieren, die mit der infiltrierten Datei verbunden ist. Der Server agiert also quasi als „Kommandokonsole“ für den Hackerangriff. Zudem lassen sich ASP-fähige Script-Programme, wie beispielsweise VBScript, nicht nur aus der Ferne aktivieren, sondern es können zusätzlich weitere Parameter am Ende einer URL eingefügt werden. Dadurch kann das Script bei jedem Aufruf durch den Browser geändert werden – fertig ist die Webshell, die nicht nur spezifische Kommandos beschränkt ist, sondern individuell ausgebaut werden kann. Damit steht Hackern eine kleine aber gemeine Erweiterung auf einem Webeserver zur Verfügung, die Kommandos direkt und ohne die Notwendigkeit eines Log-ins ausführt.

Allein über den Browser können dadurch Angreifer interaktiv auf dem Zielserver Kommandos oder Programme ausführen, deren Ausgaben analysieren und basierend darauf zielgerichtet weitere Aktionen durchführen – so als ob die Angreifer an der Systemkonsole sitzen. Durch die Möglichkeit der Erweiterung ihrer Rechte als SYSTEM können die Angreifer im Fall Hafnium nicht nur auf dem betroffenen System, sondern teilweise im gesamten Netzwerk schalten und walten, wie sie wollten.

Tipp: Wer sich noch genauer über das Thema Webshells informieren will, kann dies in einem detaillierten Beitrag aus der Reihe “Serious Security” bei den Kollegen von Naked Security tun: https://nakedsecurity.sophos.com/2021/03/09/serious-security-webshells-explained-in-the-aftermath-of-hafnium-attacks/