¿Qué tienen de particular los exploits activos y cómo podemos priorizar en consecuencia?
Rachel Cheyfitz
Shani Gal
21 de noviembre de 2019
0 minutos de lecturaNo todas las vulnerabilidades son iguales.Si bien es cierto que nunca debes ignorar una vulnerabilidad de código abierto, algunas pueden tardar en ser manipuladas y utilizadas para hackear tu sistema. Por otro lado, algunas vulnerabilidades conocidas sí representan un riesgo alto e inmediato.
En un mundo de vulnerabilidades cada vez más numerosas, es difícil encontrarlas todas y atenderlas con la rapidez necesaria. Podemos suponer que muchos responsables de mantenimiento quizá se den por vencidos antes de empezar, simplemente por la frustración que genera la cantidad.
Para distinguir y priorizar las distintas vulnerabilidades, debemos evaluar el riesgo que representa cada una, decidir cuál es el nivel mínimo de riesgo que queremos abordar y empezar por ahí.
Uno de los principales factores de riesgo es qué tan fácil resulta hackear una vulnerabilidad específica. Cuando alguien demuestra cómo aprovechar una vulnerabilidad, eso se denomina exploit. Cuando se publica ampliamente, en fuentes como publicaciones de blogs, foros, exploit-db o frameworks de explotación como metasploit, suele llamarse exploit activo.
Solo un pequeño porcentaje de las vulnerabilidades conocidas será explotado; en otras palabras, se usará para hackear un sistema. Las vulnerabilidades de mayor riesgo son las que tienen más probabilidades de ser explotadas y, por lo tanto, deben priorizarse y atenderse primero, como se muestra en el diagrama:

En esta publicación, detallamos cómo los exploits activos aumentan el riesgo, cómo evaluar ese riesgo y cómo priorizar y corregir tus vulnerabilidades con rapidez.
Apache Struts: un exploit usado en ataques reales que provocó un hackeo
Probablemente hayas oído hablar de la brecha de seguridad de Equifax, una reconocida empresa de calificación crediticia que expuso los datos personales de 145,5 millones de sus clientes. La brecha se originó en una vulnerabilidad conocida en un paquete de Apache Struts, para la que había exploits activos publicados apenas unos días antes del ataque. La disponibilidad del código del exploit ayudó a los hackers a vulnerar posteriormente los sistemas de Equifax, dos meses después de su publicación, y las consecuencias fueron devastadoras. Consulta la cronología de los ataques a Apache Struts a continuación:

¿Qué es la madurez del código de exploit y cómo influye en el riesgo de una vulnerabilidad?
Usamos la madurez de cualquier código de exploit (o madurez del exploit, para abreviar) para medir qué tan viable es realmente una vulnerabilidad en el mundo real, en función de lo siguiente:
Si el exploit se ha publicado (¿está “activo”?); y
La “utilidad” real de esos exploits publicados; es decir, si esas publicaciones facilitan de verdad el aprovechamiento de la vulnerabilidad.
En otras palabras, si no hay ningún exploit disponible, lo más probable es que sea más difícil aprovechar una vulnerabilidad. Al mismo tiempo, aunque sí haya un exploit disponible, eso tampoco significa necesariamente que la vulnerabilidad pueda explotarse con facilidad.
Factores que influyen en el riesgo que representa un exploit publicado
En esta publicación, analicemos dos factores que influyen en la madurez del código de exploit.
Factor I: ¿qué tan viable es explotar esta vulnerabilidad?
El primer factor es si existe una brecha entre la teoría académica y su aplicación práctica, y qué tan grande es esa brecha. Para comprender los riesgos que representa un exploit activo, debemos evaluar si:
Es práctico y puede aplicarse en el mundo real, o si por ahora es solo una teoría; y
puede aplicarse en todos los casos o está limitado por ciertas condiciones
Un exploit que solo se ha discutido en teoría podría representar mucho menos riesgo que uno publicado, probado y comprobado. Del mismo modo, un exploit aplicable solo al 1 % de los casos en los que aparece la vulnerabilidad representa mucho menos riesgo que uno que demuestra cómo hackearla fácilmente, sin importar las circunstancias.
Factor II: ¿qué nivel de experiencia se necesita?
El segundo factor es el nivel de experiencia necesario para explotar realmente la vulnerabilidad. ¿Se necesita ser un hacker experto para manipularla o hasta alguien principiante puede hacerlo? Cuanto más fácil sea usar el exploit, más probable será que alguien lo haga.
Ahora que tenemos esto en perspectiva, es más fácil entender cómo los exploits publicados suelen estar relacionados con vulnerabilidades que terminan siendo hackeadas. No sorprende queeste estudio muestre que, cuando hay un exploit publicado disponible, la vulnerabilidad tiene cuatro veces más probabilidades de ser explotada. Otros estudios incluso han afirmado que la publicación de un exploit aumenta el riesgo 7 veces.
Si ya tenemos CVSS, ¿por qué también necesitamos la madurez del exploit?
El Sistema de Puntuación de Vulnerabilidades Comunes (CVSS) ya pondera algunos factores de riesgo en su cálculo, incluida la madurez del código, que mide si hay código de exploit público relevante disponible. Sin embargo, a medida que la cantidad de vulnerabilidades conocidas aumenta exponencialmente, el sistema integral de puntuación no siempre refleja el riesgo real (o la falta de este) que puede representar una vulnerabilidad. En una publicación de su blog a principios de este año, Liran Tal señaló que, si bien “la puntuación de vulnerabilidad CVSS la determinan varias partes reconocidas, el complejo sistema consta de más de una docena de características clave y, sin la orientación, la experiencia y la información de respaldo adecuadas, es fácil cometer errores”.
Priorizar según la madurez del exploit no solo es acertado, sino también eficaz
Al priorizar específicamente según la madurez del exploit, podemos identificar con eficacia las vulnerabilidades más riesgosas y reducir el conjunto priorizado a solo alrededor del 10 % del total. Entre los clientes de Snyk, solo entre el 4 % y el 12 % de sus vulnerabilidades tienen un exploit maduro disponible; la cifra varía según el ecosistema (consulta la tabla a continuación). Este hallazgo coincide con otros datos, como la estadística que se encuentra aquí, según la cual el 5,5 % de las vulnerabilidades publicadas tienen exploits que se han observado activos.
El porcentaje de vulnerabilidades explotables respecto del total puede variar entre ecosistemas, según el uso de los paquetes. En la tabla a continuación se muestran los datos promedio de los clientes de Snyk para algunos ecosistemas clave:
Ecosistema | Vulnerabilidades explotables |
|---|---|
JavaScript | 19,1 % |
Java | 3,9 % |
Python | 11,6 % |
¿Debemos corregir otras vulnerabilidades? Claro que sí. Toda vulnerabilidad conlleva un riesgo (aunque algunas sean más riesgosas que otras) y hay muchas otras formas de priorizar, que abordaremos más adelante. En definitiva, como todas las vulnerabilidades representan un riesgo, debemos mantenernos alerta al priorizarlas. La mejor manera de empezar es evaluar la madurez del código de exploit.
Entonces, ¿cómo sé cuáles de mis vulnerabilidades tienen exploits activos?
Para ayudar a nuestros usuarios y protegerlos, ahora les permitimos priorizar las vulnerabilidades detectadas en sus proyectos según la madurez del exploit.
Decidimos usar tres categorías basadas en nuestra investigación y en CVSS:
Maduro: hay un exploit de código publicado que puede usarse fácilmente para aprovechar esta vulnerabilidad.
Prueba de concepto: hay una prueba de concepto teórica publicada o una explicación detallada que demuestra cómo explotar esta vulnerabilidad.
Sin exploits conocidos: no se encontró código de prueba de concepto ni un exploit para esta vulnerabilidad, o no están disponibles públicamente.
Al consultar las vulnerabilidades de tu proyecto, ahora puedes ver si una vulnerabilidad específica tiene un exploit activo. También puedes filtrar y priorizar los resultados del análisis, corregir las vulnerabilidades en consecuencia y consultar un informe agregado. Así, puedes priorizar y atender primero las vulnerabilidades más importantes y riesgosas.

¡Empieza ahora!
Empezar es fácil:
1. Inicia sesión en Snyk y ve a la página detallada de Projects de cualquiera de tus proyectos:

2. Verás los nuevos filtros en el lado izquierdo:

3. Haz clic en Mature para ver las vulnerabilidades de mayor riesgo según la madurez del exploit y empezar a corregirlas.
Consulta nuestra documentación para obtener más detalles.
¿Qué sigue?
Ahora que lanzamos la opción de priorizar según la madurez del exploit, seguiremos presentando métodos adicionales para priorizar la corrección de vulnerabilidades y ayudar a nuestros usuarios a proteger eficazmente sus dependencias.
Empieza con Capture the Flag
Aprende a resolver desafíos de Capture the Flag viendo nuestro taller virtual introductorio a pedido.
