¿Por qué nosotros?

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= 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 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

Análisis Rápido: XSS en Wayback Machine CVE-2025-58765

 Introspecto r es un framework ofensivo diseñado para analizar y explotar comportamientos HTTP avanzados que ocurren “fuera” de la respuesta inmediata desde el servidor web (OOB - out of band). Más allá de un simple request/response, el objetivo es reconstruir la ruta de ejecución completa de un payload incluyendo patrones de redirección, resoluciones DNS, ejecución de solicitudes encadenadas y seguimiento de recursos servidos por el backend. En escenarios reales, muchas vulnerabilidades críticas no se manifiestan en el HTML de salida (response), sino en la infraestructura intermedia y el comportamiento del backend: balanceadores, reverse proxies, WAFs, CDN, resolvers DNS, caches, microservicios internos y clientes HTTP automatizados . Introspector está diseñado para capturar ese “lado invisible” del flujo, registrando redirecciones, reintentos, resoluciones DNS, follow-ups automáticos, y solicitudes encadenadas que pueden ocurrir segundos después y en hosts completamente distintos. Fue creada por el equipo de research de DeepSecurity específicamente para ir más allá de Burp Collaborator , permitiendo observar no solo si existe interacción OOB, sino cómo ocurre , qué componente la dispara, qué endpoint exacto la origina y qué cadena de ejecución se activa después (DNS, redirects, retries, fetches secundarios, etc.). En la práctica, Introspector ha sido utilizado tanto en proyectos con clientes como en iniciativas de research y bug bounty , sirviendo como base para hallazgos reales y reportes públicos, incluyendo Blind SSRF en Microsoft Ads , Host Header Injection + DoS en Microsoft , y vulnerabilidades CVE 2025 - 2026 reportadas responsablemente a plataformas como GlassFish y Payara . ¿Por qué usar Introspector en un pentest avanzado? Este tipo de visibilidad es clave para explotar y validar vulnerabilidades modernas como: SSRF (incluyendo SSRF ciego y SSRF con pivot a redes internas) Host Header Injection (en especial cuando la app construye URLs absolutas para resets de password, links de verificación, callbacks, etc.) Comportamientos anómalos en balanceadores / proxies (reescritura de Host, X-Forwarded-Host, X-Forwarded-Proto, Forwarded) HTTP Request Smuggling (cuando el front-end y back-end interpretan distinto Content-Length / Transfer-Encoding) Vulnerabilidades HTTP basadas en headers (cache poisoning, routing inconsistencies, internal URL generation, open redirect indirecto)