Seite 4: Selber machen

Inhaltsverzeichnis

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)