Bem-vindo ao mundo depoiscoração sangrando. Corrigimos nossos servidores e estamos substituindo nossos certificados SSL. Mas só porque nossos servidores são consertados, isso não significa que o resto da Internet seja consertado. Temos funcionários e eles usam a Internet para trocar segredos como números de cartão de crédito e credenciais de login. Eles estão nos procurando em busca de conselhos.
Podemos aconselhar nossos clientes a usaruma página de teste Heartbleedpara ver se o site que eles desejam acessar tem a vulnerabilidade. Se um site retornar positivo, não troque segredos com ele. Mas se um sitenãoretornar positivo para Heartnet, então a situação pode ser qualquer uma das seguintes:
- O site nunca teve vulnerabilidade (bom)
- O site tinha a vulnerabilidade e a corrigiu, mas ainda está usando o certificado SSL possivelmente comprometido (ruim)
- O site tinha a vulnerabilidade e a corrigiu, e regenerou o certificado SSL, mas sem regenerar as chaves (ruim)
- O site teve a vulnerabilidade, corrigiu-a, regenerou as chaves e substituiu o certificado SSL. (bom)
Existe algum meio que possamos dar aos nossos funcionários, antes de digitarem o número do cartão de crédito no formulário, para informarem obomcenários doruimuns?
Como instruímos nossos funcionários a minimizar sua exposição a servidores comprometidos pelo Heartbleed?
Responder1
Essencialmente, não, não existe uma maneira única de diferenciar os cenários bons dos ruins, porque seus usuários não têm visibilidade total dos sistemas que estão usando.
A extensão dos danos causados pelo bug ainda é em grande parte desconhecida, a maior parte dos danos foi potencialmente causada no passado e continuará a impactar a Internet por um longo tempo. Simplesmente não sabemos quais segredos foram roubados, quando ou por quem.
Por exemplo: o coração do OpenSSL do Google sangra há cerca de um ano. Adversários desconhecidos vasculham os servidores e procuram segredos interessantes – novamente, não há como sabermos se eles fizeram isso ou não – até encontrarem uma conta pertencente a alguém com acesso autorizado a outro sistema, como Twitter.com ou AnyBank. co.uk ou dev.redhat.com. Com acesso a essas contas, eles poderiam continuar explorando, obtendo acesso a outros sistemas, causando outros danos (visíveis ou não), comprometendo ainda mais outras contas – sem que ninguém suspeitasse da origem da violação. Neste estágio, você já está longe dos sangrentos servidores OpenSSL, e esta é uma das consequências mais desagradáveis do Heartbleed. Somado a isso está o risco de as chaves privadas dos servidores serem comprometidas.
A confiança leva muito tempo para ser construída e pode ser rapidamente perdida. Não estou dizendo que não tivemos problemas de confiança na internet antes, mas o Heartbleed definitivamente não ajudou. Reparar os danos levará muito tempo, e entender isso faz parte da compreensão de como você pode proteger a si mesmo e a seus funcionários/clientes/chefes, etc. - e como não pode. Existem algumas coisas que você pode controlar, para limitar sua exposição à vulnerabilidade, e há coisas que você não pode controlar - mas elas ainda afetarão você. Por exemplo, você não pode controlar como todos os outros decidem responder a esta vulnerabilidade – a NSA supostamente descobriu o bug, mas manteve silêncio. Isso foi muito ruim para o resto de nós, mas não tínhamos como nos proteger contra isso.
Como usuário da Internet você pode e deve:
- Entenderquão ruimo bug é
- NÃO responda/seguir links em e-mails solicitando que você redefina sua senha - em vez disso, acesse diretamente o site da empresa/organização e redefina ativamente sua senha. Momentos como esses golpistas gostam de fazer phishing
- Verifique se há Heartbleed no seu telefone Android. Há umaaplicativodo Lookout Mobile Security que verifica sua versão do OpenSSL.
Verifique os sites que você visita para Heartbleed (lista de verificação incompleta):
O servidor está usando OpenSSL?
- Não: você não é diretamente afetado (por este bug). Continue usando o site, mas altere sua senha caso outro servidor afetado direta ou indiretamente pelo bug tenha acesso à sua senha. Isso pressupõe, é claro, que todos esses servidores nessa rede tenham sido corrigidos, emitidos novos certificados... etc.
- Sim: Vá para 2.
O servidor está em uma versão do OpenSSL sem Heartbleed? Certifique-se de que sua ferramenta check-for-heartbleed realmente verifique a vulnerabilidade e não o cabeçalho HTTP ou algum outro "indicador".
- Não: Não envie nenhum segredo para o site, mas se possível envie uma nota ao webmaster.
- Sim: Vá para 3.
Alguma versão anterior do OpenSSL tinha Heartbleed?
- Não: alguns administradores não atualizaram para a versão mais recente do OpenSSL porque ela não foi testada em campo por tempo suficiente. Seus servidores nunca foram vulneráveis a esse bug, mas pelos motivos apresentados acima, talvez seja melhor alterar sua senha.
- Sim: o servidor estava vulnerável e é possível que quaisquer dados na memória tenham sido comprometidos entre o momento da atualização para a versão vulnerável e o momento da divulgação (até dois ou até três anos).
Aqui voltamos à confiança: quando você perde a confiança de alguém, isso é uma coisa ruim. Principalmente se esse alguém for seu usuário/cliente/chefe. Para reconquistar a confiança deles, você precisa começar a construir novamente e abrir-se para o diálogo.
Aqui está o que um administrador da web pode publicar para começar:
- Versões anteriores do OpenSSL (vulneráveis/não vulneráveis)
- Versão atual e quando foi atualizada
E se a versão anterior do OpenSSL fosse vulnerável:
- Quando o certificado SSL atual foi gerado
- Descrição detalhada de como o certificado antigo foi revogado
- Garantia de que um novo segredo foi usado para o novo certificado
- Sugestões para usuários com base nas informações acima
Se você é usuário, tem todo o direito de solicitar esse tipo de informação, e deve fazê-lo, para o bem de todos os usuários do serviço. Isto aumentaria a visibilidade para a comunidade de segurança e tornaria mais fácil para os usuários minimizarem sua exposição a servidores comprometidos.