Introducción
Hola a todos, en este caso consideraba relevante comentar un hallazgo que hace poco se hizo público y me ha hecho especial ilusión y es que me han asignado un CVE.
Como contexto comentar que tengo una experiencia profesional de cinco años en el momento de escribir este post 02/05/2024 y en pentesting llevo dos años en la empresa Plexus Tech. Comento esto porque lo considero relevante a tener en cuenta, ya que descubrí esta vulnerabilidad realizando una auditoría y surgió de manera fortuita.
Descubriendo CVE-2024-4304
Como profesional de la ciberseguridad, uno de los aspectos más apasionantes de mi trabajo es la constante búsqueda de vulnerabilidades en sistemas y aplicaciones. Recientemente, mientras realizaba una auditoría en un organismo público, me encontré con un hallazgo que destacó entre los demás: un Cross Site Scripting Reflected (XSS), una vulnerabilidad bien conocida pero con consecuencias potencialmente graves si se explota correctamente.
El Cross Site Scripting (XSS) es una vulnerabilidad que permite a un atacante ejecutar scripts en el navegador de un usuario final, lo que puede llevar a la manipulación de datos, robo de sesiones, o incluso toma de control total sobre la sesión del usuario. En resumen, es una puerta trasera peligrosa en la seguridad de una aplicación web.
Durante mi auditoría, descubrí una vulnerabilidad XSS en una aplicación web utilizada por el organismo público. Al enviar ciertos datos maliciosamente diseñados a través de la URL, pude manipular el comportamiento de la página y ejecutar scripts en el navegador de los usuarios.
Lo que inicialmente parecía ser una vulnerabilidad común en varias auditorías como es XSS Reflected https://owasp.org/www-community/attacks/xss/ con criticidad media, se convirtió en un 0day puesto que el software utilizado estaba actualizado a la última versión y no se conocían vulnerabilidades adheridas.
En este sentido lo primero que hice fue comunicarme con mi equipo en Plexus y a continuación con el cliente para obtener su permiso de cara a tramitar la vulnerabilidad con el instituto nacional de ciberseguridad en España (INCIBE). Una vez obtuve el acuerdo previo contacté con INCIBE para tramitar el posible CVE.
COMUNICACIÓN
Cuando hayamos pasado estas etapas y tengamos la certeza que estamos frente a un posible CVE, es necesario comunicarlo con alguna entidad CNA como es INCIBE o MITRE. Yo opté por esta primera opción. A continuación expongo la información que requiere INCIBE para comunicar una nueva vulnerabilidad.
https://www.incibe.es/incibe-cert/sobre-incibe-cert/politica-reporte-vulnerabilidades
Una vez que hemos notificado a INCIBE en relación a una posible vulnerabilidad, nos adjuntarán una plantilla que debemos rellenar por correo electrónico como la siguiente y aplicarán a nuestro caso un número de ticket:
Plantilla a rellenar:
*********************************************************
* *
* New vulnerabilities discovery form *
* *
*********************************************************
-------------------------------------------------------------------------------------
| Section 1: Contact Information |
-------------------------------------------------------------------------------------
Applicant name:
Organization:
Email:
PGP key:
Mentions (if you prefer be anonymous fill with "anonymous"): _____ reported by Spanish National Cybersecurity Institute (INCIBE)
Ranking CVEs asignados(https://www.incibe.es/incibe-cert/alerta-temprana/vulnerabilidades/asignacion-publicacion-cve)
- ¿Quieres aparecer en el ranking?:
- Nombre completo a mostrar (2 apellidos) o pseudónimo:
Puede consultar la política de protección de datos en la siguiente página web https://www.incibe.es/incibe/proteccion-datos-personales
-------------------------------------------------------------------------------------
| Section 2: Vulnerability Information |
-------------------------------------------------------------------------------------
Vulnerability type (Check the option with *):
Cross Site Request Forgery (CSRF) | |
Cross Site Scrtipting (XSS) | |
Directory Transversal | |
Incorrect Access Control | |
Insecure Permissions | |
Integer Overflow | |
Missing SSL Certificate Validation | |
SQL Injection | |
XML External Entity (XXE) | |
Other or unknown | |
Attack type produced (Check the option with *):
Context dependent | |
Local | |
Physical | |
Remote | |
Other | |
Impact (Check the option with *):
Code Execution | |
Denial of service | |
Escalation of Privileges | |
Information Disclosure | |
Other | |
Discovery date:
Device manufacturer:
Device model:
Device version:
Affected components:
Manufacturer POC (Point of Contact):
Do you contact with the manufacturer after the communication with INCIBE?
CVSS v3.1:
CVSS vector:
CWE:
Vulnerability description:
Previous requirements:
Proof of concept:
-------------------------------------------------------------------------------------
| Section 3: Solution and Additional Information |
-------------------------------------------------------------------------------------
Proposed solution:
References:
--------------------------------------------------------------------------------------
TLP:RED
En este sentido debemos cumplimentarla lo mejor posible y volver a enviarla a INCIBE para que ellos gestionen nuestro caso.
Proof of Concept (PoC)
La vulnerabilidad residía, dentro del software utilizado por el organismo público, en un apartado para inyectar código que no se validaba correctamente y se podía llevar a cabo inyección de código JavaScript malicioso. Para ello utilicé BurpSuite tirando un diccionario con varios payloads y en el Intruder pude observar en la respuesta de la petición, un Content-Length que me hizo sospechar de que efectivamente el servidor se tragó el payload y… efectivamente.
Como consejo recordad siempre evidenciar todos los pantallazos que os encontréis en las auditorías, puesto que es la evidencia más clara de las vulnerabilidades que habéis descubierto (a veces me ha pasado que el cliente nos diga que esa vulnerabilidad no la tiene y lo que hacen es parchearla y no decir nada XD) o incluso si se tramita un posible CVE como fue este caso que te sirve como clara evidencia del mismo.
Conclusión
Una vez que la vulnerabilidad fue parcheada, mi trabajo no había terminado. Para dar a conocer esta vulnerabilidad a la comunidad de seguridad cibernética y garantizar que otros estén informados y protegidos, solicité un Identificador de Vulnerabilidad y Exposición Común (CVE por sus siglas en inglés) para documentar el 0day XSS que descubrí. Este identificador único sirve como estándar de referencia para identificar y compartir información sobre vulnerabilidades de seguridad.
El proceso de asignación de un CVE me hizo mucha ilusión y subraya la importancia de la divulgación responsable en la ciberseguridad. Al hacer público este hallazgo, contribuí a la base de conocimientos global de vulnerabilidades, lo que permite a otros profesionales de la seguridad cibernética tomar medidas para proteger sus propios sistemas y aplicaciones. El CVE fue catalogado como CVE-2024-4304:
Lo plasmé en la siguiente publicación de LinkedIn:
https://www.linkedin.com/feed/update/urn:li:activity:7190675941092655105
Finalmente y después de cuatro meses esperando se pudo publicar e INCIBE me puso en el Salón de la fama:
¡Ojalá sea el primero de muchos! ¡Muchas gracias!