Leitores como você ajudam a apoiar o MUO. Quando você faz uma compra usando links em nosso site, podemos ganhar uma comissão de afiliado.
Na última semana de outubro de 2022, o OpenSSL Project revelou duas vulnerabilidades encontradas na biblioteca OpenSSL. Tanto o CVE-2022-360 quanto o CVE-2022-3786 foram rotulados como problemas de gravidade "alta" com uma pontuação CVSS de 8,8, apenas 0,2 pontos abaixo do necessário para serem considerados "críticos".
O problema está no processo de verificação de certificados que o OpenSSL realiza para autenticação baseada em certificado. A exploração das vulnerabilidades pode permitir que um invasor lance um ataque de negação de serviço (DoS) ou até mesmo um ataque de execução remota de código. Patches para os dois pontos fracos encontrados no OpenSSL v3.0.0 a v3.06 já foram lançados.
O que é OpenSSL?
O OpenSSL é um utilitário de linha de comando de criptografia de código aberto amplamente usado, implementado para manter segura a troca de tráfego da Web entre um cliente e um servidor. Ele é usado para gerar chaves públicas e privadas, instalar certificados SSL/TLS, verificar as informações do certificado e fornecer criptografia.
O problema veio à tona em 17 de outubro de 2022, quando o Polar Bear divulgou duas vulnerabilidades de alto nível encontradas no OpenSSL versão 3.0.0 a 3.0.6 para o OpenSSL Project. As vulnerabilidades são CVE-2022-3602 e CVE-2022-3786.
Em 25 de outubro de 2022, a notícia das vulnerabilidades chegou à internet. Mark Cox, engenheiro de software da Red Hat e vice-presidente de segurança da Apache Software Foundation, deu a notícia em um tweet.
Como um invasor pode explorar essas vulnerabilidades?
O par de vulnerabilidades CVE-2022-3602 e CVE-2022-3786 são propensos a ataque de estouro de buffer que é um ataque cibernético no qual o conteúdo da memória do servidor é abusado para revelar informações do usuário e chaves privadas do servidor ou executar a execução remota de código.
CVE-2022-3602
Essa vulnerabilidade permite que um invasor aproveite a saturação do buffer na verificação de certificado X.509 na verificação de restrição de nome. Isso acontece após a verificação da cadeia de certificados e requer uma assinatura de CA no certificado mal-intencionado ou verificação de certificado para continuar, apesar da falha no mapeamento para um emissor confiável.
Um invasor pode incorporar um esquema de phishing como criar um endereço de e-mail fabricado para estourar quatro bytes na pilha. Isso pode resultar em um ataque de negação de serviço (DoS) no qual o serviço fica indisponível após uma falha ou o invasor pode executar a execução remota de código, o que significa que um código é executado remotamente para controlar o aplicativo servidor.
Essa vulnerabilidade pode ser acionada se um cliente TLS autêntico se conectar a um servidor mal-intencionado ou se um servidor TLS autêntico se conectar a um cliente mal-intencionado.
CVE-2022-3786
Esta vulnerabilidade é explorada como CVE-2022-3602. A única diferença é que um invasor cria um endereço de e-mail malicioso para estourar um número arbitrário de bytes contendo o “.” caractere (decimal 46). No entanto, no CVE-2022-3602, apenas quatro bytes controlados pelo invasor são explorados.
O notório flashback da vulnerabilidade “Heartbleed”
Em 2016, um problema semelhante foi descoberto no OpenSSL, que recebeu uma classificação de gravidade “Crítica”. Esse era um bug de manipulação de memória que permitia aos invasores comprometer chaves secretas, senhas e outras informações confidenciais em servidores vulneráveis. O bug infame é conhecido como Coração Sangrado (CVE-2014-0160) e até hoje, mais de 200.000 máquinas são consideradas vulneráveis a essa fraqueza.
Qual é a correção?
No mundo atual de segurança cibernética, muitas plataformas implementam proteções de estouro de pilha para manter os invasores afastados. Isso fornece a mitigação necessária contra estouro de buffer.
A mitigação adicional contra essas vulnerabilidades envolve a atualização para a versão mais recente do OpenSSL. Como o OpenSSL v3.0.0 a v3.0.6 é vulnerável, é recomendável atualizar para o OpenSSL v3.0.7. No entanto, se você usar OpenSSL v1.1.1 e v1.0.2, você pode continuar a usar essas versões, pois elas não são afetadas pelos dois vulnerabilidades.
As duas vulnerabilidades são difíceis de explorar
As chances de abuso dessas vulnerabilidades são baixas porque uma das condições é um certificado malformado assinado por uma CA confiável. Devido ao cenário de ataques cada vez maior, a maioria dos sistemas modernos garante a implementação de mecanismos de segurança integrados para evitar esses tipos de ataques.
A segurança cibernética é uma necessidade no mundo de hoje, com mecanismos de proteção integrados e avançados, vulnerabilidades como essas são difíceis de explorar. Graças às atualizações de segurança lançadas pelo OpenSSL a tempo, você não precisa se preocupar com essas vulnerabilidades. Apenas tome as medidas necessárias, como corrigir seu sistema e implementar boas camadas de segurança, e você estará seguro para usar o OpenSSL.