¿Por qué las organizaciones confían en Snyk para ganar la batalla de la seguridad del código abierto?

Definir y explicar el papel de un equipo de seguridad interno dedicado a investigar y analizar vulnerabilidades en los ecosistemas de código abierto —para garantizar su seguridad— no es tarea fácil. Es difícil dar una respuesta concisa cuando alguien hace la pregunta aparentemente sencilla: «¿A qué se dedica el equipo de seguridad de Snyk?». No hay una respuesta breve que explique exactamente qué hacemos y cuál es nuestra especialidad.

Creo que el problema se debe a que «investigador» y «analista» en general, y «analista de seguridad» o «investigador de seguridad» en particular, deben de ser algunos de los títulos más usados y desgastados desde «consultor». Pueden significar literalmente cualquier cosa, y cada empresa parece tener una definición completamente distinta de lo que hace su equipo de investigación de seguridad (cuando siquiera tiene uno).

Es probable que no logre explicar del todo a las personas que conozco fuera del trabajo a qué me dedico. Pero esta publicación es, al menos, un intento por reducir el problema y explicar de una vez por todas qué hace aquí, en Snyk, el extraordinario equipo de investigación de seguridad.

En este artículo hablaremos de lo siguiente:

• Nuestra misión

• Nuestros métodos

  • Bases de datos estructuradas de los ecosistemas de la comunidad

  • Bases de datos no estructuradas y avisos

  • Descubrir vulnerabilidades no publicadas

  • Divulgaciones de la comunidad y el ámbito académico

  • Investigación propia y análisis de tendencias de vulnerabilidades

• Resumen

Nuestra misión

La misión de Snyk es hacer que el mundo del código abierto sea más seguro y ayudar a los desarrolladores a asumir un papel activo en la protección de sus bases de código. Una de las principales formas en que lo hacemos es analizar las bibliotecas de código abierto y las imágenes de contenedor que usan nuestros usuarios para detectar vulnerabilidades, ofrecerles la información más precisa y útil posible sobre los hallazgos y darles la opción de corregir los problemas.

La función del equipo de investigación de seguridad en la empresa es reunir y desarrollar la base de datos de vulnerabilidades Snyk Intel, que impulsa nuestros análisis y proporciona información a los usuarios para que puedan corregir las vulnerabilidades antes de que se conviertan en amenazas de seguridad.

Crear y mantener una base de datos de seguridad de primer nivel es una tarea difícil que requiere mucho esfuerzo, no solo para garantizar la precisión de los datos, sino también la amplitud y profundidad de la base de datos. La forma más sencilla de explicar exactamente cómo lo hacemos es mostrarte cómo buscamos, verificamos y priorizamos las vulnerabilidades para la base de datos.

Nuestros métodos

Usamos varios métodos para garantizar una cobertura continua de los problemas de seguridad del código abierto:

1. Bases de datos estructuradas de los ecosistemas de la comunidad

Las fuentes más evidentes de vulnerabilidades en los ecosistemas de código abierto son las bases de datos impulsadas por la comunidad, como rubysec, friends of php, rustsec y muchas otras. Estas bases de datos son seleccionadas por desarrolladores de código abierto que trabajan dentro del ecosistema y buscan dar la mayor visibilidad posible a los problemas de seguridad que existen en él.

El equipo de investigación de seguridad de Snyk sigue activamente estas bases de datos comunitarias para estar al tanto de las vulnerabilidades divulgadas por la comunidad. Sin embargo, a pesar del excelente trabajo que hace la comunidad para informar a los usuarios del ecosistema sobre estas vulnerabilidades, a menudo aún queda trabajo adicional y necesario por hacer.

El equipo de investigación de seguridad verifica y analiza cada vulnerabilidad divulgada para:

1. verificar que realmente se trate de una vulnerabilidad: esto implica investigar la vulnerabilidad divulgada y, si es necesario, crear pruebas de concepto para confirmar que efectivamente se puede explotar.

2. definir una descripción completa y precisa de la vulnerabilidad, incluida su gravedad y puntuación CVSS: al investigar la vulnerabilidad, podemos comprender mejor sus posibles impactos y vectores de ataque, así como el uso probable del paquete vulnerable dentro del ecosistema. Con esta información, elaboramos una descripción y un aviso de gravedad para que los desarrolladores comprendan mejor la vulnerabilidad y cómo podría afectar su base de código.

3. verificar que la información sobre metadatos importantes, como las versiones corregidas y los paquetes afectados, esté completa y sea precisa: investigamos la base de código del paquete para identificar los cambios exactos que introdujeron y corrigieron la vulnerabilidad. Después, contrastamos esta información con el nombre y las versiones precisas del paquete para asegurarnos de marcar solo los paquetes y las versiones vulnerables.

4. identificar las funciones o clases vulnerables dentro de un paquete: durante la priorización de las vulnerabilidades, buscamos identificar las funciones exactas (o función) vulnerables dentro del paquete. Estos metadatos permiten a los desarrolladores saber si su uso específico del paquete es vulnerable.

5. monitorear y priorizar las vulnerabilidades divulgadas que se explotan activamente: incluso después de que se publica una vulnerabilidad, es necesario hacer un seguimiento para detectar si se divulga más información, especialmente si se publica un método de explotación avanzado. Monitoreamos diversas fuentes para detectar las explotaciones a medida que se publican y las priorizamos para brindar información sobre su nivel de sofisticación, de modo que los desarrolladores sepan cómo priorizar la corrección de estas vulnerabilidades.

2. Bases de datos no estructuradas y avisos

Es útil que existan bases de datos estructuradas dentro de los ecosistemas; sin embargo, también hay muchísima información sobre nuevas vulnerabilidades en bases de datos no estructuradas y avisos públicos. Por eso es fundamental monitorear y priorizar este tipo de fuentes.

El ejemplo más evidente son las bases de datos CVE y NVD, que registran muchas vulnerabilidades en un formato no estructurado y no legible por máquinas. Además de CVENVD, hay innumerables avisos de productos y listas de correo individuales, como la lista de correo de Apache, los blogs de actualizaciones de Node.JS, los avisos de seguridad de Jenkins y muchas más, que requieren nuestra atención.

Aunque, por supuesto, el equipo también debe aplicar aquí todo el trabajo descrito en la sección anterior, también es necesario organizar los datos en un formato legible tanto para las máquinas como para las personas. Por ejemplo, aunque NVD o la lista de correo de Apache indiquen que una vulnerabilidad afecta a «Apache Tomcat», lo que los desarrolladores necesitan saber es si el paquete específico que usan es vulnerable, de los 958 paquetes relacionados con «Apache Tomcat» disponibles actualmente en Maven.

Mediante una investigación exhaustiva de la base de código vulnerable, el equipo puede identificar los parámetros del código afectado. Después, usamos nuestras herramientas internas para analizar los paquetes que probablemente estén relacionados con esta vulnerabilidad y comprobar si contienen el código vulnerable. Solo después de verificar que el código vulnerable existe y es pertinente, asignamos la vulnerabilidad a un paquete específico. Este trabajo reduce considerablemente los falsos positivos en nuestra base de datos y, a su vez, permite que los desarrolladores que usan Snyk se concentren en corregir vulnerabilidades, en lugar de lidiar con ruido irrelevante.

3. Descubrir vulnerabilidades no publicadas

Hasta ahora, describí principalmente cómo el equipo ayuda a priorizar las vulnerabilidades conocidas y a hacer que sean más útiles para los desarrolladores, algo que, por supuesto, es fundamental. Sin embargo, otra de sus funciones es fortalecer la seguridad de los ecosistemas de código abierto mediante la identificación de vulnerabilidades que aún no se han divulgado.

Junto con nuestro equipo de datos, desarrollamos varios algoritmos de aprendizaje automático para descubrir lo que llamamos vulnerabilidades de «medio día». Se trata de vulnerabilidades que quizá se hayan comentado en distintos foros públicos, pero que todavía no se han divulgado oficialmente.

Es bien sabido que estas vulnerabilidades suelen ser las más peligrosas, porque el tiempo que transcurre entre que se empieza a hablar de una vulnerabilidad y se reconoce oficialmente, y que el público en general puede tomar medidas para corregirla, es una ventana que los actores maliciosos pueden aprovechar gracias a su conocimiento anticipado de la vulnerabilidad.

Ayudamos a cerrar esta brecha y podemos descubrir vulnerabilidades recién encontradas y alertar a los usuarios al principio de su ciclo de vida. Para ello, buscamos en lugares donde suelen debatirse en etapas iniciales las correcciones de código, los informes de errores y las posibles vulnerabilidades, como las solicitudes de cambios y los problemas en sistemas de control de versiones, los tickets de JIRA o sitios como Reddit o StackOverflow.

Gracias a nuestra base de datos preexistente, recopilada y seleccionada manualmente, de fragmentos de código vulnerables, informes de errores y descripciones de vulnerabilidades, contamos con una amplia variedad de recursos para crear nuestros modelos de aprendizaje automático. Por eso, nuestros sistemas pueden procesar miles de eventos en todos los paquetes de los ecosistemas que admitimos y alertar al equipo sobre posibles vulnerabilidades. En conjunto, creemos que hemos creado probablemente el feed de alertas de mayor alcance disponible actualmente.

Estas alertas llegan al sistema de alerta temprana del equipo, que luego las prioriza. Un analista comparte la información de la alerta y, si es necesario, verificamos la vulnerabilidad creando una prueba de concepto y nos comunicamos con los responsables del mantenimiento del paquete para conocer su perspectiva sobre la posible vulnerabilidad.

Después de hablar con los responsables del mantenimiento y verificar la vulnerabilidad, la publicamos en nuestra base de datos para que todo el ecosistema conozca el problema de seguridad y pueda corregirlo. Solo el año pasado ayudamos a divulgar aproximadamente 200 vulnerabilidades de esta manera, entre ellas la inyección de comandos en Vizion y el ataque de temporización que afectaba a los populares paquetes Escada y Elliptic.

4. Divulgaciones de la comunidad y el ámbito académico

La divulgación responsable de vulnerabilidades es un modelo común en el mundo de la ciberseguridad. Consiste en divulgar primero de forma privada las vulnerabilidades de día cero, lo que da a los responsables del mantenimiento del código y las aplicaciones tiempo suficiente para publicar una corrección o un parche antes de que la vulnerabilidad se haga pública. De lo contrario, pondríamos en riesgo la seguridad de los usuarios finales. Como siempre, la clave está en encontrar el equilibrio: el objetivo es reducir tanto el tiempo que la vulnerabilidad permanece en privado como el tiempo que la aplicación sigue siendo vulnerable sin una corrección.

Snyk lanzó su programa de divulgación de vulnerabilidades en 2019 con el objetivo de cerrar esta brecha y facilitar que los investigadores puedan reportar vulnerabilidades, reconociendo, por supuesto, su arduo trabajo al descubrirlas.

Nuestro equipo de seguridad prioriza cuidadosamente todos y cada uno de los informes de vulnerabilidades. Para hacerlo, se requieren conocimientos específicos y comprensión del lenguaje en cuestión, del paquete y de su contexto. Una vez verificados los detalles de la vulnerabilidad, el equipo trabaja en estrecha colaboración con los responsables del mantenimiento para corregirla a tiempo.

Por último, como Autoridad de Numeración CVE (CNA), ayudamos a asignar un identificador CVE al problema y a publicar un aviso detallado. En 2019, ayudamos a divulgar más de 130 vulnerabilidades. Algunos ejemplos destacados son la ejecución remota de código en mongo-express y la escritura arbitraria de archivos en yarn.

Trabajamos con investigadores independientes, profesionales de seguridad y la comunidad académica para divulgar vulnerabilidades. Los investigadores individuales usan nuestro programa de divulgación para reportar una o, a veces, varias vulnerabilidades que afectan a determinados paquetes. Por su parte, los investigadores académicos que descubren nuevos tipos de vulnerabilidades se ponen en contacto con Snyk para usar nuestro programa de divulgación masiva de múltiples vulnerabilidades en todo el ecosistema. Comenzamos 2020 con una gran alianza con el equipo del Security Lab de Johns Hopkins University, con quienes ayudamos a divulgar más de 60 vulnerabilidades (y contando). Algunos ejemplos destacados son CVE-2019-10795 en undefsafe y CVE-2019-10777 en aws-lambda.

5. Investigación propia y análisis de tendencias de vulnerabilidades

La última pieza del rompecabezas de la seguridad es nuestra investigación interna para descubrir y divulgar de forma responsable nuevas vulnerabilidades en el ecosistema de código abierto. En Snyk, consideramos que descubrir y divulgar de forma responsable nuevas vulnerabilidades es fundamental para mantener seguro el ecosistema, y para hacerlo aprovechamos nuestra base de datos de vulnerabilidades existentes. Al analizar las tendencias de vulnerabilidades en un lenguaje específico o en varios lenguajes, identificamos características clave de las vulnerabilidades que probablemente sean frecuentes en el ecosistema.

En otras palabras, si vemos que una vulnerabilidad determinada aparece en varios paquetes del ecosistema, todos con vectores de ataque similares, sabemos que es probable que haya otras vulnerabilidades aún no descubiertas. Además, sabemos que es probable que otros actores con intenciones maliciosas conozcan esta posibilidad e intenten aprovecharla.

Por eso, Snyk busca aprovechar sus capacidades de investigación de manera cuidadosa y eficiente para descubrir tanto nuevos tipos de vulnerabilidades a gran escala, como zip-slip, como nuevos casos de tipos de vulnerabilidades en tendencia en paquetes populares. Para llevar a cabo esta investigación, combinamos el análisis de grandes volúmenes de datos para identificar tipos de fragmentos vulnerables, patrones de código u otras características similares en paquetes potencialmente vulnerables, con la investigación de diversos vectores de explotación. Luego, nuestras herramientas internas pueden probarlos en el paquete potencialmente vulnerable y determinar si realmente lo es.

Una vez descubiertas, usamos nuestro proceso y cronograma de divulgación responsable para informar las vulnerabilidades a los responsables de mantenimiento afectados y ayudar a desarrollar una corrección. Después, divulgamos públicamente la vulnerabilidad en nuestra base de datos y le asignamos un CVE.

Resumen

El resultado de todo este arduo trabajo es un producto de seguridad que cumple cuatro objetivos fundamentales:

1. Oportunidad: la información que reciben nuestros usuarios sobre vulnerabilidades y exploits llega a tiempo para que puedan actuar. Así, reciben alertas sobre vulnerabilidades mucho antes de que se difundan ampliamente y los actores maliciosos puedan aprovecharlas.

2. Exhaustividad: los usuarios pueden tener la tranquilidad de conocer todas sus vulnerabilidades, sin preocuparse por otras vulnerabilidades potencialmente explotables que podrían estar ocultas en su base de código.

3. Precisión: los datos proporcionados son precisos y eliminan el temido ruido y los falsos positivos de un análisis de seguridad.

4. Utilidad: los datos permiten a los desarrolladores clasificar rápidamente las vulnerabilidades que los afectan y priorizar su trabajo en consecuencia.

En conjunto, estos cuatro objetivos permiten que los usuarios de Snyk sepan que, a pesar de la interminable maraña de vulnerabilidades en los ecosistemas de código abierto, cuentan con un equipo dedicado de expertos en seguridad, listo para entrar en acción y brindarles toda la información que necesitan para protegerse y proteger el resto del código abierto.

Encuentra vulnerabilidades en tu código: crea una cuenta gratuita de Snyk.