Operación Pescador: de un upload expuesto a una shell web y una escalada trivial por SUID
De un directorio de subidas expuesto a RCE por un PHP disfrazado de imagen, y de ahí a root por un bash con el bit SUID activo.
Principiante · Linux
URL del reto: labs.thehackerslabs.com/machines/149
Por qué la diseñé
Operación Pescador gira alrededor de una cadena muy concreta, una superficie web mal expuesta, un archivo subido que queda accesible desde una ruta pública y una ejecución de comandos que termina en una escalada local casi inmediata por unos permisos mal puestos. Técnicamente es sencilla, y esa es la intención, que se vea lo poco que hace falta cuando una aplicación permite ejecutar código desde una zona que nunca debió ser pública.
Si además el host arrastra un binario con SUID mal asignado, el salto a root deja de ser una escalada y pasa a ser un trámite. La monté para que esa relación entre un upload inseguro y un permiso catastrófico quedara a la vista.
La máquina de un vistazo
Expone SSH y un Apache que redirige a un host interno, mail.innovasolutions.thl, que hay que resolver a mano. La cadena arranca en una carpeta /uploads pública, sigue por un fichero PHP disfrazado de imagen que ejecuta comandos, pasa por una reverse shell como www-data y termina en un bash con el bit SUID activo que entrega root.
Cómo la monté, paso a paso
Una app que solo responde por su nombre
El Apache redirige a mail.innovasolutions.thl, así que sin añadir ese host en /etc/hosts no se llega a la aplicación. Es un detalle pequeño, pero enseña que el contexto de la petición cuenta, y que una enumeración que ataca solo por IP se queda fuera.
El directorio de subidas, abierto al público
Con gobuster aparece una carpeta /uploads accesible desde fuera. Dentro dejé un fichero que aparenta ser una imagen pero cuya extensión es .php. Ese es el fallo central, un directorio de subida expuesto con material ejecutable dentro. En cuanto alguien da con el recurso, el servidor está en juego.
El parámetro que ejecuta comandos
Al PHP disfrazado le puse un parámetro, cmd, que ejecuta comandos del sistema. Un wfuzz sobre la URL lo encuentra, y a partir de ahí hay RCE directa. No hace falta ningún bypass sofisticado. Basta con una ruta de uploads visible, un archivo ejecutable dentro y un parámetro que llama al sistema, y con eso se pierde el servidor.
Del www-data a root por un bash con SUID
Con la RCE saqué una reverse shell como www-data. Al revisar los binarios con SUID aparece el que lo rompe todo, /usr/bin/bash con el bit activo. Con eso la escalada es inmediata, /bin/bash -p conserva privilegios y entrega root. Tener bash con SUID rompe por completo el modelo de privilegios del sistema, y no necesita encadenar nada más.
Qué quería enseñar
Operación Pescador enseña una cadena muy reconocible en escenarios web mal protegidos.
| Fase | Qué enseña | Error que representa |
|---|---|---|
| Redirección a host interno | La app depende de un Host concreto | Enumeración que ignora el nombre |
| /uploads expuesta | El contenido subido queda a la vista | Directorios públicos con material ejecutable |
| PHP disfrazado de imagen | La zona de subida ejecuta | Uploads inseguros sin separación |
| Parámetro cmd | RCE directa | Web shells dejadas accesibles |
| bash con SUID | Escalada trivial a root | Permisos catastróficos sobre binarios comunes |
Lo que importa es lo poco que hace falta cuando una aplicación ejecuta código desde una zona que nunca debió ser pública y el sistema arrastra encima una configuración SUID desastrosa.