Cat 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 secondsEntramos 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.
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

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