Skip to main content

O que é uma vulnerabilidade conhecida?

Escrito por

6 de fevereiro de 2018

0 minutos de leitura

Esta publicação foi publicada originalmente no CSO Online, em 15 de dezembro de 2017.

Ouvimos muito sobre a importância de lidar com vulnerabilidades conhecidas. A maioria dos relatórios anuais de segurança aponta que elas são responsáveis pela maior parte das explorações bem-sucedidas, e não faltam vulnerabilidades famosas — de Heartbleed a ImageTragick — para nos lembrar da gravidade do problema. Se elas são tão importantes, vamos parar um momento para definir o que é uma vulnerabilidade conhecida.

Resposta 1: uma vulnerabilidade com um ID CVE

Um termo praticamente sinônimo de “vulnerabilidade conhecida” é CVE, sigla para “Common Vulnerabilities and Exposures” (Vulnerabilidades e Exposições Comuns), da MITRE. Quando uma nova vulnerabilidade é descoberta, uma Autoridade de Numeração CVE (CNA) pode atribuir a ela um número CVE, usado para identificá-la em bancos de dados e ferramentas.

Vale lembrar que CVE não é um banco de dados, mas sim um identificador. O National Vulnerability Database (NVD) é a fonte oficial de informações relacionadas a CVEs. Quando uma CVE é adicionada ao NVD, normalmente vem acompanhada de algumas informações, como uma breve descrição e a definição dos produtos afetados pela vulnerabilidade, na forma de um CPE (Common Platform Enumeration). A qualidade das informações no NVD varia bastante, dependendo da fonte que contribuiu com elas.

Com exceção das CVEs reservadas antes de uma divulgação futura, é seguro afirmar que uma vulnerabilidade com um número CVE é conhecida. No entanto, muitas vulnerabilidades recebem um número CVE, mas nunca chegam ao NVD, o que dificulta entendê-las de fato. Além disso, muitas vulnerabilidades conhecidas não têm uma CVE.

Resposta 2: uma vulnerabilidade divulgada na internet

Com bastante frequência, vulnerabilidades são descobertas, compartilhadas e (esperamos) corrigidas sem que ninguém solicite uma CVE. Isso é especialmente comum em projetos de código aberto, nos quais praticamente tudo acontece publicamente. É comum usuários divulgarem uma vulnerabilidade sem perceber ao abrir uma issue em um projeto no GitHub, da mesma forma que relatam outros bugs, sem considerar que estão chamando atenção para uma falha de segurança ainda não corrigida.

Mesmo quando as issues são relatadas de forma privada e responsável, a correção da vulnerabilidade acaba sendo disponibilizada em código aberto. Nesse momento, ela costuma ser mencionada nas notas da versão, em uma issue ou junto aos detalhes da alteração no código. Essas informações são incluídas de propósito, pois essa é a única maneira de avisar aos usuários do projeto que existe um risco de segurança (e uma correção). Alguns mantenedores de projetos obtêm uma CVE para essas vulnerabilidades, mas, na prática, isso raramente acontece, seja por falta de conhecimento, seja pelo esforço necessário.

Essas vulnerabilidades também são conhecidas e podem ser consideradas mais preocupantes do que aquelas com uma CVE. Quem usa um projeto pode inspecioná-lo para encontrá-las, mas isso levaria tempo e seria difícil de fazer em grande escala. Por outro lado, um invasor pode examinar projetos de bibliotecas populares e encontrar esses problemas com relativa facilidade, pois basta analisar os projetos mais populares para alcançar muita gente. Elas são chamadas de vulnerabilidades não catalogadas. Catalogá-las em um banco de dados nos leva à próxima categoria de vulnerabilidades conhecidas.

Resposta 3: uma vulnerabilidade registrada em bancos de dados públicos

Embora o NVD seja o banco de dados de vulnerabilidades mais oficial, existem outros. VictimsDB, RedHat e Openwall são exemplos de bancos de dados públicos de vulnerabilidades, disponíveis para consulta por qualquer pessoa. Muitas vulnerabilidades nesses bancos não têm uma CVE — como as vulnerabilidades não catalogadas mencionadas anteriormente — ou são publicadas neles antes da atribuição de uma CVE.

Uma vulnerabilidade registrada em um banco de dados público é quase tão conhecida quanto uma que tem uma CVE. Ela fica armazenada em um local público, acessível tanto a defensores quanto a invasores, e informa ambos sobre o risco envolvido. A única diferença entre o NVD e esses bancos de dados está no processo de seleção para inclusão, que varia de um banco para outro.

Resposta 4: uma vulnerabilidade registrada em bancos de dados fechados

Nem todos os bancos de dados de vulnerabilidades são abertos para consulta. Muitas empresas criam e mantêm seus próprios bancos de dados, mas os mantêm fechados ao público. Clientes podem pagar para acessar a lista de vulnerabilidades, o que lhes permite fazer a triagem e tentar mitigar aquelas que mais os afetam.

Bancos de dados fechados de vulnerabilidades são uma maneira útil de descobrir falhas que você teria dificuldade para encontrar por conta própria e de se proteger caso invasores também as encontrem. Ainda assim, eu não chamaria essas vulnerabilidades de conhecidas. A menos que o fornecedor do banco de dados também o tenha vendido aos invasores (o que duvido que algum deles faça), é tão provável que o invasor encontre outra vulnerabilidade no seu sistema quanto aquela que você acabou de comprar.

Resposta 5: uma vulnerabilidade compartilhada na dark web

Assim como o mercado legítimo de bancos de dados de vulnerabilidades, a dark web tem seus próprios repositórios de vulnerabilidades, que são vendidos no mercado negro. Como o retorno financeiro para os invasores é bem diferente, uma única vulnerabilidade pode custar milhões — ou ser distribuída de graça ou por um preço baixo.

Essas vulnerabilidades definitivamente não são conhecidas. Na verdade, costumam ser chamadas de vulnerabilidades “zero-day”, pois os invasores sabem da existência delas antes de se tornarem conhecidas (zero dias após a divulgação). Às vezes, elas podem ser publicadas abertamente; nesse caso, eu as classificaria como vulnerabilidades não catalogadas, conforme a resposta 2.

Vulnerabilidades zero-day são importantes, sem dúvida, mas a probabilidade de invasores explorá-las antes que se tornem públicas é muito menor do que no caso de vulnerabilidades realmente conhecidas.

Resumo

Uma vulnerabilidade é uma vulnerabilidade, seja conhecida ou não. A principal diferença entre as duas é a probabilidade de um invasor saber da existência dela e, por isso, tentar explorá-la. Portanto, quanto mais conhecida for a vulnerabilidade, mais urgente deve ser sua correção.

Recomenda-se priorizar os três primeiros tipos de vulnerabilidade, talvez nessa ordem. Depois de controlá-los, trabalhe para corrigir as vulnerabilidades mais abaixo na lista.

Leia mais

blog feature ai lilac
Blog

Transforme seu backlog de vulnerabilidades em pull requests com remediação agentiva

O Evo Remediation Agent está em Open Preview e traz a resolução automatizada de dependências para o Evo Agentic AppSec. Agora, as equipes de AppSec podem executar campanhas contínuas de remediação

illustration hero ai
Blog

PHP corrige duas vulnerabilidades críticas de RCE sem autenticação (CVE-2026-109618, CVE-2026-109619): atualize agora

Duas falhas críticas no ciclo de requisições do PHP podem permitir execução remota de código sem autenticação. Atualize para uma versão corrigida ou instale um backport do fornecedor para versões mais antigas.

AI Background min crop
Blog

A IA está acionando todos os riscos que você aceitou: sete insights do painel de segurança de IA sem filtros

A IA está tornando os ataques mais baratos e rápidos, expondo riscos que as organizações já carregam. Quatro líderes de segurança explicam por que a defesa na velocidade das máquinas e a correção mais rápida são essenciais.