Wenn Penetrationstester ins System gelangt sind kann man sich ihre Aktivitäten ein bisschen vorstellen wie die einer Armee oder Rebellengruppe, die ein besetztes Land plündert. Man schmarotzt sich durch das System des Opfers und nimmt mit, was man kriegen kann: Shells, Netzwerkdienstprogramme, schlecht geschützte Passwortdateien und so weiter. Es geht darum, so wenig Malware wie möglich einzuschleusen und das, was man findet zu nutzen, um das System weiter auszukundschaften. Oder damit zu einem späteren Zeitpunkt erneute Angriffe zu starten.
Das Ganze nennt sich „Malware-freies“ Hacken und ist weitaus schwieriger aufzudecken als früher genutzte Techniken. Ed Skoudis hat in einem Interview im vergangenen Oktober erwähnt, dass Angreifer für ihre Aktivitäten nach dem Eindringen in Systeme sogar PowerShell verwenden.
In diesem Beitrag beschäftigen wir uns damit, wie man sich vom ursprünglich gehackten System aus weiterbewegt. Echte Penetrationstester nennen dies „Seitwärtsbewegung“. Wir wollen hier demonstrieren, dass dies mit nur wenigen importierten Tools gelingen kann.
Die Domain des Unternehmens Acme
Hat man die verborgenen Werte bereits im ursprünglichen Zielsystem gefunden sollte man sich schleunigst aus dem Staub machen. Die meisten Hacker haben aber nicht so viel Glück, es sei denn sie landen auf dem Laptop des CEO.
Um unsere Penetrationstests etwas realistischer zu gestalten haben wir eine Domain eingerichtet (Amazon Web Services macht es möglich) und nach sorgfältigem Studieren dieses Dokuments von Amazon Web Services einen Domänencontroller (mit Active Directory und DNS) installiert und anschließend zwei Windows-Server aufgebaut.
In unserem imaginären Unternehmen Acme mit dem imaginären Domainnamen acme.local haben wir zwei imaginäre Mitarbeiter – nennen wir sie Jane und Bob – eingestellt und mit einem Server verbunden. Im Domänencontroller haben wir den Nutzern grundlegende Berechtigungen für das Netzwerk mithilfe der Gruppenrichtlinie „Zuweisen von Benutzerrechten“ erteilt. Um die Sache etwas spannender zu machen, sollten sich die beiden Server nicht miteinander vernetzen lassen. Entsprechend haben wir auch die Firewall etwas weniger streng konfiguriert als von Amazon empfohlen.
Es handelt sich hierbei ganz offensichtlich um eine ziemlich rudimentäre Infrastruktur. Es ist aber durchaus vorstellbar, dass sich solch ein kleines System in einem großen Unternehmen oder vielleicht bei einem externen Lieferanten befindet. Beispiele gibt es.
Hacker-Know-how
Wie zuvor haben wir einen RAT, hier war es Janes Windows 2008-Server, verwendet. Zu Penetrationstest-Zwecken haben wir zwei Tools in Janes Ordner „Eigene Dateien“ geladen: Ncat und ein Hilfsprogramm namens PsExec ( mehr zum Thema Parameterverwendung in diesem Technet-Artikel).
Beide Tools sind Teil einer Grauzone: Sie sind für IT-Administratoren gleichermaßen nützlich wie für Hacker. Ihre alleinige Existenz in einem System ist nicht per se ein Zeichen für kriminelle Handlungen. Man kann sie natürlich in einem weniger offensichtlichen Ordner als „Eigene Dateien“ verstecken, aber das spielt hier keine große Rolle.
Mithilfe von Ncat haben wir eine Shell auf Janes Server ausgeführt und damit begonnen Informationen zu sammeln. Das erklärte Ziel der Penetrationstests besteht darin, wie ein Hacker vorzugehen – also Informationsfetzen zusammen zu tragen und daraus Rückschlüsse zu ziehen.
Mit dem Befehl hostname finden wir den Namen des Rechners heraus, auf dem auf dem wir gelandet sind (siehe oben). Die Antwort war „Miller“.
Der Befehl systeminfo förderte weitere technische Details zutage: neben dem Hostnamen wurden uns die IP-Adresse, der Name und die Version des Betriebssystems sowie der Domänenname angezeigt. Allesamt sehr nützliche Informationen.
Nehmen wir an, wir sind auf der Suche nach personenbezogenen Daten und habe nichts Interessantes gefunden. Wir würden unser Glück gerne auf einem weiteren Server versuchen. Mit Hilfe von Nmap, könnten wir das System nach IP-Adressen durchsuchen, doch wir bleiben bei unserer schlanken Variante von Penetrationstests.
Also geben wir stattdessen den Befehl arp -a ein, um zu sehen, was sich sonst noch im Subnetz befindet. Und siehe da: Der ARP-Cache spuckt einen weiteren Rechner in der Nähe aus.
Doch wie dorthin gelangen?
Der Joker: lokaler Administrator
Hier kann theoretisch PsExec weiterhelfen. Für nicht wenige eines der Lieblingstools. Mit dem Befehl kann man eine Remote-Verbindung zu einem anderen Rechner in der Domäne aufbauen und eine Shell oder einen anderen Windows-Befehl ausführen. Das Windows-Programm netsh bietet ebenfalls Remote-Funktionen, ist jedoch weniger flexibel.
Das erste Problem für Penetrationstester besteht darin, dass PsExec den Namen des Remote-Computers braucht (siehe Syntax). Im Moment haben wir aber nur die IP-Adresse.
Also müssen wir wieder auf Beutezug gehen.
Im Ordner \Windows\system32 finden wir nslookup, das klassische Tool zum Konvertieren von URLs in IP-Adressen und umgekehrt. In der Windows-Version kann eine IP-Adresse direkt in nslookup eingegeben werden und schon wird der DNS-Name ausgeworfen.
Der Remote-Computer hieß „amstel“. Der IT-Administrator hat also nach „Miller“ offensichtlich eine Vorliebe für Biernamen. Etwas, das man im Hinterkopf behalten sollte.
Anschließend versuchten wir Folgendes:
psexec \\amstel.acme.local -u jane@acme.local cmd.exe
Aber Windows lehnte Janes Konto ab.
Es gab zwei Probleme. Erstens hatten wir Jane in unserer Rolle als Administrator von Acme nicht erlaubt, sich an einem anderen Rechner anzumelden. Zweitens benötigte Jane selbst Administratorrechte, um PsExec auszuführen, die sie aber nicht hatte.
Dieses Beispiel ist sehr praxisnah – es ist immer eine gute Idee, den durchschnittlichen Nutzer davon abzuhalten, im Netzwerk herumzustreunen. Hacker und Penetrationstester allerdings wissen: Auf dem Rechner, auf dem sie gelandet sind, gibt es häufig lokale Konten mit erweiterten Berechtigungen.
Bei Windows gibt es seit jeher lokale Konten mit Administratorrechten, die selbst dann noch auf Laptops und Servern schlummern, wenn sie schon lange nicht mehr gebraucht werden. In der Regel haben diese Konten so offensichtliche Namen wie Admin oder Administrator und leicht zu erratende Passwörter wie Admin1234 oder ähnliches.
Hacker nutzen solche Sicherheitslücken aus, indem sie die Passwörter der lokalen Administratorkonten erraten.
Fairerweise muss man einräumen, dass Microsoft sich des Problems bewusst ist und Administratorrechte für lokale Konten in den letzten Betriebssystem-Versionen standardmäßig deaktiviert hat. Außerdem wird versucht, das Hinzufügen lokaler Nutzerkonten zu unterbinden.
Die wundersame Seitwärtsbewegung
Obwohl unser Arsenal an Tools sehr eingeschränkt war hofften wir, dass es nicht so schwierig sein würde, die Kontrolle über Bobs Server zu übernehmen. Es kam anders. Dazu mehr zu einem späteren Zeitpunkt.
Unserer Meinung nach ist die Reverse-Shell-Methode mit Netcat nicht vollständig transparent. Bei Remote-Befehlen mit Eingabeaufforderungen bekamen wir Probleme, von unserem Hacker-Rechner aus Text einzugeben – insbesondere beim Befehl runas.
Also wiesen wir kraft unserer Rolle als IT-Administrator von Acme Jane erweiterte Berechtigungen zu. Aber trotzdem konnte Janes Domänenkonto nicht auf Bobs Server zugreifen.
Als Penetrationstester konnten wir Befehle über PsExec ausführen. PsExec hat die wünschenswerte Eigenschaft, Passwortparameter zuzulassen. In unserem aktuellen Setup konnten wir deshalb eine Brute-Force-Attacke auf das Passwort des lokalen Administrators von Bobs Server starten. Damit hatten wir schließlich Erfolg (siehe unten).
Wir hatten gehofft in unserem Reverse-Shell-Szenario mithilfe von PsExec eine Shell auf Bobs Amstel-Server zu erstellen. Es gelang uns aber lediglich, einen einzigen Shell-Befehl (keine Skripte) über die Befehlszeile auszuführen, und selbst das war eine schwere Geburt. Es gab offensichtlich keinen einfachen Weg, nach personenbezogenen Daten und anderen Strings im Remote-Verzeichnis zu suchen. Dennoch war PsExec hilfreich.
Hacker wie Penetrationstester können mit PsExec nach Administratorkonten auf Rechnern in der Domain suchen. Und solche Konten können sehr ergiebig sein.
Wenn alle Stricke reißen, es gibt noch SSH
Nach unserer ersten Übung in Sachen Penetrationstests hatten wir den Eindruck, dass Windows es einem durchaus schwer machen kann, Remote-Befehle auszuführen. Unmöglich ist es nicht, aber schwierig.
Und IT-Administratoren verärgert das ihrerseits. Und genau deshalb installieren sie die Open-Source-Software SSH in Windows-Infrastrukturen!
Es ist also nicht ungewöhnlich, dass ein SSH-Server ausgeführt wird. Als IT-Administrator von Acme hatten wir freeSSHd auf Bobs Server eingerichtet.
Dank SSH begannen die Türen sich nun langsam zu öffnen. Mithilfe der RAT haben wir eine SSH-Clientanwendung auf Janes Rechner geladen und ausgeführt. Und im Handumdrehen gelangten wir mit dem zuvor eingerichteten lokalen Administratorkonto per SSH auf Bobs Server. Dafür nutzen wir die SSH –Portweiterleitung – ebenfalls ein von Penetrationstestern gern genutztes Feature.
Professionelle Penetrationstester (und Hacker) würden wahrscheinlich fortschrittlichere Tools verwenden. Doch das Prinzip ist dasselbe.
