Puntuación de vulnerabilidades de seguridad 101: presentamos CVSS para CVE

Al igual que se clasifican los errores de software según su nivel de gravedad, también se clasifican las vulnerabilidades de seguridad, ya que es necesario evaluar su impacto y riesgo, lo que ayuda a gestionar las vulnerabilidades.

El Forum of Incident Response and Security Teams (FIRST) es una organización internacional de investigadores y científicos informáticos de confianza en el ámbito de la seguridad, a quienes se les encomendó la tarea de crear prácticas recomendadas y herramientas para los equipos de respuesta a incidentes, así como estandarizar las políticas y metodologías de seguridad.

Una de las iniciativas de FIRST es un grupo de interés especial (SIG) responsable de desarrollar y mantener la especificación del Sistema común de puntuación de vulnerabilidades (CVSS), con el objetivo de ayudar a los equipos a comprender y priorizar la gravedad de las vulnerabilidades de seguridad.

Puntuación de vulnerabilidades

CVSS se reconoce como un sistema de medición estándar para industrias, organizaciones y gobiernos que necesitan puntuaciones precisas y uniformes del impacto de las vulnerabilidades.

El modelo cuantitativo de CVSS garantiza mediciones reproducibles y precisas, y permite a los usuarios ver las características subyacentes de la vulnerabilidad que se usaron para generar las puntuaciones.

CVSS se usa habitualmente para priorizar las actividades de corrección de vulnerabilidades y calcular su gravedad en los sistemas de una organización.

Desafíos de CVSS

Falta de contexto de aplicabilidad

Las puntuaciones de las vulnerabilidades no siempre tienen en cuenta el contexto correcto en el que una organización usa un componente vulnerable. El sistema Common Vulnerabilities and Exposures (CVE) puede considerar distintas variables al determinar la puntuación de una organización, pero también existen otros factores que pueden afectar la forma de gestionar una vulnerabilidad, independientemente de la puntuación que le asigne un CVE.

Por ejemplo, es posible que una vulnerabilidad de gravedad alta según CVSS, detectada en un componente usado para pruebas —como un entorno de pruebas—, reciba poca o ninguna atención de los equipos de seguridad, TI o I+D. Una razón podría ser que el componente se use internamente como herramienta y no esté expuesto de ninguna manera a una interfaz pública ni sea accesible para nadie.

Además, las puntuaciones de las vulnerabilidades no contemplan consecuencias importantes, como cuando una vulnerabilidad afecta dispositivos médicos, automóviles o redes de servicios públicos. Cada organización debe clasificar las vulnerabilidades y considerar las implicaciones específicas según la relevancia y prevalencia de los componentes vulnerables en sus productos.

Puntuación incorrecta

La puntuación de una vulnerabilidad se compone de más de una docena de características clave y, sin la orientación, experiencia e información de respaldo adecuadas, es fácil cometer errores. Un estudio académico[1] reciente descubrió que los participantes respondieron correctamente solo el 57 % de las preguntas de seguridad sobre la puntuación de vulnerabilidades CVE. El estudio también explica qué indicios informativos son esenciales para mejorar la precisión y cuáles pueden generar confusión y reducirla.

No es raro encontrar falsos positivos en un CVE o imprecisiones en las puntuaciones asignadas a cualquiera de los grupos de métricas. Esto conlleva el riesgo de perder la confianza en un CVE o generar una alarma injustificada en las organizaciones.

CVSS tiene un rango de puntuación de 0 a 10, que corresponde a niveles de gravedad desde bajo hasta alto o crítico. La evaluación imprecisa de las variables puede dar como resultado una puntuación que corresponda a un nivel CVSS incorrecto. Otro estudio[2] de Carnegie Mellon University informó resultados similares sobre la precisión de las puntuaciones. El informe afirma: «Más de la mitad de los encuestados no se mantiene de forma consistente dentro de un margen de precisión de cuatro puntos CVSS», cuando una diferencia de solo 4 puntos puede cambiar la gravedad de alta o crítica a niveles inferiores.

[1] Allodi, Luca & Banescu, Sebastian & Femmer, Henning & Beckers, Kristian. (2018). Identifying Relevant Information Cues for Vulnerability Assessment Using CVSS. 119-126. 10.1145/3176258.3176340.

[2] Spring, J.M, Hatleback, E. Householder, A. Manion, A. Shick, D. "TOWARDS IMPROVING CVSS" Carnegie Mellon University, December 2018

El método de Snyk

En Snyk, usamos CVSS v3.1 para evaluar y comunicar las características de las vulnerabilidades de seguridad y su impacto.

El equipo especializado de investigación de seguridad de Snyk participa en el descubrimiento de nuevas vulnerabilidades en distintos ecosistemas. Además, revisa las puntuaciones CVE para confirmar que reflejen correctamente los niveles de gravedad y así compensar las imprecisiones de puntuación mencionadas anteriormente, cometidas por otras autoridades que emiten CVE.

La base de datos de vulnerabilidades de Snyk ofrece metadatos complementarios a los detalles CVE de cada vulnerabilidad. El equipo de investigación de seguridad agrega información seleccionada a cada vulnerabilidad, como una descripción general del componente vulnerable y detalles sobre el tipo de vulnerabilidad, enriquecidos con ejemplos y enlaces de referencia a commits, correcciones u otra información relacionada.

La siguiente imagen muestra una vulnerabilidad de seguridad de cross-site scripting (XSS) detectada en el framework frontend React, que afecta distintas versiones de la serie 16.x del módulo React DOM.

La imagen también muestra la métrica base de la puntuación CVSS v3.1 y un desglose detallado de las métricas.

Cómo funciona CVSS

A lo largo de la historia de CVSS hubo tres versiones, desde su lanzamiento inicial en 2004 hasta la adopción generalizada de CVSS v2.0 y, finalmente, la especificación actual de CVSS v3.1. El resto de este artículo se centra en CVSS v3.1.

La especificación ofrece un marco que estandariza la forma de puntuar las vulnerabilidades y las clasifica para reflejar distintas áreas de preocupación.

Las métricas de una puntuación CVSS se dividen en tres grupos:

1. Base: métricas de evaluación del impacto y la explotabilidad que no dependen del momento en que se evalúa la vulnerabilidad ni del entorno del usuario, como la facilidad con que se puede explotar. Por ejemplo, si una vulnerabilidad impide por completo el acceso a un componente vulnerable, tendrá un impacto alto en la disponibilidad.

2. Temporal: métricas que consideran circunstancias que afectan la puntuación de una vulnerabilidad. Por ejemplo, si se conoce un exploit para una vulnerabilidad, la puntuación aumenta; si hay un parche o una corrección disponible, disminuye.

3. Entorno: métricas que permiten adaptar la puntuación al impacto en el entorno específico de un usuario o una organización. Por ejemplo, si la organización considera muy importante la disponibilidad de un componente vulnerable, puede establecer un requisito alto de disponibilidad y aumentar la puntuación CVSS general.

El grupo de métricas base constituye la base de un vector CVSS. Si hay métricas temporales o de entorno disponibles, se incluyen en la puntuación CVSS general.

Grupos de métricas CVSS 3.0 de FIRST / CC-BY-SA-3.0

Puntuaciones base

Las métricas base de CVSS se componen de subgrupos de métricas de explotabilidad e impacto, y evalúan su aplicabilidad a un componente de software que puede afectar a otros componentes (software, hardware o dispositivos de red).

La explotabilidad representa el esfuerzo y los medios necesarios para explotar la vulnerabilidad de seguridad, y se compone de lo siguiente:

• Vector de ataque (AV): representa los cuatro medios por los que puede llevarse a cabo un ataque: físico, local, adyacente y de red. Cuanto más accesible sea el medio, mayor será la puntuación.

Por ejemplo, una vulnerabilidad de cross-site scripting (XSS) en jQuery que pudiera aprovecharse en un sitio web público se puntuaría como un vector de ataque de red.

• Complejidad del ataque (AC): puede tener una puntuación baja o alta, según si el ataque requiere que se cumpla una circunstancia o configuración especial como condición previa para ejecutarse correctamente. Por ejemplo, un path traversal, relativamente fácil de ejecutar y detectado, entre otros casos, en el paquete Next.js en 2018 y 2017, tiene una complejidad de ataque baja. Un ejemplo de complejidad de ataque alta es un ataque de temporización detectado en Apache Tomcat.

• Privilegios necesarios (PR): puede tener uno de estos niveles de puntuación: ninguno, bajo o alto. Estos niveles corresponden a los privilegios que debe obtener un atacante para explotar la vulnerabilidad. Por ejemplo, una inyección de código arbitrario en Wordpress MU permitía que usuarios autenticados cargaran y ejecutaran archivos maliciosos de forma remota. Esto corresponde a un nivel bajo, porque cualquier usuario autenticado podría ejecutar el ataque, independientemente de su rol y permisos en una aplicación de Wordpress.

• Interacción del usuario (UI): la puntuación es alta cuando no se requiere ninguna acción del usuario para ejecutar correctamente un ataque, y más baja cuando se requiere algún tipo de interacción. Por ejemplo, para que los módulos maliciosos comprometan el entorno, primero es necesario que el usuario interactúe con ellos al instalar el paquete malicioso. En el ecosistema npm, hemos visto docenas de paquetes maliciosos; uno de ellos fue un intento de robar variables de entorno mediante un ataque de typosquatting en un paquete llamado crossenv. Estos ejemplos reciben puntuaciones bajas porque requieren la interacción del usuario.

El subgrupo de métricas de impacto representa las consecuencias de una explotación exitosa de un componente vulnerable para la confidencialidad, integridad y disponibilidad. Se compone de lo siguiente:

• Confidencialidad (C): mide el grado de pérdida de confidencialidad del componente afectado, por ejemplo, la divulgación de información a usuarios no autorizados. Por ejemplo, se produce una pérdida alta de confidencialidad cuando se explota una vulnerabilidad de inyección de scripts arbitrarios en aplicaciones Angular (más precisamente, AngularJS). Una entrada del usuario que se origina como evento DOM y no se sanea correctamente puede dar lugar a la ejecución de código.

• Integridad (I): mide el grado de pérdida de integridad del componente afectado, como la posibilidad de modificar datos tras explotar correctamente el componente vulnerable. Por ejemplo, se produjo una pérdida alta de integridad en el framework de código abierto Apache Struts 2, cuando una serialización incorrecta permitió ejecutar comandos arbitrarios. Esta vulnerabilidad fue noticia en 2017 por su papel en la filtración de datos de Equifax. Puedes leer más al respecto en nuestro blog.

• Disponibilidad (A): mide la pérdida de disponibilidad de los recursos y las funciones del componente afectado, por ejemplo, si un ataque relacionado con el componente vulnerable podría provocar una denegación de servicio para los usuarios. Por ejemplo, una versión de lodash vulnerable a la denegación de servicio mediante expresiones regulares puede causar una interrupción alta de la disponibilidad. Cuando lodash se usa como biblioteca frontend, la explotación de esta vulnerabilidad afecta los navegadores de los usuarios finales; pero el problema se agrava cuando lodash se usa en una aplicación Node.js del lado del servidor, donde el impacto hace que el bucle de eventos deje de responder y afecta todas las solicitudes entrantes de un servicio API.

Es importante tener en cuenta que, cuando el alcance cambia, las métricas de impacto representan las consecuencias de mayor grado, ya sea para el componente vulnerable en sí o para el componente afectado.

Por último, el alcance es una métrica nueva que se introdujo en CVSS v3.0. El alcance indica si una vulnerabilidad de seguridad afecta recursos adicionales, más allá de sí misma. Los valores asignados a la métrica de alcance pueden ser sin cambios o con cambios. Si la explotación exitosa de un componente vulnerable afecta recursos regidos por otro ámbito de autorización, significa que el alcance ha cambiado.

Por ejemplo, las vulnerabilidades de scripting entre sitios (XSS) en phpMyAdmin se considerarían un cambio de alcance porque el componente vulnerable es phpMyAdmin, que se ejecuta como una aplicación PHP del lado del servidor; sin embargo, el alcance del impacto es el navegador del usuario.

Las vulnerabilidades de seguridad, como la ejecución remota de comandos, en la que el componente vulnerable cuenta con privilegios muy elevados, son un buen ejemplo de cómo el alcance puede extenderse más allá de la autorización de ese único componente y afectar potencialmente a otros componentes.

Puntuaciones temporales

El propósito de la puntuación temporal es proporcionar contexto sobre el momento en que se evalúa la gravedad de una CVE. Por ejemplo, si existen exploits públicos conocidos para una vulnerabilidad de seguridad, su nivel de criticidad y la gravedad de la CVE aumentan debido a la facilidad considerable para acceder a los recursos necesarios para llevar a cabo esos ataques.

La puntuación CVSS general se calcula incluyendo la parte de la puntuación temporal y se basa en el valor de mayor riesgo. Solo se incluye si existe riesgo temporal. Por lo tanto, los valores temporales asignados a la vulnerabilidad mantienen la puntuación CVSS general como mínimo en el mismo nivel o incluso pueden reducirla, pero no pueden aumentarla.

Las métricas de puntuación temporal son:

• Madurez del código de explotación (E)—mide la probabilidad de que se explote la vulnerabilidad, según el grado de madurez del código de explotación público disponible. Los valores posibles son 'U' si no hay código de explotación disponible; 'P' si hay código de prueba de concepto conocido; 'F' si hay código de explotación funcional disponible; o 'H' si existe una alta probabilidad de explotación, ya sea gracias a herramientas de ataque automatizadas, como el conocido framework Metasploit, o en los casos en que no se requiere un código de explotación especial para ejecutar un ataque exitoso.

• Nivel de remediación (RL)—mide la facilidad para aplicar una mitigación o completar la remediación de esta vulnerabilidad. Por ejemplo, si un proveedor divulga y gestiona correctamente una vulnerabilidad, para cuando se haga pública la CVE, el componente vulnerable ya debería tener una ruta de actualización. Los valores posibles son 'O' si el proveedor ofrece una solución oficial mediante un parche o una actualización; 'T' si hay una solución temporal disponible, como una versión con correcciones urgentes o alternativas para mitigar la vulnerabilidad; 'W' si se conoce una alternativa, pero no es oficial ni cuenta con el respaldo del proveedor; y, por último, 'U' si no hay ninguna mitigación o remediación de conocimiento público.

• Confianza en el reporte (RC)—mide el grado de confianza en el reporte de la vulnerabilidad. A veces, los reportes de seguridad divulgados no proporcionan información de contexto suficiente, material de respaldo en forma de una prueba de concepto o pasos para reproducir el problema, lo que dificulta evaluar la credibilidad del reporte y su impacto. Los valores posibles son ‘C’ para indicar un alto nivel de certeza al reproducir el reporte, ‘R’ si se proporcionaron datos razonables para confirmar el reporte y ‘U’ si se desconocen detalles sobre la causa raíz de la vulnerabilidad.

A las tres métricas temporales se les puede asignar una ‘X’ para indicar que no se deben asignar valores ni deben afectar la puntuación base.