Heartbleed – O que realmente acontece?

Postado em: 11 de abril de 2014 - Por: Thiago Palmeira

Esta semana, o mundo virtual entrou na “Porta dos Desesperados” (bons tempos!) em função da vulnerabilidade do OpenSSL nomeada de Heartbleed. Agora você vai entender do que, realmente, ela se trata e porque ela ganhou este nome.

A vulnerabilidade está ligada à funcionalidade conhecida como TLS Heartbeat Extension da versão 1.0.1 do OpenSSL. TLS Heartbeats são utilizados como pacotes “keep alive” que servem para que os pontos de uma conexão criptografada possam manter a sessão aberta mesmo quando não estão trocando nenhum tipo de informação propriamente dita. Um heartbeat consiste em uma mensagem e uma réplica, de forma que qualquer um dos pontos podem confirmar tanto se a sessão está aberta quanto se a conexão fim-a-fim está funcionando corretamente.

Como o bug heartbleed ocorre?

Tirinha explica com humor como acontece o bug Heartbleed

“How the Heartbleed bug works”, tirinha original do site XKCD

Paul Ducklin, do blog Naked Security, em Anatomy of a data leakage bug, descreve toda a anatomia da vulnerabilidade, qual vamos tentar resumir aqui:

A RFC 6520 determina que o tamanho máximo de um heartbeat request é 214 (16384 bytes), mas, em condições normais, o OpenSSL gera requisições muito menores.
Um heartbeat request consiste em:

  • Message Type, 1 byte – 0x01, que aponta a mensagem como sendo um TLS1_HB_REQUEST.

  • Payload Length, 2 bytes – Representação, em hexadecimal, do tamanho do payload + o padding.

  • Payload, 2 bytes – sequência de 16-bit, o payload propriamente dito.

  • Payload, 16 bytes – Dados aleatórios de forma a complementar o tamanho do payload (18-byte).

  • Padding, 16 bytes – Dados aleatórios complementares, requeridos pelo padrão.

É esperado que respostas a um heartbeat request contenham uma cópia do payload da requisição como uma forma de verificar que o canal criptografado ainda está funcionando nos dois sentidos.

Acontece que, quando versões vulneráveis do OpenSSL (1.0.1 a 1.0.1f) respondem a um heartbeat request, elas não tomam muito cuidado em analisar o os dados recebidos. Desta forma, você pode enviar um heartbeat request pequeno e, sorrateiramente, informar que enviou uma mensagem muito maior simplesmente configurando o campo Payload Length para 0xFFFF (65535 bytes – o maior número que se pode representar em 16-bit). Com isso, o OpenSSL irá, sem pestanejar, copiar 65535 bytes a partir de sua requisição, mesmo que você não tenha enviado todos esses bytes. Isso significa que o servidor irá te enviar o dado original da requisição seguido de qualquer informação que calhou de estar na RAM, em sequência. Divertido, não?

Este “vazamento”, ou “sangramento” de informação (do inglês, “leak” ou “bleed”) através do Heartbeat (do inglês, “batimento cardíaco” analogia ao fato de verificar se alguém está vivo) deu o nome Heartbleed à vulnerabilidade.

Obviamente, a maior parte dos dados recebidos são inúteis. Porém, ao sangrar (heartbleed) continuamente um servidor e monitorar uma infinidade de blocos de 64KB de dados, uma hora ou outra você pode acabar esbarrando em dados um bocado interessantes como conteúdos de mensagens, credenciais de acesso, chaves de sessão ou até mesmo as chaves privadas do servidor.

O que fazer?

Felizmente, já existe um patch para a vulnerabilidade e os servidores apenas precisam se atualizar para a versão OpenSSL 1.0.1g. Caso isso não seja possível ou viável em alguns casos, outra solução é recompilar sua versão do OpenSSL sem o suporte a TLS Heartbeat.

E quanto a trocar minhas senhas?

É fato que muitos estão gritando: “Alterem suas senhas, agora ou chorem!” e isso, a princípio, soa um pouco exagerado. Na verdade é e não é, ao mesmo tempo.

Embora suas senhas não tenham, necessariamente, vazado através desta vulnerabilidade, é provável que tenham.

Desta forma, caso você seja aquele tipo de pessoa que nasceu virada para a Lua e vivia ganhando Frutare no palito ou que costuma vir com a mão recheada de trunfo, talvez, você consiga dormir tranquilo. Caso contrário, pode se preparar para alterar algumas senhas!

Porém, não corra com isso desesperadamente, alterando todas as senhas em todos os sites como se sua vida dependesse disso!

Antes, é importante verificar se o provedor daquele determinado site ou serviço já se atualizou contra a vulnerabilidade ou você apenas deixará sua nova senha elegível ao um vazamento.

Nosso post anterior citou uma lista, da Mashable, publicando uma lista de sites populares afetados pela vulnerabilidade contendo a resposta dos responsáveis sobre as ações tomadas.

Agora cuidado com o phishing

Nesse alvoroço, uma coisa para se ter cuidado é com ataques de phishing.

Muitos “espertinhos” aproveitam esses tempos de desespero e se preparam para pescar.

Então esteja atento a emails camaradas informando que você precisa alterar suas senhas com urgência e lhe fornecendo um link para que você acesse e, rapidamente, proteja-se alterando suas credenciais. Nessa brincadeira, você sofre um ataque de phishing, acessando um link falso e fornecendo suas credenciais aos danadinhos. Você não quer isso.

Sendo assim, caso você receba um email lhe pedindo para alterar sua senha e este email contenha um link para isso, desconfie!

Vá no site do serviço, realize o procedimento por lá e não seja pescado!

Então, você está desesperado?

Caso positivo, abra as portas abaixo:

  1. Grite;

  2. Nade no chão;

  3. Verifique se o site já tratou da vulnerabilidade;

  4. Não clique em links de emails camaradas convidando você a trocar suas senhas;

  5. E, por fim, troque suas senhas!

Leia também