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-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
11324há 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
  • 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

    root@kitploit:~
    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