Máquina ICA:1 - VulnHub (OSCP Style)
Introducción
La máquina se encuentra en la plataforma VulnHub y figura con una dificultad fácil. Se trata de una máquina temática en la que debemos descubrir el proyecto secreto en el que está trabajando ICA. Esta máquina se descarga y se tiene que correr desde VirtualBox, nada de desplegarla de una plataforma.
Fue durante la resolución de esta máquina que mi Kali murió, así que iniciaremos con capturas de pantalla del sistema anterior y posteriormente cambiarán por las de mi nuevo Kali.
Despliegue
Primero iniciamos la máquina desde VirtualBox. Para esto, descargamos la máquina desde la plataforma y en VirtualBox seleccionamos Archivo -> Importar servicio virtualizado.
Esta ya está configurada para iniciar y tomar una IP por DHCP de manera automática.
Reconocimiento
Por medio de un escaneo de puertos con nmap, detectamos aquellos que se encuentren activos con un estatus open en la máquina víctima:
nmap -p- --open -T5 -Pn -n 192.168.0.28 -oG allPorts
Vemos que se encuentran habilitados los servicios de SSH, HTTP y MySQL.
Cabe mencionar que olvidé realizar el escaneo exhaustivo en busca de versiones con nmap, sin embargo, la máquina es bastante sencilla que no lo requerimos; pero es algo que no debe pasar.
Servicio HTTP
Si entramos al sitio web veremos un panel de logueo de un software llamado qdPM versión 9.2.
Buscando por una vulnerabilidad, nos encontramos con que cuenta con un password exposure, es decir, filtración de contraseñas para la base de datos (recordemos que el puerto de MySQL está habilitado).
Su explotación es de lo más sencilla y se basa en simplemente acceder a una dirección específica del servidio web.
http://192.168.0.28/core/config/databases.yml
Procedemos a descargarlo desde curl:
Este archivo muestra el usuario y contraseña para la base de datos (y sí, en texto claro).
Enumeración MySQL
Para acceder a MySQL de manera remota podemos valernos de la herramienta del mismo nombre:
mysql -u qdpmadmin -h 192.168.0.28 -p
Con esto le indicamos a la herramienta el usuario, el hosto remoto y que vamos a autenticarnos con una contraseña, la cual nos pedirá en cuanto ejecutemos el comando.
Como podemos ver, las credenciales son válidas y ahora podemos enumerar las bases de datos en busca de más credenciales para poder acceder al sistema. Para ello, primero listamos las bases de datos:
show databases;
La base de datos de nombre staff parece tener información sobre el personal de la empresa, por lo que podemos suponer que contiene credenciales en su interior. Para trabajar con ella, empleamos la instrucción:
use staff;
Posteriormente, podemos listar las tablas con las que cuenta la base de datos en busca de información de interés:
show tables;
Vamos a enumerar el contenido tanto de la tabla login como de user. Para ello, solo debemos ejecutar la instrucción:
select * from login;
Esta tabla contiene contraseñas y las identifica por un id de usuario a cada una. Sin embargo, no tenemos usernames. Para ello, enumeramos la tabla faltante:
select * from user;
Esta tabla nos devuelve un listado de usuarios, y ya con estos, podemos crear un pequeño diccionario que incluya tanto el nombre como aparece en la base de datos, como el mismo nombre pero en minúsculas (recordemos que generalmente los nombres de usuario son solo en minúsculas, así que cubrimos esa posibilidad).
Por otro lado, creamos un diccionario con las contraseñas que encontramos:
Estas están codificadas en base64, y lo delata el símbolo de igual (=) al final de cada una. Para descifrarlas, lo pasamos por la siguiente instrucción en bash:
while read p; do echo $p | base64 -d;echo; done<passwords
Esta instrucción nos devolverá las contraseñas ya descifradas, así que las guardamos en un diccionario que usaremos con el listado de usuarios en un ataque de fuerza bruta en busca de credenciales válidas.
Fuerza bruta a SSH
Dado que solo nos resta un servicio por analizar en la máquina, probamos el ataque de fuerza bruta contra SSH en busca de credenciales válidas. Para ello, empleamos la herramienta Hydra.
hydra -L usuarios -P b64_passwords ssh://192.168.0.28 -f
Con esto le indicamos a Hydra que emplee como usuario de entrada cada renglón del archivo usuarios, lo mismo para las contraseñas y que ataque el servicio SSH del servidor remoto.
Como podemos ver, el ataque es exitoso y nos devuelve credenciales válidas para el usuario travis. Recordemos que la herramienta se detiene cuando encuentra credenciales válidas, por lo que siempre vale la pena intentar nuevamente con las entradas restantes (como buena práctica, y solo cuando sea posible editar el diccionario; es decir, que no sea demasiado grande). En este caso, solo dejamos los usuarios restantes después de travis y volvemos a correr la herramienta; veremos que podemos obtener otro usuario válido:
Primero intentemos acceder a la máquina con las credenciales del usuario travis.
SSH
Vemos que las credenciales obtenidas son correctas, logrando acceder a la máquina remota con una consola estable como solo SSH lo puede ofrecer. Listamos la flag de usuario para evidenciar el acceso:
Escalada de privilegios
Es hora de enumerar el sistema en busca de posibles vectores de ataque para escalar privilegios. Primero, intentamos listar posibles permisos sudo que tenga nuestro usuario:
Vemos que travis no tiene permitido la ejecución de sudo en el sistema, por lo que proseguimos. Listamos ahora binarios con permisos SUID:
find / -perm -u=s 2>/dev/null
Dentro del listado veremos un binario que no es típico de un sistema Linux, el cual se llama get_access. Si lo ejecutamos veremos la siguiente salida:
Al parecer lista un par de datos sobre la máquina. Como vimos en máquinas anteriores, si un binario es llamado de manera relativa y no absoluta, puede generar una vulnerabilidad de la que nos podemos aprovechar por medio de un Path Hijacking; sobre todo cuando se trata de un binario SUID, ya que al ser ejecutado, realizará la acción que le indiquemos como el usuario privilegiado. Para corroborar esto, mostramos las strings del binario:
strings /opt/get_access
Como podemos observar, la herramienta ejecuta aparte el binario cat, y este es llamado de manera relativa sin la ruta absoluta; el candidato perfecto para un Path Hijacking. Este proceso ya lo hemos explicado con anterioridad, así que solo seguimos el procedimiento. Primero creamos nuestro propio cat que llevará a cabo, adivinaste, un cambio de permisos SUID a la bash (prometo cambiar esto para la siguiente máquina para intentar nuevos enfoques).
Por último, solo modificamos el PATH para que incluya nuestro directorio con el cat “malicioso”.
Y listo, solo necesitamos ejecutar el binario SUID. Veremos que ya no muestra el contenido que vimos con anterioridad, por lo que podemos suponer que la herramienta se ejecutó como queríamos. Lo comprobamos con un vistazo a los permisos de la bash, viendo que ahora son SUID.
Solo nos resta ejecutar la bash con la bandera -p para obtener una consola como el usuario administrador, habiendo comprometido la máquina correctamente.
Cabe destacar que si intentamos ver la flag de root, debemos recordar que ahora cat no funciona, ya que siempre estará llamando a nuestro cat personalizado. Para poder emplear el cat de siempre, deberemos llamarlo de manera absoluta:
/bin/cat root.txt
