Substituição de Chaves

No Alerta de Segurança Debian 1571, o Time de Segurança do Debian revelou uma falha no gerador de números aleatórios usado pelo OpenSSL no Debian e seus derivados. Como resultado desta falha, certas chaves criptográficas são muito mais comuns do que elas deveriam ser, de tal forma que um atacante poderia adivinhar a chave através de um ataque de força bruta com conhecimento mínimo do sistema. Isto afeta particularmente o uso de chaves criptográfica no OpenSSH, OpenVPN e certificados SSL.

Esta página documento como realizar os procedimentos de substituição de chaves para pacotes cujas chaves foram afetadas pela vulnerabilidade do OpenSSL.

Outros softwares usam chaves criptográficas, mas não são vulneráveis pois o OpenSSL não é usado para gerar ou trocar suas chaves.

Para instruções de substituição de chaves para outros softwares, você pode estar interessado em checar as informações enviadas por usuários em https://wiki.debian.org/SSLkeys (em inglês).

OpenSSH

Um pacote atualizado já foi lançado via DSA-1576, que facilita a transformação de chaves.

1. Instale as atualizações de segurança no DSA-1576

Uma vez que a atualização esteja aplicada, chaves fracas de usuários serão automaticamente rejeitadas quando possível (embora elas não possam ser detectadas em todos os casos). Se você está usando tais chaves para autenticação de usuário, elas deixarão de funcionar imediatamente e terão que ser substituídas (veja o passo 3).

Chaves de host do OpenSSH podem ser automaticamente regeradas quando a atualização de segurança do OpenSSH é aplicada. A atualização pedirá uma confirmação antes de aceitar este passo.

2. Atualize arquivos known_hosts do OpenSSH

A re-geração das chaves de host fará com que um aviso seja exibido quando conectar-se ao sistema usando SSH até que a chave do host seja atualizada no arquivo known_hosts do cliente. O aviso será parecido com este:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.

Neste caso, a chave de host simplesmente foi trocada, e você deverá atualizar o arquivo known_hosts relevante conforme indicado na mensagem de aviso. É recomendado que você use um canal confiável para trocar a chave do servidor. Ela encontra-se no arquivo /etc/ssh/ssh_host_rsa_key.pub no servidor; sua impressão digital (fingerprint) pode ser impresso usando o comando:

ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub

Em adição aos arquivos known_hosts específicos dos usuários, pode existir um arquivo de sistemas /etc/ssh/ssh_known_hosts. Este arquivo é usado tanto pelo cliente ssh quanto pelo sshd para a funcionalidade de hosts.equiv. Este arquivo também precisa ser atualizado.

3. Verifique todas as chaves OpenSSH de usuário

A rota de ação mais segura é re-gerar todas as chaves OpenSSH de usuário, exceto onde é possível estabelecer com elevado grau de certeza que a chave foi gerada em um sistema não afetado.

Verifique se sua chave é afetada executando a ferramenta ssh-vulnkey, incluída na atualização de segurança. Por padrão, o ssh-vulnkey checará o local padrão para chaves de usuário (~/.ssh/id_rsa, ~/.ssh/id_dsa e ~/.ssh/identity), seu arquivo authorized_keys (~/.ssh/authorized_keys e ~/.ssh/authorized_keys2) e as chaves de host do sistema (/etc/ssh/ssh_host_dsa_key e /etc/ssh/ssh_host_rsa_key).

Para verificar todas as suas chaves, assumindo que elas estão no local padrão (~/.ssh/id_rsa, ~/.ssh/id_dsa, ou ~/.ssh/identity):

ssh-vulnkey

Para verificar todas as chaves no seu sistema:

sudo ssh-vulnkey -a

Para verificar uma chave em um local não-padrão:

ssh-vulnkey /caminho/para/a/chave

Se o ssh-vulnkey disse Unknown (no blacklist information) (Desconhecida (sem informação de lista negra)), então não há informação se a chave é afetada. Em caso de dúvida, destrua a chave e gere uma nova.

4. Regerar quaisquer chaves de usuário afetadas

Chaves OpenSSH usadas para autenticação de usuário devem ser manualmente regeradas, incluindo aquelas que podem ter sido transferidas para um sistema diferente após terem sido geradas.

Novas chaves podem ser geradas usando ssh-keygen, e.g.:

   $ ssh-keygen
   Generating public/private rsa key pair.
   Enter file in which to save the key (/home/user/.ssh/id_rsa):
   Enter passphrase (empty for no passphrase):
   Enter same passphrase again:
   Your identification has been saved in /home/user/.ssh/id_rsa.
   Your public key has been saved in /home/user/.ssh/id_rsa.pub.
   The key fingerprint is:
   00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 user@host

5. Atualize arquivos authorized_keys (se necessário)

Uma vez que as chaves de usuário tenham sido regeradas, as chaves públicas relevantes devem ser propagadas para os arquivos authorized_keys (e arquivos authorized_keys, se aplicável) em sistemas remotos. Tenha certeza que excluiu a chave afetada.

OpenSSL: instruções para geração de chave PEM genérica

Isto é apenas um lembre para aqueles (re-)geraram certificados codificados PEM. Seu site provavelmente possui outras políticas implementadas que você deveria seguir sobre como gerenciar chaves. Adicionalmente, você pode precisar obter certificados assinados novamente por uma Autoridade Certificadora externa ao invés de usar um certificado auto-assinado como exibido abaixo: 

cd /etc/ssl/private
openssl genrsa 1024 > meusite.pem
cd /etc/ssl/certs
openssl req -new -key ../private/meusite.pem -x509 -days 9999 -out meusite.pem

bincimap

O pacote bincimap cria automaticamente um certificado auto-assinado através do programa openssl para o serviço bincimap-ssl, e coloca-o em /etc/ssl/certs/imapd.pem. Para regerá-lo, execute: 

rm -f /etc/ssl/certs/imapd.pem
dpkg-reconfigure bincimap

boxbackup

Boxbackup não está presente no Debian estável (stable), somente no testing/Lenny.

O autor original publicou uma análise de impacto inicial das chaves criadas em sistemas com aleatoriedade insuficiente no PRNG. Você pode ler os detalhes aqui.

Se o PRNG em seu OpenSSL foi insuficientemente aleatório, você precisa:

cryptsetup

O cryptsetup não usa openssl para criptografia (isto aplica-se para dispositivos LUKS e dm-crypt).

Se o cryptsetup foi configurado para usar arquivos-chave criptografados com SSL (uma configuração não-padrão que deve ser explicitamente definida pelo usuário) e uma versão quebrada do openssl foi usada para gerar o arquivo-chave, a criptografia do arquivo-chave por ser mais fraca do que o esperado (pois o salto não é verdadeiramente aleatório).

A solução é re-criptografar o arquivo-chave (se você está razoavelmente certo de que o arquivo criptografado não foi revelado para terceiros) ou limpar e reinstalar a(s) partição(ões) afetadas usando uma nova chave.

Instruções para re-criptografar um arquivo-chave:

Faça os passos a seguir para cada arquivo-chave criptografado com SSL, substituindo <caminho_chave_criptografada_ssl> com o caminho para o arquivo real: 

tmpkey=$(tempfile)
openssl enc -aes-256-cbc -d -salt -in <caminho_chave_criptografada_ssl> -out "$tmpkey"
shred -uz <caminho_chave_criptografada_ssl>
openssl enc -aes-256-cbc -e -salt -in "$tmpkey" -out <caminho_chave_criptografada_ssl>
shred -uz "$tmpkey"

dropbear

Se você tem chaves /etc/ssh/*host*, remova-as ou siga as instruções para openssh primeiro, antes de atualizar as chaves do dropbear.

O postinst do dropbear converte as chaves openssh existentes para o formato dropbear, se ele não pode localizar as chaves de host dropbear. 

rm /etc/dropbear/*_host_key
dpkg-reconfigure dropbear

Note que chaves que foram geradas pelo próprio Dropbear não são vulneráveis (ele usa a libtomcrypt ao invés do OpenSSL).

ekg

Usuários dos programas ekg ou ekg2 (o último só está na experimental) que usam a funcionalidade de criptografia SIM, que geraram um par de chaves usando o comando /key [-g|--generate] (que usa a libssl para fazer o trabalho) deverão regerar suas chaves após atualizar a libssl e reiniciar o programa.

Os desenvolvedores originais enviaram uma notícia em seu site web: http://ekg.chmurka.net/index.php

Se você precisar de mais ajuda, por favor, pergunte nas listas ekg-users@lists.ziew.org ou ekg2-users@lists.ziew.org (em inglês e polonês).

ftpd-ssl

rm -f /etc/ftpd-ssl/ftpd.pem /etc/ssl/certs/ftpd.pem
dpkg-reconfigure ftpd-ssl

Isto cobre a configuração padrão. Se o administrador local fez alguma configuração de infra-estrutura SSL além disso, estas chaves também terão que ser regeradas.

gforge

O pacote gforge-web-apache2 no sid e lenny configura um site web com um certificado fictício (dummy) se nenhum certificado existente é localizado. Usuários são encorajados a substituí-lo com um certificado real. O certificado fictício (dummy) em questão é o Snake Oil, portanto já deveria ser considerado como fraco (mesmo sem o bug SSL), mas alguns usuários podem aceitá-lo sem pensar duas vezes.

MIT Kerberos (krb5)

Nenhuma parte do MIT Kerberos no Debian 4.0 (Etch) usa OpenSSL, e portanto o Kerberos no Debian 4.0 não é afetado.

No Lenny, o pacote binário separado krb5-pkinit usa OpenSSL. O próprio MIT Kerberos não gera pares de chaves de longo prazo até mesmo quando a extensão PKINIT é usada, portanto quaisquer pares de chaves de longo prazo vulneráveis teriam sido geradas fora do MIT Kerberos propriamente dito. A extensão PKINIT somente referencia pares de chaves existentes e não é responsável pelo gerenciamento de chaves.

Pares de chaves de longo prazo usados pelo PKINIT podem ser afetadas se geradas em um sistema Debian afetado, mas tal geração é externa ao MIT Kerberos.

No entanto, as funções de chave aleatória do OpenSSL são usadas para a troca DH quando a autenticação PKINIT é usada, o que significa que um atacante pode ser capaz de usar força bruta para ganhar acesso à resposta do KDC para uma autenticação PKINIT e subsequentemente ganhar acesso para quaisquer sessões criadas usando tickets de serviço daquela autenticação.

Quaisquer KDCs usando a extensão PKINIT do Lenny deverão atualizar seus pacotes libssl0.9.8 imediatamente e reiniciar o Kerberos KDC com: 

/etc/init.d/krb5-kdc restart

Quaisquer tickets ticket-granting (TGTs) do Kerberos ou sessões criptografadas resultantes de uma autenticação PKINIT usando um Kerberos KDC com a libssl afetada deveria ser tratados como suspeitos; é possível que atacantes com capturas de pacotes sejam capazes de comprometes essas chaves e sessões.

Nessus

O script de pós-instalação do pacote do servidor Nessus (nessusd) cria algumas chaves SSL para comunicação segura entre um servidor Nessus e o cliente. Esse canal de comunicação deveria ser considerado comprometido uma vez que um usuário mal intencionado poderia ser capaz de interceptar a informação trocada entre o servidor e o cliente (o que inclui informação sobre vulnerabilidades em hosts remotos) e potencialmente enviar comandos para os servidores como o usuário que está autenticado.

Adicionalmente, se o administrador criou a chave CA do Nessus ou um certificado de usuário (com o nessus-mkcert-client) para autenticação remota em um servidor que tinha instalada a versão do OpenSSL afetada por este problema de segurança, essas chaves deverão ser consideradas comprometidas. Note que os usuários remotos com acesso ao servidor Nessus podem disparar ataques a servidores que eles têm permissão para atacar e, se habilitado na configuração local (no Debian o padrão é não) enviar extensões que poderiam ser executadas no servidor Nessus com privilégios de root.

Os scripts de configuração do mantenedor regerarão os certificados OpenSSL quando configurados se ele não puder achá-los. Você terá que remover os certificados e gerar novos usando:

rm -f /var/lib/nessus/CA/cacert.pem
rm -f /var/lib/nessus/CA/servercert.pem
rm -f /var/lib/nessus/private/CA/cakey.pem
rm -f /var/lib/nessus/private/CA/serverkey.pem
dpkg-reconfigure nessusd

Quando isto estiver concluído, você terá que remover as antigas chaves de usuário em /var/lib/nessus/users/NOME_DE_USUÁRIO/auth e regerá-las novamente com nessus-mkcert-client. Antigas chaves serão invalidadas uma vez que a chave CA tenha sido removida.

Após a chave CA ter sido regerada, você também precisará distribuir o novo certificado CA para os seus usuários, e seus usuários terão que aceitar o novo certificado do servidor Nessus quando eles reconectarem. As configurações do certificado para o antigo servidor deveriam ser removidas automaticamente mas você também pode removê-las manualmente editando o arquivo .nessusrc.cert (se estiver usando o cliente Nessus) ou o arquivo .openvasrc.cert (se estiver usando o cliente OpenVAS).

OpenSWAN / StrongSWAN

rm /etc/ipsec.d/private/`hostname`Key.pem /etc/ipsec.d/certs/`hostname`Cert.pem
dpkg-reconfigure (open|strong)swan
/etc/init.d/ipsec restart

Cuidado: Reiniciar os serviços ipsec encerra todas as conexões IPSec atualmente abertas, que podem ter que ser reiniciados na outra ponta.

OpenVPN

Faça um backup dos seus arquivos de chaves secretas. Embora os nomes de chaves sejam arbitrários, eles podem ser detectados executando 

grep secret /etc/openvpn/*.conf

Recrie-os usando 

openvpn --genkey --secret NOME_DO_ARQUIVO_SECRETO

Então, copie as chaves secretas compartilhadas para os hosts remotos e reinicie a VPN em cada host com 

/etc/init.d/openvpn force-reload

Proftpd

O empacotamento Debian não inclui geração de chaves, portanto os passos a seguir só serão necessários se chaves SSL foram criadas externamente.

O futuro pacote proftpd a ser enviado para a instável (unstable) inclui um modelo tls.conf com o comentário abaixo (em inglês).

Note que a geração de certificados auto-assinados é um pouco diferente da sugerida na seção genérica de openssl, para evitar o uso de uma senha quando o daemon está iniciando.

Você pode (re)gerar um certificado auto-assinado usando um comando como: 

 openssl req -x509 -newkey rsa:1024 -keyout /etc/ssl/private/proftpd.key -out /etc/ssl/certs/proftpd.crt -nodes -days 365

Ambos os arquivos devem ter permissão de leitura somente par ao root. os caminhos dos arquivos podem ser checados/configurados através das seguintes diretivas de configuração: 

TLSRSACertificateFile                   /etc/ssl/certs/proftpd.crt
TLSRSACertificateKeyFile                /etc/ssl/private/proftpd.key
TLSCACertificateFile                    /etc/ssl/certs/CA.pem
TLSOptions                              NoCertRequest

puppet

Há dois métodos de manipular certificados puppet, um é via capistrano, o segundo é manualmente.

O processo de regerar certificados SSL do Puppet usando capistrano está detalhado aqui: http://reductivelabs.com/trac/puppet/wiki/RegenerateSSL (em inglês)

Os passos manuais são os seguintes:

  1. Você precisa limpar e regerar suas informações de CA: 
    /etc/init.d/puppetmaster stop
rm -rf $vardir/ssl/*
/etc/init.d/puppetmaster start

    No entanto, se você estiver executando o mongrel, ao invés de iniciar o puppetmaster a partir do script de inicialização, você precisará primeiro parar a interface web ouvinte (apache, nginx, etc.) e então fazer o seguinte: 

    puppetmasterd --daemonize ; sleep 30 ; pkill -f 'ruby /usr/sbin/puppetmasterd'

    A comando acima é necessário porque por alguma razão quando executando com o mongrel, o puppetmaster não regerará sua CA.

  2. Limpe todos os certificados clientes 
    /etc/init.d/puppet stop
rm $vardir/ssl/*
  3. Faça com que cada cliente requisite um novo certificado: 
    puppetd --onetime --debug --ignorecache --no-daemonize
  4. Uma vez que todas as requisições tenham chego, você pode assiná-las de uma vez só: 
    puppetca --sign --all
  5. Inicie seus clientes puppet: 
    /etc/init.d/puppet start

Você também pode habilitar auto-assinar temporariamente, se você sente-se confortável com isso.

sendmail

O sendmail (tanto no Etch quanto no Lenny) opcionalmente criam certificados OpenSSL padrões no momento da instalação.

O procedimento de substituição de chaves é trivial: 

/usr/share/sendmail/update_tls new

Se você personalizou os modelos em /etc/mail/tls, esses valores serão reusados para criar os novos certificados.

ssl-cert

O certificado snakeoil /etc/ssl/certs/ssl-cert-snakeoil.pem pode ser recriado com: 

make-ssl-cert generate-default-snakeoil --force-overwrite

telnetd-ssl

rm -f /etc/telnetd-ssl/telnetd.pem /etc/ssl/certs/telnetd.pem
dpkg-reconfigure telnetd-ssl

Isto cobre a configuração padrão. Se o administrador local fez alguma configuração de infra-estrutura SSL além disso, estas chaves também terão que ser regeradas.

tinc

Remova todas os arquivos de chaves públicas e privadas que são suspeitos:

  1. Remova rsa_key.priv.
  2. Edite todos os arquivos no diretório hosts/ e remova os blocos de chaves públicas.

Gere um novo par de chaves pública/privada: 

tincd -n <netname> -K

Troque seu arquivo de configuração de host com a nova chave pública com outros(as) membros(as) da sua VPN. Não esqueça de reiniciar seus daemons tinc.

tor

Tor não está na estável (stable), mas é afetado no Lenny.

Clientes executando a versão 0.1.2.x não são afetados. Os nós Tor ou provedores de serviço ocultos executando qualquer versão, assim como qualquer um na versão 0.2.0.x são afetados.

Por favor, veja o anúncio de vulnerabilidade na lista de anúncios do Tor.

Atualizar para 0.1.2.19-3 (disponível no testing, instável - unstable, backports.org e no costumeiro repositório noreply.org) ou 0.2.0.26-rc-1 (disponível na experimental e no costumeiro repositório noreply.org) é recomendado. Se você possui umrelay estas versões forçarão a geração de novas chaves de servidor (/var/lib/tor/keys/secret_*).

Se você executa um nó Tor sem usar a infra-estrutura do pacote (usuário debian-tor, /var/lib/tor como DataDirectory etc.) você precisará remover manualmente as chaves ruins. Veja o link para o alerta postado acima.

Se você é um provedor de serviço oculto e criou sua chave no período de tempo afetado com uma libssl ruim então por favor, exclua sua chave privada privada do serviço oculto. Isto mudará seu nome de host do serviço oculto e pode requerer uma reconfiguração dos seus servidores.

Se você está executando a versão 0.2.0.x, uma atualização é altamente recomendada — 3 dos 6 servidores de autoridade v3 tinham chaves comprometidas. Antigas versões 0.2.0.x deixarão de funcionar em uma ou duas semanas.

xrdp

O xrdp usa chaves geradas. A maioria dos clientes não checa essas chaves por padrão, portanto, mudá-las é indolor. Você só tem que fazer: 

rm /etc/xrdp/rsakeys.ini
/etc/init.d/xrdp restart

O xrdp não está na estável (stable).