Pontuação de vulnerabilidades de segurança 101: conheça o CVSS para CVEs

Assim como bugs de software são classificados por nível de gravidade, as vulnerabilidades de segurança também precisam ser avaliadas quanto ao impacto e ao risco, o que ajuda no gerenciamento de vulnerabilidades.

O Fórum de Equipes de Segurança e Resposta a Incidentes (FIRST) é uma organização internacional formada por pesquisadores e cientistas de segurança da computação de confiança. Sua missão é criar boas práticas e ferramentas para equipes de resposta a incidentes, além de padronizar políticas e metodologias de segurança.

Uma das iniciativas da FIRST é um Grupo de Interesse Especial (SIG), responsável por desenvolver e manter a especificação do Sistema Comum de Pontuação de Vulnerabilidades (CVSS), para ajudar as equipes a entender e priorizar a gravidade das vulnerabilidades de segurança.

Pontuação de vulnerabilidades

O CVSS é reconhecido como um sistema padrão de medição para setores, organizações e governos que precisam de pontuações precisas e consistentes sobre o impacto das vulnerabilidades.

O modelo quantitativo do CVSS garante medições reproduzíveis e precisas e permite que os usuários vejam as características subjacentes da vulnerabilidade usadas para gerar as pontuações.

O CVSS é usado com frequência para priorizar atividades de correção de vulnerabilidades e calcular a gravidade das vulnerabilidades encontradas nos sistemas de uma organização.

Desafios do CVSS

Falta de contexto de aplicabilidade

As pontuações de vulnerabilidade nem sempre levam em conta o contexto correto em que um componente vulnerável é usado por uma organização. Um sistema de Vulnerabilidades e Exposições Comuns (CVE) pode considerar diversas variáveis ao determinar a pontuação de uma organização. Ainda assim, outros fatores podem afetar a forma como uma vulnerabilidade é tratada, independentemente da pontuação atribuída a ela por um CVE.

Por exemplo, uma vulnerabilidade de alta gravidade segundo o CVSS, encontrada em um componente usado para testes, como um harness de teste, pode receber pouca ou nenhuma atenção das equipes de segurança, TI ou P&D. Isso pode acontecer porque o componente é usado internamente como ferramenta e não fica exposto em uma interface pública nem acessível a qualquer pessoa.

Além disso, as pontuações de vulnerabilidade não consideram consequências concretas, como quando uma vulnerabilidade afeta dispositivos médicos, carros ou redes de serviços públicos. Cada organização precisa avaliar e considerar as implicações específicas, com base na relevância e na prevalência nos componentes vulneráveis de seus produtos.

Pontuação incorreta

A pontuação de uma vulnerabilidade é composta por mais de uma dúzia de características importantes. Sem orientação, experiência e informações de apoio adequadas, é fácil cometer erros. Um estudo acadêmico[1] recente constatou que os participantes responderam corretamente a apenas 57% das questões de segurança sobre pontuação de vulnerabilidades CVE. O estudo também explica quais informações são essenciais para aumentar a precisão e quais podem causar confusão e reduzir a precisão das pontuações.

Não é incomum encontrar falsos positivos em um CVE ou imprecisões nas pontuações atribuídas a qualquer grupo de métricas. Isso pode levar à perda de confiança em um CVE ou causar pânico desnecessário nas organizações.

O CVSS usa uma escala de 0 a 10, associada a níveis de gravidade que vão de baixo a alto ou crítico. Uma avaliação imprecisa das variáveis pode resultar em uma pontuação correspondente a um nível incorreto do CVSS. Outro estudo[2] da Universidade Carnegie Mellon apresentou conclusões semelhantes sobre a precisão das pontuações. O relatório afirma: “Mais da metade dos entrevistados não mantém uma precisão consistente dentro de uma margem de quatro pontos CVSS”, sendo que uma diferença de apenas 4 pontos pode mudar a classificação de gravidade de alta ou crítica para níveis 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

A abordagem da Snyk

Na Snyk, usamos o CVSS v3.1 para avaliar e comunicar as características das vulnerabilidades de segurança e seu impacto.

A equipe de pesquisa de segurança dedicada da Snyk trabalha para descobrir novas vulnerabilidades em diferentes ecossistemas. Além disso, avalia as pontuações de CVEs para confirmar se refletem corretamente a gravidade e compensar as imprecisões de pontuação mencionadas, cometidas por outras autoridades que emitem CVEs.

O banco de dados de vulnerabilidades da Snyk oferece metadados complementares aos detalhes de cada CVE. A equipe de pesquisa de segurança seleciona informações para cada vulnerabilidade, como uma visão geral do componente vulnerável, detalhes sobre o tipo de vulnerabilidade, exemplos e links de referência para commits, correções ou outros materiais relacionados.

A imagem a seguir mostra uma vulnerabilidade de segurança de cross-site scripting (XSS) encontrada no framework frontend React, que afeta diferentes versões da série 16.x do módulo React DOM.

A imagem também mostra a métrica base da pontuação CVSS v3.1, com o detalhamento das métricas.

Como funciona o CVSS

Ao longo de sua história, o CVSS teve três versões: do lançamento inicial, em 2004, à ampla adoção do CVSS v2.0 e, por fim, à especificação atual, o CVSS v3.1. O restante deste artigo se concentra no CVSS v3.1.

A especificação fornece uma estrutura que padroniza a forma de pontuar vulnerabilidades, categorizando-as para refletir áreas específicas de preocupação.

As métricas de uma pontuação CVSS são divididas em três grupos:

1. Base — métricas de avaliação de impacto e explorabilidade que não dependem do momento em que a vulnerabilidade é avaliada nem do ambiente do usuário, como a facilidade de exploração. Por exemplo, se uma vulnerabilidade impedir o acesso completo a um componente vulnerável, o impacto sobre a disponibilidade receberá uma pontuação alta.

2. Temporal — métricas que consideram circunstâncias que afetam a pontuação de uma vulnerabilidade. Por exemplo, a pontuação aumenta quando há uma exploração conhecida para a vulnerabilidade e diminui quando existe um patch ou uma correção disponível.

3. Ambiental — métricas que permitem adaptar a pontuação ao impacto no ambiente específico de um usuário ou organização. Por exemplo, se a organização considera muito importante a disponibilidade de um componente vulnerável, pode definir um requisito alto de disponibilidade e aumentar a pontuação CVSS geral.

O grupo de métricas base fundamenta o vetor CVSS. Se houver métricas temporais ou ambientais, elas também serão consideradas na pontuação CVSS geral.

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

Pontuações base

As métricas base do CVSS são compostas por subgrupos de métricas de explorabilidade e impacto. Elas avaliam a aplicabilidade a um componente de software, que pode afetar outros componentes, como software, hardware ou dispositivos de rede.

A explorabilidade representa o esforço e os meios necessários para explorar uma vulnerabilidade de segurança e é composta pelos seguintes elementos:

• Vetor de ataque (AV) — representa quatro meios pelos quais um ataque pode ocorrer: físico, local, adjacente e pela rede. Quanto mais acessível o meio, maior a pontuação.

Por exemplo, uma vulnerabilidade de cross-site scripting (XSS) no jQuery que pudesse ser explorada em um site público receberia a classificação de vetor de ataque pela rede.

• Complexidade do ataque (AC) — recebe uma pontuação baixa ou alta, dependendo de o ataque exigir ou não uma condição ou configuração especial como pré-requisito para ser executado com sucesso. Por exemplo, um path traversal, relativamente fácil de executar e encontrado no pacote Next.js em 2018 e 2017, tem baixa complexidade de ataque. Um exemplo de alta complexidade é um ataque de temporização encontrado no Apache Tomcat.

• Privilégios necessários (PR) — pode receber uma destas pontuações: nenhum, baixo ou alto. Esses níveis correspondem aos privilégios que um invasor precisa obter para explorar a vulnerabilidade. Por exemplo, uma injeção de código arbitrário no Wordpress MU permitia que usuários autenticados carregassem e executassem arquivos maliciosos remotamente. A pontuação é baixa porque qualquer usuário autenticado podia executar o ataque, independentemente de sua função ou permissões no aplicativo Wordpress.

• Interação do usuário (UI) — recebe uma pontuação alta quando nenhuma ação do usuário é necessária para que o ataque seja executado com sucesso e uma pontuação menor quando é necessário algum tipo de interação. Por exemplo, módulos maliciosos comprometem o ambiente quando são instalados, portanto, é preciso que alguém instale o pacote malicioso. No ecossistema npm, já vimos dezenas de pacotes maliciosos, incluindo uma tentativa de roubar variáveis de ambiente por meio de um ataque de typosquatting em um pacote chamado crossenv. Esses são exemplos de pontuação baixa, pois exigem a interação do usuário.

O subgrupo de métricas de impacto representa os efeitos sobre a confidencialidade, a integridade e a disponibilidade de um componente vulnerável quando ele é explorado com sucesso. Ele é composto pelos seguintes elementos:

• Confidencialidade (C) — mede o grau de perda de confidencialidade do componente afetado, como a divulgação de informações a usuários não autorizados. Por exemplo, há uma grande perda de confidencialidade quando uma vulnerabilidade de injeção de script arbitrário é explorada em aplicativos Angular (mais precisamente, AngularJS). Uma entrada do usuário originada de um evento DOM e não devidamente sanitizada pode resultar na execução de código.

• Integridade (I) — mede o grau de perda de integridade do componente afetado, como a possibilidade de modificar dados após explorar a vulnerabilidade com sucesso. Por exemplo, houve uma grande perda de integridade no framework de código aberto Apache Struts 2, quando uma serialização incorreta levou à execução de comandos arbitrários. Essa vulnerabilidade ganhou destaque em 2017 por estar relacionada à violação de dados da Equifax. Você pode ler mais sobre o assunto no nosso blog.

• Disponibilidade (A) — mede a perda de disponibilidade de recursos e funcionalidades do componente afetado, como a possibilidade de um ataque relacionado ao componente vulnerável causar uma negação de serviço para os usuários. Por exemplo, uma versão do lodash está vulnerável à negação de serviço por expressão regular. Quando o lodash é usado como biblioteca frontend, a exploração dessa vulnerabilidade afeta os navegadores dos usuários finais. O problema é ainda mais grave quando o lodash é usado em um aplicativo de servidor Node.js: o loop de eventos deixa de responder e todas as solicitações recebidas por um serviço de API são afetadas.

É importante observar que, quando o escopo muda, as métricas de impacto representam as consequências mais graves, seja para o próprio componente vulnerável, seja para o componente afetado.

Por fim, o escopo é uma nova métrica introduzida no CVSS v3.0. Ele indica se uma vulnerabilidade de segurança afeta recursos além dela própria. Os valores atribuídos à métrica de escopo podem ser inalterado ou alterado. Se a exploração bem-sucedida de um componente vulnerável afetar recursos regidos por outro escopo de autorização, isso indica que o escopo foi alterado.

Por exemplo, vulnerabilidades de cross-site scripting (XSS) no phpMyAdmin seriam consideradas uma mudança de escopo, pois o componente vulnerável é o phpMyAdmin, que funciona como um aplicativo PHP no lado do servidor; no entanto, o impacto ocorre no navegador do usuário.

Vulnerabilidades de segurança como a execução remota de comandos, em que o componente vulnerável recebe privilégios muito elevados, são um bom exemplo de como o escopo pode ir além da autorização daquele componente e potencialmente afetar outros componentes.

Pontuações temporais

A pontuação temporal contextualiza o momento da gravidade de uma CVE. Por exemplo, se há exploits públicos conhecidos para uma vulnerabilidade de segurança, isso aumenta a criticidade e a gravidade da CVE, pois torna muito mais fácil acessar os recursos necessários para realizar esses ataques.

A pontuação geral do CVSS é calculada considerando também a pontuação temporal, com base no maior risco atribuído a cada valor. Ela só é incluída quando há risco temporal. Portanto, os valores atribuídos à pontuação temporal podem manter a pontuação geral do CVSS como está ou até reduzi-la, mas nunca aumentá-la.

As métricas da pontuação temporal são:

• Maturidade do código de exploit (E)—mede a probabilidade de exploração da vulnerabilidade, de acordo com o grau de maturidade do código de exploit público disponível. Os valores possíveis são 'U' para nenhum código de exploit disponível; 'P' para um código de prova de conceito conhecido; 'F' para um código de exploit funcional disponível; ou 'H' para uma alta probabilidade de exploração, possível graças a ferramentas de ataque automatizadas, como o conhecido framework Metasploit, ou em casos em que não é necessário um código de exploit especial para realizar um ataque bem-sucedido.

• Nível de correção (RL)—mede a probabilidade de aplicar uma mitigação ou concluir a correção da vulnerabilidade. Por exemplo, se uma vulnerabilidade tiver sido divulgada e tratada adequadamente por um fornecedor, quando a CVE se tornar pública, o componente vulnerável já deverá ter um caminho de atualização. Os valores possíveis são 'O' para uma correção oficial disponibilizada pelo fornecedor por meio de um patch ou atualização; 'T' para uma correção temporária disponível, como uma versão de hotfix ou uma solução alternativa para mitigar a vulnerabilidade; 'W' quando há uma solução alternativa conhecida, mas não oficial nem compatível com o fornecedor; e, por fim, 'U' quando não há mitigação ou correção conhecida publicamente.

• Confiança no relatório (RC)—mede o grau de confiança no relatório da vulnerabilidade. Às vezes, os relatórios de segurança divulgados não fornecem informações completas, como contexto, materiais de apoio na forma de uma prova de conceito ou etapas para reproduzir o problema. Isso dificulta a triagem da credibilidade do relatório e do impacto. Os valores possíveis são ‘C’ para indicar alto grau de certeza na reprodução do problema, ‘R’ quando foram fornecidas informações razoáveis para confirmar o relatório e ‘U’ quando há detalhes desconhecidos sobre a causa raiz da vulnerabilidade.

É possível atribuir ‘X’ às três métricas temporais para indicar que nenhum valor deve ser atribuído e que elas não devem afetar a pontuação base.