A Vulnerabilidade Heartbleed é um bug severo na popular biblioteca de criptografia chamada OpenSSL. A falha permite roubo de informação protegida pelas criptografias nos protocolos SSL/TLS, esta que é de comum uso para segurança na internet. Os protocolos SSL/TLS fornecem comunicação segura e privacidade em conexões de internet, muito utilizados em aplicações web, email, mensageiros instantâneos (IM) e redes de comunicação privadas (VPNs).
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.
Como posso identificar sites vulneráveis?
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
O que é CVE-2014-0160?
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.
Por quê esta falha é chamada de Heartbleed?
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.
O que torna a falha Heartbleed única?
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.
Isso é uma falha na concepção da especificação do protocolo SSL/TLS?
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.
Eu estou afetado pela vulnerabilidade?
É 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.
O quão a falha está difundida?
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.
Quais as versões afetadas do OpenSSL?
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.
Quão difundidas são as versões vulneráveis do OpenSSL?
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).
E os Sistemas Operacionais?
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)
Algumas distribuições de sistemas operacionais que NÃO possuem a versão com a vulnerabilidade no OpenSSL:
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)
Como o OpenSSL pode ser corrigido?
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 extensão heartbeat deve ser removida com o intuito de ajudar na deteção de serviços vulneráveis?
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.
É possível detectar se alguém aproveitou a falha e usou contra mim?
O abuso desta falha não deixa qualquer tipo de vestígio ou informações incomuns nos logs.
É possível que IDS/IPS possam detectar e bloquear o ataque?
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.
Já houveram muitos ataques?
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.
O invasor pode acessar realmente só 64 kilobytes da memória?
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.
Este é um ataque man in the middle como ocorreu na Apple?
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.
Os clientes de autenticação TLS conseguem lidar com isso?
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.
O modo FIPS do OpenSSL consegue lidar com isso?
Não, o OpenSSL Federal Information Processing Standard (FIPS) não possui efeito algum sobre essa vulnerabilidade.
O Perfect Forward Secrecy (PFS) minimiza esta 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.
A extensão heartbeat pode ser desabilitada durante o pareamento do protocolo TLS?
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.
Quem encontrou a vulnerabilidade Heartbleed?
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.
O que é Defensics SafeGuard?
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.
Quem coordena a resposta a esta vulnerabilidade?
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.
Existe um lado bom de tudo isso?
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.
Onde encontrar mais informação?
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.
Fonte: Via Alcyon Ferreira de Souza Junior e http://www.portaltic.com
http://heartbleed.com (texto original, publicado 7 de abril de 2014, ~19:00 UTC)
Renato Mendes Figueiredo | Renatomefi IT Solutions
Samuel Mendes
https://github.com/renatomefidf/heartbleed
