Metasploit: Exploits für alle

Inhaltsverzeichnis

Tools wie das Metasploit Framework (MSF) sind heftig umstritten: Die einen sehen darin geradezu eine Einladung zu kriminellen Aktivitäten und wollen die Verbreitung am Liebsten gleich ganz verbieten. Die anderen argumentieren, dass die freie Verfügbarkeit solcher Tools Administratoren dazu zwinge, ihre Netze abzusichern und Patches einzuspielen und somit letztlich für mehr Sicherheit sorge.

Wie dem auch sei, Fakt ist: Es gibt die Tools, jeder kann sie sich besorgen und wer sie nicht kennt, hat gegenüber Angreifern einen entscheidenden Nachteil. Denn nur wer eine Vorstellung davon hat, wie einfach heutzutage Exploits entwickelt und eingesetzt werden können, kann auch die Gefahr realistisch einschätzen, die von einem Sicherheitsproblem ausgeht. Und schließlich bieten gerade Tools wie MSF angehenden Sicherheitsexperten einen idealen Einstieg in die Welt der Exploits und Shellcodes. Alles in Allem Grund genug, das Framework auf heise Security vorzustellen.

Das Metasploit Framework ist auf der Homepage der Entwickler [1] kostenlos verfügbar, die meisten Module stehen unter GPL. Außer Versionen für Linux und Windows gibt es dort angepasste Pakete für FreeBSD. Während das Linuxarchiv nur die Dateien des Frameworks enthält, die der Nutzer einfach in ein Verzeichnis seiner Wahl entpackt, ist bei der Windows-Version etwas mehr Aufwand nötig. Das Framework ist in der Skripsprache Perl geschrieben, die Windows von Haus aus erstmal nicht versteht. Deshalb schaufelt der Installer neben dem MSF auch eine angepasste Cygwin-Umgebung mit auf die Platte. Cygwin, das Unixfunktionen auf Windows abbildet, bringt den Interpreter für Perl und andere Tools wie Netcat mit. Die "Snapshots" des Frameworks, in denen Metasploit zwischen Versionssprüngen neue Exploits integriert oder Funktionen hinzufügt, gibt es allerdings nur für Linux. Dafür steht mit msfupdate ohnehin ein Programm zum komfortablen Update des Frameworks auch unter Windows bereit.

Dunkle Künste

Dunkle Künste

Ein Programm, das ein Sicherheitsproblem tatsächlich ausnutzt, also beispielsweise über einen Pufferüberlauf eigenen Code einschleust und ausführt, wird üblicherweise als Exploit bezeichnet. Die Entwicklung solcher Exploits erachten selbst altgediente Programmierer oft als "schwarze Magie". Ein erfolgreicher Angriff über einen Buffer-Overflow beispielweise erfordert außerdem eine Menge mühsamer Fleißarbeit. Der Entwickler muss mit Sprungadressen experimentieren, Platz für die sogenannte Payload finden, die den einzuschleusenden Code enthält, und diesen dann noch unverändert in den Speicher des angegriffenen Systems schaffen.

Doch schon bei kleinen Änderungen am Zielsystem -- also beispielsweise einer anderen Bibliotheksversion -- funktioniert der mühsam erarbeitete Code nicht mehr. So ist es beispielsweise selten, dass ein Entwickler eine "universelle" Speicheradresse in verschiedenen Versionen von Windows findet, an der er seinen Shellcode platzieren und per Buffer-Overflow zur Ausführung bringen kann. Die Folge: Für jede Plattform, auf der eine bestimmte Sicherheitslücke auftritt, fängt er von vorne an. Das Metasploit Framework vereinfacht diese Aufgabe durch seinen modularen Aufbau und flexiblen, wiederverwendbaren Code.

Angriffslustig

Das Framework ist zunächst einmal eine Sammlung von Exploits. Dabei unterscheidet Metasploit zwischen dem eigentlichen Angriffsmechanismus, der speziell auf eine Sicherheitslücke angepasst sein muss, und dem Shellcode, der dabei zur Ausführung kommt. Letzterer wird von generischen Perl-Modulen bereitgestelllt und der Metsploit-Nutzer kann sich so auf die Entwicklung des Angriffscodes konzentrieren. Aber selbstverständlich kann er auch für bereits existierende Angriffsmodule neue Shellcodes entwerfen, die sich dann auch in anderen Modulen wieder nutzen lassen.

Der einfachste Shellcode bindet eine Command-Shell wie sie cmd.exe oder die Bash bereitstellen an einen Netzwerk-Port, sodass deren Funktionen jedermann zur Verfügung stehen, der zu diesem Port eine Verbindung aufbaut. Etwas raffinierter arbeitet die so genannte Reverse-Shell, die auch hinter einer Firmen-Firewall funktioniert. Sie baut selbständig eine Netzwerkverbindung zu einem Server auf und stellt auf dieser den Shell-Prompt bereit. (Reverse, weil der Verbindungsaufbau genau anders herum läuft wie bei einer Telnet- oder SSH-Sitzung).

Der "Meterpreter" ist eine spezielle Payload. Sie wird direkt in einen laufenden Prozess auf dem Zielsystem injiziert und ist somit schwer zu erkennen. Einmal gestartet führt der Meterpreter nicht nur Kommandos aus; er lässt sich auch durch nachladbare Plugins erweitern. So liefert beispielsweise der "Sam Juicer" die Passwort-Hashes des angegriffenen Systems. Damit entfällt die Notwendigkeit, erst eigene Tools mühsam aufs Zielsystem zu transferieren.

Die VNC-Payload ist besonders spektakulär: Das Framework startet auf dem angegriffenen System einen neuen Prozess, in welchem es einen modifizierten VNC-Server ausführt -- ohne auch nur einmal auf die Platte zu schreiben. Fortan kann der Angreifer mit einem VNC-Client auf dem übernommenen System arbeiten, als säße er direkt davor. Insgesamte stellt das Framework rund 70 verschiedene Payloads bereit.

Fundgrube

Mit seinen circa hundert Exploits kann Metsploit zwar nicht mit Tools wie Nessus mit seinen nahezu 10.000 Plugins konkurrieren, aber das ist auch nicht das Ziel. Die mitgelieferten Exploits des MSF sind eine wahre Fundgrube für Entwickler und lassen sich mit minimalem Aufwand für Angriffe neue Schwachstellen recyceln.

Trotzdem ist fast alles vorhanden, was Administratoren in den letzten Jahren schlaflose Nächte bereitet hat. Exploits für Sicherheitslücken in Samba, Apache und Microsofts Internet Information Server (IIS) liefert das Framework ebenso wie Module, mit dem sich Schwachstellen auf Client-Seite ausnutzen lassen, beispielsweise die Sicherheitslücke im LSASS, über die sich auch der Sasser-Wurm verbreitet. Des Weiteren greift das Framework FTP-Server, Backupprogramme, PHP- und MySQL-Applikationen und einiges mehr an. Dabei beschränkt sich MSF keineswegs nur auf Windows-Systeme; auch für Linux oder Suns Solaris sind Exploits im Angebot.

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.

Selber machen

Selber machen

Für Entwickler, die eigene Exploits schreiben, bietet das Framework einige Hilfestellungen. Zwar ist dieser Teil des Frameworks weniger gut dokumentiert und somit weniger zugänglich. Doch beim Erstellen eigener Exploits kann man sich an dem existierenden Code orientieren. Die zugrundeliegende Infrastruktur des MSF ist ebenfalls in Perl geschrieben, unterstützt durch Module in C und Python. Und wer ein wenig Perl kann, dürfte keine Probleme haben, mit etwas wie

my $sock =
 Msf::Socket::Tcp->new(
  'PeerAddr' =>$targetHost,
  'PeerPort' => $targetPort, );

einen Socket für eine Verbindung zum mit RHOST und RPORT spezifizierten Zielsystem zu erstellen. Da die meisten Grundfunktionen bereits vorhanden sind, entfällt viel Entwicklungsarbeit. Sockets, Netzwerkprotokolle, Attack-Strings -- für alle Aspekte eines Exploits hält das Framework Funktionen bereit.

Die mitgelieferten, ausführlich dokumentierten Exploits bieten auch eine gute Basis für eigene Experimente. Aus dem WMF-Exploit, bei dem ein lokaler Web-Server spezielle WMF-Dateien ausliefert, ließe sich beispielsweise mit zwei, drei Zeilen Perl-Code ein Exploit für eine neue Schwachstelle in der Verarbeitung von HTTP-Headern in einem Web-Browser basteln.

Außerdem bringt MSF einige Skripte mit, die beim Aufspüren und Analysieren von Sicherheitslücken in Applikationen zur Hand gehen. PatternCreate() erzeugt beispielsweise einen charakteristischen String, den man an eine Funktion übergibt, in der ein Buffer-Overflow auftritt. Mit Hilfe eines Debuggers, kann der Exploit-Entwickler dann emitteln, welcher Teil des Strings die Rücksprungadresse überschrieben hat, das Skript patternOffset.pl liefert den dazugehörigen Offset. So kann der Angreifer die Rücksprungadresse kontrolliert überschreiben.

MSFpescan findet bestimmte Kommandosequenzen in Dateien, die im Portable Executable Format (PE) für Windows vorliegen, für die ELF-Files von Linux leistet MSFelfscan dasselbe. Hintergrund: Bei einem Buffer-Overflow ist es oft notwendig, sich bestimmte Kommandos bei DLLs oder ELF-Files auszuborgen, die bereits in den Adressraum des verwundbaren Prozesses eingeblendet sind, damit der eigene Assemblercode angesprungen wird. Besonders komfortabel lassen sich solche Kommandos mit der Opcode-Datenbank finden, die die Entwickler unter [2] bereitstellen; allerdings finden sich dort bisher nur Werte für englische und französiche Windows-Versionen.

Die Entwickler von Shellcode unterstützt das Framework ebenfalls. Shellcode besteht aus Assembler-Befehlen, die direkt in den Speicher des Zielsystems geschrieben werden. Dies ist oft äußerst schwierig: Zum einen ist der Platz für die Payload meist auf ein paar Hundert Byte begrenzt; zum anderen muss der Angreifer reservierte Bytefolgen vermeiden, damit der Shellcode auf seinem Weg ins Zielsystem nicht verändert wird. Das MSF vereinfacht die Suche mit dem Skript msfencode enorm: Der Entwickler gibt vor, was die Payload leisten soll, auf welchem System sie läuft und welche Bytefolgen tabu sind; das Framework versucht, aus diesen Vorgaben einen Shellcode zu bauen.

Einer weiteren Schwierigkeit bei der Shellcode-Entwicklung nimmt sich das Framework ebenfalls an: In der Regel kennt der Exploit-Entwickler nicht die genaue Adresse, an der sein Code landet, den er anspringen lassen will. Deshalb baut er eine Art Auffangrampe, die er ungefähr anspringt und von der aus der Prozessor einfach zum eigentlichen Shellcode durchrutscht. Im einfachsten Fall der so genannten NOP-Sleds (oder auch -Slides) besteht diese Rampe aus NOP-Befehlen (0x90), die den Prozessor anweisen, einen Taktzyklus nichts zu tun ("no Operation") und dann mit dem nächsten Befehl fortzufahren.

Dies ist allerdings sehr auffällig: Auch das schläfrigste IDS wird hellhörig, wenn eine große Menge NOPs über die Leitung geht. Deshalb bringt das Framework verschiedene "Nopsled-Encoder" mit. Deren Schlitten sind so gebaut, dass die CPU jede Stelle anspringen kann und dort gültigen Code vorfindet, der jedoch keine relevanten Daten verändert.

Fazit

Auch mit dem Metasploit Framework kommt der aufstrebende Hacker letzlich nicht ganz um kryptische Assemblerbefehle und sperrige Sprungadressen herum -- zumindest, wenn er nicht nur die vorgefertigten Exploits nutzen will. Das universelle "Point&Click-Root"-Tool bleibt weiterhin ein Traum der Scriptkiddies. Das Metasploit Framework verstärkt allerdings einen Trend, der schon länger zu beobachten ist: Die Zeit zwischen der Veröffentlichung einer Sicherheitslücke und den ersten Exploits, die diese ausnutzen, wird immer kürzer.

Dabei ist Metasploit noch lange nicht das Ende der Fahnenstange: Mit Core Impact und Immunity Canvas richten sich zwei ähnliche Produkte an professionelle Sicherheitsexperten mit entsprechendem Budget. Deren zahlende und registrierte Nutzer erhalten passende Exploit-Module für Schwachstellen oft sogar schon vor deren Veröffentlichung.

Für Anfänger im Bereich Security bietet das Metasploit Framework einen interessanten Einblick in die Exploit-Entwicklung. Und den Profis erspart das Framework die zermürbende, immer wiederkehrende Alltagsarbeit, indem es für Routineufgaben modularen und wiederverwendbaren Code bereitstellt oder, wie im Falle der Shellcode-Encoder, langwieriges Rumprobieren erspart.

"Nur mal so probieren" sollte man das Framework aber nur am eigenen System oder solchen, bei denen der Besitzer die Erlaubnis erteilt hat. Während ein Portscan zwar als unhöflich gilt, an sich aber noch nicht strafbar ist, stellt der Versuch, mit einem Exploit in ein System einzudringen, schon eine strafbare Handlung dar.

Momentan arbeiten die Entwickler an Version 3.0 des Frameworks. Dies soll nicht mehr in Perl, sondern in Ruby geschrieben sein. Die Entwickler haben auf der Mailingliste des Projekts angekündigt, dabei auch die eingebauten Scan-Funktionen zu erweitern -- ein Schritt in Richtung eines universellen Sicherheitstools, das vom Auffinden von Schwachstellen bis zum Exploit alles bietet. Das Release ist für den Anfang des nächsten Jahres angekündigt.

Literatur

[1] Homepage des Metasploit-Projekts

[2] Opcode-Datenbank (ju)