Metasploit: Exploits für alle
Seite 3: Jetzt mit GUI
Jetzt mit GUI
Zum Ausprobieren der Exploits stellt MSF drei Oberflächen bereit: msfconsole, msfweb und msfcli. Nach dem Start von MFSweb lauscht auf dem lokalen Sytem auf TCP-Port 55555 ein einfacher Webserver, der eine grafische Benutzeroberfläche zur Auswahl von Exploits und weiterer Parameter wie Ziel-IP, Port und Payload zur Verfügung stellt. Der Vorteil von MSFweb besteht darin, dass mehrere Benutzer gleichzeitig auf das Webinterface zugreifen können. Allerdings ist der Mini-Exploit-Server vollkommen ungesichert und stellt somit selbst ein Sicherheitsrisiko dar; die Entwickler raten sogar von der Benutzung ab und bezeichnen MSFweb eher als Demonstration der Möglichkeiten des Frameworks. Per Voreinstellung erlaubt MSFweb nur Verbindungen vom lokalen Rechner. Teamarbeiter müssen die Konfiguration anpassen und sollten dabei nicht vergessen, MSFweb abzusichern.
Mit MSFcli steht eine angepasste Version der Metasploit-Konsole msfconsole zur Verfügung, die sich besonders zum Einsatz in Skripten eignet. Hierfür verwendet sie eine leicht abgewandelte Syntax, die den gesamten Prozess der Auswahl von Zielen, Exploit und Payload in einen einzigen Befehl packt.
Das Hauptinterface ist die MFSconsole. Wer die Linux-Bash nutzt, wird sich sofort zu Hause fühlen -- dank Cygwin auch in der Windows-Version. Linuxer sollten in jedem Fall noch das Paket Term::ReadLine::Gnu aus dem Verzeichnis "extras" installieren, um alle Bash-Annehmlichkeiten wie Kommandovervollständigung nutzen zu können.
Außer den üblichen Konsolenbefehlen gibt es spezielle Kommandos für das Framework. So zeigt der Befehl show exploits alle verfügbaren Exploits an, show payloads listet analog die Shellcodes.
Der Befehl "use" in Verbindung mit dem Namen eines Exploitmoduls wechselt in die spezifische Umgebung dieses Exploits. Das schafft Übersicht und vereinfacht die Nutzung, da alle weiteren Kommandos nur noch für diesen Exploit sinnvolle Optionen anzeigen. Beispielsweise ist es nicht möglich, einen Linux-Exploit mit einer Windows-Payload zu kombinieren; weiterhin verlangen einige Payloads nach einer privilegierten Shell auf dem angegriffenen System, die nicht jeder Exploit liefert. In dem Perl-Modul legt der Entwickler von vornherein fest, welche Payloads mit dem Exploit funktionieren, und -- ebenso wichtig -- welche Ziele überhaupt verwundbar sind. Das Framework achtet auf diese Abhängigkeiten.
Wechselt man also mit
use apache_chunked_win32
in das Modul für den schon länger bekannten Exploit für die Sicherheitslücke, die bei einigen Apache-Versionen zur Kompromittierung des Systems führen kann, zeigt das Framework nur die entsprechenden Informationen an. Der Befehl show payloads listet dementsprechend auch nur noch die Win32-Payloads, während show targets die verwundbaren Ziele anzeigt -- in diesem Fall Apacheversionen von 1.2.x bis 1.3.24, die unter Windows laufen.
Alle weiteren Informationen teilt man dem Exploit über reservierte lokale Variablen wieder, die das Exploitmodul ausliest. Die vom Exploit benötigten Informationen listet show options
Im Beispiel muss außer der IP-Adresse des Ziels und gegenenfalls der Portnummer, auf dem Apache horcht, noch die Programmversion des angegriffenen Webservers angegeben werden:
set RHOST 192.168.1.10
set RPORT 80
set TARGET 2
Dies weist das Framework an, den Webserver des Systems mit der IP 192.68.1.10 anzugreifen, auf dem ein Apache in Version 1.3.22 läuft. Die Variable "PAYLOAD" legt fest, welchen Shellcode der Angriff einschleusen und ausführen soll. Für einige (wenige) Angriffe haben die Entwickler außerdem eine Funktion implementiert, die prüft, ob das gewählte Ziel überhaupt verwundbar ist. Der Befehl check führt den Test durch. Hat man ein verwundbares System gefunden, startet das Kommando exploit den Angriff. Das Framework überträgt den Angriffscode inklusive Payload an das Zielsystem. Bei erfolgreicher Ausführung kann der Angreifer beispielsweise mit einem Telnet-Client auf das System zugreifen und es fernsteuern.
