O Bug Heartbleed.

Bug Heartbleed 

A Bug Heartbleed é uma vulnerabilidade grave na biblioteca de software criptográfico OpenSSL popular. Esta fraqueza permite roubar as informações protegidas, em condições normais, pela criptografia SSL / TLS usada para proteger a Internet. SSL / TLS fornece a segurança ea privacidade de comunicação através da Internet para aplicações tais como web, e-mail, mensagens instantâneas (IM) e em algumas redes privadas virtuais (VPNs). 

O bug Heartbleed permite que qualquer pessoa na internet para ler a memória dos sistemas protegidos pelas versões vulneráveis ​​do software OpenSSL. Isso compromete as chaves secretas usadas para identificar os prestadores de serviços e para criptografar o tráfego, os nomes e senhas dos usuários e do conteúdo real. Isso permite que atacantes para espionar as comunicações, roubar dados diretamente dos serviços e os usuários e para representar os serviços e usuários. 

O que vazamentos na prática? 

Nós testamos alguns dos nossos próprios serviços do ponto de vista do atacante. Nós atacamos a nós mesmos de fora, sem deixar rastro. Sem o uso de qualquer informação privilegiada ou credenciais pudemos roubar de nós mesmos as chaves secretas usadas para os nossos certificados X.509, nomes de usuário e senhas, mensagens instantâneas, e-mails e documentos críticos de negócios e comunicação. 

Como parar o vazamento? 

Enquanto a versão vulnerável do OpenSSL está em uso, pode ser abusado. OpenSSL Fixa foi lançado e agora ele tem que ser implantado. Fornecedores de sistemas operacionais e de distribuição, fornecedores de equipamento, fornecedores de software independentes que adotar a correção e notificar seus usuários. Os prestadores de serviços e os usuários têm que instalar a correção, uma vez que se torna disponível para os sistemas operacionais, dispositivos de rede e software que utilizam. 

Q & A 

Qual é a CVE-2014-0160? 

CVE-2014-0160 é a referência oficial para este bug. CVE (Common Vulnerabilities and Exposures) é o padrão para nomes de Vulnerabilidade de Segurança da Informação mantidos pela MITRE. Devido à descoberta de co-incidente um CVE duplicado, CVE-2014-0346, que foi atribuído a nós, não deve ser utilizado, uma vez que os outros independentemente veio a público com o identificador CVE-2014-0160. 

Por que ele é chamado de Bug Heartbleed? 

Bug é na implementação do OpenSSL da extensão TLS / DTLS (protocolos de segurança da camada de transporte) batimentos cardíacos (RFC6520). Quando é explorado leva ao vazamento do conteúdo da memória a partir do servidor para o cliente e para o cliente para o servidor. 

O que torna o Bug Heartbleed único? 

Bugs no software único ou biblioteca vêm e vão e são fixados por novas versões. No entanto, este bug deixou grande quantidade de chaves privadas e outros segredos expostos na Internet. Considerando a longa exposição, facilidade de exploração e os ataques não deixando nenhum vestígio esta exposição deve ser levado a sério. 

Isso é uma falha de projeto na especificação do protocolo SSL / TLS? 

Não. Isso é problema de implementação, ou seja, erro de programação na biblioteca popular, OpenSSL que fornece serviços criptográficos, como SSL / TLS para as aplicações e serviços. 

O que está sendo divulgado? 

A criptografia é usada para proteger os segredos que podem prejudicar sua privacidade ou segurança, se vazar. A fim de coordenar a recuperação a partir deste bug classificamos os segredos comprometidos a quatro categorias: 1) material de chave primária, 2) materiais chave secundária e 3) de conteúdo protegido e 4) colaterais. 

O que é vazado material de chave primária e como recuperar? 

Estas são as jóias da coroa, as próprias chaves de criptografia. Chaves secretas vazaram permitir que o invasor para descriptografar qualquer tráfego passado e futuro para os serviços de conservação e para representar o serviço à vontade. Qualquer proteção dada pela criptografia e assinaturas nos certificados X.509 podem ser anuladas. A recuperação deste vazamento requer remendar a vulnerabilidade, a revogação das chaves comprometidas e reemissão e redistribuindo novas chaves. Mesmo fazendo tudo isso ainda vai deixar qualquer tráfego interceptado pelo atacante no passado ainda vulnerável a descriptografia. Tudo isso tem que ser feito pelos proprietários dos serviços. 

O que é vazado material de chave secundária e como recuperar? 

Estes são, por exemplo, as credenciais do usuário (nomes de usuário e senhas) utilizados nos serviços vulneráveis​​. A recuperação deste vazamento, os armadores de serviço primeiro para restaurar a confiança no serviço de acordo com as etapas descritas acima. Após isso os usuários podem começar a mudar suas senhas e as possíveis chaves de criptografia de acordo com as instruções dos titulares dos serviços que foram comprometidos. Todas as chaves de sessão e cookies de sessão deve ser invalidado e considerado comprometido. 

O que é conteúdo protegido vazou e como recuperar? 

Este é o conteúdo real manipulados pelos serviços vulneráveis. Pode ser dados pessoais ou financeiros, comunicação privada, tais como e-mails ou mensagens instantâneas, documentos ou qualquer coisa vista vale a pena proteger por criptografia. Somente os proprietários dos serviços será capaz de estimar a probabilidade que foi vazado e devem notificar os seus usuários em conformidade. A coisa mais importante é restaurar a confiança para o material de chave primária e secundária, como descrito acima. Só isso permite uma utilização segura dos serviços comprometidos no futuro. 

O que é colateral vazou e como recuperar? 

Colateral vazaram são outros detalhes que tenham sido expostos ao atacante no conteúdo da memória vazada. Estes podem conter detalhes técnicos, tais como endereços de memória e medidas de segurança, tais como canários utilizados para proteger contra ataques de estouro. Estes têm apenas valor contemporâneo e perderá o seu valor para o atacante quando OpenSSL foi atualizado para uma versão corrigida. 

Recuperação soa trabalhoso, há um atalho? 

Depois de ver o que vimos por "atacar" a nós mesmos, com facilidade, decidimos levar isso muito a sério. Nós fomos laboriosamente através remendar nossos próprios serviços críticos e estão lidando com possível comprometimento de nosso material de chave primária e secundária. Tudo isso apenas no caso de não estávamos primeiros a descobrir isso e isso poderia ter sido explorado na natureza já. 

Como revogação e reedição de certificados funciona na prática? 

Se você é um fornecedor de serviços que assinaram seus certificados com uma Autoridade de Certificação (CA). Você precisa verificar o seu CA como chaves comprometidas pode ser revogado eo novo certificado relançado para as novas chaves. Algumas CAs fazer isso de graça, alguns podem ter uma taxa. 

Sou afetado pelo bug? 

Você é susceptível de ser afectada, quer direta ou indiretamente. OpenSSL é a biblioteca de criptografia de código aberto mais popular e TLS (Transport Layer Security) a implementação usada para criptografar o tráfego na Internet. Seu site popular sociais, site da sua empresa, comércio local, local passatempo, site que você instalar o software a partir de ou até mesmo sites operados por seu governo pode estar usando OpenSSL vulnerável. Muitos dos serviços on-line usar o TLS para tanto a identificar-se para você e para proteger sua privacidade e transações. Você pode ter aplicações de rede com logins garantidos por esta implementação de buggy do TLS. Além disso, você pode ter o software do lado do cliente no seu computador que pode expor os dados do seu computador, se você se conectar a serviços comprometidos. 

Como generalizada é isso? 

O software mais notável usando OpenSSL são os servidores web de código aberto como o Apache e nginx. A parcela de apenas aqueles dois dos sítios ativos na Internet mercado combinada era mais de 66% de acordo com abril 2014 Levantamento da Netcraft Web Server. Além disso OpenSSL é usado para proteger, por exemplo, servidores de e-mail (protocolos SMTP, POP e IMAP), servidores (protocolo XMPP), redes privadas virtuais (VPNs SSL), dispositivos de rede e grande variedade de software do lado do cliente de chat. Felizmente muitos sites grandes consumidores são salvos por sua escolha conservadora de SSL / TLS equipamento de terminação e software. Serviços progressistas Ironicamente menores e mais ou aqueles que atualizado para melhor e mais recente criptografia será afetado mais. Além disso OpenSSL é muito popular no software cliente e um pouco popular em aplicações de rede que têm mais inércia no sentido de obter as atualizações. 

Quais versões do OpenSSL são afetados? 

Estatuto dos diferentes versões: 

OpenSSL 1.0.1 através 1.0.1f (inclusive) são vulneráveis 

OpenSSL 1.0.1g não é vulnerável 

OpenSSL 1.0.0 ramo não é vulnerável 

OpenSSL 0.9.8 ramo não é vulnerável 

Bug foi introduzido para OpenSSL em dezembro de 2011 e foi para fora no selvagem desde OpenSSL liberar 1.0.1 em 14 de marco de 2012. OpenSSL 1.0.1g lançado em 07 abril de 2014 corrige o bug. 

Quão comum são as versões vulneráveis ​​do OpenSSL? 

As versões vulneráveis ​​foram lá fora, há mais de dois anos e agora eles têm sido rapidamente adotado pelos sistemas operacionais modernos. Um fator de contribuição importante foi que as versões TLS 1.1 e 1.2 veio disponíveis com a primeira versão OpenSSL vulnerável (1.0.1) e comunidade de segurança foi empurrando o TLS 1.2 devido a ataques anteriores contra TLS (como a Besta). 

Como cerca de sistemas operacionais? 

Algumas distribuições do sistema operacional que já fornecidos com a versão OpenSSL potencialmente vulnerável: 

Debian Wheezy (estável), 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 May 2012) e 5,4 (OpenSSL 1.0.1c 10 May 2012) 

FreeBSD 10.0 - 1.0.1e OpenSSL 11 fev 2013 

NetBSD 5.0.2 (OpenSSL 1.0.1e) 

OpenSUSE 12.2 (OpenSSL 1.0.1c) 

Distribuição do sistema operacional com as versões que não são vulneráveis​​: 

Debian Squeeze (oldstable), OpenSSL 0.9.8o-4squeeze14 

SUSE Linux Enterprise Server 

FreeBSD 8.4 - 0.9.8y OpenSSL 05 de fevereiro de 2013 

FreeBSD 9.2 - 0.9.8y OpenSSL 05 de fevereiro de 2013 

FreeBSD 10.0p1 - 1.0.1g OpenSSL (Na 08 abril 2014 18:27:46 UTC) 

FreeBSD - 1.0.1g OpenSSL (Pelo 7 abr 2014 21:46:40 UTC) 

Como pode OpenSSL ser corrigido? 

Mesmo que a correção de código real pode parecer trivial, equipe OpenSSL é o especialista em corrigi-lo corretamente para versão fixa 1.0.1g ou mais recente deve ser usado. Se isso não for possível os desenvolvedores de software pode recompilar OpenSSL com o aperto de mão removido do código por tempo de compilação opção de DOPENSSL_NO_HEARTBEATS. 

Deve pulsação ser removido para auxiliar na detecção de serviços vulneráveis​​? 

A recuperação deste bug poderia ter beneficiado se a nova versão do OpenSSL que tanto ter corrigido o bug e os batimentos cardíacos desativado temporariamente até que alguma versão futura. Maioria, se não quase todos, de implementações TLS que responderam ao pedido de batimentos cardíacos no momento da descoberta foram versões vulneráveis ​​do OpenSSL. Se apenas versões vulneráveis ​​do OpenSSL teria continuado a responder à batida do coração para os próximos meses, então em grande escala coordenada resposta para alcançar os proprietários de serviços vulneráveis ​​se tornaria mais viável. No entanto, a resposta rápida por parte da comunidade da Internet no desenvolvimento de ferramentas de detecção on-line e autônomos rapidamente superou a necessidade de remoção de batimentos cardíacos por completo. 

Posso detectar se alguém tem explorado isso contra mim? 

A exploração desta bug não deixa qualquer vestígio de qualquer coisa acontecer anormal para os logs. 

Pode IDS / IPS detectar ou bloquear este ataque? 

Embora os batimentos cardíacos podem aparecer em diferentes fases de a configuração da conexão, detecção de intrusão e sistemas de prevenção de regras (IDS / IPS) para detectar batimentos cardíacos têm sido desenvolvidos. Devido à criptografia diferenciar entre o uso legítimo e ataque não pode ser baseado no conteúdo do pedido, mas o ataque pode ser detectada através da comparação do tamanho do pedido contra o tamanho da resposta. Isto implica que o IDS / IPS pode ser programado para detectar o ataque, mas não bloqueá-lo, a menos que os pedidos de batimentos cardíacos são bloqueados completamente. 

Tem este sido abusado na natureza? 

Nós não sabemos. Comunidade de Segurança deverá implantar honeypots TLS / DTLS que aprisionam os atacantes e para alertar sobre tentativas de exploração. 

Pode atacante acesso apenas 64k de memória? 

Não há limitação total de 64 kilobytes para o ataque, esse limite só se aplica a um único batimento cardíaco. Atacante pode manter reconectar ou durante uma conexão TLS ativo manter solicitando número arbitrário de 64 pedaços de kilobytes de memória até que o conteúdo segredos suficientes são revelados. 

Isso é um bug MITM como empreendedores da Apple falhar bug foi? 

Não, isso não requer um homem no ataque do meio (MITM). Atacante pode contactar directamente o serviço vulnerável ou atacar qualquer usuário que se conecta a um serviço mal-intencionado. No entanto, além de ameaça direta o roubo do material de chave permite que o homem em que os atacantes do meio para representar os serviços comprometidos. 

A autenticação de certificado de cliente TLS mitigar esse? 

Não, pedido batimentos cardíacos podem ser enviados e é respondida durante a fase de handshake do protocolo. Isso ocorre antes da autenticação do certificado de cliente. 

O modo FIPS do OpenSSL mitigar esse? 

Não, OpenSSL Federal Information Processing Standard mode (FIPS) não tem efeito sobre a funcionalidade batimentos cardíacos vulnerável. 

A Perfect Forward Secrecy (PFS) mitigar esse? 

Uso de Perfect Forward Secrecy (PFS), que infelizmente é raro, mas poderoso, deve proteger as comunicações passadas de descriptografia retrospectiva. Por favor, veja https://twitter.com/ivanristic/status/453280081897467905 como bilhetes vazaram pode afetar isso. 

Pode pulsação extensão ser desativado durante o handshake TLS? 

Não, vulnerável código de extensão pulsação é ativado, independentemente dos resultados das negociações da fase aperto de mão. A única maneira de se proteger é fazer o upgrade para versão fixa do OpenSSL ou recompilar OpenSSL com o aperto de mão removido do código. 

Quem encontrou o Bug Heartbleed? 

Este bug foi descoberto independentemente por uma equipe de engenheiros de segurança (Riku, Antti e Matti) em Codenomicon e Neel Mehta, da Google Segurança, que primeiro relatou à equipe OpenSSL. Equipe Codenomicon encontrado bug heartbleed, melhorando a função de salvaguarda em ferramentas de teste de segurança Defensics da Codenomicon e relatou este bug para o NCSC-FI para a coordenação e elaboração de relatórios de vulnerabilidade equipe OpenSSL. 

O que é a salvaguarda Defensics? 

O recurso salvaguarda da segurança TestTools Defensics da Codenomicon testa automaticamente o sistema de destino para deficiências que comprometem a integridade, a privacidade ou segurança. A salvaguarda é a solução sistemática para expor verificações que falharam criptográficos certificados, vazamentos de privacidade ou fraquezas autenticação de bypass que têm expostos os usuários de Internet ao homem no meio ataques e espionagem. Além do bug Heartbleed o novo recurso de salvaguarda Defensics TLS pode detectar, por exemplo, a falha de segurança explorada em GnuTLS amplamente utilizado software open source de aplicação funcionalidade SSL / TLS eo "Ir a falhar;" bug na implementação do TLS / SSL da Apple, que foi corrigido em fevereiro de 2014. 

Quem coordena a resposta a esta vulnerabilidade? 

Imediatamente após a nossa descoberta do bug em 3 de abril de 2014, NCSC-FI assumiu a tarefa de verificar-lo, analisá-lo ainda mais e chegar aos autores do OpenSSL, software, sistema operacional e os vendedores de eletrodomésticos, que foram potencialmente afetados. No entanto, essa vulnerabilidade tenha sido encontrado e detalhes lançado de forma independente por outros antes de este trabalho foi concluído. Os fornecedores devem ser notificando seus usuários e prestadores de serviços. Prestadores de serviços de Internet devem ser notificando seus usuários finais, onde e quando é necessária uma acção potencial. 

Existe um lado bom de tudo isso? 

Para os prestadores de serviços que são afetadas esta é uma boa oportunidade para atualizar a força das chaves secretas usadas segurança. Um lote de software recebe atualizações que de outra forma não teria sido urgente. Embora isso seja doloroso para a comunidade de segurança, podemos ter certeza de que a infra-estrutura dos criminosos e seus segredos foram expostos também. 

O que pode ser feito para evitar que isso aconteça no futuro? 

A comunidade de segurança, incluímos, deve aprender a encontrar esses erros humanos inevitáveis ​​mais cedo. Por favor, apoiem o esforço de desenvolvimento de software que você confia sua privacidade. Doar dinheiro para o projeto OpenSSL.

The Heartbleed Bug