Penetrationstests, Teil 4: Die Seitwärtsbewegung

HackerWenn 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.

Anzeige

Dieser Artikel beschäftigt sich damit, wie man sich vom ursprünglich gehackten System aus weiterbewegt. Echte Penetrationstester nennen dies „Seitwärtsbewegung“. Hier soll demonstriert werden, dass dies mit nur wenigen importierten Tools gelingen kann.

Die Domain des Unternehmens Acme

Wurden 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 die Penetrationstests etwas realistischer zu gestalten wurde 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 dem imaginären Unternehmen Acme mit dem imaginären Domainnamen acme.local wurden zwei imaginäre Mitarbeiter – nennen wir sie Jane und Bob – eingestellt und mit einem Server verbunden. Im Domänencontroller wurden 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 wurde 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 wurde ein RAT, hier war es Janes Windows 2008-Server, verwendet. Zu Penetrationstest-Zwecken wurden 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. Sie könnten natürlich in einem weniger offensichtlichen Ordner als „Eigene Dateien“ verstecken, aber das spielt hier keine große Rolle.

Penetrationstest Teil 4 Bild 1

Mithilfe von Ncat wurde 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 fand man den Namen des Rechners heraus, auf dem auf dem man gelandet war (siehe oben). Die Antwort war „Miller“. Der Befehl systeminfo förderte weitere technische Details zutage: Neben dem Hostnamen wurde die IP-Adresse, der Name und die Version des Betriebssystems sowie der Domänenname angezeigt. Allesamt sehr nützliche Informationen.

Nimmt man an, man ist auf der Suche nach personenbezogenen Daten und hat nichts Interessantes gefunden. Man würden sein Glück gerne auf einem weiteren Server versuchen. Mit Hilfe von Nmap, kann das System nach IP-Adressen durchsucht werden, doch hier bleibt es bei der schlanken Variante von Penetrationstests. Also wird stattdessen den Befehl arp -a eingegeben, 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 hat man aber nur die IP-Adresse. Also muss man wieder auf Beutezug gehen.

Im Ordner \Windows\system32 wurde nslookup gefunden, 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 wird Folgendes versucht:

PsExec \\amstel.acme.local -u [email protected] cmd.exe

Aber Windows lehnte Janes Konto ab.

Es gab zwei Probleme. Erstens wurde Jane in der 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 das Arsenal an Tools sehr eingeschränkt war hoffte man, 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. Die Reverse-Shell-Methode mit Netcat ist nicht vollständig transparent. Bei Remote-Befehlen mit Eingabeaufforderungen gab es Probleme, von dem Hacker-Rechner aus Text einzugeben – insbesondere beim Befehl runas. Also wurden Jane erweiterte Berechtigungen zugewiesen. Aber trotzdem konnte Janes Domänenkonto nicht auf Bobs Server zugreifen. 

Als Penetrationstester war es möglich Befehle über PsExec ausführen. PsExec hat die wünschenswerte Eigenschaft, Passwortparameter zuzulassen. In dem aktuellen Setup konnte man deshalb eine Brute-Force-Attacke auf das Passwort des lokalen Administrators von Bobs Server starten. Damit war man schließlich erfolgreich (siehe unten).

Penetrationstest Teil 4 Bild 2

Es wurde gehofft in dem Reverse-Shell-Szenario mithilfe von PsExec eine Shell auf Bobs Amstel-Server zu erstellen. Es gelang 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 der ersten Übung in Sachen Penetrationstests entstand der 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 wurde freeSSHd auf Bobs Server eingerichtet. Dank SSH begannen die Türen sich nun langsam zu öffnen. Mithilfe der RAT wurde eine SSH-Clientanwendung auf Janes Rechner geladen und ausgeführt. Und im Handumdrehen gelangte man mit dem zuvor eingerichteten lokalen Administratorkonto per SSH auf Bobs Server. Dafür nutzte man 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.

http://sites.varonis.com/de/
 

Das könnte Sie ebenfalls interessieren:

Penetrationstests, Teil 1: Kalkuliertes Risiko

Penetrationstests, Teil 2: RATs

Penetrationstests, Teil 3: RATs und Reverse-Shells

Anzeige

Weitere Artikel

Newsletter
Newsletter Box

Mit Klick auf den Button "Jetzt Anmelden" stimme ich der Datenschutzerklärung zu.