Holiday

Executive summary — Holiday is a seven-link chain against a bespoke Node.js/Express booking application ("Booking Management") sitting behind a User-Agent-filtering WAF, with blacklist-based input validation at every following step. The login form hides a blind SQL injection against SQLite whose own oracle is poisoned by the WAF (it blocks the word select), forcing the boolean queries to be built without subqueries, leaning on rowid instead. Once inside, a stored XSS in the booking notes system — approved by an admin bot running PhantomJS, a browser unmaintained since 2018 that ignores the Content-Security-Policy header — becomes the vector for firing a command injection against the admin panel's export endpoint, already under the admin's authenticated session. The rest is classic lateral movement: a self-planted SSH key installed through the RCE grants access as algernon, and a misconfigured sudo rule over npm install hands over a trivial root escalation through npm's lifecycle scripts.

When a massive fuzz fails to tell any route apart from the rest, the most likely explanation isn't an empty site — it's that something is intercepting the request before it reaches the application and always answering the same way: a web application firewall, a proxy, or middleware filtering on some property of the request itself. The next logical move is to vary that property, not the paths.

Why it works: the application's middleware checks whether the User-Agent "looks like" a browser (likely a simple substring check such as contains("Mozilla")) and returns the generic 404 to any client that fails it — curl, nmap, and most scanners/fuzzers by default. This is a security-by-obscurity control (CWE-807): it authenticates nothing, it just hides the attack surface from anything that doesn't impersonate a browser. With the right UA, the real app shows up: a login form for "Booking Management", with /login, /agent and /admin routes.

Resumen ejecutivo — Holiday es una cadena de siete eslabones sobre una aplicación Node.js/Express de reservas ("Booking Management") construida a medida, protegida por un WAF que filtra por User-Agent y por una validación de entrada basada en blacklists en cada paso siguiente. El login esconde una inyección SQL ciega sobre SQLite cuyo propio oráculo está envenenado por el WAF (bloquea la palabra select), lo que obliga a construir las consultas booleanas sin subqueries, apoyándose en rowid. Una vez dentro, un XSS almacenado en el sistema de notas de reservas —aprobado por un bot administrador que corre PhantomJS, un navegador sin soporte desde 2018 que ignora la cabecera Content-Security-Policy— se convierte en el vector para disparar una command injection en el endpoint de exportación del panel de administración, ya con la sesión autenticada del admin. El resto es movimiento lateral clásico: una clave SSH propia instalada por RCE da acceso como algernon, y un sudo mal configurado sobre npm install entrega una escalada a root trivial a través de los lifecycle scripts de npm.

Cuando un fuzzing masivo no distingue ninguna ruta del resto, lo más probable no es que el sitio esté vacío, sino que algo está interceptando la petición antes de que llegue a la aplicación y respondiendo siempre igual — un firewall de aplicación web (WAF), un proxy, o un middleware que filtra por alguna característica de la petición en sí. El siguiente paso lógico es variar esa característica, no las rutas.

Por qué funciona: el middleware de la aplicación comprueba si el User-Agent "parece" un navegador (probablemente una comprobación simple de substring, tipo contains("Mozilla")) y devuelve el 404 genérico a cualquier cliente que no lo cumpla — curl, nmap, la mayoría de escáneres y fuzzers por defecto. Es un control de seguridad por oscuridad (CWE-807): no autentica nada, solo oculta la superficie de ataque a quien no imite un navegador. Con el UA correcto aparece la aplicación real: un formulario de login para "Booking Management", con rutas /login, /agent y /admin.