O que é uma vulnerabilidade? Fraqueza, ameaça, risco e exploit

Grande parte da confusão em segurança começa com quatro palavras que as pessoas usam como se significassem a mesma coisa: vulnerabilidade, ameaça, risco e exploit. Uma notícia diz que "uma vulnerabilidade crítica foi explorada", e o leitor entende que aconteceu um único evento. Na prática, são quatro coisas diferentes. Separá-las ajuda você a decidir o que corrigir primeiro, o que monitorar e o que pode esperar.

Este artigo traz definições de trabalho, mostra como as quatro se encadeiam e explica dois sistemas de nomenclatura que você vai encontrar em toda parte. A CWE nomeia tipos de fraqueza. A CVE nomeia falhas específicas em produtos específicos. As últimas seções tratam de duas ideias que surpreendem quem está começando: uma vulnerabilidade sem caminho alcançável costuma ser de baixo risco, e uma configuração errada conta como vulnerabilidade mesmo sem nenhum bug de código.

Você não precisa de laboratório para este artigo. A parte prática é um exercício no papel. Se você leu antes o artigo sobre a tríade CIA, o passo do impacto logo abaixo vai parecer familiar.

#Quatro palavras, quatro funções

Comece pela definição oficial. O glossário do Computer Security Resource Center do NIST define vulnerabilidade como uma fraqueza em um sistema de informação, em seus procedimentos de segurança, em seus controles internos ou na sua implementação, que pode ser explorada ou acionada por uma fonte de ameaça. A palavra que importa é "fraqueza". Uma vulnerabilidade é uma propriedade do sistema. Ela existe mesmo que ninguém esteja procurando por ela.

#Vulnerabilidade

Vulnerabilidade é uma fraqueza que pode ser usada para causar dano. Alguns exemplos:

• Um formulário web que cola o que o usuário digitou diretamente em uma consulta ao banco de dados. Esse tipo de fraqueza é bem conhecido, e a CWE tem uma entrada para ele (veja mais abaixo).
• Um servidor de arquivos que ainda aceita um protocolo de criptografia antigo e fraco.
• Um bucket de armazenamento que deixa qualquer pessoa listar o conteúdo.
• Uma versão de biblioteca de software com um bug de corrupção de memória documentado publicamente.

Uma vulnerabilidade não precisa de um atacante para existir. Ela precisa existir no sistema, e isso é a primeira coisa a verificar quando você avalia algo.

#Ameaça

Ameaça é uma circunstância, um agente ou um evento que poderia aproveitar uma fraqueza e causar dano. O NIST usa o termo "fonte de ameaça" para a parte ou o evento: um grupo criminoso, um insider mal-intencionado, uma enchente ou um administrador que erra em um arquivo de configuração.

A diferença para a vulnerabilidade está na direção. A vulnerabilidade descreve o que pode sofrer uma ação. A ameaça descreve o que pode agir. Ameaça é algo potencial. Ela não precisa estar sendo usada contra você agora para importar.

#Risco

Risco combina a probabilidade de um evento danoso com o tamanho do estrago se ele acontecer. O NIST SP 800-30 Revisão 1, o guia de avaliação de risco, trata o risco como função da probabilidade e do impacto. Em termos simples, risco é o quanto algo é provável, pesado contra o dano caso aconteça. É um julgamento, não um cálculo preciso.

Muitas equipes desenham uma matriz com probabilidade em um eixo e impacto no outro. A matriz ajuda a pensar, mas não é uma medição. Duas descobertas com a mesma nota de severidade podem ter riscos muito diferentes, porque a nota descreve a falha e o risco descreve o seu ambiente.

#Exploit

Exploit é um método, um trecho de código ou uma sequência de passos que usa uma vulnerabilidade para produzir um resultado que os projetistas não pretendiam. A palavra pode se referir à técnica em si ou à ferramenta que a executa.

Duas relações valem ser lembradas. Primeiro, um exploit precisa de uma vulnerabilidade contra a qual funcionar. Segundo, uma vulnerabilidade não precisa de exploit público para existir. Muitas vulnerabilidades são conhecidas e nunca ganham um exploit público. Outras são acionadas por uma entrada simples que qualquer pessoa pode testar.

#Como as quatro se conectam

As quatro palavras descrevem uma única cadeia. Veja a sequência, usando um formulário de login genérico como exemplo:

1. Fraqueza. O formulário de login aceita tentativas de senha ilimitadas. Não há bloqueio nem limite de taxa. Essa é a vulnerabilidade.
2. Fonte de ameaça. Alguém tem uma lista de senhas vazadas de um incidente antigo e reutiliza essas senhas em muitas contas. Essa é a ameaça.
3. Exploit. Um script curto envia milhares de tentativas de login e registra as que dão certo. Esse script é o exploit.
4. Impacto. Uma conta correspondente é tomada. O atacante lê os dados daquele usuário, o que é perda de confidencialidade, e pode alterar configurações, o que é perda de integridade.
5. Risco. Quanto isso importa depende de duas coisas: a probabilidade dos passos 2 e 3 no seu ambiente e o tamanho do estrago do passo 4 para as contas envolvidas. O formulário é alcançável pela internet? As contas usam autenticação em dois fatores? O que cada conta consegue acessar?

Você pode quebrar a cadeia em vários pontos. Um limite de tentativas elimina a fraqueza. A autenticação em dois fatores torna um palpite bem-sucedido muito menos útil. Restringir o formulário a uma rede privada reduz o alcance da ameaça. Cada controle quebra um elo diferente, então é preciso saber em qual elo você está trabalhando.

#Como CWE e CVE nomeiam falhas

Você vai ver dois identificadores o tempo todo em notícias de segurança, avisos de fabricantes e relatórios de scanners. Eles respondem perguntas diferentes, e confundi-los é um dos erros mais comuns de quem está começando.

#CWE: o tipo de fraqueza

O site da CWE descreve a CWE como uma lista mantida pela comunidade com fraquezas comuns de software e hardware. Ela define fraqueza como uma condição em um componente de software, firmware, hardware ou serviço que, sob certas condições, pode contribuir para a introdução de vulnerabilidades. A CWE responde à pergunta: que tipo de erro é este?

Cada entrada da CWE tem um número. A entrada para injeção de SQL é a CWE-89, que trata da neutralização imprópria de elementos especiais em um comando SQL. A entrada para cross-site scripting é a CWE-79. Essas entradas não citam nenhum produto. Elas descrevem um padrão que aparece em muitos produtos e ajudam desenvolvedores a reconhecê-lo antes de publicar o código.

#CVE: a falha específica

A CVE é uma lista de vulnerabilidades de segurança divulgadas publicamente. Cada registro descreve uma falha em um produto, normalmente com as versões afetadas e links para avisos. O identificador tem este formato:

CVE-ANO-NUMERO

Um exemplo real é a CVE-2021-44228, a falha no Apache Log4j 2 que ficou conhecida como Log4Shell. O identificador diz qual falha é. O registro diz qual produto e quais versões são afetados e onde encontrar a correção do fabricante.

A CVE responde a outra pergunta: qual falha específica, em qual produto, é esta? Um único tipo da CWE pode ter muitos registros CVE em produtos diferentes, porque o mesmo tipo de erro se repete várias vezes.

#Lendo os dois juntos

Ao ler um registro CVE, procure o tipo de fraqueza ao qual ele se associa. Um registro associado à CWE-89 informa que a falha é uma injeção de SQL, mesmo que o produto seja desconhecido. Isso permite aplicar o que você sabe sobre a categoria a um caso novo. O caminho inverso também ajuda: se um produto tem histórico de um tipo de fraqueza, você sabe o que verificar primeiro.

#Por que uma vulnerabilidade sem caminho alcançável costuma ser de baixo risco

Imagine um serviço com uma falha conhecida, mas que escuta apenas no endereço de loopback do seu notebook. Nenhuma outra máquina consegue se conectar a ele. Isso é uma vulnerabilidade? Sim. O risco é alto? Normalmente não, porque a probabilidade é muito baixa. Ninguém fora do seu notebook alcança a falha, então nenhuma fonte de ameaça consegue usá-la pela rede.

É a ideia de risco funcionando. Probabilidade menor dá risco menor, mesmo quando o impacto seria grave. A severidade sozinha não decide o que corrigir primeiro.

Cuidado, porém. "Não há caminho alcançável hoje" é uma afirmação sobre um momento. Algumas coisas mudam o quadro:

• Uma mudança de rede, como um novo redirecionamento de porta, uma regra de grupo de segurança na nuvem ou uma rota de VPN, pode tornar um serviço alcançável.
• Uma máquina comprometida na mesma rede pode alcançar serviços invisíveis do lado de fora.
• Um funcionário enganado por uma mensagem de phishing pode virar o caminho para um sistema interno.
• A própria aplicação pode expor o serviço por outra rota, como um proxy ou um redirecionamento.

Ou seja, baixo risco não é risco zero, e não quer dizer ignorar a falha. A correção normalmente pode esperar atrás de achados que têm caminhos alcançáveis, e você deve verificar de novo a alcançabilidade sempre que a rede mudar.

#Por que a configuração errada conta como vulnerabilidade

Muitos iniciantes acham que vulnerabilidade tem de ser um bug no código. Essa visão é restrita demais. A definição do glossário do NIST inclui a "implementação" do sistema e os "controles internos", e a CWE também cobre fraquezas de configuração. Uma configuração que expõe dados ou acesso é uma fraqueza, mesmo que nenhuma linha de código esteja errada.

Veja um exemplo simples. Este bloco do nginx liga a listagem de diretórios para um caminho:

location /backup/ {
    autoindex on;
}

Nenhum código está quebrado. O nginx faz exatamente o que esta linha diz. Mas qualquer pessoa que alcance o caminho vê a lista de arquivos da pasta, e alguns desses arquivos podem ser backups que nunca deveriam ser públicos. A fraqueza está na configuração, e alguém pode usá-la para descobrir coisas que não deveria saber.

Outras configurações erradas comuns seguem a mesma lógica:

• Um bucket de armazenamento em nuvem com leitura pública, quando deveria ser privado.
• Uma senha de administrador padrão que nunca foi trocada.
• Modo de depuração ligado em uma aplicação de produção, que pode mostrar rastros de erro a visitantes.
• Uma interface administrativa exposta à internet pública em vez de uma rede privada.

Verifique os seus sistemas desta forma. Para qualquer configuração que controla quem pode ver ou alterar algo, pergunte se um desconhecido conseguiria usá-la. Se sim, você tem uma vulnerabilidade, tenha ela sido escrita por um desenvolvedor ou escolhida por um administrador.

#Prática: classifique cinco achados no papel

Não é preciso laboratório. Pegue uma folha de papel ou um arquivo de texto e resolva cinco casos. Para cada um, escreva quatro respostas curtas: a fraqueza, a fonte de ameaça provável, se é preciso um exploit para usá-la e se ela é alcançável pela internet ou só a partir de uma rede interna.

1. Uma aplicação web usa uma versão de biblioteca com uma falha documentada publicamente. A aplicação é alcançável pela internet.
2. A listagem de diretórios está ativa em um caminho de backup. O servidor só é alcançável pela rede do escritório.
3. Um serviço com uma falha conhecida escuta apenas no endereço de loopback de um notebook.
4. Um formulário de login não tem limite de tentativas, mas todas as contas exigem um segundo fator.
5. Um bucket de armazenamento em nuvem está com leitura pública, e está vazio no momento.

Para cada caso, escreva uma frase que comece com "O risco é" e dê o motivo. Compare suas respostas com o raciocínio acima. Os casos 1 e 4 geram as frases de risco mais úteis, porque a alcançabilidade e o segundo fator mudam a probabilidade do dano. O caso 5 é uma configuração errada que continua sendo vulnerabilidade, mesmo sem nada armazenado no bucket hoje, porque dados podem chegar amanhã.

Guarde as respostas. Quando você ler um aviso real no futuro, pode aplicar as mesmas quatro perguntas.

#Erros comuns

• Usar vulnerabilidade e exploit como sinônimos. Vulnerabilidade é a fraqueza. O exploit é o método que a usa.
• Tratar a nota de severidade do scanner como o seu risco. A nota descreve a falha de forma geral. Seu risco depende da alcançabilidade, dos seus dados e dos seus controles.
• Ignorar configurações erradas por não haver bug de código. Configurações também podem ser vulnerabilidades.
• Achar que "nenhum exploit conhecido" significa seguro. Significa que nenhum exploit público é conhecido hoje. Não diz nada sobre a existência de um exploit privado.
• Achar que inalcançável significa inalcançável para sempre. Mudanças de rede e máquinas comprometidas podem mudar o caminho.
• Confundir um identificador CVE com um tipo de fraqueza. A CVE nomeia uma falha em um produto. A CWE nomeia a categoria do erro.

#Como ir além

Leia a entrada de vulnerabilidade no glossário do NIST e as seções de avaliação de risco do NIST SP 800-30 Revisão 1. Depois, abra qualquer registro CVE que te interesse e identifique três coisas: o produto e as versões afetadas, a descrição da falha e o mapeamento CWE, se houver. Esse hábito transforma uma lista de identificadores em um quadro claro, e é a habilidade central para ler avisos de segurança.

Quando os quatro termos estiverem firmes, a próxima pergunta é como uma fraqueza poderia ser alcançada de propósito. O artigo sobre modelagem de ameaças com STRIDE mostra uma forma estruturada de listar ameaças contra um sistema antes que alguém o ataque. Ele usa o mesmo vocabulário que você acabou de aprender, então as distinções acima vão importar por lá.

Quando você ler registros CVE com frequência, vai perceber que a descrição costuma dizer a condição necessária para acionar a falha. Essa condição é a sua primeira verificação de alcançabilidade. Anote-a ao lado da versão afetada e da sua própria exposição.

#Fontes

• Glossário do NIST CSRC: vulnerability
• CWE: About CWE
• CVE: Overview
• NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments