Injection

Injection es una máquina de la plataforma DockerLabs con dificultad Fácil, basada en Linux Debian. Expone SSH en el puerto 22 y un servidor web Apache con una aplicación PHP en el puerto 80.

Esta máquina introduce una vulnerabilidad web clásica y una de las más prevalentes en la industria: la SQL Injection (SQLi). El objetivo es explotar un formulario de login vulnerable para obtener credenciales, acceder al sistema via SSH y escalar privilegios mediante un binario con el bit SUID mal configurado.

Desplegamos la máquina con auto_deploy.sh. El script levanta el contenedor, configura la red interna injection_net, levanta un proxy web en localhost:8080 → 172.20.0.3:80 y nos sitúa dentro del entorno kali-pentesting. IP asignada: 172.20.0.3.

Lanzamos Nmap con scripts NSE (-sC). Resultado: SSH en el 22 y HTTP en el 80 con Apache. Nmap detecta además una cookie PHPSESSID sin el flag httponly — indicador de que hay una aplicación PHP con gestión de sesiones, y que la cookie podría ser robada via XSS. El título HTTP muestra "Iniciar Sesión" — hay un panel de login en el puerto 80.

Aplicamos fuzzing con Gobuster para descubrir recursos ocultos. Encontramos dos archivos PHP: index.php (Status 200, Size 2921) — el panel de login principal — y config.php (Status 200, Size 0) — archivo de configuración accesible pero que devuelve respuesta vacía, probablemente contiene credenciales de base de datos hardcodeadas aunque el servidor no las renderiza directamente.

El formulario de login en index.php construye una query SQL con los datos introducidos por el usuario sin sanitizarlos. Probamos un payload clásico de SQL Injection para bypassear la autenticación:

— User: admin
— Password: ' or '1'='1

El payload cierra la cadena de la contraseña con ', añade la condición OR '1'='1' que siempre es verdadera, y hace que la query devuelva el primer usuario de la base de datos independientemente de la contraseña real. El servidor responde revelando el nombre del usuario y su contraseña en texto claro: Dylan / KJSDFG789FGSDF78.

Con las credenciales obtenidas de la SQLi, nos conectamos por SSH como dylan. El servidor emite el aviso habitual de OpenSSH moderno sobre algoritmos post-cuánticos — es informativo, no bloquea la conexión. Obtenemos shell como dylan.

Primer paso tras obtener acceso: sudo -l. El sistema responde "sudo: command not found" — sudo ni siquiera está instalado en este sistema. Vector cerrado.

Pasamos al segundo vector: búsqueda de binarios con el bit SUID activado. El comando find / -perm -4000 lista todos los ejecutables que corren con los privilegios de su propietario (normalmente root). Entre los resultados destaca /usr/bin/env — un binario que normalmente no debería tener SUID.

Consultamos GTFOBins para la entrada de env en la sección SUID — a diferencia de las máquinas anteriores donde usamos la sección Sudo, aquí el vector es el bit SUID. GTFOBins documenta que env con SUID puede escalar privilegios ejecutando env /bin/sh -p. El flag -p es crítico: indica a /bin/sh que no descarte los privilegios efectivos heredados del binario SUID, manteniendo el uid efectivo de root.

Ejecutamos el comando de GTFOBins. env corre con SUID de root, lanza /bin/sh -p que preserva el uid efectivo de root. Obtenemos shell como root. Verificamos con whoami.

Injection introduce la vulnerabilidad web más conocida del mundo — la SQL Injection. Un simple payload de una línea bypasea completamente la autenticación y expone credenciales reales del sistema. La lección más importante: nunca confiar en el input del usuario sin sanitizar. El segundo aprendizaje es la diferencia entre los vectores de escalada — aquí no hay sudo, lo que obliga a buscar binarios SUID. env con SUID es un error de configuración grave y evitable: en un sistema bien securizado, los únicos binarios con SUID deben ser los estrictamente necesarios (passwd, su, mount).