UpDown

Executive summary — UpDown doesn't fall to a single vulnerability, but to the combination of four controls that, individually, almost work: an extension blacklist on file upload, an LFI that forces a .php suffix, a deletion of the uploaded file at the end of the request, and a disable_functions list that blocks the whole system/exec family. An exposed .git repository hands over the source code and a secret header that unlocks the dev vhost; the phar:// wrapper defeats both the extension blacklist and the include() restriction at once; and the site-checker loop itself turns the file deletion into a ~270-second window the attacker controls through the content of their own payload. disable_functions forgets proc_open, giving RCE as www-data. From there, a SUID binary that calls Python 2 — where input() is eval() — escalates to developer, and a sudo NOPASSWD over easy_install (which by design runs the setup.py of any package) closes the chain as root.

Resumen ejecutivo — UpDown no cae por una vulnerabilidad aislada, sino por la combinación de cuatro controles que, por separado, casi funcionan: una blacklist de extensiones en la subida de ficheros, un LFI que fuerza el sufijo .php, un borrado del fichero subido al terminar la petición y un disable_functions que bloquea toda la familia system/exec. Un repositorio .git expuesto entrega el código fuente y una cabecera secreta que abre el vhost de desarrollo; el wrapper phar:// anula a la vez la blacklist de extensiones y la restricción del include(); y el propio bucle de comprobación de sitios convierte el borrado del fichero en una ventana de ~270 segundos que el atacante controla con el contenido de su propio payload. disable_functions olvida proc_open, lo que da RCE como www-data. De ahí, un binario SUID que invoca Python 2 —donde input() es eval()— escala a developer, y un sudo NOPASSWD sobre easy_install (que ejecuta por diseño el setup.py de cualquier paquete) cierra la cadena en root.