RECONOCIMIENTO

Para comenzar, vamos a realizar un escaneo de puertos abiertos en la máquina víctima mediante la herramienta nmap. Observamos en el output del comando que existen 3 puertos expuestos:

nmap --open -p- -sS --min-rate 5000 -vvv -n -Pn -oG allPorts 10.10.10.79
nmap -sCV -p22,80,443 -oN targeted 10.10.10.79

Observamos que tenemos expuesto el servicio SSH, en una versión bastante desactualizada, el cual podriamos aprovechar a lo largo de la intrusión si conseguimos credenciales válidas. De momento no nos va a servir de mucho mas.

Por otro lado tenemos dos servicios web expuestos, uno por HTTP y otro por HTTPS. Nos está mostrando nmap gracias a los script de enumeración lanzamos el nombre de dominio, el cual vamos a introducir a nuestro archivo de hosts local.

echo '10.10.10.79 valentine.htb' >> /etc/hosts

Si realizamos una petición a ambos puertos, parece que se nos muestra lo mismo, sin ninguna diferencia, unicamente una imagen que carga desde un directorio de la web.

Para hacer un reconocimiento más exhaustivo, ya que tenemos el puerto 443 expuesto, vamos a inspeccionar el certificado y lanzar una serie de script específicos para ese puerto.

nmap --script "Vuln and Safe" -p443 -oN scriptScan 10.10.10.79

Viendo el output, podemos observar que el servidor parece vulnerable a HeartBleed.

HeartBleed es un agujero de seguridad de software en la biblioteca de código abierto OpenSSL, solo vulnerable en su versión 1.0.1f, que permite a un atacante leer la memoria de un servidor o un cliente, permitiéndole por ejemplo, conseguir las claves privadas SSL de un servidor

Wikipedia

EXPLOTACIÓN

Para su explotación, vamos a utilizar un script en Python3 de Github que nos va a permitir extraer información de la memoria del servidor. Para ello nos lo vamos a traer a nuestra máquina y vamos a tener que ejecutarlo unas cuantas veces.

wget https://gist.github.com/akshatmittal/10279360
python3 heartbleed.py 10.10.10.79 | grep -v "00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00"

Llegará un momento que vamos a tener acceso a una variable codificada en base64. Vamos a copiarnosla y decodearla, así tendremos lo que aparentemente puede ser una contraseña.

Nos la vamos a guardar y vamos a proceder a enumerar un poco más a fondo el servidor web.

Fuzzing Web

Vamos a proceder a realizar un ataque de fuzzing al servidor web para la enumeración de directorios. Para ello vamos a utilizar la herramienta gobuster.

gobuster dir -u http://valentine.htb -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-big.txt -t 200 -r --no-error -o ../content/gobuster.txt

SI visitamos el primer directorio, /dev, observamos dos archivos de texto.

Tenemos un archivo llamado hype_key. Nos lo vamos a traer a nuestra máquina local y lo vamos a decodificar, ya que está en hexadecimal.

curl -s -X GET 'http://10.10.10.79/dev/hype_key' | xxd -r -p > hype_key

Vemos que se trata aparentemente de la clave privada del usuario Hype. Pero está cifrada. Si recordamos, debido a la vulnerabilidad HeartBleed habiamos obtenido una contraseña. Vamos a utilizarla para desencriptar la clave privada mediante la herramienta openssl.

openssl rsa -in hype_key -out hype_key.decripted

Teniendo ya la clave privada desencriptada, vamos a asignarle los privilegios adecuados (chmod 600 hype_key.decripted) y vamos a intentar conectarnos como el usuario Hype a la máquina víctima.

ssh -i hype_key.decripted hype@10.10.10.79

Cabe destacar, que por la antigüedad de la máquina y del cifrado de las claves, al principio me dio un error de autenticación. Buscando en Internet, la solución que se encontró fue incluir las siguientes dos lineas en el archivo de configuracion de SSH.

Ya tenemos acceso como el usuario Hype en la máquina víctima.

ESCALADA DE PRIVILEGIOS

Enumerando los procesos de la máquina y el directorio del usuario, vemos varias trazas y signos de sesiones de tmux.

Vemos que se ha creado un directorio socket donde luego se ha asociado la sesión de tmux. Si observamos los permisos de este directorio, vemos que pertenecemos al grupo asignado y tenemos permisos de escritura y de lectura. Vamos a aprovecharnos de ellos, para reutilizar esa sesión de tmux, que como hemos visto en los procesos, parece que es ROOT quien lo está ejecutando.

tmux -S /.devs/dev_sess

Ya tenemos una terminal como el usuario ROOT, y podemos ver las flags de ambos usuarios.