Programa de divulgación de vulnerabilidades de Snyk: ¿qué sucede tras bambalinas?
Asaf Biton
14 de abril de 2020
0 minutos de lecturaEn Snyk, creemos firmemente en mantener segura a la comunidad de código abierto. Por eso lanzamos nuestro programa de divulgación responsable de vulnerabilidades, que abarca todas las vulnerabilidades encontradas en paquetes de código abierto administrados y en lenguajes como JavaScript, Java, Python, .NET, Go, Ruby y PHP.
¿Por qué divulgar vulnerabilidades con Snyk?
Con nuestro proceso de divulgación de vulnerabilidades en Snyk, buscamos cerrar la brecha entre investigadores y mantenedores, y aliviar algunos de los desafíos y dificultades asociados con la divulgación responsable, como comentamos en un artículo anterior.
Entonces, ¿cómo cerramos esa brecha? Cuando se reporta una nueva vulnerabilidad a Snyk, se envía directamente al equipo de seguridad para que evalúe y verifique el reporte. Como empresa que prioriza a los desarrolladores, creemos en un enfoque que también toma en cuenta el punto de vista de los mantenedores. Mantenemos un diálogo abierto y colaborativo de principio a fin (de acuerdo con nuestra política de divulgación de vulnerabilidades). Buscamos escuchar ambas perspectivas y, en última instancia, llegar a una decisión que el mantenedor acepte y que también sea la más responsable, según nuestra experiencia y conocimientos, considerando todos los factores, como el contexto del paquete, la gravedad, la probabilidad de explotación y más.
Snyk también es una CNA (Autoridad de Numeración de CVE), por lo que podemos asignar identificadores CVE a los problemas que se nos reportan. Una vez que se publica una corrección (o, si no recibimos respuesta en un plazo de 50 días), asignamos un identificador CVE al problema y publicamos un aviso público. Asignar un CVE a una vulnerabilidad es fundamental, ya que permite que todo el ecosistema conozca el problema y que los desarrolladores y las organizaciones puedan actuar para proteger su código.
Durante todo el proceso, nos aseguramos de enviar actualizaciones periódicas a la persona que reportó inicialmente la vulnerabilidad y, aún más importante, le damos crédito por su valioso hallazgo.
Hasta ahora, nuestro programa ha divulgado de manera responsable 88 vulnerabilidades reportadas por distintos investigadores externos. Veamos uno de estos casos.
Estudio de caso: colaboración con Johns Hopkins University
Recientemente, colaboramos con investigadores de Johns Hopkins University en una divulgación a gran escala de 57 vulnerabilidades.
Como parte de su tesis, el equipo de Johns Hopkins University ideó una forma revolucionaria de automatizar la búsqueda de vulnerabilidades:
"Proponemos un concepto novedoso, llamado Object Property Graph (OPG), para capturar las interacciones entre objetos de JavaScript y facilitar la detección de vulnerabilidades en JavaScript. Un OPG representa toda la información sobre los nombres de los objetos, como los nombres de variables y propiedades, los ámbitos de los objetos y los objetos mismos, como nodos en una estructura similar a un grafo. Así, se puede recorrer el grafo para resolver un objeto durante la ejecución. El OPG ofrece dos tipos principales de utilidades: (i) facilitar la creación de un CFG y un DFG mejores, es decir, más precisos, cuando se encuentra una resolución de objetos desconocida; y (ii) proporcionar las interacciones entre objetos para poder consultarlas en busca de determinados patrones de vulnerabilidad.
Diseñamos e implementamos un marco de trabajo, llamado OPGen, para generar OPG en aplicaciones de Node.js durante una llamada ejecución simulada. Aplicamos OPGen para detectar cuatro tipos de vulnerabilidades en Node.js: inyección de comandos, contaminación de prototipos, ejecución de código arbitrario y recorrido de rutas.
Sobre el CPG (grafo de propiedades del código), agregamos los nodos de objetos y las aristas relacionadas. Para ello, simulamos la ejecución del código y verificamos si hay algún flujo de datos que comience en la entrada del usuario y pueda llegar a las funciones de destino."
- Song Li, JHU Security Labs
Luego, el equipo se comunicó con nosotros mediante el formulario de divulgación de vulnerabilidades. Les respondimos invitándolos a una videollamada para hablar sobre la naturaleza de los hallazgos, su alcance y cómo podíamos apoyarlos.
Una vez que entendimos la magnitud de la divulgación, creamos un repositorio privado compartido donde el equipo podía agregar nuevos hallazgos. El equipo nos proporcionó el tipo de vulnerabilidad, el paquete y las versiones afectadas, una POC y una referencia al código vulnerable. Todo en un formato único que se ingresa en una canalización personalizada para nuestros sistemas internos, lo que nos ayudó a gestionar eficazmente el gran volumen de hallazgos.
Con una herramienta interna que creamos, verificamos las POC pertinentes y luego evaluamos por completo los hallazgos y trabajamos con los mantenedores correspondientes para divulgar las vulnerabilidades de forma responsable.
Hasta la fecha, hemos publicado más de 55 vulnerabilidades gracias a esta colaboración, entre ellas, vulnerabilidades de inyección de comandos, recorrido de rutas, contaminación de prototipos y ejecución de código. Algunos ejemplos son SNYK-JS-BLAMER-559541, SNYK-JS-BODYMEN-548897 y SNYK-JS-PULVERIZR-560122.
Seguimos trabajando de cerca con el equipo de JHU Security Labs en nuevos hallazgos y en vulnerabilidades que aún no se han publicado.
¿Cómo empezar?
Un primer paso importante es leer nuestra política de divulgación de vulnerabilidades.
Una vez que lo hayas hecho, la forma recomendada de enviar un reporte es usar el formulario de divulgación específico.
Incluye toda la información posible, en particular:
descripción del problema
pasos para reproducirlo (o una prueba de concepto)
datos de contacto: así sabremos a quién dar crédito y podremos comunicarnos contigo si necesitamos más información.
Como alternativa, también puedes escribirnos a report@snyk.io. Una vez más, asegúrate de incluir toda la información posible.