Heartbleed: como o bug em um protocolo de segurança afeta você e seus dados


9/4/14 às 20h36

Falhas de segurança em sistemas computacionais são, infelizmente, comuns. Mesmo com todo o aparato técnico e organizacional de que dispomos para programar sistemas, o elo fraco (nós, humanos) ainda existe e por isso, como em tudo que tocamos, a programação também é suscetível a falhas.

Normalmente correções de bugs se limitam a ganhar uma linha no changelog de uma aplicação. São quase sempre ignoradas; se muito, xingadas por nos obrigar a instalar uma nova atualização — mais ainda quando é preciso reiniciar o sistema inteiro, né Windows? Só que, às vezes, uma falha é tão grave, tão impactante, que quebra algumas barreiras e chega até aos ouvidos de quem não se liga muito em tecnologia. Foi assim com o bug do milênio e parece que é o caso do Heartbleed, uma grave falha no OpenSSL divulgada essa semana por pesquisadores da Codenomicon e do Google.

O que é essa falha? Como ela te afeta? Por que está todo mundo tão preocupado com ela? Após ler um punhado de artigos sobre o assunto, este vai ao ar com a missão de responder essas perguntas da forma mais didática e completa possível.

O básico de criptografia, SSL e OpenSSL

Você já deve ter ouvido algum especialista em segurança dizendo para prestar atenção na barra de endereços do navegador quando estiver fazendo alguma transação via Internet. Nesses casos, ela deve apresentar um cadeado e ter um “https” no início do endereço, como nesta imagem:

Cadeado e https no acesso ao Gmail.
Este site é seguro!

Esses dois detalhes indicam sessões seguras, protegidas pelo protocolo SSL (Secure Socket Layer) ou TLS (Transport Layer Security). Esses dois criptografam a troca de dados entre cliente (você) e servidor (site, servidor de e-mail, bate-papo, VPN), o que impede que um terceiro leia o conteúdo que transita entre essas duas pontas. Ainda que ele consiga acesso aos dados, tudo o que esse cara terá nas mãos será um punhado de caracteres que não fazem sentido algum. Isso é, resumidamente, criptografia: sem as chaves que descriptografam o conteúdo, é impossível lê-lo.

SSL e TSL são usados desde a década de 1990 e padrões para aplicações sensíveis na Internet. Por “aplicações sensíveis”, leia-se qualquer informação que na posse de alguém mal intencionado consiga causar danos. Informações como senhas e números de cartão de crédito, por exemplo, e coisas mais triviais, como alguns sistemas de bate-papo baseados no protocolo XMPP e e-mails (protocolos SMTP, POP e IMAP).

Existem várias bibliotecas SSL/TLS usadas em servidores, todas com a mesma finalidade. O OpenSSL é uma das mais populares por ser aberto e gratuito — é aqui, aliás, nos bastidores da Internet que o software livre é largamente usado. Servidores populares, como Apache e nginx, que juntos respondem por 2/3 dos sites existentes, utilizam o OpenSSL. Qualquer problema nesse, pois, é automaticamente de grandes proporções. Serviços e sites pequenos e gigantes confiam no OpenSSL para blindar conexões seguras.

O que nos leva ao Heartbleed.

O que é o Heartbleed?

A falha descoberta no OpenSSL ganhou esse nome porque é explorada a partir de uma extensão chamada “hearbeat” (batimento cardíaco, em inglês): quando está se comunicando com um servidor via conexão segura, o cliente manda “batidas” constantes apenas para se certificar que a comunicação está ativa, que ela não caiu, e continuar trocando informações.

Com algum conhecimento, uma pessoa mal intencionada de olho em um servidor comprometido pela falha pode utilizar-se dessa extensão para obter respostas do servidor. A cada “batida”, ele consegue 64 Kb de informações — ocorre, pois, um vazamento de memória, um “sangramento no coração”. Parece e é, de fato, pouca coisa, mas o processo pode ser repetido indefinidamente e, com isso, formar porções mais suculentas de informações. Essas, que em um cenário ideal seriam indecifráveis, pelo Heartbleed chegam de forma bastante legível a quem as requisitou.

Com isso dá para pescar entre um monte de caracteres inúteis coisas valiosas, como as já mencionadas senhas e números de cartão de crédito. Existe, porém, algo ainda mais cobiçado: os certificados de segurança dos servidores.

Usando outra analogia, os certificados funcionam como se fossem as chaves para decifrar o conteúdo enviado pelo cliente (você) que fica embaralhado durante o transporte graças ao SSL/TLS. Quem explora o Heartbleed tem grandes chances de localizar o certificado naqueles blocos de 64 Kb. Esses pequenos pedaços de dados vêm da RAM, a memória volátil que o servidor (qualquer computador, na realidade) usa para alocar dados temporariamente, aqueles estão sendo usados no momento. Como um servidor que lida com senhas e informações sensíveis sempre recorre ao SSL/TLS, os certificados recorrentemente aparecem na RAM.

O certificado permite ler qualquer conteúdo interceptado no passado e que porventura venha a ser obtido futuramente, desde que as chaves criptográficas não sejam alteradas no servidor (mais sobre isso abaixo). Não só: ele também pode ser muito útil para scams, ataques em que um site falso se passa pelo original para obter dados dos usuários.

Como me protejo disso?

Os pesquisadores que identificaram o Heartbleed comunicaram o pessoal do OpenSSL antes de divulgar o problema. Isso deu tempo para desenvolver patches (correções) para as principais distribuições Linux. Espera-se, agora, que os serviços de hospedagem e grandes sites apliquem essa correção, como muitas já fizeram — o Yahoo, que ganhou destaque por ter vários logins e senhas de e-mail vazados logo após a divulgação da Heartbleed, afirma já ter tapado o buraco nos seus principais sites e que o trabalho em suas propriedades menores está em andamento.

E eu e você, o que podemos fazer? A princípio, quase nada. Depois que um dado site tiver sanado a falha, trocar a senha é uma boa ideia. Mas pode não ser suficiente, se alguém tiver obtido com sucesso aquele certificado. Aqui entra o segundo passo que os responsáveis por esses serviços que usam o OpenSSL deveriam tomar: atualizar os certificados. O problema? É um processo lento e, em muitos casos, custoso. Alguns analistas estimam que as consequências do Heartbleed reverberarão daqui a um ano…

Não dá para saber quando a falha no OpenSSL é explorada, o ataque não deixa rastros e é transparente para usuário e servidor. Pior: ela existe desde dezembro de 2011 e ninguém garante que tenha passado despercebida nesse meio tempo. Pensar no cenário mais grave é o ideal na hora de remediar casos graves como esse, mas nem sempre o comedimento ganha a queda de braço com o financeiro. É de se esperar que Facebook, Google e Yahoo, bem como serviços que provêm infraestrutura para outros, como Amazon e Heroku, façam todo o possível para evitar o pior, mas e a hospedagem de US$ 5/mês? E aquele site novo, semi-desconhecido, que cumpre uma função no seu trabalho ou para você mesmo?

É difícil abordar o assunto sem soar alarmista, embora talvez seja o caso. Ao The Verge, Nicholas Weaver, pesquisador de segurança da ICSI, disse que o Heartbleed “é catastroficamente ruim, simplesmente um bug incrivelmente danoso”. No blog do Tor Project, a recomendação é de que “se você precisa muito de anonimato ou privacidade na Internet, talvez seja desejável ficar completamente fora dela pelos próximos dias, até que as coisas se ajeitem”. Eles oferecem um navegador que se gaba de não deixar rastros de navegação.

Esta ferramenta indica, de forma nem sempre confiável (há falsos-positivos), que sites ainda não corrigiram o OpenSSL. O LastPass, um gerenciador de senhas, colocou no ar outra semelhante. Na nossa ponta, na condição de usuários, o máximo que dá para fazer é esperar e ter cautela relação aos sites que visitamos e como os acessamos.

***

Os textos abaixo serviram de base para o que você leu acima e são úteis para aprofundar a leitura:

Colabore
Assine o Manual

Privacidade online é possível e este blog prova: aqui, você não é monitorado. A cobertura de tecnologia mais crítica do Brasil precisa do seu apoio.

Assine
a partir de R$ 9/mês