Die praktische Anwendung des Metasploit Exploiting Frameworks bietet enorme Möglichkeiten zur Vereinfachung eines Pentests. Dazu gehört unter anderem der automatisierte Exploitingvorgang durch die Einbindung weiterer Tools, wie auch die Verwendung von Multistage Payloads oder der automatisierte Sammelvorgang von Informationen nach einem erfolgreichen Exploitingvorgang.
All diese Automatismen helfen allerdings nicht weiter, wenn bereits die Anwendung eines Exploits scheitert. Dies ist beispielsweise der Fall, wenn das Zielsystem zwar die Schwachstelle aufweist, Metasploit dieses System nicht vollständig unterstützt. Bevor wir uns im dritten Artikel, in der nächsten Ausgabe, mit dem automatisierten Exploitingvorgang mehrerer Systeme beschäftigen, passen wir in diesem Artikel einen vorhandenen Exploit an eine vorgegebene Zielumgebung an.
MS08-067
Dieser Artikel beschäftigt sich mit einer Schwachstelle, die in dem Microsoft Bulletin MS08-067 beschrieben wird. Über diese Schwachstelle soll es, laut diesem Bulletin, möglich sein Remotezugriff auf ein Windowssystem zu erlangen. Wie in Abbildung 1 dargestellt, wird dieses Sicherheitsproblem von Microsoft als kritisch eingestuft. Diese Schwachstelle lässt sich über das Netzwerk ausnützen und es ist nahezu jedes Windows Betriebssystem davon betroffen. Ende des Jahres 2008/ Anfang 2009 rückte die dargestellte Schwachstelle durch den Conficker Wurm in regelmäßigen Abständen in die Medien. Vor allem durch das scheinbar nachlässige Patchverhalten vieler Systembetreuer konnte sich Conficker bis in das Jahr 2009 in hohem Maße verbreiten. An dieser Stelle muss auf die hohe Relevanz eines einwandfrei funktionierenden und zeitnahen Patchmanagement hingewiesen werden. Probleme, wie sie von dieser Schwachstelle ausgehen bzw. durch den Conficker Wurm ausgelöst wurden, entstehen im Normalfall nicht, wenn in einem Unternehmen sauber definierte Prozesse zur System- und Softwareaktualisierung vorhanden sind und diese auch korrekt umgesetzt werden.
Auf Grund dieser sehr interessanten aber nicht besonders ruhmreichen Vergangenheit, des hohen Verbreitungsgrades und der enormen Gefahr, die von dieser Schwachstelle ausgeht, stellt diese ein sehr gutes Beispiel dar, um verfügbare Exploits praktisch anzuwenden und diese auch an das Zielsystem anzupassen. Im Folgenden wird dies anhand des in Abbildung 2 dargestellten Windows 2003 Serversystems mit Service Pack 2 und deutscher Sprachversion demonstriert.
Als Metasploit Version kommt die in Listing 1 dargestellte Version 3.3-dev auf einem Backtrack 4-prefinal Linuxsystem zum Einsatz. Da sich der benötigte Exploit bereits seit einiger Zeit im Framework befindet, sollten auch die meisten früheren Versionen aus dem Jahr 2009 funktionieren. Prüfen lässt sich das sehr einfach mit dem, in Listing 2 dargestellten Befehl
„msfcli | grep ms08_067“.
Quote:
Listing 1: eingesetzte Metasploit Version
=[ msf v3.3-dev
+ -- --=[ 381 exploits - 231 payloads
+ -- --=[ 20 encoders - 7 nops
=[ 156 aux
msf > version
Framework: 3.3-dev.6055
Console : 3.3-dev.6706
|
Einer der ersten Schritte eines typischen Pentests ist die Erkennung des Zielsystems inklusive aller verfügbaren Dienste. Hierfür kann beispielsweise Nmap mit seiner System- und Diensterkennung verwendet werden. Für solche Aufgaben sind die Nmap Optionen „–A“ oder „–sV“ und „–O“ üblicherweise sehr hilfreich. Seit Version 5.0 verfügt Nmap über die Nmap Scripting Engine (NSE) und beinhaltet ein Script für die Erkennung der in diesem Artikel behandelten Schwachstelle. Ein Scanvorgang, der Nmap veranlasst einen ganzen Netzwerkbereich auf die Schwachstelle zu testen, lässt sich beispielsweise mit folgendem CLI Aufruf erstellen:
Code:
nmap -p445 -PN -sS -oA windows.445 --script=smb-check-vulns.nse 192.168.1.0/24
Die System und Diensterkennung liefert die benötigten Details über das eingesetzte Betriebssystem und die offenen Ports mit Versionsdetails, sowie auch eine erste Einschätzung ob das geprüfte System die Schwachstelle (MS08-067) aufweist. Für weitere Informationen bezüglich Nmap und NSE sei auf die Links in den Internetressourcen am Ende des Artikels verwiesen.
Der Einsatz des Metasploit Exploiting Frameworks beginnt mit der Suche nach einem passenden Exploit, für die per Nmap ermittelte Schwachstelle. Im Rahmen dieses Artikels wird hierfür die „msfcli“ verwendet. Um den passenden Exploit zu finden, bietet sich die Verwendung des Linuxtools grep an. Eine beispielhafte Ausgabe des Suchvorganges ist in Listing 2 dargestellt.
Code:
Listing 2: Exploit Auswahl
m1k3@s3cur1ty:/pentest/exploits/framework3$ ./msfcli | grep ms08 | grep 067[*] Please wait while we load the module tree...
exploit/windows/smb/ms08_067_netapi Microsoft Server Service Relative Path Stack Corruption
Kommt die msfconsole zum Einsatz, lässt sich der Exploit mit folgendem Aufruf ermitteln:
Code:
search exploits ms08_067
Da die von diesem Exploit benötigten Speicheradressen je nach eingesetztem Service Pack unterschiedlich sind und sich zusätzlich noch zwischen den einzelnen Sprachversionen unterscheiden, muss dieser Exploit für die Zielsystemversion optimiert sein. Metasploit bringt bereits eine hohe Anzahl solcher definierter „Targets“ mit und ermöglicht meist eine einfache Anwendung der Exploits. In Listing 3 ist ein Ausschnitt der möglichen Windows Zielsysteme des gewählten Exploits mit dem vollständigen CLI Aufruf dargestellt. An dieser Ausgabe ist erkennbar, dass Windows 2003-SP2 mit deutschem Sprachpaket offensichtlich nicht unterstützt wird und der Exploit dadurch in der vorhandenen Ausführung nicht für das Zielsystem einsetzbar ist.
Code:
Listing 3: ms08_067_netapi Targets (Auszug)
m1k3@s3cur1ty:/pentest/exploits/framework3$ ./msfcli exploit/windows/smb/ms08_067_netapi T[*] Please wait while we load the module tree...
Id Name
-- ----
0 Automatic Targeting
5 Windows 2003 SP0 Universal
6 Windows 2003 SP1 English (NO NX)
7 Windows 2003 SP1 English (NX)
8 Windows 2003 SP2 English (NO NX)
9 Windows 2003 SP2 English (NX)
Um den Exploit trotz der fehlenden Sprachunterstützung für das vorhandene Zielsystem einsetzen zu können, muss im ersten Schritt der Sourcecode des Exploits analysiert werden. Das zuständige Ruby File ist unterhalb des Framework Root-Ordners „/pentest/exploits/framework3“ zu finden. Die Namensgebung des Exploits ist identisch mit dem Source File und verwendet als Dateiendung ein „rb„ für Ruby. Unter dem „modules“ Ordner findet man alle von Metasploit angebotenen Exploits, Payloads und Auxiliary-Module, wie auch die vorhandenen Encoder. An dieser Stelle sei jedem eine kurze Reise durch die Metasploit Ordner Hierarchie nahe gelegt.
Code:
m1k3@s3cur1ty:/pentest/exploits/framework3$ sudo vim modules/exploits/windows/smb/ms08_067_netapi.rb
Der allgemeine Aufbau dieser Source-Files wird in diesem Artikel nicht weiter beschrieben. In den meisten Fällen ist die Struktur dieser Files weitestgehend selbsterklärend. Nach kurzem Einlesen ist der Aufbau verständlich und man findet die relevanten Bereiche des Exploits ohne größere Probleme. In unserem Fall erkennen wir an der Definition der Targets, dass unterschiedliche Zielsysteme verschiedene Adressen in der Ret-Variable besitzen. Des Weiteren lässt sich aus den Kommentaren erkennen, dass es sich bei diesen Adressen um die Speicheradressen einer „JMP ESI“ Funktion handelt. Nach dieser Analyse des Sourcecodes ist somit bekannt, dass eine JMP-ESI Adresse eines deutschen Windows 2003 Servers mit SP2 benötigt wird.
Als Basis für diesen Artikel wird ein Windows 2003 Server ohne Execution Protection (NX) betrachtet. Weitere Informationen zu Execution Protection (NX) finden Sie in den Internet Ressourcen am Ende des Artikels.
Analyse im Debugger
Der folgende Abschnitt betrachtet die Analyse eines Windows 2003 Server Systems mit dem Ziel, durch den vorhandenen Metasploit Exploit „ms08_067_netapi“ einen privilegierten Systemzugriff zu erlangen. Es wird die im Source File erkannte „JMP ESI“ Funktion gesucht und beschrieben wie man diese Information zu einem funktionierenden Exploit umsetzt.
Im Normalfall eines Angriffs bzw. eines Pentests müsste man das Zielsystem nachbauen und mit Hilfe eines Debuggers auf dem Testsystem die Adresse einer „JMP ESI“ Funktion ermitteln. Der Einfachheit halber wird in diesem Artikel direkt das Zielsystem für diese Analyse verwendet.
Zum Debuggen bietet sich das frei erhältliche Tool Oldybg an, welches keine Installation benötigt.
Nach dem Start des Debuggers hängen wir, wie in Abbildung 3 dargestellt ist, mit File-Open den Internet Explorer an den Debugger an. Hierfür kann nahezu jeder beliebige Prozess verwendet werden. Der angehängte Prozess läuft dadurch im Debugger ab, wodurch sich dessen Funktionsweise detailliert analysieren lässt.
read more:
Metasploit - fixing the framework | www.s3cur1ty.de
![Permalink for '[Slides] Pixels want to talk'](/themes/lilina/web//media/mark_off.gif.pagespeed.ce.FiDKaoEBZK.gif)
