Netzwerke angreifen, um sie zu sichern

Beim Durchstöbern eines Konferenz-Archivs fiel mir ein altes Video von Fyodor, dem Hauptentwickler des Nmap-Scanners, ins Auge. Da ich damals selbst im Publikum gesessen habe, wollte ich eigentlich nur meine Erinnerungen auffrischen, als ich mir das Video dann noch einmal ansah [1] . Dabei fiel mir dann allerdings auf, wie rasant sich das Tool in den letzten Jahren entwickelt hat. Nicht nur die Performance, mit der Nmap mittlerweile Tausende von Hosts in kurzer Zeit scannen kann, hat sich im Vergleich zu den ersten Versionen extrem verbessert, auch die Scripting Engine NSE kann sich nun wirklich sehen lassen. Standen vor einigen Jahren nur wenige Skripte zur Verfügung, enthält die aktuelle Version von Nmap weit über 400.

Auch die Datenbank mit den Fingerprints, die zum Ermitteln der Services und des eingesetzten Betriebssystems zum Einsatz kommen, umfasst mittlerweile mehrere Tausend Einträge. Die Version 6.40 von Nmap steht seit Mitte August zum Download [2] zur Verfügung und sollte in dieser Version über die Software-Repositories der meisten Linux-Distributionen zu haben sein.

Mit der Nmap Scripting Engine (NSE) stellt das Scanning-Tool eine elegante Methode zur Verfügung, mit denen Anwender beliebige Security-Tests ausführen können. Die Tests helfen dabei, aktive Netwerkdienste zu ermitteln, Schwachstellen der eingesetzten Software und eventuell vorhandene Backdoors zu identifizieren. Es gibt sogar die Möglichkeit, Exploit-Code auf gefundene Schwachstellen anzuwenden.

Universell per Skript erweiterbar

Die Scripting Engine besteht aus zwei Teilen. Das Herzstück ist der integrierte Lua-Interpreter. Die Scriptsprache Lua [5] ist primär dafür gedacht, die Funktionalität von bestehenden Programmen zu erweitern. Aus diesem Grunde ist der Interpreter auch extrem klein, sodass er sich prima in bestehende Tools integrieren lässt. Neben Nmap greifen bereits viele andere Tools auf Lua zurück, beispielsweise auch das bekannte Intrusion Detection System »Snort« und der Packet-Analyzer »Wireshark« . Neben dem Interpreter stellt die NSE-Bibliothek die zweite Komponente der Scripting Engine dar. Diese ist dafür verantwortlich, Nmap und Lua miteinander zu verbinden. Neben den Lua-Standardfunktionen stellt diese Bibliothek sehr mächtige Nmap-spezifische Methoden zur Verfügung. Diese lassen sich in NSE-Skripten mit einer »require« -Anweisung einbinden.

Skript-Kategorien

Die NSE-Skripte selbst gliedern sich in unterschiedliche Kategorien. So befinden sich beispielsweise Skripte zum Identifizieren von Schwachstellen in der Kategorie »vuln« , während die Skripte der Kategorie »exploit« versuchen, die identifizierten Schwachstellen auszunutzen. Ruft man Nmap mit aktivierter Scripting Engine auf, ohne jedoch ein spezielles Skript oder eine Kategorie anzugeben, so kommen die Default-Skripte zum Einsatz. Neben den bereits erwähnten existieren noch die Kategorien auth, broadcast, brute, discovery, dos, external, fuzzer, intrusive, malware, safe und version. Die Scripting Engine erwartet die Skripte im Verzeichnis »/usr/share/nmap/scripts/« . Nmap selbst nimmt diese dann über die Option »--script« entgegen. Mittels »--script-args« erhalten die Skripte die passenden Argumente. Dies ist etwa bei den Brute-Force-Skripten nötig.

Während der Entwicklung von neuen NSE-Skripten kann man Nmap auch einfach mittels »--datadir« den genauen Dateisystempfad angeben, um das Skript von einer beliebigen Stelle aus auszuführen. Ist die Entwicklung abgeschlossen, sollte die Datei schließlich in das Default-Skriptverzeichnis kopiert werden. Neben den eigentlichen Lua-Skripten liegt dort auch eine Datei »script.db« . Diese kennt alle vorhandenen Skripte und die dazugehörigen Kategorien. Mittels der Nmap-Option »--script-updatedb« wird diese auf den aktuellen Stand gebracht. Die Option »--script-help« macht genau das, was der Name vermuten lässt, wobei auch Wildcards möglich sind. Eine Hilfe zu allen NSE-Skripten, die den Service »httpd« betreffen ( Abbildung 1 ), liefert:

Abbildung 1: Die Hilfe zeigt, welche Nmap-Module es für den http-Daemon gibt.

# nmap --script-help "http-*"

Das zweite Beispiel ( Abbildung 2 ) führt einen Scan auf dem lokalen Port 21 durch. Ist dieser offen, kommen die Skripte »ftp-anon« und »ftp-brute« zum Einsatz. ftp-anon prüft, ob ein anonymer Login auf dem Server möglich ist und listet im Erfolgsfall das Root-Verzeichnis des Servers auf. Das zweite Skript führt einen Brute-Force-Angriff aus. Dabei greift Nmap auf die Bibliothek »unpwdb.lua« aus dem Verzeichnis »nselib« zurück. Diese wiederum bedient sich der beiden Dateien »usernames.lst« und »passwords.lst« für den Brute-Force-Angriff. Beide Dateien sind Teil der regulären Nmap-Installation, sodass die Brute-Force-Skripte direkt einsatzbereit sind, ohne erst ein Wörterbuch mit Benutzernamen und Passwörtern herunterladen zu müssen.

Abbildung 2: So sieht ein Brute-Force-Angriff auf den FTP-Port 21 aus. Der Aufruf dazu ist ein simpler Einzeiler, der Effekt ein brutaler Passwort-Angriff.

Nmap kommt in der aktuellen Version 6.40 mit weiteren 400 fertigen NSE-Skripten daher. Sollte trotzdem nicht das passende dabei sein, so ist es recht leicht, eigene Skripte in Lua zu schreiben oder die bestehenden Skripte abzuändern. NSE-Skripte sind immer so aufgebaut, dass diese einen Header, eine Port-Regel und eine Action enthalten. Das Beispiel ( Listing 1 ) zeigt, wie sich SSH-Server identifizieren lassen, die auf einem nicht Default-Port lauschen, also beispielsweise auf Port 443. Dies könnte ein Indiz dafür sein, dass bestehende Compliance-Regeln bei der Konfiguration des Server nicht eingehalten wurden. Solche Server werden gerne dazu genutzt, um einfache Paketfilter zu umgehen, die SSH blockieren sollen. Port 443 ist der Standard-Port für gesicherte http-Verbindungen ( »https« ) und daher fast immer offen. Ein Paketfilter, der lediglich bis OSI-Level 4 arbeitet, würde hier nicht feststellen können, dass über den Port 443 kein Web-Traffic, sondern eine SSH-Verbindung läuft.