La Vulnerabilidad de las Vulnerabilidades -Parte 2

Autor: XDEV para Ciberprisma

¿Qué sabemos realmente del mundo de las vulnerabilidades?

ECOSISTEMA (del Sombrero Blanco)

El ecosistema de las vulnerabilidades ha logrado grandes avances a lo largo de los años buscando sistematizar la detección, clasificación, análisis y comunicación de las vulnerabilidades e incluso dando valoraciones sobre la complejidad de explotación e impacto asociado a una vulnerabilidad.

La búsqueda de ésta estandarización y modelado permitió la creación de bases de datos públicas y privadas (comerciales) sobre las vulnerabilidades.

Uno de los esquemas de identificación y numeración más conocido y utilizado globalmente es el realizado por la fundación MITRE y se conoce como CVE (Common Vulnerabilities and Exposures-Vulnerabilidades y exposiciones comunes). Los identificadores son asignados por las autoridades de numeración conocidos como CNAs (CVE Numbering Authorities – Autoridades de numeración CVE ). Estas organizaciones distribuidas alrededor del mundo son las autorizadas en asignar los ID de CVE, información descriptiva de la vulnerabilidad, dar advertencias, medidas de mitigación, etc.

Por otra parte, las vulnerabilidades se encuentran asociadas a determinados softwares, paquetes de software o sistemas. Estos últimos pueden ser categorizados utilizando la base de datos de enumeración de plataformas comunes o CPE (Common Platform Enumeration). Éste es otro esquema de identificación estandarizado para que sea interpretado por las máquinas vinculando las vulnerabilidades con productos y plataformas IT.

Como seguramente ya sabemos, la explotación de las vulnerabilidades se basa en los pequeños errores del hardware, software, paquetes o sistema. Pero recordemos que un error no necesariamente culmina en una vulnerabilidad explotable. Para esto surgió el estándar de enumeración de debilidades comunes o CWE (Common Weakness Enumeration). Esta lista es generada con el esfuerzo de la comunidad mirando las necesidades de las partes (entidades de gobierno, mundo académico y la industria en general), priorizando teóricamente las debilidades del software de manera coherente, flexible y abierta.

Ambos esquemas de identificación CVE y CWE poseen sus sistemas de puntuación (scoring). Las entradas CWE se basan en el sistema de puntuación CWSS (Common Weakness Scoring System) y las entradas CVE en su sistema CVSS (Common Vulnerability Scoring System).

Existen otros esquemas de identificación y numeración que incluyen el boletín de seguridad de Microsoft, la base de datos de Seebug (SSV) o las recomendaciones de seguridad de VMWARE, VMSA (VM Security Advisory). No sólo existen dichos esquemas para las vulnerabilidades sino también para modalidades de ataques y amenazas, como ser CAPEC (enumeración y clasificación de patrones comunes de ataque) desarrollado por MITRE o la metodología Cadena Cyber Kill (por sus siglas en inglés, CKC) de Lockheed Martin. Esperemos más adelante poder hablar sobre los aspectos de inteligencia de amenazas que introduce CKC, con descripciones de modelos para comprender los comportamientos de los atacantes.

CVE

¿Quién crea el estándar?

La corporación MITRE es una organización privada sin fines de lucro creada en 1958 con el fin de guiar al gobierno de los Estados Unidos en lo referente a ingeniería y temas técnicos.

Desde el 2009 fue elegida para operar los centros de investigación y desarrollo financiados con fondos federales (FFRDC) del Instituto de Ingeniería y Desarrollo de Sistemas de Seguridad Nacional (HSSEDI). El departamento de seguridad nacional de EEUU estableció el HSSEDI como su principal recurso de ingeniería en sistemas para satifacer su demanda de experiencia con un rápido acceso al mejor nivel.

Vulnerabilidades y exposiciones comunes (CVE)

Dijimos que es un código de identificación único, conocido como identificador CVE (CVE-ID) y está formado por las siglas CVE seguidas por el año en que es registrada la vulnerabilidad o exposición y un número arbitrario de cuatro o más dígitos.

¿Quiénes intervienen?

Actualmente existen 157 organizaciones de 26 países en CVE
Vendedores y proyectos: 142
Investigadores de vulnerabilidades: 26
Certs Nacionales y de industrias: 7
ROOT CNAs: 1 (MITRE)
Alto nivel ROOT CNAs:2 (CISA-JPCERT/CC)

Ciclo de vida

La cronología de los diferentes eventos que llevan a una vulnerabilidad desde ser detectada a encontrar su solución se conoce como el ciclo de vida de la misma.

Este ciclo comprende períodos de tiempo que pueden ser significativos de cara a los riesgos y a las oportunidades de los atacantes. Un claro ejemplo de ésto son los tiempos que existen entre el momento en que se establece un ID CVE y cuando el mismo es divulgado.

El ciclo suele estar dividido en 3 grandes etapas:

– Presentación inicial y tratamiento: donde el CVE Content Team analiza, investiga y procesa las solicitudes de registro

-Candidatura: Asignación del CVE-ID. Esta puede ser directa por parte del CVE Content Team, después de que éste realice el estudio de la nueva vulnerabilidad. Directa por parte del CVE Editor, en caso de una vulnerabilidad difundida ampliamente (tipo día cero- 0 day). Reserva de un identificador por parte de una organización o individuo.

-Etapa de publicación en la lista (una vez aceptada la candidatura), donde puede prolongarse por tiempo indefinido, ya que incluye procesos de revisión o de agregado de contenido.

En resumidas cuentas, los informes de CVE pueden provenir de cualquier persona que descubra una falla y la notifique, como algún proveedor, investigador o simplemente un usuario astuto. Una de las maneras en que estas vulnerabilidades son detectadas es a través de la oferta de recompensas por parte de los proveedores por detectar fallas de seguridad, para incentivar su divulgación responsable.

La información de la falla llegará a un CNA de un modo u otro, quien asigna un número de identificación de CVE a la información, escribe una descripción breve e incluye las referencias. Luego, la entrada de CVE se publica en el sitio web de CVE. Es posible que no todos estos pasos ocurran de inmediato, ya que los proveedores suelen mantener en secreto las fallas de seguridad hasta que se desarrolle y pruebe una solución. De esta manera, se reducen las oportunidades para aquellos que buscan aprovecharse de las fallas sin parches.

A continuación podemos ver gráficamente el ciclo de vida de las vulnerabilidades, realizado por ENISA (agencia de ciberseguridad de la Unión Europea).

Puntuación

El análisis de riesgo de una vulnerabilidad es cuantificado mediante un sistema de puntuación que intenta indicar cuál es la gravedad de la misma. Este sistema de puntuación es conocido como CVSS (Common Vulnerability Scoring System) y es llevado adelante por el foro de equipos de seguridad y respuesta de incidentes (FIRST). La última versión es la 3.1, implementada en JUNIO de 2019, pero es frecuente ver valores de la v2.0 en vulnerabilidades anteriores a JUNIO de 2015 (cuando se publicó la v3.0) mientras se prepara una version 4.0 con un listado de mejoras que podemos ver aquí. Por lo general, se proporciona como un valor cualitativo (bajo/medio/alto).

En su versión actual el sistema de puntuación utiliza y pondera 3 métricas diferentes:

1.Métricas básicas (obligatorias):

• Métricas de explotación :
  – Vector de ataque: ataque físico o desde internet.
  – Complejidad del ataque: dificultad de explotación. Condiciones requeridas.
  – Privilegios requeridos.
  – Interacción del usuario: necesidad de que un usuario (no el atacante) intervenga.
• Alcance: afecta a otros componentes, una vez explotada la vulnerabilidad o no.
• Métricas de impacto : Confiabilidad – Integridad – Disponibilidad

2.Métricas Temporales (opcional): Son métricas que pueden cambiar en el tiempo.

• Madurez del código de explotación: sin prueba, teóricos a totalmente desarrollados.
• Nivel de solución/remedio: métricas del estado de los parches.
• Confianza del reporte: describe la credibilidad de los datos técnicos publicados.

3.Métricas ambientales (opcional): La intención de esta métrica es permitir personalizar/customizar. Una organización puede redefinir las métricas para adaptarlas a su propio panorama TI.

En esta oportunidad, no trataremos el esquema de puntuación en profundidad pero sí es importante recalcar que las mismas vulnerabilidades pueden ser de mayor riesgo o no dependiendo de nuestro ambiente y nuestra ponderación a métricas como confiabilidad, integridad y disponibilidad de la información.

Conclusiones

Sin lugar a dudas, existe una necesidad de lograr establecer estándares en el ambiente de las vulnerabilidades y los ataques que permitan acelerar y mejorar la comunicación entre todas las partes (víctimas, industria, público en general, etc). Más allá de lo logrado por la entidad sin fines de lucro como la corporación MITRE, es importante cuestionarse sobre quiénes participan y de qué manera. De igual manera que vemos números o valoraciones cualitativas como “riesgosas o de bajo riesgo” sin recibir demasiada información de cómo se obtuvieron dichos valores o valoraciones.

En el mundo, varias organizaciones dependen sólo de una fuente de información, algo que sin dudas no es bueno como estrategia, y no sólo eso sino que entre fuentes existen direfencias o discrepancias. Un simple ejemplo de ésto son las diferencias entre versionados del sistema de puntuación CVSS, algo que no suele aclararse en el momento en que alguien de la industria (tal vez incluso CNA) presenta cifras y/o valuaciones estadísticas, lo cual influirá en la toma de decisiones varias, desde compras/adquisiciones de software y/o hardware hasta en la planificación defensiva, planes de contingencia, etc. Escuchar pronósticos de lluvia, basándonos en la húmedad ambiente, de quienes venden sensores de humedad, sin que ellos sepan dónde vivimos, no siempre es preciso y/o beneficioso. Lo que no quiere decir que la húmedad ambiente, junto a otros parámetros, no sea útil para determinar un pronóstico de lluvia.

Les dejo un gráfico que muestra la puntuación de diferentes vulnerabilidades bajo 2 versiones diferentes de CVSS ( v2 y v3).

Observemos la primera línea para entender que la misma vulnerabilidad para el versionado 2 resulta crítica, mientras que para el 3 es de alto riesgo. Tomando como crítico de 9 a 10 puntos y alto de 7 a 8.9. Ambas tablas tomadas de un informe EDGESCAN 2021.

Sin dudas, la puntuación CVSS es una estimación, no es una ciencia exacta, es por esto que es necesario utilizar las métricas ambientales para una mejor personalización de la misma.

Por otra parte, bajo ninguna circunstancia debemos únicamente mirar las vulnerabilidades críticas. Puede ser más perjudicial dejar sin solución 15 o más vulnerabilidades con un puntaje debajo de 7 que solucionar una de 9 puntos. Sobre todo si partimos de la base no precisa, donde las vulnerabilidades valuadas debajo de 7 puntos podrían en realidad ser de 8 puntos para nuestra organización en función de las métricas ambientales. O sencillamente, los investigadores pueden cambiar de valoración cierta vulnerabilidad en el transcurso del tiempo. Es importante para ésto que en las valoraciones se dejen en claro no sólo el versionado utilizado sino también los parámetros utilizados y valorados.

Sólo para que lo visualicen he aquí un ejemplo: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

CVSS 3.1 / AV (vector de ataque): N (red) / AC (complejidad de ataque): H (alta) / PR (privilegios requeridos) : N (ninguno) / UI (interacción del usuario): N (ninguna) / S (alcance): U (sin cambios) cambios) / C (confidencialidad) : H (alta) / I (integridad) : H (alta) / A (disponibilidad): N (ninguno). Esto da una vulnerabilidad de valor: 7.4

Ahora, si agregamos al análisis de la vulnerabilidad parámetros temporales: E:P/RL:O/RC:C, la puntuación obtenida es de 6.7, pasando entonces de una vulnerabilidad de alto riesgo a una de riesgo medio. Simplemente cambiando la madurez del exploit de prueba de concepto (E:P a E:H) a alta, el puntaje resultante es 7.1

Si desean jugar con cálculos les dejo algunas calculadoras: CISCO v1, v2, v3, v3.1 y la oficial v3.1

Asimismo, debemos tener en mente que las vulnerabilidades publicadas no representan el universo de vulnerabilidades. Existen diferencias estadísticamente significativas entre el nivel de gravedad de las vulnerabilidades CVE (registradas oficialmente) y las que no son CVE (es decir, aquellas que no se enumeraron ni se incluyeron en las bases de datos de CVE). Por lo general, éstas últimas suelen recibir puntuaciones más altas. Por otra parte, tenemos un lado B: quienes pagan buenas sumas de dinero por vulnerabilidades sin publicar y/o aquellas que no fueron vendidas y son utilizadas por ciberdelincuentes/ciberespías para beneficio propio.

Y para finalizar este combo letal, no debemos olvidar que las organizaciones que son objeto de ataques suelen optar por no divulgar dicha información por miedo a pérdidas económicas, entorpeciendo así los tiempos de las posibles soluciones para las potenciales víctimas.

Es importante no confundir gestión de vulnerabilidades con gestión de riesgos. La gestión de las vulnerabilidades centra su atención en cómo detectar, categorizar, inventariar y reparar debilidades. Su gestión puede realizarse basándose en el riesgo, pero permítanme repetir, no debe ser confundida con la gestión de riesgos. La gestión de riesgos es la forma de abordar la incertidumbre relativa a futuras situaciones de desastre o amenaza.

En otras palabras, si el sector IT de una organización fuera un puente, las vulnerabilidades representarían grietas, ausencia de tornillos, barandas rotas u óxidos en la estructura. La gestión de vulnerabilidades es el mantenimiento que debe recibir el puente al descubrir esas debilidades, mientras que la gestión de riesgos valora el hecho de mantenerlo en pie (cada una de sus partes), evalúa los costos e impactos de destrucciones parciales o totales, aprecia las amenazas y vulnerabilidades que podrían debilitar el puente o incluso hacerlo caer y estudia la probabilidad para que el desastre ocurra. En respuesta a preguntas tales como: ¿qué probabilidad existe de que un empleado o persona externa martille sobre una de las grietas o sobre cierta estructura crítica? ¿Qué ocurriría si el puente debiera soportar tránsito de vehículos extremadamente pesados o la posibilidad de sufrir desastres naturales como terremotos, tsunamis y/o vientos huracanados?

Parte 1

01010011 01100001 01101100 01110101 01100100 01101111 01110011 00101100 00100000 01101101 01101001 01110011 00100000 01100011 01110101 01110010 01101001 01101111 01110011 01101111 01110011 00100000 01101100 01100101 01100011 01110100 01101111 01110010 01100101 01110011 00100001

FUENTES:
https://info.edgescan.com/hubfs/Edgescan2021StatsReport.pdf
https://www.enisa.europa.eu/publications/technical-reports-on-cybersecurity-situation-the-state-of-cyber-security-vulnerabilities/at_download/fullReport

---