O que há de novo no CVSS 4.0
8 de novembro de 2023
0 minutos de leituraNeste post do blog, vamos apresentar a visão da Snyk sobre o novo sistema de pontuação de vulnerabilidades, o CVSS 4.0, lançado em 1º de novembro de 2023.
Por que isso foi necessário?
A revisão do sistema representa uma evolução natural no cenário das vulnerabilidades de segurança cibernética e uma solução para superar os pontos fracos da metodologia anterior. Desde seu lançamento, em 2016, o CVSS 3 tem se mostrado uma ferramenta robusta de avaliação, usada por profissionais para indicar o impacto potencial e o nível de risco de diversas vulnerabilidades, ajudando organizações e pessoas a se protegerem melhor contra ameaças cibernéticas.
Sete anos depois, o CVSS 4.0 chega como a próxima versão, com o objetivo de oferecer mais granularidade e refinar ainda mais a metodologia de pontuação para acompanhar melhor a evolução das ameaças de segurança cibernética e do cenário digital.
O que vai mudar?
Vamos analisar as mudanças por meio de uma comparação técnica entre as versões 3.1 e 4.0.
Observação: os níveis e as faixas de severidade (Baixa, Média, Alta e Crítica) de cada valor qualitativo de severidade permanecerão os mesmos.
Parâmetro Attack Vector
O novo parâmetro Attack Vector, além de incorporar algumas mudanças semânticas que tornam a especificação mais abrangente (por exemplo, componente em vez de sistema ou físico em vez de proximidade), terá a mesma finalidade de antes.
Por isso, não esperamos mudanças na forma de usar esse parâmetro ao avaliar vulnerabilidades com o CVSS 4.0.
Parâmetro Attack Complexity
O parâmetro Attack Complexity do CVSS 3.1 será dividido em Attack Complexity e Attack Requirements para permitir mais granularidade.
O novo parâmetro Attack Complexity foi criado para ser usado em ataques altamente especializados que envolvem “a evasão ou o contorno de técnicas que reforçam a segurança”.
Já Attack Requirements abrangerá os casos em que a exploração bem-sucedida “depende da presença de condições específicas de implantação e execução do sistema vulnerável que possibilitem o ataque.”
A principal diferença entre Attack Complexity e Attack Requirements está na finalidade das condições específicas que possibilitam o ataque. De acordo com o documento de especificação, Attack Requirements será usado somente para registrar cenários NÃO contemplados pelo parâmetro Attack Complexity novo (ou seja, não deve ser usado em cenários que contornam técnicas de mitigação de exploits).
No ecossistema de código aberto, esperamos que esse parâmetro seja menos usado, já que Attack Complexity só será usado em ataques altamente especializados. Por outro lado, é provável que Attack Requirements seja mais usado, pois abrangerá condições que “surgem naturalmente como consequência da implantação e execução do sistema vulnerável”.
Parâmetro Privileges Required
O novo parâmetro Privileges Required incorpora apenas pequenas mudanças, que visam trazer mais clareza e deixar o texto mais conciso. O valor do parâmetro também permanece inalterado.
Não esperamos mudanças na forma de usar esse parâmetro para avaliar vulnerabilidades.
Parâmetro User Interaction
O documento de especificação do CVSS 4.0 apresenta mudanças importantes no novo parâmetro User Interaction — mais especificamente, em seus valores. Isso permitirá avaliar as condições do ataque com mais precisão.
User Interaction terá três valores possíveis (em vez dos dois da versão CVSS 3.1).
None — Este valor tem uma definição aprimorada que dá ênfase ao usuário humano. Portanto, pode ser usado quando “o sistema vulnerável pode ser explorado sem a interação de nenhum usuário humano, além do atacante”.
Passive — O uso previsto abrange ataques que podem ser realizados por meio de ações involuntárias da vítima.
Active — Ao contrário do caso anterior, esse valor será usado quando o ataque depender de a vítima “realizar interações específicas e conscientes com o sistema vulnerável e a carga maliciosa do atacante”. Outra possibilidade é que as “interações da vítima contornem ativamente os mecanismos de proteção, levando à exploração da vulnerabilidade”.
Essas adições permitirão uma distribuição mais equilibrada dos níveis de severidade das vulnerabilidades, substituindo os valores antigos de User Interaction. Por isso, o uso desse parâmetro no processo de avaliação de vulnerabilidades vai mudar.
Tríade CIA
Não há mudanças significativas na tríade CIA, além de pequenos ajustes de redação para manter a consistência das definições em todo o documento de especificação.
É provável que o uso desses parâmetros permaneça inalterado.
Parâmetro Scope
O parâmetro Scope será substituído por Subsequent System Impact Metrics, que favorecerá uma distribuição de severidade mais equilibrada e maior precisão na avaliação do impacto de uma vulnerabilidade.
Essa mudança não apenas permitirá parametrizar a alteração de escopo, mas também identificar as consequências para o sistema subsequente.
A nova abordagem mudará o processo de avaliação de vulnerabilidades e oferecerá uma maneira mais precisa de avaliar o impacto.
Métricas de ameaças
Também há mudanças importantes em Threat Metrics (antes chamado de Temporal Score), mas vamos abordar apenas Exploit Code Maturity. Esse parâmetro passará a se chamar Exploit Maturity e terá quatro valores possíveis, em vez de cinco (o valor Functional será removido). As novas definições dos valores de Exploit Maturity foram aprimoradas e agora incluem requisitos específicos que precisam ser atendidos para justificar seu uso.
Not Defined — Esse valor deve ser usado quando “não há informações confiáveis sobre ameaças disponíveis para determinar as características de Exploit Maturity”.
Attacked (antes High) — Esse valor pode ser usado quando 1) houver relatos de ataques ou 2) o exploit tiver atingido um nível de maturidade que permita sua integração a diversas soluções, como kits de exploração, que buscam simplificar e automatizar a exploração.
PoC — Deve ser usado quando um dos requisitos a seguir for atendido:
“Há uma prova de conceito disponível publicamente.”
“Não há conhecimento de tentativas relatadas de explorar essa vulnerabilidade.”
“Não há conhecimento de soluções disponíveis publicamente usadas para simplificar as tentativas de explorar a vulnerabilidade.”
Unreported — não é PoC nem Attacked, mas é diferente de Not Defined (use esse valor em cenários em que há informações sobre ameaças disponíveis).
Essas mudanças vão alterar o uso do parâmetro Exploit Maturity.
Como as mudanças vão afetar os usuários?
Além dos pontos destacados na seção anterior, vamos analisar três exemplos de vulnerabilidades e tentar avaliá-las com o CVSS 4.0, explicando o processo.
Execução remota de código que afeta o pacote microsoft.chakracore, versão 1.10.1
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H — 7.5 Alta
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 Alta
O ataque pode ser realizado pela rede, portanto AV:N. De acordo com a especificação, AC:H deve ser usado quando há necessidade de contornar proteções como ASLR. Com base nas informações disponíveis sobre essa vulnerabilidade, acreditamos que ela se enquadra nesse cenário. Não há indicação de requisitos de privilégios baixos ou altos, portanto PR:N. A exploração bem-sucedida depende da existência de outro usuário humano. No entanto, não há evidências suficientes de que esse usuário precise interagir ativamente com a carga maliciosa do atacante, portanto UI:P. Como “um atacante que explorasse a vulnerabilidade com sucesso poderia assumir o controle de um sistema afetado”, a confidencialidade e a integridade são afetadas, portanto VC:H, VI:H e VA:N. Acreditamos que o impacto também se estenda ao sistema subsequente, que, neste caso, é a máquina da vítima. No entanto, o impacto dependerá das permissões que o atacante terá na máquina da vítima, portanto SC:L, SI:L, SA:L.
Execução remota de código que afeta o pacote ipython, versão 8.10.0
CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:L — 4.2 Média
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 Baixa
Devido à finalidade do pacote, o ataque só pode ser realizado localmente, portanto AV:L. A exploração bem-sucedida não exige contornar mecanismos de segurança, mas depende do sistema operacional e de uma configuração específica de implantação (a biblioteca `ctypes`, incluída por padrão nas instalações do Python, precisa estar desativada). Esse cenário se enquadra em AC:L e AT:P. O atacante também precisaria ter acesso ao ambiente local, o que implica PR:L. A vítima precisaria interagir de forma ativa e consciente com a carga maliciosa do atacante, chamando a função vulnerável “no Windows em um ambiente Python no qual `ctypes` não está disponível”, o que significa UI:A. Com base nas informações disponíveis sobre essa vulnerabilidade, acreditamos que não haverá impacto na tríade CIA dentro do sistema vulnerável, mas apenas no sistema subsequente. Isso porque os comandos são executados no sistema host, e a instalação do Python não é afetada diretamente. Além disso, os comandos do shell são “limitados ao escopo do processo atual”, o que corresponde a SC:L e SI:L. Como não há evidências de impacto na disponibilidade do sistema subsequente, temos SA:N.
Cross-site scripting que afeta o pacote org.jenkins-ci.plugins:rundeck, versão 3.6.11
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N — 5.4 Média
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 Média
O ataque pode ser realizado pela rede e não exige contornar “técnicas de mitigação de exploits” nem usar uma configuração especial de implantação para ser bem-sucedido, portanto AV:N, AC:L e AT:N. No entanto, o atacante precisa de uma conta ativa para executar o exploit. Como se trata de um XSS armazenado, a vítima não precisa realizar ações específicas com a carga maliciosa, portanto UI:P. O impacto será no sistema subsequente, pois o atacante pode ler ou modificar dados no navegador da vítima, resultando em VC:N/VI:N/VA:N/SC:L/SI:L/SA:N.
Exemplos oficiais foram publicados por first.org.
Conclusões gerais
É possível observar de imediato que o CVSS 4.0 trará melhorias ao processo de avaliação de vulnerabilidades. Os usuários poderão identificar o impacto na segurança com mais precisão, contribuindo para uma priorização melhor das questões de segurança. Quanto à distribuição de severidade, é razoável esperar que o CVSS 4.0 promova uma distribuição mais equilibrada graças à sua maior granularidade. Esse equilíbrio vai evitar a concentração excessiva de vulnerabilidades em uma determinada faixa de severidade. Também esperamos menos vulnerabilidades com pontuação de severidade elevada, especialmente porque o CVSS 4.0 “manterá as mesmas faixas de pontuação para cada valor qualitativo de severidade” do CVSS 3.1.
Quando o CVSS v4.0 estará disponível?
Desde 18 de junho, a equipe de segurança da Snyk começou a atribuir a versão 4.0 do CVSS a todas as novas vulnerabilidades identificadas pelo Snyk Open Source. Além de basear a severidade dos novos problemas no CVSS v4.0, a Snyk vai disponibilizar gradualmente os novos atributos de vetor nos fluxos de trabalho das diferentes linhas de produtos e atualizar a forma de consumir diretamente essas novas informações.
Se quiser saber mais sobre como usar o framework CVSS para avaliar a gravidade das vulnerabilidades, confira nosso artigo introdutório sobre a pontuação de vulnerabilidades de segurança.
Referências:
CVSS 4.0:
https://www.first.org/cvss/v4.0/examples