Como me recupero do bug do Heartbleed no OpenSSL?

CVE-2014-0160 aka Heartbleed é uma vulnerabilidade no OpenSSL. Parece assustador.

Como determino se sou afetado?

Se sou afetado, o que preciso fazer? Aparentemente, a atualização não é suficiente.

Essa vulnerabilidade tem um alto potencial de impacto, porque se o seu sistema tiver sido atacado, ele permanecerá vulnerável mesmo após o patch e os ataques podem não ter deixado rastros nos logs. Provavelmente, se você acertou rapidamente e não é um alvo de alto nível, ninguém terá conseguido atacá-lo, mas é difícil ter certeza.

Eu sou vulnerável?

A versão de buggy do OpenSSL

O software do buggy é a biblioteca OpenSSL 1.0.1 até 1.0.1f e OpenSSL 1.0.2 até beta1. As versões mais antigas (0.9.x, 1.0.0) e as versões em que o erro foi corrigido (1.0.1g em diante, 1.0.2 beta 2 em diante) não são afetadas. É um bug de implementação, não uma falha no protocolo, portanto, apenas os programas que usam a biblioteca OpenSSL são afetados.

Você pode usar a ferramenta de linha de comando openssl version -apara exibir o número da versão do OpenSSL. Observe que algumas distribuições portam a correção de bug para versões anteriores; se o log de alterações do seu pacote mencionar a correção de bug do Heartbleed, tudo bem, mesmo se você vir uma versão como 1.0.1f. Se openssl version -amencionar uma data de compilação (não a data na primeira linha) de 07/04/2014 em torno da UTC ou à noite, você deve estar bem. Observe que o pacote OpenSSL pode ter 1.0.0seu nome mesmo que a versão seja 1.0.1 ( 1.0.0refere-se à compatibilidade binária).

Aplicativos afetados

A exploração é realizada através de um aplicativo que utiliza a biblioteca OpenSSL para implementar conexões SSL . Muitos aplicativos usam o OpenSSL para outros serviços de criptografia, e isso é bom: o bug está na implementação de um recurso específico do protocolo SSL, o "batimento cardíaco".

Convém verificar quais programas estão vinculados à biblioteca do seu sistema. Em sistemas que usam dpkg e apt (Debian, Ubuntu, Mint,…), o comando a seguir lista os pacotes instalados, exceto as bibliotecas que usam libssl1.0.0(o pacote afetado):

apt-cache rdepends libssl1.0.0 | tail -n +3 |
xargs dpkg -l 2>/dev/null | grep '^ii' | grep -v '^ii  lib'

Se você executar algum software de servidor que esteja nesta lista e ouvir conexões SSL, você provavelmente é afetado. Isso diz respeito a servidores Web, servidores de email, servidores VPN etc. Você saberá que ativou o SSL porque precisou gerar um certificado, enviando uma solicitação de assinatura de certificado a uma autoridade de certificação ou fazendo sua própria autoassinatura. certificado. (É possível que algum procedimento de instalação tenha gerado um certificado autoassinado sem você perceber, mas isso geralmente é feito apenas para servidores internos, não para servidores expostos à Internet.) Se você executou um servidor vulnerável exposto à Internet, considere-o comprometido. a menos que seus logs não mostrem conexão desde o anúncio em 07/04/2014. (Isso pressupõe que a vulnerabilidade não foi explorada antes do anúncio.) Se o servidor foi exposto apenas internamente,

O software cliente é afetado apenas se você o usou para se conectar a um servidor mal-intencionado. Portanto, se você se conectou ao seu provedor de e-mail usando o IMAPS, não precisa se preocupar (a menos que o provedor tenha sido atacado - mas se for o caso, eles devem avisar você), mas se você navegou em sites aleatórios com um navegador vulnerável, pode ser necessário se preocupar. Até agora, parece que a vulnerabilidade não estava sendo explorada antes de ser descoberta; portanto, você só precisa se preocupar se estiver conectado a servidores maliciosos desde 08/04/2014.

Os programas a seguir não são afetados porque não usam o OpenSSL para implementar o SSL:

• SSH (o protocolo não é SSL)
• Chrome / Chromium ( usa NSS )
• Firefox (usa NSS) (pelo menos com o Firefox 27 no Ubuntu 12.04, mas não com todas as compilações?

Qual é o impacto?

O bug permite que qualquer cliente que possa se conectar ao seu servidor SSL recupere cerca de 64 kB de memória do servidor por vez. O cliente não precisa ser autenticado de forma alguma. Repetindo o ataque, o cliente pode despejar diferentes partes da memória em tentativas sucessivas. Isso potencialmente permite que o invasor recupere todos os dados que estiveram na memória do processo do servidor, incluindo chaves, senhas, cookies etc.

Uma das partes críticas de dados que o invasor pode recuperar é a chave privada SSL do servidor. Com esses dados, o invasor pode se passar por seu servidor.

O bug também permite que qualquer servidor ao qual seu cliente SSL conectado recupere cerca de 64 kB de memória do cliente por vez. Isso é preocupante se você usou um cliente vulnerável para manipular dados confidenciais e depois se conectou a um servidor não confiável com o mesmo cliente. Os cenários de ataque neste lado são, portanto, significativamente menos prováveis ​​do que no lado do servidor.

Observe que, para distribuições típicas, não há impacto na segurança da distribuição de pacotes, pois a integridade dos pacotes depende de assinaturas GPG, não de transporte SSL.

Como faço para corrigir a vulnerabilidade?

Correção de servidores expostos

1. Coloque todos os servidores afetados offline. Enquanto estiverem em execução, eles estão potencialmente vazando dados críticos.

2. Atualize o pacote da biblioteca OpenSSL . Todas as distribuições devem ter uma correção até agora (com 1.0.1g ou com um patch que corrige o bug sem alterar o número da versão). Se você compilou da fonte, atualize para 1.0.1g ou superior. Verifique se todos os servidores afetados foram reiniciados.
   No Linux, você pode verificar se processos potencialmente afetados ainda estão em execução comgrep 'libssl.*(deleted)' /proc/*/maps

3. Gere novas chaves . Isso é necessário porque o bug pode ter permitido que um invasor obtenha a chave privada antiga. Siga o mesmo procedimento que você usou inicialmente.

   • Se você usar certificados assinados por uma autoridade de certificação, envie suas novas chaves públicas à sua CA. Quando você receber o novo certificado, instale-o no seu servidor.
   • Se você usa certificados autoassinados, instale-o no seu servidor.
   • De qualquer maneira, mova as chaves e os certificados antigos para fora do caminho (mas não os exclua, apenas verifique se eles não estão mais sendo usados).

4. Agora que você possui novas chaves descomprometidas, pode colocar seu servidor novamente online .

5. Revogue os certificados antigos.

6. Avaliação de danos : todos os dados que estiveram na memória de um processo que atende às conexões SSL podem ter vazado. Isso pode incluir senhas de usuários e outros dados confidenciais. Você precisa avaliar quais podem ser esses dados.

   • Se você estiver executando um serviço que permita autenticação por senha, as senhas dos usuários que se conectaram desde pouco antes da divulgação da vulnerabilidade devem ser consideradas comprometidas. Verifique seus logs e altere as senhas de qualquer usuário afetado.
   • Também invalide todos os cookies de sessão, pois eles podem ter sido comprometidos.
   • Os certificados de cliente não são comprometidos.
   • Quaisquer dados trocados desde pouco antes da vulnerabilidade podem ter permanecido na memória do servidor e, portanto, podem ter sido vazados para um invasor.
   • Se alguém gravou uma conexão SSL antiga e recuperou as chaves do servidor, agora pode descriptografar a transcrição. (A menos que o PFS tenha sido garantido - se você não sabe, não foi.)

Remediação em outros casos

Os servidores que apenas escutam no host local ou na intranet devem ser considerados expostos apenas se usuários não confiáveis ​​puderem se conectar a eles.

Com os clientes, existem apenas cenários raros nos quais o bug pode ter sido explorado: uma exploração exigiria que você usasse o mesmo processo do cliente para

1. manipular dados confidenciais (por exemplo, senhas, certificados de clientes, ...);
2. e, no mesmo processo, conectado a um servidor malicioso por SSL.

Por exemplo, um cliente de email que você usa apenas para se conectar ao seu provedor de email (não totalmente não confiável) não é uma preocupação (não é um servidor mal-intencionado). A execução do wget para baixar um arquivo não é uma preocupação (não há dados confidenciais a serem vazados).

Se você fez isso entre 07/04/2014 à noite UTC e atualizou sua biblioteca OpenSSL, considere comprometidos os dados que estavam na memória do cliente.

Referências

• O Bug Heartbleed (por uma das duas equipes que descobriram o bug independentemente)
• Como exatamente a pulsação do OpenSSL TLS (Heartbleed) explora funciona?
• Heartbleed significa novos certificados para todos os servidores SSL?
• Heartbleed: O que é e quais são as opções para mitigá-lo?

Para testar se você é vulnerável, acesse aqui: http://filippo.io/Heartbleed/

Se você achar que está vulnerável, atualize openssle reinicie o servidor da web.

Não há como se recuperar desse bug. Salve todos os logs, eles serão necessários no caso de alguém realmente perceber que a vulnerabilidade realmente existia antes de ser anunciada