cubeCat robo de cookies

┌──(lass㉿lass)-[~/hackthebox/GitHack/cat.htb]
└─$ nmap 10.10.11.53
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-02-06 21:34 -05
Nmap scan report for cat.htb (10.10.11.53)
Host is up (1.0s latency).
Not shown: 998 closed tcp ports (reset)
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 5.18 seconds

Entramos al puerto 80

Comprobación de cookies

Incluso antes de iniciar sesión, notamos que la aplicación asigna cookies a nuestra sesión:

Enumeración de subdominios y directorios

Mientras tanto, buscamos subdominios pero no encontramos nada significativo. A continuación, realizamos la enumeración de directorios utilizando dirsearchuna lista de palabras predeterminada:

Durante la enumeración, descubrimos un directorio .git :

Extrayendo el repositorio .git

Para aprovechar esto, utilizamos una herramienta llamada git-dumper , que ayuda a automatizar la extracción de .gitrepositorios. Esta herramienta verifica si el listado de directorios está habilitado y descarga recursivamente el .gitcontenido para su posterior análisis.

chevron-rightGit-dumper hashtag

1. Crear y activar un entorno virtual (venv)


2. Instalar git-dumper


3. Clonar y usar GitTools (opcional)


4. Ejemplo de uso

Descargar un repositorio .git expuesto:

Revisión del código fuente extraído:

Después de extraer el .gitdirectorio, ahora tenemos acceso a una gran parte del código fuente. Esto nos permite comprender mejor la estructura de la aplicación y sus posibles vulnerabilidades.

Con esta información podemos proceder a analizar el código fuente e identificar debilidades explotables.


Identificación de vulnerabilidades

1. XSS almacenado en el registro (join.php)

Al revisar join.php, notamos que una entrada de usuario no saneada se almacena directamente en la base de datos durante el registro:

En este caso, los campos usernamey no se desinfectan ni se validan antes de almacenarlos en la base de datos, lo que permite que un atacante inyecte cargas útiles XSS almacenadas .email

Ejemplo de ataque:

Un atacante podría registrarse con el siguiente nombre de usuario:

Dado que la entrada se almacena en la base de datos sin desinfección, cada vez que se muestra este nombre de usuario, se ejecuta el script malicioso, robando potencialmente cookies de otros usuarios.

Esto podría aprovecharse para secuestrar sesiones o realizar otros ataques dentro de la aplicación.


2. Inyección SQL en accept_cat.php

Analizando accept_cat.php, encontramos otra vulnerabilidad importante: Inyección SQL debido a la entrada directa del usuario en consultas SQL.

He aquí por qué esto es peligroso:

  • $cat_nameno se desinfecta antes de usarse en la consulta SQL.

  • Se utiliza la concatenación de cadenas , lo que la hace propensa a ataques de inyección SQL.

  • exec()se utiliza en lugar de declaraciones preparadas , dejando la aplicación expuesta.

Ejemplo de ataque:

Un atacante podría enviar una solicitud POST con:

Esto daría como resultado la siguiente ejecución de consulta SQL:

Si se ejecuta, esto eliminaría toda la accepted_catstabla , causando una pérdida importante de datos.


Pero aquí, para explotar esto, necesitamos obtener acceso al usuario Axel .

Eso es un problema, así que intentemos obtener acceso a Axel (tal vez robando cookies a través del XSS almacenado que encontramos).

Pero ¿cómo vamos a hacer que Axel vea nuestro nombre de usuario para que pueda verlo?

Cuando lo revisé contest.php, pudimos ver que Axel es el administrador.

Al explorar el admin.php, se verifica si el usuario es Axel.

Más adelante, si vamos más allá, podremos ver que él es el tipo que puede aceptar o rechazar el gato que presentamos para el concurso.

Cuando el administrador revisa, nuestra carga útil se muestra debido a esta línea:


Básicamente, este es el flujo. ¡Ahora, ejecutémoslo!

Utilicé una carga útil básica ya que no es necesario omitir nada:

No olvides iniciar el servidor web:

Después de unos segundos, recibimos una cookie para el administrador: Axel

Vamos a usarlo. Ahora podemos ver el panel de administración

Vamos a intentar descifrar cada uno de ellos. En el caso de Rosa, se descifró el hash de la contraseña.

Entramos como rosa por ssh

Todos los usuarios

Hay un total de 4 usuarios en la máquina.

Después de un tiempo, al verificar el registro de Apache, podemos encontrar las credenciales de inicio de sesión del usuario Axel:

Al navegar por la máquina no encontré nada para rootear. Al verificar /var/mail/axel, podemos ver el correo.

Miramos los puertos corriendo:

Podemos usar chisel o proxychains en esta ocasion use proxy:

Si ves la parte inferior de la página, hay un número de versión.

¡Quizás busquemos algún CVE! Porque no hay repositorios ni nada.

Aquí se almacena xss, ahora si recuerdan lo del correo... las cosas empezaron a coincidir.

También tenga en cuenta en el correo que Rosa mencionó

Bien ahora iniciamos sesion como axel en el panel:

Last updated