Una mirada crítica al CVSS

Durante mucho tiempo, evaluar la gravedad de un fallo de seguridad siguió siendo un ejercicio complicado. Por un lado, los investigadores de seguridad describían el problema en su más oscura luz, y por otro, los editores o fabricantes atemperaban sistemáticamente -cuando no negaban el problema por completo-.

No se definía un baremo común, por lo que había que confiar en uno u otro, y aprender a descifrar los distintos boletines de seguridad para saber si el riesgo era realmente bajo, medio, alto, crítico, si estabas más bien «en verde», «en rojo», o en medio de todo. Por tanto, a menos que se tuviera una buena formación técnica, era fácil caer en la paranoia o -lo que es peor- ignorar los problemas.

Esta observación dio lugar al CVSS (Common Vulnerability Scoring System), un sistema de puntuación de vulnerabilidades creado por FIRST (Forum of Incident Response and Security Teams) y ampliamente apoyado por los editores y fabricantes de software. Su principal objetivo es permitir calcular, comparar y comprender la gravedad de las vulnerabilidades de seguridad. Es utilizado por la mayoría de las bases de datos (CVE, NVD, OSVD, Security Focus, Secunia, etc.) y por muchos actores de la informática (Cisco, Oracle, Adobe, Qualys, etc.).)

Este artículo se refiere a la versión actual de CVSS (CVSSv2).

Puntuación detallada y transparente

CVSS permite calcular tres puntuaciones:

  • Una puntuación base, que permite a cualquiera evaluar un problema. Es la puntuación más utilizada, sobre todo por los auditores.
  • Una puntuación ambiental, que permite tener en cuenta las especificidades del entorno de destino para ajustar la puntuación básica en función del contexto. que permite tener en cuenta el ciclo de vida de la vulnerabilidad: ¿se ha corregido, existen medidas paliativas, se explota activamente? Al igual que la puntuación medioambiental, permite revisar al alza o a la baja la puntuación de referencia.
    • Sin entrar en los detalles de cómo se calcula la puntuación (cuyo algoritmo es público), la puntuación base se basa en la evaluación de dos métricas: la explotabilidad de la vulnerabilidad y el impacto que puede tener en la seguridad. Cada una de estas dos métricas se evalúa en base a tres criterios.

      Para la explotabilidad:

      • El vector de acceso: ¿se puede explotar la vulnerabilidad desde Internet, desde una red adyacente o requiere acceso local?
      • La complejidad de acceso: ¿es sencillo, moderadamente complejo o muy complejo acceder al componente vulnerable?
      • Los requisitos de autenticación: ¿es posible acceder de forma anónima al componente vulnerable para explotar el fallo? ¿O hay uno o varios niveles de autenticación?
        • Para el impacto:

          • Impacto en la privacidad: ¿es completo, parcial o inexistente?
          • Impacto en la integridad: ¿es completo, parcial o inexistente?
          • Impacto en la disponibilidad: ¿es completo, parcial o inexistente?
            • Una vez evaluados los distintos criterios, se obtiene una puntuación final sobre 10. Cuanto más alta sea la puntuación, más crítica será la vulnerabilidad. También obtenemos -y aquí es donde CVSS es particularmente interesante- un vector de replicación detallado, que muestra cómo se evaluó cada criterio para calcular la puntuación.

              Pongamos un ejemplo: un sitio web está configurado para devolver páginas de error extremadamente detalladas, que contienen referencias al código infractor. Al hacerlo, revela información potencialmente sensible que permitirá a un malintencionado dirigir mejor los ataques.

              Se trata de una página web, muy sencilla, accesible desde Internet con un navegador. No se necesitan conocimientos técnicos especiales para empujar el servidor a la falla, y no se requiere autenticación.

              La explotabilidad puede expresarse así:

              • Vector de acceso: Internet (Vector de acceso: Red)
              • Complejidad de acceso: Baja (Complejidad de acceso: Baja)
              • Autenticación: Ninguna (Autenticación: Ninguna)
              • El vector parcial que representa esta métrica se escribirá como: AV:N/AC:L/Au:N

                El impacto, por otro lado, es sólo en la privacidad. Y la vulneración es sólo parcial:

                • Impacto en la privacidad: Parcial

                • Impacto en la integridad: Ninguno

                • Impacto en la disponibilidad: Ninguno

                  El vector parcial que representa esta métrica se escribirá, por tanto: C:P/I:N/A:N

                  El vector final correspondiente a esta vulnerabilidad será por tanto: AV:N/AC:L/Au:N/C:P/I:N/A:N. Este vector corresponde a una puntuación de 5,0, lo que la convierte en una vulnerabilidad de criticidad media. Esta puntuación puede determinarse o verificarse de forma muy sencilla utilizando la calculadora CVSS del NIST, disponible en línea.

                  A veces la puntuación base es incorrecta

                  El mismo problema puede tener a veces un impacto muy diferente.

                  Imagina que fuera posible acceder de forma anónima a todos los documentos que se suben a un sitio saltándose un paso de validación:

                  • En un sitio de intercambio destinado a alojar fotos de los platos favoritos de los usuarios, el impacto será potencialmente menor. En el peor de los casos, se podrá acceder a la foto del dimsum fallido de la que Bernard se avergonzó un poco (pero no lo suficiente como para no guardársela, obviamente).
                  • En un sitio para subir documentos confidenciales, sin embargo, el impacto será mayor. Se podrían encontrar contratos, copias de DNI, nóminas…

                  En ambos casos, se obtendrá el mismo vector y la misma puntuación (aquí 5,0, con el mismo vector que se acaba de calcular arriba). Esto no refleja en absoluto la situación real, y es un claro límite de la puntuación básica. Esta es una de las razones por las que existen criterios medioambientales.

                  Hay cinco de estos criterios, y todos son opcionales:

                  • El potencial de daños colaterales de la vulnerabilidad (Ninguno, Bajo, Bajo a Medio, Medio a Alto, Alto)
                  • El número de sistemas vulnerables en el entorno objetivo (Ninguno, Bajo, Medio, Alto)
                  • El nivel de exigencia de confidencialidad (Bajo, Medio, Alto)
                  • El nivel de exigencia en términos de integridad (Bajo, Medio, Alto)
                  • El nivel de exigencia en términos de disponibilidad (Bajo, Medio, Alto)

                  Si tomamos los dos ejemplos anteriores, en un caso los daños colaterales son bajos y en el otro son potencialmente catastróficos. Del mismo modo, el nivel de exigencia en términos de confidencialidad no es el mismo (bajo para uno, alto para el otro). Si se incorporan estos dos criterios al cálculo se obtendrán dos puntuaciones finales bastante diferentes:

                  • 4,5 para el primer caso (AV:N/AC:L/Au:N/C:P/I:N/A:N/CDP:L/CR:L). Esta puntuación es media y coincide con el nivel de criticidad del defecto relativamente bien.
                  • 8,0 para el segundo caso (AV:N/AC:L/Au:N/C:P/I:N/A:N/CDP:H/CR:H). Esta puntuación es consistente y corresponde a la alta criticidad del defecto.
                    • Aquí podemos ver claramente los límites de la puntuación básica, y el interés de afinarla mediante criterios ambientales.

                      Por todo ello, a veces es difícil para un auditor evaluar correctamente estos criterios ambientales. Sin un conocimiento detallado del objetivo -lo que es bastante habitual en las pruebas de caja negra-, evaluar el potencial de daños colaterales es peligroso. Sin embargo, sin este criterio, la puntuación obtenida en el segundo caso es significativamente menor (6,0 – AV:N/AC:L/Au:N/C:P/I:N/A:N/CR:H) y refleja mal la criticidad del fallo.

                      A pesar de sus cualidades, CVSS tiene, por tanto, límites que a veces son complejos de superar, y una puntuación puede ser destripada por infrautilización o abuso de criterios opcionales.

                      Criterios temporales confusos

                      El tercer grupo de criterios sigue el ciclo de vida de una vulnerabilidad y -de nuevo- ajusta la puntuación. Abarca:

                      • Explotabilidad – ¿hay código público para explotar la vulnerabilidad, es funcional, es una prueba de concepto, hay dudas sobre su existencia?
                      • Existencia de contramedidas – ¿están disponibles, sólo hay soluciones provisionales o hay un parche no oficial?
                      • La propia existencia de la vulnerabilidad: ¿se ha confirmado o sólo hay sospechas?
                      • Cuando se confía plenamente en la existencia de las vulnerabilidades, como suele ocurrir en una auditoría, estos criterios no son muy adecuados. Además, en la medida en que sólo permiten rebajar la criticidad de una vulnerabilidad, cabe preguntarse si siempre es prudente utilizarlas; con el pretexto de que una vulnerabilidad aún no ha sido explotada, ¿es conveniente rebajar su puntuación? ¿No se corre el riesgo de dar al lector una falsa sensación de seguridad, cuando una vulnerabilidad 0day puede estar ya comprometiendo su perímetro?

                        En verdad, hay cierto debate. Sin embargo, parece que está surgiendo un consenso en los debates en curso en torno a CVSSv3, que consistiría en utilizar los criterios temporales para aumentar la puntuación en lugar de reducirla. Mientras tanto, me cuento entre los que preferirían una puntuación alta unida a un plan de acción claro.

                        No obstante, puede ser interesante, por ejemplo para un CERT o en un enfoque de observación continua de la seguridad de un perímetro, actualizar la puntuación de una vulnerabilidad a lo largo del tiempo.

                        CVSS en el punto de mira de los críticos

                        Además de estas dificultades para juzgar el contexto para obtener una puntuación que refleje la realidad de los problemas, se han hecho muchas críticas a CVSS.

                        La más frecuente se refiere a la evaluación del impacto en tres niveles (ninguno, parcial, completo), e insiste en su falta de granularidad: efectivamente, un mensaje de error que revele el direccionamiento IP interno y una vulnerabilidad de path traversal que permita descargar el archivo /etc/passwd tendrán ambos un impacto parcial en la confidencialidad, pero las consecuencias serán potencialmente muy diferentes. Varias empresas han sugerido introducir un nivel adicional para ayudar a reflejar esta diferencia. Esto es particularmente cierto en el caso de Oracle, que ha introducido un nivel «parcial+», desviándose del estándar CVSSv2.

                        Otra crítica común es la incapacidad de evaluar adecuadamente la seguridad de las contraseñas con CVSS. Es habitual encontrar dispositivos o aplicaciones en una red configurados con una contraseña por defecto; utilizando esta contraseña, se toma el control del objetivo, o incluso de todo el entorno; sin embargo, ¿cómo se puede reflejar un fallo de seguridad utilizando el CVSS? Si establecemos el criterio de «Autenticación» en «Simple», la puntuación cae drásticamente, no reflejando así la realidad de la criticidad. Pero al ponerlo en «Ninguno» también se distorsiona la realidad para obtener una puntuación, lo que va en contra del principio de transparencia de la puntuación. Durante nuestras auditorías, nos enfrentamos regularmente a este dilema.

                        Otra crítica justificada es que es imposible evaluar la criticidad de un escenario de ataque con CVSS. A veces es posible explotar varias vulnerabilidades de criticidad moderada para lograr un compromiso completo de un perímetro. Sin embargo, la evaluación CVSS sólo abordará cada una de las vulnerabilidades tomadas de forma independiente; será necesario que el auditor presente el escenario como un todo y destaque el riesgo final, sin poder basarse en un vector de evaluación específico.

                        Por último, se puede criticar al CVSS por ser demasiado granular; a veces es difícil, si no inútil, diferenciar entre una puntuación de 5,6 y una puntuación de 5,8. De hecho, FIRST ha propuesto una escala simplificada de tres niveles para hacer frente a esta crítica:

                        • Una puntuación de 0 a 3,9 corresponde a una baja criticidad
                        • Una puntuación de 4 a 6.9 corresponde a una criticidad media
                        • Una puntuación de 7 a 10 corresponde a una criticidad alta

                        Una valoración bastante positiva

                        A pesar de las críticas que se le pueden hacer, la calificación CVSS va en la dirección correcta:

                        • Para una empresa que quiera evaluar su nivel de seguridad, permite entender mejor la valoración que hace el auditor. Al utilizar los criterios medioambientales para afinar el análisis, también permite poner de manifiesto los fallos que suponen un fuerte riesgo y gestionar mejor los planes de acción correctiva.
                        • Para una empresa que realiza auditorías, empuja al consultor a considerar adecuadamente cada problema y su impacto, y limita las valoraciones alarmistas o fantasiosas. También permite apoyar su propósito con el cliente, gracias al vector detallado en particular.
                        • A partir de su amplia adopción por los diversos actores del mercado de la seguridad, permite finalmente tener una base común para la discusión y la evaluación. Esta estandarización, a pesar de sus imperfecciones, es bienvenida.
                          • Por último, FIRST está tratando de responder a las diversas críticas hechas a CVSSv2 incluyendo aún más actores en el proceso de estandarización de la versión 3. Esta versión debería estabilizarse durante 2014. Apostemos que hasta entonces, el debate será apasionante.

                            Para más información:

                            • Guía de puntuación de CVSS
                            • La formulación de las deficiencias, fallos y faltas de CVSSv2 – una carta abierta a FIRST
                            • CVSSv3 – Dirección futura

                            .

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *