Skip to content
KitploitKITPLOIT
FerramentasBlog
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
CVE-2020-16898 — CVE-2020-16898 (Mau Vizinho) Lógica de Detecção e Regra para a Vulnerabilidade TCP/IP do Microsoft Windows | Kitploit
Ferramentas/GitHubGitHub/advanced-threat-research/cve-2020-16898
Análise de VulnerabilidadesExploraçãoSegurança de RedeDetecção de Intrusão
GitHubadvanced-threat-research/cve-2020-16898

CVE-2020-16898

CVE-2020-16898 (Mau Vizinho) Lógica de Detecção e Regra para a Vulnerabilidade TCP/IP do Microsoft Windows

Ver Repositório

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar
Site
20930há 5 anosRevisado pelo Kitploit

CVE-2020-16898: “Bad Neighbor”

Pontuação CVSS: 8.8

Vetor CVSS: CVSS3.0/AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H/E:P/RL:O/RC:C

Visão Geral

Em 13 de outubro, a Microsoft anunciou uma vulnerabilidade excecionalmente crítica na pilha IPv6 do Windows, que permite a um atacante enviar pacotes maliciosamente concebidos para executar potencialmente código arbitrário num sistema remoto. A prova de conceito partilhada com os membros do MAPP é extremamente simples e perfeitamente fiável. Resulta num BSOD imediato (Ecrã Azul da Morte), mas, mais importante, indica a probabilidade de exploração para aqueles que conseguem contornar as mitigações do Windows 10 e do Windows Server 2019. Os efeitos de um exploit que concedesse execução remota de código seriam generalizados e de grande impacto, uma vez que este é o tipo de bug que poderia ser tornado wormável. Para facilitar a referência, nomeámos a vulnerabilidade “Bad Neighbor” porque está localizada num “Protocolo” de Descoberta de Vizinhos ICMPv6, utilizando o tipo de Anúncio de Router.

Este documento foi preparado pela McAfee Advanced Threat Research. Tem como objetivo fornecer informações valiosas para administradores de rede e pessoal de segurança, que procuram compreender melhor esta vulnerabilidade e defender-se contra a exploração. A assinatura produzida aqui deve ser cuidadosamente considerada e testada em ambientes de staging antes de ser utilizada em produção e pode beneficiar de uma afinação específica para a implementação alvo.

As informações aqui fornecidas estão sujeitas a alterações sem aviso prévio e são fornecidas "COMO ESTÃO", com todas as falhas, sem garantia ou garantia quanto à precisão ou aplicabilidade das informações a qualquer situação ou circunstância específica e para utilização por sua conta e risco. Além disso, não podemos garantir quaisquer benchmarks de desempenho ou eficácia para quaisquer assinaturas.

Assinatura

A assinatura Suricata para esta vulnerabilidade está localizada em cve-2020-16898.rules e contém a seguinte lógica:

alert icmp any any -> any any (msg:"Potential CVE-2020-16898 Exploit"; lua:cve-2020-16898.lua; sid:202016898; rev:1;)

O script Lua correspondente pode ser encontrado em cve-2020-16898.lua. Contém a lógica necessária para analisar corretamente a camada ICMPv6 e identificar a potencial exploração do Bad Neighbor, da seguinte forma:

Uma vez localizado o início da camada ICMPv6, testamos o primeiro byte da camada para garantir que é um pacote ICMPv6 de Anúncio de Router (Tipo = 134) - se não for, saímos.

Como as primitivas do Suricata não foram atualizadas para analisar as opções ICMPv6, saltamos simplesmente para o 17.º byte da camada ICMPv6, pois é aí que as Opções devem começar, se presentes (os primeiros 16 bytes são campos de comprimento estático, conforme RFC 4443). A partir daí, percorremos todas as Opções até que os bytes do pacote se esgotem. Para cada Opção, estamos apenas interessados nos primeiros dois bytes: os campos Tipo e Comprimento da Opção, respetivamente. Enquanto ignoramos todas as Opções que não são RDNSS, para Tipo de Opção = 25 (RDNSS), verificamos se o Comprimento (segundo byte na Opção) é um número par. Se for, sinalizamo-lo. Se não, continuamos. Como o Comprimento é contado em incrementos de 8 bytes, multiplicamos o Comprimento por 8 e saltamos esse número de bytes para chegar ao início da próxima Opção (subtraindo 1 para ter em conta o byte de comprimento que já consumimos).

Com esta regra, também verificamos se o Comprimento é pelo menos 3, conforme RFC 8106 exige, mas em última análise esta verificação pode ser supérflua, uma vez que estamos apenas preocupados se o Comprimento é par ou não.

Baixar ferramenta