Skip to main content

¿Qué tienen de particular los exploits activos y cómo podemos priorizar en consecuencia?

Escrito por
Headshot of Rachel Cheyfitz

Rachel Cheyfitz

Headshot of Shani Gal

Shani Gal

prioritize vulns

21 de noviembre de 2019

0 minutos de lectura

No 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:

Diagrama de Venn que muestra todas las vulnerabilidades divulgadas, las vulnerabilidades explotadas y las vulnerabilidades en tu entorno, y destaca las vulnerabilidades clave que pueden ser

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:

Cronología del ataque a Apache Struts 2 que muestra la divulgación de la vulnerabilidad, la solución, la publicación del exploit y el aumento de los ataques entre el 14 de febrero y el 29 de abril.

¿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
**
(datos agregados de Snyk)**

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.

Panel de vulnerabilidades que muestra un problema de alta gravedad de Zip Slip en adm-zip y una opción para abrir un pull request con la corrección.

¡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:

Panel de proyectos que muestra repositorios con opciones de búsqueda y filtros por origen, una barra de progreso de importación y recuentos de problemas de nivel alto, medio y bajo.

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

Escala de madurez de exploits que muestra las categorías Maduro, Prueba de concepto, Sin exploit conocido y Sin datos, con sus cantidades y descripciones.

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.