Divulgación de vulnerabilidades: ¿qué viene primero, el error de seguridad en PHP o el CVE?

Para los investigadores de seguridad, hay una serie de obstáculos que superar al reportar una posible vulnerabilidad, mucho antes de que el problema en sí sea ampliamente reconocido. Convencer a los responsables del proyecto de que existe un problema es el primer obstáculo, incluso cuando se cuenta con un ejemplo funcional.

A veces, la línea que separa la identificación de una ruta vulnerable como error o como vulnerabilidad de seguridad es tenue y difusa. También puede ocurrir lo contrario: que una vulnerabilidad reportada se reclasifique como error, aunque se haya utilizado como vector de ataque.

Un buen ejemplo es la divulgación de vulnerabilidades que DeveloperSteve siguió en el lenguaje central de PHP, a raíz de una vulnerabilidad de uso después de liberar identificada en la función `concat()`. Se demostró en un evento de captura la bandera. El equipo reportó el problema de seguridad, pero varios artículos después, el reporte se reclasificó como un error, a pesar de que la vulnerabilidad se había utilizado.

Hace poco seguí el proceso de CVE para el incidente de la biblioteca dompdf, lo que agregó tiempo a la cronología del incidente, que abarcó 7 meses. Esto sigue aumentando mi aprecio por el trabajo que implica atender los matices de la publicación de un CVE.

Es importante tener en cuenta que muchos proyectos de código abierto como este están a cargo de personas apasionadas que contribuyen a ellos; muchas también trabajan a tiempo completo y enfrentan las mismas presiones que todos nosotros mientras administran proyectos de gran escala como este.

Veamos la cronología del incidente.

Cronología de los reportes del incidente de dompdf

Como parte de la divulgación pública de Positive Security en marzo de 2022, también publicaron la cronología previa a la divulgación.

El primer reporte a los responsables del proyecto se realizó en octubre de 2021, a través del proceso de la página para reportar problemas de seguridad del proyecto. Tras meses sin respuesta, el equipo de Positive Security intentó escalarlo como un error en el repositorio.

Finalmente, después de la divulgación pública de la vulnerabilidad, se publicó una versión corregida. Además, DeveloperSteve pudo aprovechar la ruta vulnerable para crear las condiciones necesarias para generar una shell inversa. 

Esto se demuestra en la aplicación Snyk-Labs PHP-Goof de Snyk, que incluye la vulnerabilidad original a la que DeveloperSteve agregó vulnerabilidades de seguridad relacionadas con PHP.

Con toda la investigación previa y los ejemplos de código de prueba de concepto de la shell inversa, DeveloperSteve logró obtener un CVE para el incidente 7 meses después del reporte inicial. 

Cómo funciona el proceso de CVE 

Después de pasar recientemente por el proceso de CVE, ahora comprendemos y valoramos más el trabajo de los investigadores de seguridad al reportar vulnerabilidades. 

DeveloperSteve envió una solicitud de CVE a Mitre, junto con toda la investigación original, y actualmente está pendiente de un análisis más detallado. Esta vulnerabilidad también se agregó como ejemplo en la aplicación de demostración PHP-Goof.

En un ejemplo reciente, un investigador reportó en enero una vulnerabilidad de uso después de liberar. Se incluyó en las páginas de vulnerabilidades de Snyk y se identificó como CVE-2021-21708.

Cómo solicitar un CVE

Al principio, el proceso parecía bastante sencillo: enviar un formulario web y esperar a que alguien validara los hallazgos. Al visitar la página de reportes y solicitudes de CVE.org, DeveloperSteve descubrió que hay varios pasos antes de poder enviar la solicitud. 

El primer paso del proceso es identificar la organización socio de CVE autorizada para reservar y publicar CVE relacionados con la vulnerabilidad reportada. Estas organizaciones se conocen como autoridades de numeración de CVE o CNA. 

Una organización designada como CNA puede clasificar las vulnerabilidades de seguridad y luego reservar y publicar identificadores CVE para las divulgaciones de seguridad reportadas.

Por ejemplo, en 2021, Snyk asumió la responsabilidad del programa de divulgación de vulnerabilidades del ecosistema de Node.js. Por eso, Snyk es una CNA y publica con regularidad reportes de seguridad CVE para numerosos ecosistemas, como npm.

Nota: Snyk ofrece un formulario sencillo para reportar vulnerabilidades de seguridad.

Conclusiones sobre los reportes de CVE

A veces, la línea entre determinar si una ruta vulnerable reportada es un error o una vulnerabilidad es difusa. Además, hay casos en los que un error reportado genera una ruta vulnerable y, en realidad, representa una amenaza para la seguridad. 

Más allá del error o problema de seguridad inicial que detecte la comunidad, un investigador de seguridad o un colaborador, está la fase de investigación, en la que se analiza más a fondo el problema reportado. Con frecuencia, los actores maliciosos usan errores como vectores de ataque para introducir comportamientos no deseados en una aplicación o infraestructura. 

En Snyk, el equipo de seguridad se dedica a detectar vulnerabilidades de seguridad desde sus primeras etapas, cuando se reportan como errores, incluso antes de que se conviertan en CVE oficiales. Este compromiso de Snyk ayuda a mantener a nuestros usuarios seguros e informados lo antes posible.