CVSS 3.0 ¿Qué es y como calcularlo?

Hoy vamos a ver algo muy elemental para todos los pentester, pero que sin embargo los aficionados al hacking que nunca han hecho un informe, quizás no lo tengan tan claro, o incluso tal vez, ni han oído hablar de ello.

                             

Cuando se realiza una auditoria de seguridad (Pentest), en busca de vulnerabilidades / brechas de seguridad, en el análisis final y consiguiente informe, las vulnerabilidades encontradas en el sistema deben de ser presentadas al cliente (responsable del sistema auditado).
En este informe, además del nombre y clase de la vulnerabilidad, lugar donde se ha encontrado, prueba de concepto de la misma para la comprensión del cliente, etc., debe de concretarse el impacto de la misma sobre el sistema. En otras palabras, debe de decirse que tan peligrosa es esta vulnerabilidad y como afectará a nuestro sistema. Para ello han de tenerse en cuenta diversos factores, ya que ni todas las vulnerabilidades son igual de peligrosas, ni un mismo tipo de vulnerabilidad puede afectar a todos los sistemas por igual (aquí entran en juego otros elementos, como la infraestructura del sistema, las versiones de software / hardware utilizados, que el sistema sea más o menos accesible, etc.).

En un ejemplo fácil de entender a todos los públicos, si situamos como equivalente a un sistema, una vivienda común, una casa, no es lo mismo que este rota  y no cierre la puerta que comunica con la calle y da acceso a la vivienda, que esté rota y no cierre la puerta que da acceso a la cocina.
En este ejemplo, el tipo de vulnerabilidad en los dos casos sería la misma, una puerta rota, pero como se puede comprender con facilidad, el impacto que producen a la seguridad de la persona que vive en esta vivienda, no es el mismo. Aunque ambas puertas deben de repararse, solo una de ellas se consideraría CRITICA y debería de repararse lo antes posible, ya que expone a toda la vivienda al acceso de personas ajenas a la misma, a robos, etc.

Volviendo al mundo del pentesting, para ayudarnos a valorar las diferentes situaciones que pueden darse a la hora de valorar el impacto de las vulnerabilidades encontradas, surge un sistema de puntuación de vulnerabilidad común (CVSS).

Este sistema proporciona un marco abierto para comunicar las características y el impacto de las vulnerabilidades de TI. Su modelo cuantitativo garantiza una medición precisa y repetible al tiempo que permite a los usuarios ver las características de vulnerabilidad subyacentes que se utilizaron para generar las puntuaciones. Por lo tanto, CVSS es muy adecuado como un sistema de medición estándar para industrias, organizaciones y gobiernos, que necesitan puntuar el impacto de vulnerabilidades de forma precisa.

Dos usos comunes de CVSS son la priorización de las actividades de corrección de vulnerabilidades y el cálculo de la gravedad de las vulnerabilidades descubiertas en los sistemas. La National Vulnerability Database (NVD) proporciona puntajes CVSS para casi todas las vulnerabilidades conocidas.

¿Qué es lo que vamos a ver o tener que poner en un informe?

En el informe que se genera tras una auditoria nos encontraremos algo similar a lo que se muestra en la siguiente imagen, y en caso de que seamos nosotros los que generemos el informe, tendremos que reflejarlo de la siguiente manera, utilizando estas métricas, que son las correspondientes a CVSS versión 3.0:

Ahora vamos a pasar a conocer de manera técnica que significan estas métricas y como podemos interpretarlas.


Clasificaciones CVSS v3.0:


                     

                       

MÉTRICAS DE EXPLOTABILIDAD:

Definen las probabilidades que tiene una vulnerabilidad de ser explotada, a continuación, se enumeran las distintas métricas que forman parte de este grupo y sus posibles valores:

Símbolo	Descripción
AV	Vector de ataque Esta métrica determina cómo puede ser explotada esta vulnerabilidad, y mide los requisitos de accesibilidad tanto físicos como lógicos que se requieren para la explotación satisfactoria de la vulnerabilidad. Los valores de esta métrica son: ·        Network (N): Requiere visibilidad a nivel de red (capa 3). ·        Adjacent (A): Requiere visibilidad a nivel de enlace (capa 2). ·        Local (L): Requiere acceso previo no privilegiado. ·        Physical (P): Requiere acceso físico.
AC	Complejidad del Ataque Esta métrica determina la complejidad de ataque requerida para hacer uso de la vulnerabilidad. Los valores de esta métrica son: ·        Low (L): No se requieren condiciones o circunstancias especiales para explotar la vulnerabilidad. ·        High (H): El éxito de un ataque depende de que se cumplan ciertas condiciones o circunstancias. Por ejemplo, una vulnerabilidad que requiere el conocimiento previo de cierta información o configuraciones del sistema.
PR	Privilege required Esta métrica determina el nivel de privilegios que un atacante debe tener antes poder explotar se forma satisfactoria una vulnerabilidad. Los valores de esta métrica son: ·        None (N): El atacante no requiere de ningún tipo de privilegio para explotar la vulnerabilidad de forma satisfactoria. ·        Low (L): El atacante requiere de privilegios mínimos (por ejemplo, acceso con un usuario básico) para explotar la vulnerabilidad de forma satisfactoria. ·        High(H): El atacante requiere de privilegios elevados (por ejemplo, acceso con un usuario administrador) para explotar la vulnerabilidad de forma satisfactoria.
UI	User Interaction Esta métrica determina si es necesaria la intervención del usuario para la explotación satisfactoria de la vulnerabilidad. Los niveles de esta métrica son: ·        None (N): La vulnerabilidad puede explotarse si ser necesaria la iteración por parte del usuario. ·        Required (R): La explotación de la vulnerabilidad requiere que el usuario lleve a cabo determinadas acciones.

SCOPE: 

El Scope determina el alcance que tiene una vulnerabilidad y si su explotación puede afectar a otros recursos o componentes más allá del sistema o la aplicación que sufre la vulnerabilidad.

Símbolo

Descripción

S

Scope Esta métrica determina si la explotación satisfactoria de la vulnerabilidad puede afectar indirectamente a otros componentes fuera del alcance del sistema o aplicación con la vulnerabilidad. Los valores de esta métrica son los siguientes: ·        Unchanged (U): El componente vulnerable y el componente afectado por la explotación de la vulnerabilidad es el mismo. ·        Changed (C): El componente vulnerable y el componente afectado por la explotación de la vulnerabilidad son distintos.

MÉTRICAS DE IMPACTO: 

Las métricas de impacto determinan las consecuencias de la explotación de la vulnerabilidad, a continuación, se enumeran las distintas métricas que forman parte de este grupo y sus posibles valores.

Símbolo	Descripción
C	Impacto en la Confidencialidad La confidencialidad es la propiedad de un documento, mensaje o dato que únicamente está autorizado para ser leído o entendido por algunas personas o entidades. Los valores de esta métrica son los siguientes: ·        High (H): El compromiso de información confidencial (passwords, claves de cifrado, etc.) es total. ·        Low (Low): El compromiso de información confidencial es parcial (se obtiene cierta información, pero sin que el atacante tenga control sobre qué información puede obtener). ·        None (N): No hay pérdida de confidencialidad.
I	Impacto en la Integridad La integridad es la propiedad de un documento, mensaje o dato que garantiza la veracidad de la información. Los valores de esta métrica son los siguientes: ·        High (H): Hay una pérdida total de integridad. Por ejemplo, un atacante puede modificar ficheros o información valiosa. ·        Low (Low): Hay una pérdida parcial de integridad. Por ejemplo, un atacante puede modificar ficheros o información, pero sin tener el control sobre qué información puede modificar. ·        None (N): No hay pérdida de integridad.
A	Impacto en la Disponibilidad La disponibilidad es la propiedad de un sistema, servicio o aplicación que es accesible sin impedimentos. Los valores de esta métrica son los siguientes: ·        High (H): Hay una pérdida total de disponibilidad. Por ejemplo, un atacante puede denegar totalmente el acceso a un recurso por parte de usuarios legítimos. ·        Low (Low): Hay una pérdida parcial de disponibilidad. Por ejemplo, un atacante puede degradar el servicio, pero no llega a denegar totalmente el acceso al recurso por parte de los usuarios legítimos. ·        None (N): No hay pérdida de integridad.

REFERENCIAS

Uno de mis sitios favoritos, donde poder documentarse, generar nuestras pruebas y calcular los resultados correspondientes a nuestras propias auditorias, es en el NIST: https://nvd.nist.gov/vuln-metrics/cvss .

Aquí se puede utilizar su calculadora oficial, donde podemos de variar cada uno de los puntos correspondientes a la versión 3.0 de CVSS:

https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator