Entendendo e resolvendo o problema da Vulnerabilidade #Heartbleed

Este bug permite que qualquer pessoa na internet seja capaz de ler uma parte da memória ram dos sistemas protegidos pelo OpenSSL. Assim comprometendo as chaves de identificação que os serviços utilizam para criptografar o tráfego, este que pode conter usuários, senhas e o conteúdo enviado pelo usuário. Isso permite que invasores que estão monitorando sua comunicação, sejam capazes de roubar suas informações que estariam criptografadas inicialmente.

Existe uma lista com os principais sites do mundo que estão sofrendo verificações periódicas, você pode ver esta lista aqui: https://github.com/musalbas/heartbleed-masstest/blob/master/top1000.txt

Também é possível testar um site específico de sua preferência por uma ferramenta chamada Heartbleed Test

Além disso você pode instalar uma extensão para o Google Chrome que irá te avisar se o site navegado está vulnerável: ChromeBleed

CVE-2014-0160 é a referência oficial da falha. CVE (Common Vulnerabilities and Exposures, Vulnerabilidades e Exposições públicas) é um padrão para catalogar e padronizar as vulnerabilidades de segurança da informação, a CVE é mantida pelo MITRE. Como houve uma dupla descoberta da falha, existe um outro registro de CVE , o CVE-2014-0346, este que não deve ser utilizado, pois a falha se tornou pública pelo CVE-2014-0160.

A falha está na implementação TLS/DTLS proveniente da extensão heartbeat (RFC6520) do OpenSSL. Quando ela é explorada ela vaza informações da memória do servidor para o cliente, assim como do cliente para o servidor. Pelo fato do vazamento, bleed em inglês e o nome da extensão se chamar heartbeat, a faha foi apelidada de Heartbleed.

A falha está presente apenas em um software, este que já está corrigido nas versões mais novas, porém esta falha permitiu que uma enorme quantidade de chaves privadas de criptografia fossem expostas a internet, considerando esta exposição e a facilidade de ataque e exploração da falha de forma imperceptível, tornou esta falha extremamente séria e perigosa.

Não. Este é um problema de implementação, no caso, um erro de programação na popular biblioteca OpenSSL, que provê serviços de criptografia como o SSL/TLS para aplicações e serviços.

Na prática, como a negação e a reemissão dos certificados funciona?

Se você é um provedor de serviços, em algum momento você se registrou com a sua autoridade de Certificado digital ( Certificate Authority (CA)). Então você deve checar como chaves comprometidas podem ser checadas e reemitidas. Algumas CAs fazem esta reemissão de forma gratuida, outras cobram.

É provável que você seja afetado direto ou indiretamente. A OpenSSL é a mais popular biblioteca de criptografica e implementação TLS (Segurança da camada de transporte) de código aberto utilizada em encriptação de tráfico na internet. Sua rede social, o site da sua empresa, os sites comerciais, sites que você utiliza para instalar softwares ou até os sites que seu governo utiliza estão vulneráveis com o OpenSSL. Muitos serviços online usam TLS para identificar eles mesmo para você e para proteger sua privacidade e suas transações. Você pode ter soluções em rede com logins protegidos pela implementação do TLS com a vulnerabilidade. Além disso você pode ter aplicações no seu computador que poderiam expor seus dados se você estiver conectado a serviços comprometidos.

Software mais notável usando OpenSSL são os servidores web de código aberto como Apache e nginx. A combinação desses dois servidores detém aproximadamente 66% dos sites ativos na internet, veja Netcraft\\\\\\\\\\\\\\\’s April 2014 Web Server Survey. Além disso o OpenSSL é utilizado para proteger por exemplo: servidores de e-mail (protocolos SMTP, POP e IMAP), servidores de bate-papo (protocolo XMPP ), rede virtual privada (SSL VPNs), soluções de rede e uma ampla variedade de aplicações ao lado do cliente. Felizmente grandes sites comerciais estão salvos pela escolha conservadora de seus equipamentos de terminais SSL/TLS e software. Ironicamente serviços menores e mais progressivos ou aqueles que atualizaram para a melhor e última criptação serão os mais afetados. Além disso o OpenSSL é muito popular em aplicações do lado do cliente e de alguma forma popular em soluções de rede que são mais atraídos em se atualizar.

Relação de diferentes versões: 

OpenSSL 1.0.1 até 1.0.1f (inclusive) estão vulneráveis 

OpenSSL 1.0.1g NÃO está vulnerável 

OpenSSL ramificação 1.0.0 NÃO está vulnerável 

OpenSSL ramificação 0.9.8 NÃO está vulnerável 

A falha está incluída no OpenSSL desde dezembro de 2011, e foi amplamente difundida desde o OpenSSL versão 1.0.1 de 14 de março de 2012. A versão do OpenSSL 1.0.1g que foi liberada em 7 de abril de 2014 contém a correção da falha.

As versões vulneráveis estão disponívels há dois anos agora e elas foram adotas rapidamente pelos sistemas operacionais modernos. O maior fator de contribuição foi que as versões TLS 1.1 e 1.2 ficaram disponíveis com a primeira versão OpenSSL (1.0.1) vulnerável e a comunidade de segurança vem forçando a TLS 1.2 devido a ataques mais antigos contra TLS (como o BEAST).

Algumas distribuições de sistemas operacionais que possuem a versão com a vulnerabilidade no OpenSSL: 

Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4 

Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11 

CentOS 6.5, OpenSSL 1.0.1e-15 

Fedora 18, OpenSSL 1.0.1e-4 

OpenBSD 5.3 (OpenSSL 1.0.1c 10 maio 2012) e 5.4 (OpenSSL 1.0.1c 10 maio 2012) 

FreeBSD 10.0 – OpenSSL 1.0.1e 11 fevereiro 2013 

NetBSD 5.0.2 (OpenSSL 1.0.1e) 

OpenSUSE 12.2 (OpenSSL 1.0.1c) 

Debian Squeeze (Versão estável antiga), OpenSSL 0.9.8o-4squeeze14 

SUSE Linux Enterprise Server 

FreeBSD 8.4 – OpenSSL 0.9.8y 5 fevereiro de 2013 

FreeBSD 9.2 – OpenSSL 0.9.8y 5 fevereiro de 2013 

FreeBSD Ports – OpenSSL 1.0.1g (Em 7 de abril às 21:46:40 2014 UTC) 

Mesmo que a correção pareça trivial, o time da OpenSSL está expert em resolver de maneira apropriada a falha, assim a última versão 1.0.1g ou mais novas devem ser usadas por estarem corrigidas. Se isso não for possível, desenvolvedores pode recompilar o OpenSSL sem o parâmetro do heartbeat utilizando a opção -DOPENSSL_NO_HEARTBEATS no momento da compilação.

A recuperação dessa vulnerabilidade poderia beneficiar se a nova versão do OpenSSL corrigisse a falha como desabilitasse temporariamente o heartbeat até algumas futuras versões. Parece que a maioria se não quase todas implementações TLS que respondem a requisição heartbeat hoje são versões vulneráveis de OpenSSL. Se somente versões vulneráveis de OpenSSL continuassem a a responder ao heartbeat pelos próximos meses se tornaria mais factível alcançar proprietários de serviços vulneráveis.

O abuso desta falha não deixa qualquer tipo de vestígio ou informações incomuns nos logs.

Mesmo o conteúdo da requisição heartbeat seja encriptado ele tem seu próprio tipo de registro no protocolo. Isto deve possibilitar detecção de intrusos e a prevenção de sistemas (IDS/IPS) de ser treinado para detectar o uso da requisição heartbeat. Devido a criptografia diferenciar entre o uso legítimo e ataque não pode ser baseado no conteúdo da requisição, mas a invasão pode ser detectada pela comparação do tamanho da requisição pelo tamanho da resposta. Isso parece implicar que IDS/IPS pode ser programado para detectar a invasão mas não bloquear a menos que todas as requisições heatbeat sejam bloquedas juntas.

Nós não sabemos. A comunidade de segurança deve implantar TLS/DTLS honeypots que capturam invasores e alertam sobre a tentativa de invasão.

Não há uma limitação de 64 kilobytes no ataque, esse limite se aplica somente a um único heartbeat. O invasor pode fazer diversas conexões durante uma sessão TLS ativa e continuar extraindo setores de 64 Kilobytes até que o conteúdo desejado seja totalmente revelado.

Não, essa vulnerabilidade não requer man in the middle (MITM). O invasor pode diretamente contatar o serviço vulnerável ou atacar qualquer usuário conectado a um serviço malicioso. Entretanto, além da ameaça direta o ladrão da chave possibilita aos invasores man in the middle personificar serviços comprometidos.

Não, a requisição heartbeat pode ser enviada e respondida durante a etapa de pareamento do protocolo. Isso ocorre antes da autenticação do certificado do cliente.

Não, o OpenSSL Federal Information Processing Standard (FIPS) não possui efeito algum sobre essa vulnerabilidade.

O uso do Perfect Forward Secrecy (PFS), o que, infelizmente, é raro mas poderoso, pode proteger comunicações antigas de descriptografia retrospectiva. Por favor, veja https://twitter.com/ivanristic/status/453280081897467905 como chaves que vazaram podem afetar este recurso.

Não, o código da extensão vulnerável heartbeat é ativado independemente do resultado da etapa de negociação e pareamento. O único caminho para se proteger é fazendo a atualização para uma versão corrigida do OpenSSL ou recompilar o OpenSSL sem a extensão heartbeat.

Esta falha foi uma descoberta independente feita pelo time de engenheiros de segurança (Riku, Antti and Matti) no Codenomicon e Neel Mehta do Google Security, o qual foi o primeiro a reportar isso ao time da OpenSSL. O time da Codenomicon encontrou a vulnerabilidade heartbleed enquanto melhoravam o SafeGuard, recurso do Codenomicon\\\\\\\\\\\\\\\’s Defensics, ferramenta de testes de segurança que reportou essa falha ao NCSC-FI para a coordenação de vulnerabilidade e reportou ao time OpenSSL.

A SafeGuard, recurso da Codenomicon Defensics, é uma ferramenta de segurança que automaticamente testa o sistema alvo procurando fraquezas que comprometam a integridade, proteção ou privacidade. Esta é uma solução sistemática que expõe falhas em certificados de criptografia, vazamentos de privacidade ou fraquezas na autenticação que tenham exposto os usuários da internet ao ataque man in the middle e ao hacking eavesdropping. Além da falha HeartBleed o novo recurso da Defensics TLS Safeguard pode detectar por exemplo a falha de segurança no amplamente utilizado GnuTLS, aplicação de código aberto que implementa a funcionalidade SSL/TLS no \\\\\\\\\\\\\\\”goto fail;\\\\\\\\\\\\\\\”, falha na implementação TLS/SSL da Apple que foi corrigida em Fevereiro 2014.

NCSC-FI tomou a tarefa de informar os autores do OpenSSL, softwares, sistemas operacionais e fornecedores de soluções, que foram potencialmente afetados. Entretanto, esta vulnerabilidade foi encontrada e os detalhes foram lançados de forma independente por outros, antes que este trabalho estivesse completo. Fornecedores de serviços pela internet devem notificar seus usuário onde e quando uma ação deve ser tomada.

Para aqueles provedores de serviços que foram afetados esta é uma boa hora de melhorar a segurança das chaves de criptografia utilizadas. Muitos softwares receberam updates, estes que geralmente não são atualizados. Mesmo que isso seja muito doloroso para a comunidade de segurança, nós temos certeza que a infra-estrutura de criminosos virtuais e seus segredos foram expostos também.

Este Q&A foi publicado como sequência ao aviso da OpenSSL, desde de que sua vulnerabilidade tornou-se pública em 7 de abril de 2014. O projeto OpenSSL fez uma declaração oficial em seu site https://www.openssl.org/news/secadv_20140407.txt. NCSC-FI publicou um aviso em https://www.cert.fi/en/reports/2014/vulnerability788210.html. Fornecedores individuais de distribuições de sistemas operacionais, proprietários afetados de serviços de Internet, pacotes de software e fornecedores de soluções podem emitir seus próprios avisos.

O Blog apresenta sempre novidades sobre certificação digital. Conheça e divulgue.