Novedades de CVSS 4.0
8 de noviembre de 2023
0 minutos de lecturaEn esta publicación del blog, destacaremos la perspectiva de Snyk sobre el nuevo marco de puntuación de vulnerabilidades, CVSS 4.0, que se publicó el 1 de noviembre de 2023.
¿Por qué era necesario?
El marco revisado surge como una evolución natural del panorama de las vulnerabilidades de ciberseguridad y como una solución para superar las debilidades de la metodología anterior. Desde su publicación en 2016, CVSS 3 ha demostrado ser una herramienta de evaluación sólida que los profesionales utilizan para describir el posible impacto y nivel de riesgo de diversas vulnerabilidades, lo que ayuda a organizaciones y personas a protegerse mejor contra las ciberamenazas.
Siete años después, CVSS 4.0 es la siguiente versión, cuyo objetivo es ofrecer mayor granularidad y perfeccionar aún más la metodología de puntuación para adaptarse mejor a la evolución de las amenazas de ciberseguridad y del panorama digital.
¿Qué cambiará?
Analicemos los cambios que se introducirán mediante una comparación técnica entre los marcos 3.1 y 4.0.
Nota: Los niveles y rangos de gravedad de las puntuaciones (Low, Medium, High y Critical) para cada valor cualitativo de gravedad seguirán siendo los mismos.
Parámetro Attack Vector
El nuevo parámetro Attack Vector, además de incorporar algunos cambios semánticos que proponen una especificación más inclusiva (por ejemplo, componente en lugar de sistema, o físico en lugar de proximidad), tendrá el mismo propósito que antes.
Por lo tanto, no esperamos cambios en la forma de usar este parámetro al evaluar vulnerabilidades con CVSS 4.0.
Parámetro Attack Complexity
El parámetro Attack Complexity de CVSS 3.1 se dividirá en Attack Complexity y Attack Requirements para permitir mayor granularidad.
El nuevo parámetro Attack Complexity está diseñado para usarse en ataques muy especializados que implican «evasión o elusión de técnicas que mejoran la seguridad».
Por otro lado, Attack Requirements abarcará los casos en que la explotación exitosa «depende de la presencia de condiciones específicas de implementación y ejecución del sistema vulnerable que permitan el ataque».
La principal diferencia entre Attack Complexity y Attack Requirements dependerá del propósito de las condiciones específicas que permiten el ataque. Según el documento de especificación, Attack Requirements se usará únicamente para capturar escenarios que NO estén cubiertos por el parámetro Attack Complexity nuevo (es decir, no se usará en escenarios que eludan técnicas de mitigación de exploits).
En el ecosistema de código abierto, esperamos un menor uso de este parámetro, ya que Attack Complexity solo se usará para ataques muy especializados. Sin embargo, probablemente habrá un mayor uso de Attack Requirements, ya que abarcará condiciones que «surgen de forma natural como consecuencia de la implementación y ejecución del sistema vulnerable».
Parámetro Privileges Required
El nuevo parámetro Privileges Required solo incorpora pequeños cambios para ofrecer mayor claridad y una redacción más concisa. El valor del parámetro también se mantiene sin cambios.
Anticipamos que no habrá cambios en la forma de usar este parámetro para evaluar vulnerabilidades.
Parámetro User Interaction
En el documento de especificación de CVSS 4.0 se observan cambios importantes en el nuevo parámetro User Interaction, o, más específicamente, en sus valores. Esto contribuirá a una evaluación más precisa de las condiciones del ataque.
User Interaction tendrá 3 valores posibles (en lugar de 2 en CVSS 3.1).
None: este valor incluye una definición mejorada que pone énfasis en el usuario humano. Por lo tanto, puede usarse cuando «el sistema vulnerable puede explotarse sin que interactúe ningún usuario humano, aparte del atacante».
Passive: el uso previsto abarca ataques que pueden llevarse a cabo mediante acciones involuntarias de la víctima.
Active: a diferencia del caso anterior, este valor se usará cuando el ataque dependa de que la víctima «realice interacciones específicas y conscientes con el sistema vulnerable y la carga útil del atacante». Como alternativa, las «interacciones de la víctima podrían eludir activamente los mecanismos de protección y provocar la explotación de la vulnerabilidad».
Estas incorporaciones facilitarán una mejor distribución de la gravedad de las vulnerabilidades al reemplazar los valores anteriores de User Interaction. Por lo tanto, cambiará el uso de este parámetro en el proceso de evaluación de vulnerabilidades.
Tríada CIA
No hay modificaciones importantes en la tríada CIA, aparte de pequeños cambios de redacción cuyo objetivo es mantener la coherencia entre las definiciones del documento de especificación.
Lo más probable es que el uso de estos parámetros no cambie.
Parámetro Scope
El parámetro Scope será reemplazado por Subsequent System Impact Metrics, lo que favorecerá una distribución más uniforme de la gravedad y, a la vez, ofrecerá mayor precisión al evaluar el impacto de una vulnerabilidad.
Este cambio no solo permitirá parametrizar el cambio de alcance, sino también señalar sus consecuencias en el sistema posterior.
El nuevo enfoque cambiará el proceso de evaluación de vulnerabilidades y ofrecerá una forma más precisa de evaluar el impacto.
Métricas de amenazas
También hay cambios importantes en las Threat Metrics (antes conocidas como Temporal Score), pero solo revisaremos Exploit Code Maturity. Este parámetro pasará a llamarse Exploit Maturity y tendrá cuatro valores posibles (en lugar de cinco; se eliminará el valor Functional). Se mejoraron las nuevas definiciones de los valores de Exploit Maturity, que ahora incluyen requisitos específicos que deben cumplirse para justificar su uso.
Not Defined: el valor debe usarse cuando «no se dispone de información confiable sobre inteligencia de amenazas para determinar las características de Exploit Maturity».
Attacked (antes High): el valor puede usarse cuando 1) se hayan reportado ataques o 2) el exploit haya alcanzado un nivel de madurez que permita integrarlo en diversas soluciones, como los kits de exploits, cuyo objetivo es simplificar y automatizar la explotación.
PoC: debe usarse cuando se cumpla uno de los siguientes requisitos:
«La prueba de concepto está disponible públicamente».
«No se tiene conocimiento de intentos reportados de explotar esta vulnerabilidad».
«No se tiene conocimiento de soluciones disponibles públicamente que se utilicen para simplificar los intentos de explotar la vulnerabilidad».
Unreported: no es PoC ni Attacked, pero es distinto de Not Defined (se usa en escenarios donde hay información de inteligencia de amenazas).
Estos cambios modificarán el uso del parámetro Exploit Maturity.
¿Cómo afectarán los cambios a los usuarios?
Además de lo señalado en la sección anterior, revisaremos tres ejemplos de vulnerabilidades e intentaremos evaluarlas con CVSS 4.0 mientras explicamos el proceso.
Ejecución remota de código que afecta al paquete microsoft.chakracore, versión 1.10.1
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H — 7.5 High
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:L/SI:L/SA:L — 7.6 High
El ataque puede llevarse a cabo a través de la red, por lo que corresponde AV:N. Según la especificación, se debe usar AC:H cuando se eluden protecciones como ASLR. Con la información disponible sobre esta vulnerabilidad, creemos que corresponde a este escenario. No hay indicios de requisitos previos de privilegios bajos ni altos, por lo que corresponde PR:N. La explotación exitosa depende de la presencia de otro usuario humano. Sin embargo, no hay pruebas suficientes de que el usuario tenga que interactuar activamente con la carga útil del atacante, por lo que corresponde UI:P. Dado que «un atacante que explotara con éxito la vulnerabilidad podría tomar el control de un sistema afectado», se ven afectadas tanto la confidencialidad como la integridad, por lo que corresponden VC:H, VI:H y VA:N. Creemos que el impacto también se reflejará en el sistema posterior, que en este caso es la máquina de la víctima. Sin embargo, el impacto dependerá de los permisos que tenga el atacante en la máquina de la víctima, por lo que corresponden SC:L, SI:L y SA:L.
Ejecución remota de código que afecta al paquete ipython, versión 8.10.0
CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:L — 4.2 Medium
CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N — 1.0 Low
Debido al propósito del paquete, el ataque solo puede llevarse a cabo de forma local, por lo que corresponde AV:L. La explotación exitosa no requiere eludir mecanismos de seguridad, pero está condicionada por el sistema operativo y una configuración de implementación específica (la biblioteca `ctypes`, incluida de forma predeterminada en las instalaciones de Python, debe estar deshabilitada). Este escenario corresponde a AC:L y AT:P. El atacante también necesitaría acceso al entorno local, lo que implica PR:L. La víctima tendrá que interactuar de forma activa y consciente con la carga útil del atacante al invocar la función vulnerable en «Windows en un entorno de Python donde `ctypes` no está disponible», lo que significa que corresponde UI:A. Con la información disponible sobre esta vulnerabilidad, creemos que no habrá impacto en la tríada CIA dentro del sistema vulnerable, sino únicamente en el sistema posterior. Esto se debe a que los comandos se ejecutan en el sistema host y la instalación de Python no se ve afectada directamente. Además, los comandos de shell están «limitados al alcance del proceso actual», lo que se traduce en SC:L y SI:L. Como no hay pruebas de que la disponibilidad del sistema posterior se vea afectada, corresponde SA:N.
Cross-site Scripting que afecta al paquete org.jenkins-ci.plugins:rundeck, versión 3.6.11
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N — 5.4 Medium
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N — 5.1 Medium
El ataque puede llevarse a cabo a través de la red y no requiere eludir «técnicas de mitigación de exploits» ni ninguna configuración especial de implementación para tener éxito; por lo tanto, corresponden AV:N, AC:L y AT:N. Sin embargo, el atacante necesitará una cuenta activa para llevar a cabo el exploit. Como se trata de un XSS almacenado, la víctima no necesita realizar acciones específicas con la carga útil, por lo que corresponde UI:P. El impacto se reflejará en el sistema posterior, ya que el atacante puede leer o modificar datos en el navegador de la víctima, lo que da como resultado VC:N/VI:N/VA:N/SC:L/SI:L/SA:N.
first.org publicó ejemplos oficiales en first.org.
Conclusiones generales
Podemos observar de inmediato que CVSS 4.0 ofrecerá mejoras en el proceso de evaluación de vulnerabilidades. Los usuarios podrán identificar con mayor precisión el impacto en la seguridad, lo que contribuirá a una mejor priorización de los problemas de seguridad. En cuanto a la distribución de la gravedad, es razonable esperar que CVSS 4.0 dé como resultado una distribución más equilibrada gracias a su mayor granularidad. Este equilibrio evitará una concentración excesiva de vulnerabilidades en un rango de gravedad particular. También anticipamos que habrá menos vulnerabilidades con una puntuación de gravedad elevada, sobre todo porque CVSS 4.0 «mantendrá los mismos rangos de puntuación para cada valor cualitativo de gravedad» que CVSS 3.1.
¿Cuándo estará disponible CVSS v4.0?
Desde el 18 de junio, el equipo de seguridad de Snyk comenzó a asignar la versión 4.0 de CVSS a todas las nuevas vulnerabilidades de seguridad identificadas por Snyk Open Source. Además de basar la gravedad de los nuevos problemas en CVSS v4.0, Snyk irá exponiendo gradualmente los nuevos atributos del vector en los flujos de trabajo de las distintas líneas de productos y actualizará la forma de consultar directamente la nueva información.
Si te interesa saber más sobre cómo usar el marco CVSS para evaluar la gravedad de las vulnerabilidades, consulta nuestra publicación de blog «Conceptos básicos sobre la puntuación de vulnerabilidades de seguridad».
Referencias:
CVSS 4.0:
https://www.first.org/cvss/v4.0/examples