Popcorn

Executive summary — Popcorn is a 2009 box (Ubuntu 9.10) where reconnaissance is half the challenge: fuzzing against the IP produces dozens of false positives because Apache redirects any path to the popcorn.htb vhost with an unconditional 301. Repeating the fuzz against the correct hostname surfaces four real paths, among them Torrent Hoster, a 2007 application with open registration. Its "screenshot" upload function decides whether a file is an image by reading the Content-Type the client itself declares — lying in that header is enough to upload a PHP webshell and get code execution as www-data. With credential paths exhausted, the escalation to root comes from a kernel exploit (full-nelson, CVE-2010-4258 + CVE-2010-3849 + CVE-2010-3850) compiled directly on the target.

Dating the box from the versions. OpenSSH 5.1p1 Debian 6ubuntu2 + Apache 2.2.12 maps to Ubuntu 9.10 (Karmic Koala), from October 2009. The 1024-bit DSA host key confirms it: DSA was disabled by default in OpenSSH over a decade ago. A system this old turns a kernel exploit escalation from a last resort into a leading hypothesis — worth keeping in mind from the start, without skipping enumeration.

The mechanism. Apache is configured to redirect any request that arrives by IP to the canonical vhost popcorn.htb, before checking whether the path exists. The redirect is unconditional, so the server answers 301 to absolutely everything. Since 301 was in the fuzzer's accepted status codes, every dictionary word looked like a hit. The rule this yields: always include an invented control path in any fuzzing run. If it answers the same as the "findings", the whole result set is noise — a ten-second check that here saved chasing a WordPress install that didn't exist. Note also that response size varied (313, 316, 326…) precisely because the 301 body includes the destination URL, whose length depends on the path name, which rules out filtering by a fixed size.

An exposed phpinfo() is a gift to an attacker (CWE-200). In one line it hands over: the exact kernel version (2.6.31-14-generic-pae), the architecture (i686 — meaning the exploit must be built for 32-bit), the PHP version, absolute filesystem paths and loaded extensions. The entire kernel-exploit selection later relies on this data, obtained before any code execution.

An unauthenticated API that moves arbitrary files sounds like a top-tier vector, but it runs as www-data, the same user we'll obtain by another route. It can't write into /home/george or any root-owned path, so it grants no extra privilege. Noted as a plan B in case the upload failed, and dropped once RCE landed via the other path: flashy, functional, and useless for escalation.

Resumen ejecutivo — Popcorn es una máquina de 2009 (Ubuntu 9.10) donde el reconocimiento es la mitad del reto: fuzzear contra la IP genera decenas de falsos positivos porque Apache redirige cualquier ruta al vhost popcorn.htb con un 301 incondicional. Repitiendo el fuzzing contra el nombre correcto aparecen cuatro rutas reales, entre ellas Torrent Hoster, una aplicación de 2007 con registro abierto. Su función de subida de "captura de pantalla" decide si un fichero es una imagen leyendo el Content-Type que declara el propio cliente — basta con mentir en esa cabecera para subir una webshell PHP y obtener ejecución de código como www-data. Con las vías de credenciales agotadas, la escalada a root llega por un exploit de kernel (full-nelson, CVE-2010-4258 + CVE-2010-3849 + CVE-2010-3850) compilado directamente en el objetivo.

Datar el sistema por las versiones. OpenSSH 5.1p1 Debian 6ubuntu2 + Apache 2.2.12 corresponde a Ubuntu 9.10 (Karmic Koala), de octubre de 2009. Y la clave de host DSA de 1024 bits lo confirma: DSA quedó desactivado por defecto en OpenSSH hace más de una década. Un sistema de esa antigüedad hace que la escalada por exploit de kernel pase de ser un último recurso a una hipótesis principal — conviene tenerlo en mente desde el inicio, pero sin saltarse la enumeración.

El mecanismo. Apache está configurado para redirigir cualquier petición que llegue por IP hacia el vhost canónico popcorn.htb, antes de comprobar si la ruta existe. La redirección es incondicional, así que el servidor responde 301 a absolutamente todo. Como 301 estaba en la lista de códigos aceptados del fuzzer, cada palabra del diccionario parecía un acierto. La regla que se deriva: en todo fuzzing, incluir una ruta de control inventada. Si responde igual que los "hallazgos", el resultado completo es ruido — una comprobación de diez segundos que aquí ahorró perseguir un WordPress inexistente. Nótese además que el tamaño de respuesta variaba (313, 316, 326…) precisamente porque el cuerpo del 301 incluye la URL de destino, cuya longitud depende del nombre de la ruta, lo que impide filtrar por tamaño fijo.

Un phpinfo() expuesto es un regalo para el atacante (CWE-200). En una línea entrega: la versión exacta del kernel (2.6.31-14-generic-pae), la arquitectura (i686 — hay que compilar a 32 bits), la versión de PHP, las rutas absolutas del sistema de ficheros y las extensiones cargadas. Toda la selección del exploit de kernel se apoya en este dato, obtenido antes de tener ninguna ejecución de código.

Una API sin autenticar que mueve ficheros arbitrarios suena a vector de primer orden, pero corre como www-data, el mismo usuario que obtendremos por otra vía. No permite escribir en /home/george ni en rutas de root, así que no aporta privilegios adicionales. Se anotó como plan B por si la subida fallaba y se descartó tras conseguir el RCE: llamativa, funcional, e inútil para escalar.