Cómo se reporta una vulnerabilidad en un software de manera segura

Los proveedores de software deben habilitar canales para incentivar que se reporten vulnerabilidades y se puedan mitigar antes de que sean explotadas.

Todos los días se dan a conocer públicamente cientos de vulnerabilidades que afectan a software, dispositivos, sistemas operativos o redes. Tal es así que en 2024 se volvió a batir el récord de vulnerabilidades descubiertas: más de 40.000, frente a las 29.000 de 2023, según los datos recogidos por CVEdetails.

¿Cómo es el proceso de descubrimiento de una vulnerabilidad? Puede ser interno o externo. En el primer caso, el desarrollador de un software o de un dispositivo detecta una vulnerabilidad presente en él gracias a servicios de ciberseguridad como auditorías de seguridad, pentests o ejercicios de Red Team. En el segundo caso, analistas de seguridad ajenos a la organización llevan a cabo el reporte de una vulnerabilidad que han identificado de forma directa o a través de programas de recompensa, cada vez más presentes en todas las compañías.

A continuación, vamos a explicarte cómo se reporta una vulnerabilidad en un software de una forma segura y eficaz para contribuir a que se pueda mitigar antes de que sea explotada.

1. ¿A quién se debe reportar una vulnerabilidad?

Una vez que un analista, o cualquier otra persona, detecta una debilidad en un software debe realizar el reporte de la vulnerabilidad comunicándoselo a:

• El proveedor del software en que se identificó la vulnerabilidad para que tome las medidas necesarias de cara a solventar la vulnerabilidad, por ejemplo, diseñando y lanzando un parche de seguridad. Muchas compañías disponen, hoy en día, de programas Bug Bounty para incentivar que analistas de ciberseguridad empleen su talento para detectar y reportar vulnerabilidades de una manera segura y ofrecer una recompensa por el trabajo y la ayuda brindada a mejorar la seguridad. En caso de que una organización no cuente con un programa de recompensas, debe ofrecer la información de contacto necesaria para que los usuarios o investigadores independientes puedan reportar una vulnerabilidad adecuadamente.
• En caso de que no se pueda contactar con el proveedor o se detecte una actitud dilatoria por parte de éste al mitigar una vulnerabilidad, se puede acudir a organismos públicos como los CERT. Por ejemplo, en España, el INCIBE-CERT dispone de una política de divulgación coordinada de vulnerabilidades, conocida popularmente como CVD por sus siglas en inglés.

¿A quién no se debe reportar una vulnerabilidad detectada? A terceras personas, ya que podrían emplear la información para llevar a cabo su explotación antes de que se hubiese remediado el problema.

Igualmente, los expertos en ciberseguridad recuerdan encarecidamente que no se debe hacer pública una vulnerabilidad en un software sin informar al proveedor o a un organismo público, ¿por qué? Una vez que una vulnerabilidad es pública, los actores maliciosos pueden acceder a toda la información sobre ella para desarrollar pruebas de concepto y llevar a cabo ataques de vulnerabilidades de día cero.

El uso de canales de comunicación cifrados, como PGP o reportes a través de páginas seguras es fundamental para que esta información tan crítica no caiga en malas manos.

2. ¿Qué maneras de reportar una vulnerabilidad existen?

El reporte de una vulnerabilidad puede realizarse de manera confidencial tanto si se informa al proveedor del software afectado como a un organismo público. Asimismo, los analistas de seguridad que deseen realizar el reporte de una vulnerabilidad disponen de tres grandes modelos para hacerlo:

1. El reporte privado. En estos casos, los investigadores deciden informar por canales privados a los proveedores de software y dejar en sus manos la publicación de los detalles de las vulnerabilidades. Los programas de Bug Bounty exigen a los analistas de seguridad emplear este modelo si desean recibir las recompensas ofertadas.
2. Divulgación completa y pública de la vulnerabilidad. Esta es una vía extrema para reportar una vulnerabilidad porque, como señalamos en el apartado anterior, supone abrir la puerta a ataques antes de que se mitigue una debilidad. ¿En qué casos un investigador opta por esta opción? Cuando resulta evidente que el proveedor del software no atiende a la información que se le ha reportado y no toma medidas para solventar el problema. De tal forma que, al publicar toda la información sobre una vulnerabilidad presente en un software, se busca forzar al proveedor a desarrollar un parche para mitigarla o proporcionar información a la comunidad para mitigar el problema.
3. Divulgación responsable y coordinada. Organismos públicos como el INCIBE en España o la Cybersecurity & Infrastructure Security Agency (CISA) en Estados Unidos, disponen de políticas CVD para facilitar un reporte de las vulnerabilidades coordinado y que no ponga en riesgo la seguridad de los software y las personas y empresas que los emplean. Mediante este modelo, los detalles de una vulnerabilidad son privados hasta que se desarrolle un parche de seguridad y se instale para subsanar el problema. Posteriormente, la información se hace pública. Asimismo, es importante señalar que algunas compañías también cuentan con políticas CVD para incentivar que los analistas de seguridad reporten vulnerabilidades y les dejen margen de acción para mitigarlas antes de que se den a conocer a la opinión pública. Este modelo es fundamental cuando la vulnerabilidad afecta de forma transversal a distintos productos o fabricantes, y debe coordinarse la publicación de parches de seguridad.

3. ¿Qué información debe incluirse cuando se reporta una vulnerabilidad?

El reporte que un analista de seguridad envía al proveedor del software afectado por la vulnerabilidad descubierta o a un organismo público debe contener los datos necesarios para poder identificar, comprender y mitigar una vulnerabilidad. Así, en el reporte de una vulnerabilidad se puede incluir información como:

• Pruebas que constaten la existencia de la vulnerabilidad, como capturas de pantalla, capturas de tráfico o fragmentos de código.
• La cronología del descubrimiento de la vulnerabilidad y de la puesta en conocimiento del proveedor.
• Los datos del proveedor, el software y la versión afectada por la vulnerabilidad.
• Una descripción lo más amplia posible de la vulnerabilidad y del impacto de la misma.
• El nivel de criticidad de la vulnerabilidad. Si es posible, se puede incorporar la nota que obtiene la misma según el sistema de clasificación CVSS.
• Los requisitos que se necesitan cumplir para poder explotar la vulnerabilidad.
• En caso de que exista, el código de la prueba de concepto que permita reproducir la explotación de la vulnerabilidad.
• La forma de solucionar el problema detectado en caso de que se tenga un amplio conocimiento del software.
• Si se desea, es posible establecer un plazo temporal para mitigar la vulnerabilidad antes de que se decida hacerla pública.

En algunos casos, el informe inicial que se presenta al reportar una vulnerabilidad es lo suficientemente completo como para que el proveedor pueda desarrollar un parche de seguridad. Sin embargo, es común que entre el reporte de la vulnerabilidad y la actualización del software que incorpore el parche se produzca un flujo comunicativo entre el investigador y la compañía para lograr mitigar la vulnerabilidad.

4. La importancia del Red Team a la hora de evitar que se produzca el reporte externo de una vulnerabilidad

La estrategia de detección de vulnerabilidades de una empresa que desarrolla software se puede complementar con la puesta en marcha de un programa de Bug Bounty.

Aunque esta medida puede ser de gran ayuda es fundamental disponer de otros enfoques proactivos como la realización de ejercicios de Red Team que sean capaces de anticiparse a ataques:

• Poniendo a prueba las tecnologías, procesos y personal de la una compañía.
• Simulando ataques realistas y lo más amplios posibles para detectar cualquier vulnerabilidad que pueda ser explotada por actores maliciosos.
• Proponiendo recomendaciones para optimizar las debilidades identificadas y mitigar las vulnerabilidades presentes en un software o cualquier otro activo tecnológico.

Asimismo, también es crítico que las empresas dispongan de capacidades o servicios de ciberseguridad para gestionar las vulnerabilidades y hacer frente a las vulnerabilidades emergentes una vez que estas son identificadas.

En definitiva, la identificación de vulnerabilidades es una actividad crítica a la hora de anticiparse a los actores. Por eso, es importante que las empresas proveedoras de software cuenten con canales seguros para que los analistas de seguridad puedan reportar vulnerabilidades y, además, implementen servicios de ciberseguridad que les permitan identificar debilidades antes que los ciberdelincuentes.