Skip to content
KitploitKITPLOIT
FerramentasExploitsBlog
Log in
Enviar
FerramentasExploitsBlog
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-2022-0778-POC — Prova de conceito remota para CVE-2022-0778 que injeta um certificado malicioso em um handshake TLS para acionar a vulnerabilidade de negação de serviço BN_mod_sqrt() do OpenSSL. | Kitploit
Ferramentas/GitHubGitHub/jkakavas/cve-2022-0778-poc
Análise de VulnerabilidadesExploraçãoFuzzingTestes de Penetração
GitHubjkakavas/cve-2022-0778-poc

CVE-2022-0778-POC

Prova de conceito remota para CVE-2022-0778 que injeta um certificado malicioso em um handshake TLS para acionar a vulnerabilidade de negação de serviço BN_mod_sqrt() do OpenSSL.

Ver Repositório
11332há 4 anosAinda não revisado

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

Um POC simples de disparo remoto para CVE-2022-0778

Porquê

Ao tentar validar se as implementações de servidor do nosso lado estavam/são vulneráveis ao CVE-2022-0778, mostrou-se extremamente trabalhoso fazê-lo remotamente. As instruções para criar certificados maliciosamente forjados para acionar o bug de parsing em BN_nod_sqrt() já existem há algum tempo, mas o principal problema é que a maioria das implementações de cliente tentaria analisar o certificado do cliente para usá-lo no handshake TLS. Isso, por sua vez, significava que:

  • se a implementação fosse vulnerável, o bug seria acionado e o cliente consumiria 100% e paralisaria.
  • se a implementação não fosse vulnerável, o certificado não poderia ser analisado e o cliente, com razão, sairia.

O quê

O que realmente era necessário era poder injetar uma mensagem no handshake TLS para que pudéssemos substituir o conteúdo da mensagem Certificate que o cliente envia ao servidor em resposta à mensagem CertificateRequest.

Como

Isto depende de tlslite-ng e sobrescreve o método TLSConnection._clientKeyExchange para que, durante um handshake TLS com um servidor possivelmente vulnerável:

  1. Enviamos uma mensagem ClientHello como faríamos normalmente
  2. Consumimos a ServerHelloMessage e verificamos se ela contém um CertificateRequest
  3. Se contiver, construímos uma mensagem Certificate arbitrária, carregando do disco o certificado forjado codificado em DER
  4. Enviamos a mensagem forjada ao servidor e esperamos que ele a analise, possivelmente acionando o CVE-2022-0778

O crafted.crt é criado com base nas instruções em https://github.com/drago-96/CVE-2022-0778#using-asn1-templates, sinta-se à vontade para recriá-lo, se desejar.

Uso

usage: main.py [-h] [--server SERVER] [--port PORT]

Parameters

optional arguments:
  -h, --help       show this help message and exit
  --server SERVER  Name of the server to connect for the TLS handshake,
                   defaults to "localhost"
  --port PORT      Port where server listens for TLS connections, defaults to
                   "443"
Baixar ferramenta