DROWN: Ataque em múltiplos protocolos no TLS utilizando SSLv2 (CVE-2016-0800)

A Red Hat Product Security tomou conhecimento de uma vulnerabilidade no protocolo SSLv2, que foi determinada CVE-2016-0800 e é usada em um ataque de múltiplos protocolos referido como DROWN - Decrypting RSA using Obsolete and Weakened eNcryption (Decriptação RSA utilizando Encriptação Enfraquecida e Obsoleta).

Visão Geral

Um grupo de pesquisadores de segurança descobriu que SSLv2 (Protocolo de Camada Segura de Soquetes versão 2.0) é vulnerável ao ataque do oráculo de preenchimento (padding oracle) Bleichenbacher RSA, que pode ser utilizado para decriptar texto criptográfico RSA sem o conhecimento da chave secreta RSA compartilhada. Isto pode ser feito observando respostas de um servidor que tenha a chave secreta e executa a decriptação dos textos criptográficos fornecidos pelo invasor utilizando esta chave. Os pesquisadores também demonstraram um novo ataque em múltiplos protocolos que permite decriptação de sessões SSL/TLS utilizando versões de protocolo mais recentes - SSLv3 ou qualquer versão (1.0 - 1.2) atual TLS (Segurança da Camada de Transporte) - usando esta vulnerabilidade SSLv2 . Esta falha é uma questão do protocolo SSLv2 e afeta todas as implementações do protocolo. Pesquisadores referem-se a este ataque como DROWN geral.

Além disso, foram encontradas falhas na implementação do protocolo SSLv2 na criptografia do Open SSL e bibliotecas SSL/TLS, que tornam possível executar uma variante mais eficaz do ataque DROWN, chamada de DROWN especial. Estas questões foram determinadas CVE-2016-0703 e CVE-2016-0704, e já foram recentemente corrigidas como parte da correção para CVE-2015-0293.

Mais detalhes sobre este ataque podem ser encontrados no estudo dos pesquisadores entitulado DROWN: Breaking TLS using SSLv2.

Informações Gerais

O protocolo SSLv2 tem problemas de seguranças reconhecidos e tem sido considerado inseguro desde que seu substituto, SSLv3, foi publicado em 1996. Foi também formalmente desencorajado in 2011 via RFC 6176. Sua utilização na Internet atualmente é limitada, pois clientes SSL/TLS modernos ou não suportam esta versão do protocolo, ou utilizam versão mais recente sempre que possível. Contudo, muitos servidores SSL/TLS ainda o habilitam. Tais configurações permitem que até os clientes antigos conectem-se, e antes da publicação do ataque DROWN, não se conheciam ameaças a segurança da conexão dos clientes que suportam versões do protocolo mais recentes.

Configurações afetadas pelo ataque DROWN

Um servidor é vulnerável ao ataque DROWN caso habilite o protocolo SSLv2 além do SSLv3 ou TLSv1.x, e se utilizar o conjunto de cifras para troca de chaves RSA. Um servidor que não habilita SSLv2 também pode estar vulnerável se ele compartilhar suas chaves secretas RSA com outro servidor ou serviço com SSLv2 habilitado. Por exemplo, o ataque DROWN pode também ser utilizado para decriptar sessões HTTPS para um servidor web que não habilita SSLv2 se ele compartilhar suas chaves RSA com, por exemplo, um servidor IMAP, possivelmente executando no mesmo host, que habilita SSLv2. A utilização cifras SSLv2 fracas ou exportadas é necessária para que se realize um ataque de forma eficaz.

Conexões SSL/TLS que utilizam troca de chave não-RSA, tais como Diffie-Hellman ou Elliptic Curve Diffie-Hellman, não podem ser decriptadas utilizando o ataque DROWN.

Descrição do ataque e impacto

O ataque DROWN descrito por pesquisadores consiste das seguintes etapas:

• Um invasor precisa primeiro gravar um certo número de sessões SSL/TLS entre cliente e servidor utilizando qualquer versão do protocolo e utilizando conjunto de cifras RSA. Uma dessas sessões gravadas será decriptada. Pesquisadores indicam que aproximadamente 1.000 sessões são suficientes para o ataque.

*Subsequentemente, o invasor abre várias conexões SSLv2 para o servidor. Para algumas destas conexões, o invasor precisa atacar com força bruta uma sessão de chave de 40-bit (caso uma das cifras SSLv2 EXPORT possa ser utilizada) ou de 56-bit (para conjunto de cifras utilizando DES). Pesquisadores estimam que aproximadamente 40.000 conexões são necessárias.

• Depois disto, o invasor pode decriptar dados do"premaster secret" de um dos handshakes originalmente gravados. Esta informação é utilizada para gerar chaves de sessões simétricas, consequentemente decriptar a sessão gravada SSL/TLS completa. Dados confidenciais adicionais podem ser obtidos da sessão decriptada, como as credenciais de autenticações ou cookies

Pesquisadores indicam que eles podem decriptar um handshake TLS 1.2 com um servidor utilizando chaves RSA de 2048 bit usando 1.000 handshakes gravados, 40,000 conexões SSLv2, e 2 ⁵⁰ computações offline. O ataque levou menos de 8 horas utilizando recursos de um provedor de nuvem público com custo de US$440.

Eles também indicaram que a utilização do ataque DROWN special reduz o número de conexões SSLv2 para 14.000 e pode ser realizada utilizando uma única estação de trabalho em menos de 3 minutos. Isto possibilita utilizar esta falha para realizar um ataque de man-in-the-middle (MITM) ativo e se fazer passar por um servidor TLS para os clientes TLS conectados.

Bibliotecas SSL e TLS com suporte SSLv2

Os produtos Red Hat incluem os seguintes componentes que implementam suporte para protocolo SSLv2. Este suporte pode ser habilitado baseando-se em como os aplicativos utilizam estas bibliotecas SSL/TLS.

SSLv2 em OpenSSL

Aplicativos utilizando OpenSSL devem selecionar um método de conexão para informar a biblioteca quais versões dos protocolos SSL/TLS deseja utilizar. Métodos de conexão OpenSSL ou habilitam uma única versão do protocolo, ou um método especial SSLv23pode ser utilizado para habilitar todas as versões de protocolo suportada pela biblioteca. Este é o método de conexão mais comumente utilizado. O protocolo SSLv2 é automaticamente habilitado quando este método é selecionado. Os aplicativos devem explicitamente definir a opção SSL_OP_NO_SSLv2 nos objetos relevantes SSL_CTXou SSLpara desativar SSLv2. Embora muitos aplicativos façam isto, seja incondicionalmente ou baseado nas configurações, outros aplicativos utilizam as determinações padrões de protocolos habilitados. Os aplicativos utilizando biblioteca Open SSL são, por este motivo, susceptíveis a execução com SSLv2 habilitado.

As seguintes alterações foram aplicadas ao OpenSSL incluídos nos produtos Red Hat para tratar deste problema:

• O protocolo SSLv2 deixou de ser habilitado por padrão quando utiliza-se o método de conexão SSLv23
  *Todas os conjuntos de cifras SSLv2 utilizando chaves de encriptação simétrica 40 bit (EXPORT) ou 56 bit (single DES) estão agora desabilitadas e não podem mais serem utilizadas. Os seguintes conjuntos de cifras não estão mais disponíveis:
  • EXP-RC2-CBC-MD5 / SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
  • EXP-RC4-MD5 / SSL_CK_RC4_128_EXPORT40_WITH_MD5
  • DES-CBC-MD5 / SSL_CK_DES_64_CBC_WITH_MD5
• As versões do OpenSSL nos pacotes openssl em todas atualizações do Red Hat Enterprise Linux 4 e 5 agora checam a variável de ambiente OPENSSL_ENABLE_SSL2 e se está definido, SSLv2 é habilitado por padrão quando utilizar método de conexão SSLv23. Esta variável de ambiente pode ser utilizada para reabilitar SSLv2 se necessário.

O método de conexão SSLv2 não foi afetado pela alteração do método de conexão SSLv23e ainda pode ser utilizado para estabelecer conexões utilizando o protocolo SSLv2.

Observe também que embora a lista de cifras PADRÃO nas versões OpenSSL remetidas com Red Hat Enterprise Linux 6 e 7 excluem todos os conjuntos de cifras SSLv2, este padrão não evita que servidores aceitem conexões SSLv2 de clientes que forçam o uso de um conjunto de cifras desabilitado. Esta questão foi determinada CVE-2015-3197 e também corrigida em atualizações que tratam da questão DROWN.

SSLv2 no NSS (Serviços de Segurança de Rede)

A biblioteca criptográfica do NSS implementa o protocolo SSLv2, mas não o habilita por padrão.Os aplicativos precisam requisitar explicitamente à biblioteca para habilitar SSLv2 para utilizá-lo. As versões do NSS remetidas com Red Hat Enterprise Linux 7 não permitem habilitação do protocolo SSLv2. Os aplicativos que utilizam a biblioteca NSS provavelmente não executam com o SSLv2 habilitado.

Como as bibliotecas NSS não habilitam SSLv2 por padrão, não estão planejadas atualizações imediatas para tratar da questão DROWN. Atualizações futuras no Red Hat Enterprise Linux 6 deverão desabilitar o protocolo de um modo semelhante como foi desabilitado no Red Hat Enterprise Linux 7.

Bibliotecas SSL TLS sem suporte SSLv2

Os produtos Red Hat incluem os seguintes componentes que implementam algumas versões dos protocolos TLS ou SSL, mas não implementam suporte para SSLv2. Portanto, estes componentes não são afetados por este problema. Observe que os aplicativos utilizando estas bibliotecas não afetadas podem ser afetados pelo ataque DROWN se eles compartilhares suas chaves secretas RSA com outro aplicativo que utiliza uma biblioteca SSL/TLS que suporta SSLv2.

• GnuTLS
• OpenJDK (packages java-1.6.0-openjdk, java-1.7.0-openjdk, java-1.8.0-openjdk)
• Oracle JDK (packages java-1.6.0-sun, java-1.7.0-oracle, java-1.8.0-oracle)
• IBM JDK (packages java-1.6.0-ibm, java-1.7.0-ibm, java-1.7.1-ibm, java-1.8.0-ibm)

Resolução

A Red Hat recomenda que clientes conduzam uma análise de priorização baseada em risco de seus sistemas afetados e aplicar imediatamente as correções para remediar a questão. Reiniciar o sistema depois de atualizar do modo mais seguro para garantir que todos os serviços afetados utilizem a biblioteca atualizada OpenSSL. Se não for possível uma reinicialização, é necessário reiniciar todos os serviços de rede que dependem do Open SSL depois de aplicar as correções.

Agradecimentos

A Red Hat gostaria de agradecer o projeto Open SSL por notificar estas questões. Upstream agradece Nimrod Aviram e Sebastian Schinzel como os relatores originais.

Perguntas Frequentes

Como desabilitar SSLv2 no aplicativo X?

Consulte o artigo da base de conhecimento [Securing Application 'X' in RHEL 'Y' ? ] (https://access.redhat.com/articles/1462183) para informações de como alterar configurações relativas a SSL/TLS, tais como, versões de protocolos habilitadas, em vários aplicativos remetidos em várias versões do Red Hat Enterprise Linux.

As chaves dos servidores ou certificados precisam ser regeneradas por causa deste problema?

Não. O DROWN não expõe diretamente as chaves RSA secretas, porém destina-se a chaves de sessões individuais que são geradas durante o handshakes de conexões SSL/TLS e usadas para a encriptação simétrica. O comprometimento destas chaves permitem a decriptação de sessões SSL/TLS específicas. Sendo assim, mesmo que um serviço seja detectado vulnerável ao ataque DROWN, não há necessidade de regenerar a chave do serviço ou o certificado.

O SSLv2 está habilitado nas versões do servidor da web Apache httpd remetido com os produtos Red Hat?

O servidor da web Apache httpd pode utilizar um dos seguintes módulos para fornecer serviço HTTPS:

• mod_ssl - Este módulo utiliza a biblioteca criptográfica OpenSSL e está incluído como parte da distribuição do servidor da web Apache httpd.
• mod_nss - Este módulo utiliza a biblioteca criptográfica NSS e é desenvolvido e distribuído separadamente do projeto Apache httpd.

Ambos estes módulos estão inclusos nos produtos Red Hat.

As configurações padrões para httpd utilizando mod_sslsão:

*As versões httpd remetidas com o Red Hat Enterprise Linux 7, na coleçãohttpd24no Red Hat Software Collections e com Red Hat JBoss Web Server 3, são baseadas na versão httpd 2.4 upstream e não podem ser configuradas para habilitar o protocolo SSLv2.

As versões httpd remetidas com Red Hat Enterprise Linux 5 e 6, Red Hat JBoss Web Server 1 e 2, e Red Hat JBoss Enterprise Application Platform 6 são baseadas na versões httpd 2.2 upstream. Estas versões podem ser configuradas para utilizar SSLv2, porém este protocolo está desabilitado na configuração padrão. O arquivo de configuração /etc/httpd/conf.d/ssl.confinclui as seguintes diretivas de configurações que desabilitam SSLv2:

SSLProtocol all -SSLv2

*As versões httpd remetidas com o Red Hat Enterprise Linux 4 são baseadas nas versões httpd 2.0 upstream. A configuração padrão habilita SSLv2, que pode ser desabilitada adicionando a mesma diretiva SSLProtocol listada acima para o arquivo de configuração /etc/httpd/conf.d/ssl.confe reinicializando o serviçohttpd.

As configurações padrões para httpd utilizando mod_nsssão:

• As versões mod_nss remetidas com o Red Hat Enterprise Linux 5, 6, e 7 não habilitam SSLv2 por padrão. O arquivo de configuração /etc/httpd/conf.d/nss.conf inclui, dependendo da versão do pacote mod_nss, uma das seguintes diretivas de configuração que habilita somente SSLv3 ou mais recente, ou TLSv1.0 ou mais recente:

NSSProtocol SSLv3,TLSv1
NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2

AVISO: Devido aos conhecidos problemas do protocolo SSLv3, nós continuamos a recomendação de que a versão também seja desabilitada. Veja artigo relacionado POODLE: SSLv3 vulnerability (CVE-2014-3566) para detalhes e instruções para desabilitar o protocolo SSLv3 em vários componentes dos produtos Red Hat.

O SSLv2 está habilidado nos servidores de email SMTP remetidos com o Red Hat Enterprise Linux?

Configurações Padrões de ambos os servidores de email Postfix e Sendmail no Red Hat Enterprise Linux 5, 6, e 7 não habilitam encriptação SSL/TLS.

Se um administrado de sistema habilitar SSL/TLS no Postfix, o SSLv2 é habilitado com encriptação oportunista e desabilitado com encriptação obrigatória por padrão. No Red Hat Enterprise Linux 6 e 7, é possível desabilitar SSLv2 com encriptação oportunista utilizando a opção de configuração smtpd_tls_protocols.

Se um administrador de sistema habilitar SSL/TLS no Sendmail, o SSLv2 é habilitado por padrão. No Red Hat Enterprise Linux 5, 6, e 7, é possível desabilitar SSLv2 utilizando a opção de configuraçãoServerSSLOptions.

Veja a questão"Como desabilitar SSLv2 no aplicativo X?" acima para links com mais recursos em como configurar SSL/TLS no Postfix e Sendmail.

Eu preciso atualizar minha instalação do EAP 6.4?
O EAP pode ser configurado para usar o provedor de criptografia Java (JSSE) ou o provedor nativo (APR/OpenSSL). Se você está utilizando o provedor Apr/OpenSSL então você deve seguir as etapas abaixo:

• Red Hat Enterprise Linux
  Atualize o OpenSSL para sua versão.
• Windows ou Solaris
  Uma atualização para as bibliotecas openssl estará disponível no Customer Service Platform. Esta atualização irá substituir as bibliotecas libssl e libeay e aplicativo openssl.

O EAP 6.4 foi testado no Windows utilizando APR/OpenSSL e apesar de tecnicamente a biblioteca OpenSSL necessitar de uma atuação, o EAP 6.4 irá por padrão utilizar TLSv1 e rejeitar pedidos de cifras para SSLv2 e SSLv3. O EAP não está atualmente susceptível a vulnerabilidade desta falha.

Eu preciso atualizar minha instalação do EAP 5.2?
O EAP pode ser configurado para usar o provedor de criptografia Java (JSSE) ou o provedor nativo (APR/OpenSSL). Se você está utilizando o provedor Apr/OpenSSL então você deve seguir as etapas abaixo:

• Red Hat Enterprise Linux
  Atualize o OpenSSL para sua versão.
• Windows ou Solaris
  Uma atualização para as bibliotecas openssl estará disponível no Customer Service Platform. Esta atualização irá substituir as bibliotecas libssl e libeay e aplicativo openssl.

EAP 5.2 está sendo testado no Windows para avaliar a vulnerabilidade deste para esta falha.

Eu preciso atualizar minha instalação do EWS 2.1
Esta falha afeta somente instalações Windows e Solaris onde APR/OpenSSL foram configuradas como provedores de segurança. O EWS 2.1 atualmente suporta SSLv2 e SSLv3.
Se você está utilizando o provedor Apr/OpenSSL, então você deve seguir as etapas abaixo:

• Red Hat Enterprise Linux
  Atualize o OpenSSL para sua versão.
• Windows ou Solaris
  Uma atualização para as bibliotecas openssl estará disponível no Customer Service Platform. Esta atualização irá substituir as bibliotecas libssl e libeay e aplicativo openssl.

A: Sim o EWS 2.1 está afetado, atualizações estarão disponíveis no Customer Service Portal. Esta falha afeta somente instalações Windows e Solaris onde APR/OpenSSL foi configurado como provedor de segurança. A configuração padrão JSSE não está afetada. Atualizações estarão disponíveis no Customer Service Portal.

Eu preciso atualizar a minha instalação do EWS 3.0.2?
Esta falha afeta somente instalações Windows e Solaris onde APR/OpenSSL foi configurado como provedor de segurança. O EWS 3.0.2 atualmente suporta SSLv2 e SSLv3. O EWS 3.0.3 quando lançado deixará de oferecer SSLv2 ou SSLv3.

Se você está utilizando o provedor Apr/OpenSSL, então você deve seguir as etapas abaixo:

• Red Hat Enterprise Linux
  Atualize o OpenSSL para sua versão.
• Windows ou Solaris
  Uma atualização para as bibliotecas openssl estará disponível no Customer Service Platform. Esta atualização irá substituir as bibliotecas libssl e libeay e aplicativo openssl.

Qual a situação do pacote tomcat-native?

O pacote tomcat-native não é afetado por esta falha.O pacote tomcat-native depende do sistema fornecido pelas bibliotecas OpenSSL.