En este writeup vamos a resolver la máquina Fing de dificultad Low de VulNyx.
Estructura del contenido
TL;DR – RESUMEN DE LA MÁQUINA FING (VULNYX)
Te resumo a continuación la resolución de la máquina pero si quieres ver el detalle, te invito a leer el resto del write-up:
| Comenzamos realizando reconocimiento de la máquina objetivo mediante escaneo de puertos con Nmap, detectando el servicio Finger (puerto 79) junto con SSH (22) y Apache (80). Aprovechamos el servicio Finger para realizar enumeración de usuarios mediante fuerza bruta contra diccionarios, logrando identificar el usuario válido adam. Posteriormente ejecutamos un ataque de fuerza bruta con Hydra contra el servicio SSH utilizando el usuario descubierto, obteniendo acceso inicial a la máquina víctima como adam. Una vez dentro del sistema realizamos enumeración de privilegios buscando binarios SUID y configuraciones especiales, detectando la presencia del binario doas, menos habitual que sudo. Finalmente comprobamos el archivo /etc/doas.conf, donde observamos que el usuario adam podía ejecutar el binario find como root sin contraseña. Aprovechando este permiso mal configurado y la técnica documentada en GTFOBins, ejecutamos una shell privilegiada mediante find -exec, escalando privilegios a root y accediendo a la root flag con éxito. |
Resumen de conceptos trabajados
- Enumeración de servicios con Nmap.
- Descubrimiento de usuarios servicio Finger mediante fuerza bruta con diccionarios.
- Ataque de fuerza bruta SSH con Hydra.
- Enumeración local de privilegios en binarios SUID.
- Escalada de privilegios a root con GTFOBins.
Si es tu primera máquina de VulNyx y no sabes cómo conectarte a la máquina del laboratorio, te recomiendo que visites este post donde te cuento paso a paso cómo empezar en esta plataforma.
Cómo Verificar que estamos conectados a la máquina víctima
Lo primero que tendrás que hacer cuando vayas a trabajar sobre alguna de las máquinas de VulNyx, es descargarla en tu equipo. Una vez descargada y descomprimida, irás a tu VMWare o VirtualBox y la importarás para virtualizarla.
Después de importarla, configura la conexión de red a Adaptador Puente, para que nuestra máquina atacante tenga acceso y la encuentre.
Comenzando con el reconocimiento de la máquina víctima
Iniciamos sesión siendo root y creamos previamente una nueva carpeta dentro de nuestro Kali para esta máquina y poder crear allí todo lo que analicemos.
Para asegurarnos de que la máquina víctima está conectada en la red (192.168.1.144)
arp-scan -I eth0 --localnet
y de esta forma vemos todas las IPs conectadas para empezar a analizarla (podemos comprobar que se encuentra la IP de la máquina VulNyx cuando la ejecutamos anteriormente). Vemos que la IP «is up» está activa y su ttl es de 64, es decir, SO Linux.
Fase de Enumeración / Escaneo de Puertos
Comenzamos el análisis con la fase de enumeración y escaneo de puertos mediante el comando:
nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn 192.168.1.144 -oG Escaneo_TCP
Ya en el escaneo encontramos los puertos 22 ssh de autenticación, el puerto 79 finger (¿relacionado con la máquina?) y el típico puerto 80 http donde probablemente se aloje el recurso web.
Ahora con nmap vamos a analizar un poco más en detalle cuáles son los servicios y versiones que corren para esos tres puertos abiertos.
nmap -sCV -p22,79,80 192.168.1.144
Descubrimiento de usuarios servicio Finger
Lo más relevante es ese puerto 79 donde corre un servicio llamado «finger», que:
El servicio finger es un protocolo que proporciona información de los usuarios de una máquina, estén o no conectados en el momento de acceder al servicio.
Por lo que si ejecutamos el siguiente comando podría salirnos información de usuarios del sistema…aunque ya en la respuesta del escaneo con nmap nos dice «No one logged on. x0D» por lo que no hay usuarios conectado ahora mismo aunque el servicio está activo.
Si probamos con usuarios típicos por defecto como root, admin o user, vemos que el que sí existe es el root, pero eso no significa que sea un usuario a probar en el ssh para acceder. Otros típicos como admin o user me dicen que no, pero lo ideal sería probar fuerza bruta contra un diccionario de usuarios para ver si hay respuesta existosa.
La forma de aplicar fuerza bruta usando un diccionario de usuario grande y realista como este de Seclists sería mediante este comando:
for user in $(cat /usr/share/seclists/Usernames/Names/names.txt); do
finger $user@192.168.1.144 2>/dev/null | grep Login
done
Nos saca el usuario «adam» que ya podríamos probar haciendo un ataque con Hydra para conseguir una potencial contraseña contra la que entrar por el puerto 22 abierto.
De hecho si lo comprobamos con finger vemos que está activo:
Como vimos la inicio, el puerto 80 web está abierto, pero si lo revisas solo verás una página de Apache por defecto sin más información, e incluso he realizado fuzzing con distintas herramientas buscando directorios, extensiones, archivos y subdominios, pero no encontró nada.
Ataque de fuerza bruta con Hydra
Por lo que vamos a hacer de nuevo fuerza bruta en Hydra usando el diccionario rockyou.txt de contraseñas contra el usuario «adam» para ver si nos detecta la password a usar por ssh.
Tras unos minutos, nos devuelve la contraseña «passion» por lo que la probamos por ssh.
ssh adam@192.168.1.144Y estamos dentro como el usuario adam, visualizando la primera user flag:
El siguiente y último paso es ganar acceso a la máquina como el usuario root.
Enumeración de privilegios en binarios SUID
Tras obtener acceso como el usuario adam, procedemos a revisar posibles vectores de escalada de privilegios.
Para ello lo que suelo hacer primero es ir al directorio /home para ver si hay más usuarios con más permisos de root que podamos pivotar, pero en este caso sólo existe el usuario «adam».
Lo siguiente es comprobar si tiene permisos de administrador o privilegios de root sin contraseña a binarios internos de la máquina mediante el comando «sudo -l», pero nos devuelve «permisos denegados».
Así que el siguiente paso es enumerar binarios SUID ejecutables como root mediante el comando:
find / -perm -4000 2>/dev/null
Del listado, me llama la atención el binario «doas» que no es habitual encontrarlo.
Escalada de privilegios a root con GTFObins
Si revisamos la configuración de ese binario con el comando «cat /etc/doas.conf», nos dice que el usuario adam puede ejecutar /usr/bin/find como root sin contraseña. Y sabemos que find es un binario explotable vía GTFOBins.
Si vamos por tanto a GTFObins: https://gtfobins.linuxsec.org/gtfobins/find/#suid y consultamos por SUID la forma de escalar privilegios de root, vemos este comando que si lo probamos en la terminal, nos devuelve root:
Lo único que habría que hacer esta pequeña adaptación porque escalamos con find + doas
doas /usr/bin/find . -exec /bin/bash \; -quitY ya seríamos root y podríamos consultar la root flag.
