Vulnerabilidades do OpenSSL: ataque DROWN e CacheBleed
Duas vulnerabilidades muito interessantes, o ataque DROWN e CacheBleed, foram divulgadas recentemente, tendo como alvo a criptografia OpenSSL e o SSL/TLS.
Duas vulnerabilidades muito interessantes foram divulgadas recentemente, tendo como alvo a criptografia OpenSSL e o SSL/TLS.
1 – Ataque DROWN
O primeiro é o que você deve conhecer com a maior urgência. Ele tem até um nome de marketing e um site bem chique, então você sabe que é sério: o ataque DROWN.
DROWN significa Decrypting RSA with Obsolete and Weakened eNcryption (descriptografando RSA com criptografia obsoleta e enfraquecida). Eu estou supondo que eles escolheram o nome e o domínio correspondentes em primeiro lugar e, em seguida, fizeram o acrônimo.
DROWN é uma vulnerabilidade grave que afeta HTTPS e outros serviços que dependem de SSL e TLS, alguns dos protocolos criptográficos essenciais para a segurança na Internet.
DROWN mostra que apenas suportar SSLv2 é uma ameaça para servidores e clientes modernos. Ele permite que um atacante possa descriptografar conexões TLS modernas entre clientes e servidores atualizados, enviando sondas para um servidor que suporta SSLv2 e usa a mesma chave privada.
Em suma: é uma vulnerabilidade tendo como alvo o SSLv2.
Sim, SSLv2.
O mesmo protocolo que você deve ter desativado em todos os servidores, aparelhos e configurações anos atrás, quando a vulnerabilidade POODLE do SSLv3 foi divulgada.
Se você tem SSLv2 desativado, você está pensando “Eu estou seguro, certo?”. Lembre-se: DROWN é bem pior pela sua natureza cross-protocolo, ou seja, um servidor HTTPS que não suporta SSLv2 pode ser vulnerável porque compartilha a sua chave pública com um servidor SMTP que suporta.
Um único legado, esquecido ou em um servidor não gerenciado que detém a chave privada para o seu certificado SSL/TLS é suficiente para comprometer sua segurança.
Desativando SSLv2 em seus servidores web
Um lembrete: se você estiver executando o Apache, veja aqui como desativar:
SSLProtocol All -SSLv2 -SSLv3
Ou no Nginx:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Honestamente, se você está vulnerável ao DROWN, provavelmente estava esperando por isso, deixando esse protocolo ativado por tanto tempo.
Dito isso, alguns sistemas não suspeitos poderiam ter hackeado você por causa disso, especialmente:
- Servidores de e-mail com IMAPs e POPs (IMAP ou POP3 sobre SSL) ainda podem ter configurações velhas SSLv2.
- Servidores legados ou aparelhos que você até mesmo esqueceu que tinha SSL ativado por padrão, e eles suportam SSLv2.
A correção do DROWN pelo OpenSSL
OpenSSL emitiu uma nova atualização para a base de código do OpenSSL em uma recente consulta de segurança OpenSSL, afirmando:
NOTA: Com essa atualização, OpenSSL está desabilitando o protocolo SSLv2 por padrão, assim como removendo as cifras SSLv2 EXPORT. Nós recomendamos fortemente não usar o SSLv2 devido não somente aos problemas descritos abaixo, mas a outras deficiências conhecidas do protocolo, tal como descrito em https://tools.ietf.org/html/rfc6176 –Consulta de Segurança OpenSSL
Então é oficial: SSLv2 está fora!
2 – CacheBleed: um ataque de temporização
Como se uma vulnerabilidade SSL não fosse suficiente, o CacheBleed foi anunciado recentemente.
O orçamento de marketing deles era obviamente menor a julgar pelo site, mas eles têm um nome fantasia bem legal.
Aqui está o ataque, resumido:
CacheBleed é um ataque side-channel que explora o vazamento de informações por meio de conflitos cache-bank em processadores Intel. Ao detectar conflitos cache-bank via variações de temporização em minutos, somos capazes de recuperar informações sobre os processos da vítima em execução na mesma máquina. Nosso ataque é capaz de recuperar as duas chaves secretas RSA do OpenSSL 1.0.2f, a de 2048-bit e a de 4096-bit – CacheBleed
Essa última frase vale a pena repetir: Nosso ataque é capaz de recuperar as duas chaves secretas RSA, a de 2048-bit e a de 4096-bit. Adeus, segurança.
Há apenas uma pequena dor de cabeça para esse negócio de CacheBleed:
OpenSSL classificou essa vulnerabilidade como de “baixa intensidade”, com o que estamos de acordo. A fim de montar o ataque, o atacante tem que ser capaz de executar o código de ataque na mesma máquina que executa o código da vítima. CacheBleed é um ataque complexo e há vulnerabilidades muito mais fáceis de explorar em computadores pessoais, e é improvável que alguém use o CacheBleed em tal ambiente – CacheBleed
Eu já disse isso antes e vou dizer novamente: segurança em TI é um mito.
Um passo à frente, três grandes passos para trás.
Se você gostou deste conteúdo, pode me ajudar a divulgar este conhecimento, compartilhando na sua rede social preferida. Obrigado!