¿Por qué se debe dar prioridad a la resolución de los CVE?
Ya he explicado anteriormente por qué la seguridad de las aplicação es una pila . Digo esto nuevamente porque a veces necesitamos un recordatorio de que las aplicações modernas nunca se implementan solas. No lo son.
Toda aplicação moderna se implementa en algún tipo de plataforma. Eso podría ser Apache o IIS. Podría ser un servidor de aplicação Oracle o IBM. Podría ser node.js con Express o Python con todas las bibliotecas necesarias. Así como dependemos de los sistemas operativos y de la virtualización/contenedores para proporcionarnos redes, las aplicações dependen de plataformas y bibliotecas para manejar cosas como TCP y HTTP.
Además, los desarrolladores utilizan bibliotecas para la funcionalidad. Reinventar la rueda es una pérdida de tiempo, por lo que los desarrolladores recurren al código abierto y otras vías para obtener analizadores JSON, gestión de archivos, autenticación y autorización y soporte de bases de datos. Diseño y gestión de la interfaz de usuario también. Hoy en día, la mayoría de los desarrolladores recurren a bibliotecas para proporcionar estas funciones, de modo que puedan centrarse en lo que agrega valor: la lógica de negocios y los servicios.
Una inspección de aplicações realizada en 2017 por Contrast Labs descubrió que “las bibliotecas de software de terceros representan el 79 % del código de una aplicación”. Para Java, el promedio fue de 107 bibliotecas diferentes. ¿Para .NET? 19.Como anécdota, estoy usando al menos cinco bibliotecas diferentes con node.js.
Pero lo que debería sorprendernos es lo que descubrieron sobre el estado de la seguridad con respecto a esta división.
Aunque el 79% de una aplicación se compone de bibliotecas, solo representa el 2% de las vulnerabilidades conocidas (CVE). El código personalizado representa prácticamente el resto, con el 97,3% de las vulnerabilidades.
Este riesgo desproporcionado de seguridad de abastecimiento entre bibliotecas y vulnerabilidades podría explicar por qué una encuesta de SANS encontró que "si bien el 23% de los encuestados dependen en gran medida de productos y servicios de software de terceros (COTS, servicios basados en la nube y open source software), no están asumiendo suficiente responsabilidad para garantizar la seguridad de las soluciones de terceros. Sólo el 23% de los programas de seguridad incluyen COTS”.
Hmmm. Bueno entonces, eso podría explicar la baja tasa de respuesta a la resolución de vulnerabilidades según lo informado por Kenna Security. En 2015, Kenna Security informó sobre una investigación realizada en una muestra de 50.000 organizaciones con 250 millones de vulnerabilidades y más de mil millones (MIL MILLONES) de eventos de violación y encontró dos puntos muy interesantes con respecto a la remediación de vulnerabilidades:
- En promedio, las empresas tardan entre 100 y 120 días en remediar las vulnerabilidades.
- Entre 40 y 60 días, la probabilidad de que se explote un CVE supera el 90 por ciento.
- El intervalo entre la probabilidad de explotación y el cierre de una vulnerabilidad es de alrededor de 60 días.
En otras palabras, la mayoría de las organizaciones no están abordando ese 2% de vulnerabilidades con la suficiente rapidez para evitar verse comprometidas por una de ellas. Quizás porque están ubicados en bibliotecas que no están incluidas en el programa de seguridad de la organización.
Cualquiera sea el motivo , debe ser la prioridad número uno. Y déjame explicarte por qué.
En el pasado, los atacantes tenían que:
- Infórmese sobre la vulnerabilidad
- Busque un sitio de víctimas
- Intento de ejecutar un exploit
Esto era manual y consumía mucho tiempo. A menos que fueras un objetivo de alto perfil, nadie iba a perder el tiempo contigo.
Hoy en día, las vulnerabilidades se comparten a la velocidad de Internet (que es la velocidad de la luz, en caso de que se lo esté preguntando). La columna vertebral óptica, ya sabes) y el descubrimiento de objetivos está automatizado. Los scripts y bots son capaces de buscar y marcar sitios para comprometerlos mucho más rápido (y más barato) que las personas. Es la misma forma en la que se construyen botnets del tamaño de la Estrella de la Muerte a partir de dispositivos IoT no seguros . La automatización no sólo mejora la productividad de los buenos.
Se trata de ataques no dirigidos . Ataques de oportunidad, por así decirlo, que no están planificados. Puede que no tengas datos valiosos o interesantes, pero sí tienes recursos. Y los recursos se pueden utilizar para encontrar otras víctimas y perpetrar otros ataques y, bueno, ya sabéis cómo termina esto.
Los ataques no dirigidos son especialmente comunes después de la publicación de un CVE. Esto se debe a que su código personalizado es único y, si bien contiene muchas vulnerabilidades, encontrarlas requiere tiempo y esfuerzo. Explotar un CVE que existe en una plataforma o biblioteca de uso común es muy fácil. La oportunidad es demasiado buena para dejarla pasar, porque el retorno de la inversión es alto, alto, alto. El DBIR de Verizon en 2015 señaló que “el 70% de los ataques explotaron vulnerabilidades conocidas que tenían parches disponibles”.
Es por eso que la aplicación de parches, ya sea a través de actualizaciones de software reales o virtualmente mediante el uso de un firewall de aplicação web , debe ser la prioridad uno ante la divulgación de un nuevo CVE en cualquiera del 79% de bibliotecas que componen su aplicação. Si ese CVE está relacionado con la plataforma (piense en Apache Killer) , será mejor que tenga como prioridad “Descartar todo”, porque identificar servidores web y de aplicaciones es incluso más fácil que buscar vulnerabilidades en bibliotecas.
La verdad es que si no tienes un perfil lo suficientemente alto como para ser un objetivo, aun así estás en riesgo. Probablemente estés usando la misma pila que organizaciones de alto perfil, y eso significa que es posible que te encuentren ataques no dirigidos. Si cree que no lo harán, considere que puedo ir a la base de datos CVE y encontrar todos los CVE publicados relacionados con node.js. Luego voy a builtwith.com y busco sitios web creados con Express, un marco de node.js. No solo descubro que el sitio sabe de “ 230.116 sitios web activos que usan Express y 263.872 sitios adicionales que usaron Express históricamente”, sino que también proporciona convenientemente un enlace para descargarlos.
No es exactamente el shodan.io de las aplicaciones web, pero no es mucho más difícil unir dos y dos y lograr un exploit exitoso.
Así que no cometa el error de pensar que porque no es “lo suficientemente grande” un CVE en una biblioteca o plataforma web puede ignorarse.
Así es como la gente termina siendo tendencia en Twitter. Y no en el buen sentido.
Estar a salvo. Priorice las respuestas a los CVE que afectan a toda su pila de aplicaciones. De arriba a abajo.