Por qué se debe dar máxima prioridad a la resolución de las CVE

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Ya he explicado anteriormente por qué la seguridad de las aplicaciones se basa en un conjunto de capas. Lo repito porque a veces necesitamos recordar que las aplicaciones modernas nunca se implementan de forma aislada. Nunca.

Todas las aplicaciones modernas se implementan en algún tipo de plataforma. Puede ser Apache o IIS, un servidor de aplicaciones de Oracle o IBM, node.js con Express o Python con todas las bibliotecas necesarias. Del mismo modo que dependemos de los sistemas operativos y de la virtualización o los contenedores para disponer de conectividad de red, las aplicaciones dependen de plataformas y bibliotecas para gestionar aspectos como TCP y HTTP.

Además, los desarrolladores utilizan bibliotecas para implementar distintas funcionalidades. Reinventar la rueda es una pérdida de tiempo, por lo que recurren al código abierto y a otras fuentes para obtener analizadores de JSON, herramientas de gestión de archivos, autenticación y autorización, compatibilidad con bases de datos, así como diseño y gestión de interfaces de usuario. Hoy en día, la mayoría de los desarrolladores recurren a bibliotecas para disponer de estas funciones y poder centrarse en lo que aporta valor: la lógica de negocio y los servicios.

Un análisis de aplicaciones realizado en 2017 por Contrast Labs reveló que «las bibliotecas de software de terceros representan el 79 % del código de una aplicación». En el caso de Java, la media era de 107 bibliotecas diferentes. ¿Y en .NET? 19. En mi caso, utilizo al menos cinco bibliotecas diferentes con node.js.

Pero lo que debería llamar su atención es lo que descubrieron sobre el estado de la seguridad en relación con esta división.

Aunque el 79 % de una aplicación está compuesto por bibliotecas, estas solo representan el 2 % de las vulnerabilidades conocidas (es decir, los CVE). El código personalizado concentra prácticamente el resto, con un 97,3 % de las vulnerabilidades.

Esta desproporción del riesgo para la seguridad de la cadena de suministro entre las bibliotecas y las vulnerabilidades podría explicar por qué una encuesta de SANS reveló que «aunque el 23 % de los encuestados depende en gran medida de productos y servicios de software de terceros (COTS, servicios en la nube y software de código abierto), no asume suficiente responsabilidad a la hora de garantizar la seguridad de las soluciones de terceros. Solo el 23 % de los programas de seguridad incluye productos COTS».

Hum. Pues bien, eso podría explicar la baja tasa de respuesta en la resolución de vulnerabilidades señalada por Kenna Security. Ya en 2015, Kenna Security publicó los resultados de una investigación realizada sobre una muestra de 50.000 organizaciones, con 250 millones de vulnerabilidades y más de mil millones (MIL MILLONES) de incidentes de seguridad, y reveló dos aspectos muy interesantes en relación con la corrección de vulnerabilidades:

• De media, las empresas tardan entre 100 y 120 días en corregir las vulnerabilidades.
• Entre los 40 y 60 días, la probabilidad de que se explote una CVE supera el 90 %.
• El intervalo entre el momento en que es probable que se explote una vulnerabilidad y su corrección es de unos 60 días.

En otras palabras, la mayoría de las organizaciones no corrigen ese 2 % de vulnerabilidades con la suficiente rapidez como para evitar que alguna de ellas comprometa sus sistemas. Quizá se deba a que se encuentran en bibliotecas que no están incluidas en el programa de seguridad de la organización.

Independientemente de por qué sea así, esto debe ser la máxima prioridad. Y permítanme explicarles por qué.

Antes, los atacantes tenían que:

1. Descubrir la vulnerabilidad
2. Buscar un sitio web víctima
3. Intentar ejecutar un exploit

Era un proceso manual que requerí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, por si te lo preguntabas. Ya sabes, la red troncal de fibra óptica) y la detección de objetivos está automatizada. Los scripts y bots pueden localizar y marcar sitios para atacarlos mucho más rápido (y a menor coste) que las personas. Es el mismo mecanismo por el que se crean redes de bots del tamaño de la Estrella de la Muerte a partir de dispositivos IoT desprotegidos. La automatización no solo mejora la productividad de los buenos.

Se trata de ataques no dirigidos; ataques oportunistas, por así decirlo, que no están planificados. Puede que no tengas datos valiosos o interesantes, pero sí tienes recursos. Y esos recursos pueden utilizarse para encontrar a otras víctimas y perpetrar otros ataques y, bueno, ya sabes cómo acaba esto.

Los ataques no dirigidos son especialmente frecuentes tras la publicación de una CVE. Esto se debe a que tu código personalizado es único; aunque contiene muchas vulnerabilidades, encontrarlas requiere tiempo y esfuerzo. Explotar una CVE presente en una biblioteca o plataforma de uso habitual es pan comido. Es una oportunidad demasiado buena como para dejarla pasar, porque el retorno de la inversión es muy, muy, muy alto. El informe DBIR de Verizon de 2015 señaló que «el 70 % de los ataques explotaron vulnerabilidades conocidas para las que había parches disponibles».

Por eso, la aplicación de parches —ya sea mediante actualizaciones de software reales o virtualmente mediante el uso de un firewall de aplicaciones web— debe ser la máxima prioridad cuando se divulgue una nueva CVE en cualquiera de las bibliotecas que constituyen el 79 % de su aplicación. Si esa CVE está relacionada con la plataforma (piense en Apache Killer), más vale que la prioridad sea «dejarlo todo», porque identificar servidores web y de aplicaciones es aún más fácil que buscar vulnerabilidades en bibliotecas.

Lo cierto es que, aunque no tengas un perfil lo bastante destacado como para ser un objetivo, sigues estando en riesgo. Probablemente utilices la misma pila tecnológica que las organizaciones de alto perfil, lo que significa que es muy posible que los ataques no dirigidos acaben encontrándote. Si crees que no será así, ten en cuenta que puedo consultar la base de datos de CVE y encontrar todas las CVE publicadas relacionadas con node.js. Después, me paso por builtwith.com y busco sitios web creados con Express, un framework de node.js. No solo descubro que el sitio tiene registrados «230.116 sitios web activos que utilizan Express y otros 263.872 sitios que utilizaron Express en el pasado», sino que además ofrece cómodamente un enlace para descargarlos.

No es exactamente el shodan.io de las aplicaciones web, pero tampoco es mucho más difícil atar cabos y dar con un exploit que funcione.

Así que no cometas el error de pensar que, por no ser «lo bastante grande», puedes ignorar una vulnerabilidad CVE en una biblioteca o plataforma web.

Así es como la gente acaba siendo tendencia en Twitter. Y no precisamente para bien.

Ve sobre seguro. Prioriza la respuesta a las CVE que afecten a toda la pila de tu aplicación. De arriba abajo.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie