Denegación de servicio por expresión regular en websocket-extensions

¡Te damos la bienvenida a la nueva serie del blog de Snyk! En esta serie mensual, Snyk repasa las vulnerabilidades que nuestro equipo de investigación descubrió o que le reportaron . Cada mes elegimos una vulnerabilidad destacada del mes anterior y contamos la historia de su descubrimiento, investigación y divulgación. Destacamos a los investigadores, desarrolladores y usuarios que ayudan a identificar y corregir vulnerabilidades en toda la comunidad de código abierto.

Este mes damos inicio a la serie con una vulnerabilidad descubierta en el paquete websocket-extensions.

Vulnerabilidad: ReDoS en websocket-extensionsCVE asignados:CVE-2020-7662, CVE-2020-7663Analista de Snyk:Sam SanoopDescubierta por: Robert McLaughlin

El 2 de junio de 2020, el equipo de investigación de seguridad de Snyk publicó una vulnerabilidad de denegación de servicio por expresión regular (ReDoS) identificada en el popular paquete websocket-extensions, que afectaba a más de 13,000 proyectos analizados por Snyk. Robert McLaughlin, estudiante de doctorado del programa de Ciencias de la Computación de la Universidad de California en Santa Bárbara, reportó la vulnerabilidad a Snyk. Robert trabaja en SecLab de UCSB y se centra en la «detección y reparación automatizadas de vulnerabilidades de seguridad en el software». Robert investigaba vulnerabilidades ReDoS en el ecosistema Node.js cuando identificó el problema.

Nos contó que descubrió inicialmente la vulnerabilidad después de recopilar una gran muestra de expresiones regulares de paquetes populares de npm. El equipo del laboratorio utilizó analizadores ReDoS para examinar las muestras recopiladas. Finalmente, esta vulnerabilidad se identificó con la herramienta de código abierto RegexStaticAnalysis, publicada y mantenida por Nicolaas Weideman.

La vulnerabilidad identificada podría permitir que un usuario malicioso ataque el algoritmo de expresión regular. Al proporcionar una entrada diseñada específicamente, el atacante puede provocar una situación conocida como «retroceso catastrófico», en la que el motor de estado de RegEx debe analizar una gran cantidad de rutas posibles para determinar si la cadena coincide con el patrón de RegEx. Puedes leer más sobre las vulnerabilidades ReDoS en esta publicación del blog.

Fuente: Informe sobre el estado de la seguridad del código abierto de Snyk, 2019

Además de su investigación, Robert desarrolló una prueba de concepto del exploit que nos proporcionó al reportar la vulnerabilidad. Sam Sanoop, analista del equipo de seguridad de Snyk, tenía la tarea de validar que la vulnerabilidad pudiera reproducirse. Sin embargo, al principio Sam no pudo reproducir el exploit en un contenedor de prueba con la prueba de concepto proporcionada. Robert pudo darle instrucciones adicionales sobre cómo ejecutar el exploit y, después de aclarar algunos detalles del payload del ataque, Sam confirmó que la vulnerabilidad efectivamente podía reproducirse.

Sin embargo, además de confirmar que existía código vulnerable, Sam también verificó que, en el contexto del paquete (es decir, según el uso previsto), se trataba realmente de una vulnerabilidad que debía corregirse. Este paso es particularmente importante al trabajar con vulnerabilidades ReDoS. En el código abierto se usan muchos patrones RegEx que, tras revisarlos, podrían parecer vulnerables, pero en realidad no se pueden explotar.

Una vez confirmadas la validez, el impacto y la gravedad de la vulnerabilidad, Sam investigó el código del paquete. Encontró la línea de código que introducía la vulnerabilidad y elaboró recomendaciones para corregir el problema específico que encontró. Con esta información, Sam asignó dos CVE para describir la vulnerabilidad en las versiones JavaScript y Ruby del paquete. También se comunicó con quien la reportó para confirmar que la vulnerabilidad había sido verificada, compartir los números de CVE reservados e informarle que Snyk se pondría en contacto con la persona mantenedora. En ese momento, Sam también contactó a la persona mantenedora del paquete y le proporcionó los detalles de la vulnerabilidad, así como recomendaciones específicas para implementar una corrección.

En este caso, websocket-extensions es un paquete con mantenimiento muy activo y la persona mantenedora respondió rápidamente a la información proporcionada. Un par de horas después, le confirmó a Sam que entendía la vulnerabilidad y que estaba trabajando en una corrección. Sam le proporcionó los números de CVE para que pudiera mencionarlos al publicar la corrección y acordaron una fecha para divulgar la vulnerabilidad. La persona mantenedora publicó una corrección al día siguiente de que Snyk le reportara el problema, y las descripciones de la vulnerabilidad se publicaron al día siguiente.

Esta vulnerabilidad es un excelente ejemplo de cómo el proceso de divulgación de Snyk ayuda a los investigadores a reportar sus descubrimientos y recibir reconocimiento, al mismo tiempo que colaboran con quienes mantienen proyectos de código abierto. Robert, el investigador que reportó esta vulnerabilidad, nos contó por qué eligió divulgarla a través de Snyk:

«Mi principal objetivo al divulgar una vulnerabilidad es obtener la asignación de un CVE, y Snyk lo hace muy bien. También agradezco que Snyk se ponga en contacto con las personas mantenedoras correspondientes y coordine una corrección». - Robert McLaughlin

El objetivo de Snyk es garantizar la validez y la posibilidad de explotar las vulnerabilidades, y al mismo tiempo ofrecer a quienes mantienen los proyectos una divulgación responsable y orientación detallada para corregirlas. Para obtener más información sobre esta vulnerabilidad o saber cómo reportar una vulnerabilidad que hayas descubierto en un proyecto de código abierto, consulta los siguientes enlaces.

• Reportar una vulnerabilidad

• Descripción de la vulnerabilidad (JavaScript)

• Descripción de la vulnerabilidad (Ruby)