O bug é conhecido como Heartbleed .
Estou vulnerável?
Geralmente, você é afetado se você executar algum servidor que você gerou uma chave SSL em algum momento. A maioria dos usuários finais não é (diretamente) afetada; Pelo menos o Firefox e o Chrome não usam o OpenSSL. O SSH não é afetado. A distribuição dos pacotes do Ubuntu não é afetada (depende de assinaturas GPG).
Você está vulnerável se você executar qualquer tipo de servidor que use as versões 1.0–1.0.1f do OpenSSL (exceto as versões do curso que foram corrigidas desde que o bug foi descoberto). As versões afetadas do Ubuntu são 11,10 oníricos até 14,04 pré-lançamentos confiáveis. É um erro de implementação, não uma falha no protocolo, portanto somente os programas que usam a biblioteca OpenSSL são afetados. Se você tiver um programa vinculado à versão 0.9.x antiga do OpenSSL, isso não será afetado. Apenas programas que usam a biblioteca OpenSSL para implementar o protocolo SSL são afetados; programas que usam o OpenSSL para outras coisas não são afetados.
Se você executou um servidor vulnerável exposto à Internet, considere comprometido, a menos que seus registros não mostrem conexão desde o anúncio de 2014-04-07. (Isso pressupõe que a vulnerabilidade não foi explorada antes de seu anúncio.) Se o seu servidor foi exposto apenas internamente, se você precisa alterar as chaves, isso dependerá de outras medidas de segurança implementadas.
Qual é o impacto?
O bug permite qualquer cliente que pode se conectar ao seu servidor SSL para recuperar cerca de 64kB de memória do servidor. O cliente não precisa ser autenticado de forma alguma. Ao repetir o ataque, o cliente pode despejar partes diferentes da memória em tentativas sucessivas.
Um dos dados críticos que o invasor pode recuperar é a chave privada SSL do servidor. Com esses dados, o invasor pode representar seu servidor.
Como eu me recupero em um servidor?
-
Coloque todos os servidores afetados offline. Enquanto estiverem em execução, eles estão potencialmente vazando dados críticos.
-
Atualize o libssl1.0.0 package e verifique se todos os servidores afetados foram reiniciados.
Você pode verificar se os processos afetados ainda estão sendo executados com o '' grep 'libssl. (excluído)' / proc / / maps '
-
Gere novas chaves . Isso é necessário porque o bug pode ter permitido que um invasor obtivesse 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 para sua CA. Quando você obtiver o novo certificado, instale-o no seu servidor.
- Se você usar certificados autoassinados, instale-o em seu servidor.
- De qualquer forma, mova as chaves e os certificados antigos para fora do caminho (mas não os exclua, apenas certifique-se de que eles não estão mais sendo usados).
-
Agora que você tem novas chaves não comprometidas, é possível colocar seu servidor de volta online .
-
Revoga os certificados antigos.
-
Avaliação de danos : qualquer dado que esteja na memória de um processo que atende conexões SSL pode ter vazado. Isso pode incluir senhas de usuários e outros dados confidenciais. Você precisa avaliar o que esses dados podem ter sido.
- Se você estiver executando um serviço que permita a autenticação de senha, as senhas dos usuários que se conectaram desde um pouco antes de a vulnerabilidade ser anunciada devem ser consideradas comprometidas. (Um pouco antes, porque a senha pode ter permanecido sem uso na memória por um tempo.) Verifique seus logs e altere as senhas de qualquer usuário afetado.
- Invalide também todos os cookies da sessão, pois eles podem ter sido comprometidos.
- Certificados de clientes não são comprometidos.
- Todos os dados que foram trocados desde um pouco antes da vulnerabilidade podem ter permanecido na memória do servidor e, portanto, podem ter vazado para um invasor.
- Se alguém registrou uma conexão SSL antiga e recuperou as chaves do seu servidor, ele pode agora descriptografar a transcrição. (A menos que PFS fosse assegurado - se você não sabe, não foi.)
Como eu me recupero em um cliente?
Existem apenas algumas situações em que os aplicativos clientes são afetados. O problema no lado do servidor é que qualquer um pode se conectar a um servidor e explorar o bug. Para explorar um cliente, três condições devem ser atendidas:
- O programa cliente usou uma versão com bugs da biblioteca OpenSSL para implementar o protocolo SSL.
- O cliente está conectado a um servidor mal-intencionado. (Então, por exemplo, se você se conectou a um provedor de e-mail, isso não é uma preocupação.) Isso teve que acontecer depois que o proprietário do servidor tomou conhecimento da vulnerabilidade, então presumivelmente após 2014-04-07.
- O processo do cliente tinha dados confidenciais na memória que não foram compartilhados com o servidor. (Então, se você acabou de executar
wget para baixar um arquivo, não há dados para vazar.)
Se você fez isso entre 2014-04-07 à noite UTC e atualizou sua biblioteca OpenSSL, considere todos os dados que estavam na memória do processo do cliente a serem comprometidos.
Referências