Entenda o que é esse tal de Heartbleed e saiba quais senhas você deve trocar

A essa altura do campeonato você já deve ter ouvido falar do bug chamado Heartbleed, certo? Ele é um bug de computador que, com ondas magnéticas, causa hemorragia em seres humanos. Mentira.

O negócio é muito sério e eu, como um dos autores mais sérios do Meio Bit, vou explicar aqui porque é que essa porcaria é de fato um dos piores pesadelos que a internet já passou — e está passando.

Long story short: o Heartbleed é como ficou conhecida uma vulnerabilidade do OpenSSL que atinge, portanto, milhares de servidores do mundo todo, inclusive de serviços que você usa todos os dias, como Facebook, Instagram, Pinterest, Tumblr e Google.

Como assim, “portanto”?

Oh boy, here we go… Pra entender o bug, a gente primeiro precisa entender o que significa OpenSSL. Bem, o foco do Heartbleed é a criptografia. A ideia de criptografia, na Internet, é tentar garantir que uma informação transite entre computadores de uma maneira segura, de forma que somente o remetente e o destinatário consigam interpretar o pacote de uma forma legível, para proteger a privacidade dos usuários e o acesso restrito aos dados trafegados.

Claro que a NSA discorda disso, mas deixa pra lá.

Bem, imagine a criptografia como uma linguagem secreta entre duas pessoas. Algo que, pra quem está ao redor, soa como qualquer coisa estranha e ininteligível. Por exemplo, nerdês. Ou qualquer outro idioma que só eu e você saibamos compreender.

Para que a nossa conversa prossiga de uma forma aceitável, eu e você vamos precisar ter as referências a respeito do que estamos dizendo, seja conhecer os episódios de uma série, seja os nomes dos personagens, do autor do livro, do macete do game.

Em termos de criptografia, essa linguagem e essa referências que permitem que a conversa flua e seja entendida pelas duas pessoas, seriam as chaves criptográficas.

O usuário (no caso, você! Seu usuário!) tem uma cópia desta chave no seu computador e o cliente (web app ou servidor) tem outro set. Nem preciso dizer quão importante é manter estas chaves protegidas e em um lugar seguro, certo? Vamos dizer que embaixo do carpete de entrada, não pode.

A internet tem um pacote de protocolos para lidar com segurança, comumente chamado de Secure Sockets Layer (SSL) e seu sucessor Transport Layer Security (TLS). Essa camadas SSL/TLS constituem boa parte de como a internet funciona hoje em dia.

Como quase todos protocolos web, existe uma vasta gama de soluções que provém a funcionalidade SSL/TLS para um site ou um aplicativo. O mais comum deles é uma implementação de código aberto, bem sólida (sem sacanagem), conhecida como OpenSSL.

OpenSSL é gratuito e foi desenvolvido, corrigido, aperfeiçoado, aprimorado e zaz e zaz e zaz, de uma maneira que possa ser utilizado em muitos tipos de projetos diferentes.

A gigantesca maioria dos serviços online e aplicativos hoje em dia utiliza o OpenSSL como a maneira principal de prover a funcionalidade das camadas SSL/TLS.

Dois dos mais populares projetos para web servers, Apache e Nginx, usam OpenSSL.

Além disso, vários serviços de email, clientes de mensagens instantâneas prontas em 3 minutos, roteadores, e até mesmo impressoras, usam OpenSSL.

É tanta gente usando isso que se alguém fizer uma pesquisa nas ruas, perguntando o que você faria se descobrisse que seu filho está usando OpenSSL, é capaz até alguém saber o que significa.

Essa implementação roda em 66% da Internet. Mesmo se você não fazia ideia do que era essa joça, nem pra que servia, você interage com ela diariamente.

Essa interação pode ser simples, como digitar sua senha para acessar seu e-mail, ou complexa como enviar uma mensagem íntima (ui) e privada, uma foto, ou o preenchimento de seus impostos. Não queremos que aquela sua foto caia nas mãos erradas, certo? Acesso aberto ao seu imposto de renda, então? Aposto que isso daria calafrios em muitas pessoas.

E aí, Matheus? Por que esse tal Sangue de Boi dá tanto medo?

OK! Já sabemos pra que serve o OpenSSL e que ele é uma boa parte da Internet moderna. O que aconteceria se alguém descobrisse que o OpenSSL tem uma falha? E se essa falha permitisse que as chaves secretas entre você e o servidor se tornassem repentinamente acessíveis por uma pessoa mal intencionada?

E se essa falha significasse que essa pessoa pudesse secretamente ganhar acesso às chaves que o servidor tem, fizesse uma cópia pra ela e espionasse toda comunicação que acontece entre o server e seu computador? E pegasse, entre outras coisas, suas senhas? E se essa falha fosse impossível de ser detectada em funcionamento?

Voilá, esse é o Heartbleed. Muito prazer.

Essa é uma vulnerabilidade que, até hoje, pode ter sido aproveitada sem que fosse possível ser identificada. Além disso, alguém com bastante tempo e força de vontade poderia acessar informação, muita informação, endereçada para um terceiro.

Sob quais justificativas alguém faria algo tão nefasto? Puxa vida, ninguém, né?

A pior parte da coisa é que essa vulnerabilidade está aí desde dezembro de 2011 e só foi descoberta há alguns dias. Um monte de software estava (ou está!) usando uma versão vulnerável do OpenSSL lançada em maio de 2012. Portanto, por pelo menos dois anos, qualquer app, website, site de banco ou programas de troca de mensagens que usem essa versão, podem ter sido violados. Sem KY. Sem nem a pessoa ou a empresa perceberem.

Claro, nem todo web server usa essa implementação. Mas a vasta maioria do que temos rodando hoje na Internet estava operando (ao menos até a última segunda-feira), com uma versão do OpenSSL vulnerável ao Heartbleed.

Tá, mas por que eles não corrigem o problema?!

“Eles”, é engraçado que “eles” é uma entidade meio indefinida nestes casos.

Bem, “eles” já apresentaram uma correção para o Heartbleed no OpenSSL. Já foi amplamente divulgada, inclusive, e a maioria das distribuições Linux já receberam os patches necessários e os servidores já estão, em tese, protegidos.

https://twitter.com/YahooInc/statuses/453613063753990144

Festa, fim de assunto, finito, caput, the end, vamos todos para a praia tomar cerveja, comer camarão e amassar areia com os dedos dos pés? Não. Ainda não.

Isso porque corrigir esse problema não é assim tão simples. O fix para os servidores em si não é lá difícil de ser implementado. O problema é que algumas aplicações precisam saber decidir se vão revogar e reenviar alguns certificados digitais ou esperar que eles expirem.

Principalmente nos casos de navegadores, que verificam se tal web server é seguro. Esses certificados mostram que dado website está conectado com um nome específico, e-mail e endereço DNS, o que ajuda a “provar” (imagine que estas aspas são gigantes!) sua identidade. Algo como mostrar seu RG, habilitação e CPF para um policial na rua. Ele bate os nomes com o cadastro na central e deixa você ir embora se nada estiver errado.

https://twitter.com/JamiesonBecker/statuses/453662804713566208

Vamos complicar um pouco mais? Então vem comigo! A Codenomicon, empresa de segurança que, junto com Neel Mehta (Google) descobriram o Heartbleed, percebeu que essa vulnerabilidade permitia roubar suas próprias chaves secretas, as mesmas usadas em seus certificados digitais (os renomados X.509, protocolos criptográficos muito comuns em certificados digitais). Foi possível, assim, ganhar acesso a usuários e senhas, mensagens, emails e documentos da empresa.

Os especialistas entenderam, então, que é possível que qualquer certificado enviado antes da implementação da correção do Heartbleed pode estar comprometido, veja que beleza.

Se alguém utilizou o bug para roubar os certificados digitais de algum site, antes do patch, pode ser que ele consiga fazer alterações no certificado e mascarar um site, fazendo ele se passar por uma identidade que, na realidade, ele não tem.

Por isso que eu disse que o jogo das empresas agora é ter que decidir se devem revogar e reemitir todos os certificados através de um certification authority (CA) ou esperar que eles expirem.

O mais seguro, claro, seria revogar e reemitir os certificados, mas não se trata de uma tarefa simples e trivial. Isso toma um bom tempo. Calcule o número de potenciais certificados que devem ser reemitidos. Pode ser que demore dias ou até semanas até que todo CA atue em todos os serviços possivelmente comprometidos.

Mas o que eu posso fazer para evitar que meus dados sejam comprometidos nesse meio tempo?

Eu mudaria a pergunta: o que você pode fazer para evitar que seus dados já tenham sido comprometidos?

R: nada! Aeeeeee!! \o/

Mentira. Não sabemos até que ponto as contas dos principais serviços online foram comprometidas. O que os especialistas de segurança estão fazendo é verificar quais sites podem ter sido alvo de alguma investida através do bug e alertar aos usuários que seria prudente trocarem suas senhas. Eu troquei as minhas por via das dúvidas.

Abaixo você confere a lista* de quais sites foram ou não comprometidos, se a correção já foi implementada, e se você deve ou não trocar suas senhas, confira:

Redes sociais

	Foi afetado?	Já existe uma correção?	Você precisa trocar sua senha?
Facebook	Incerto	Sim	Sim
Instagram	Sim	Sim	Sim
LinkedIn	Não	Não	Não
Pinterest	Sim	Sim	Sim
Tumblr	Sim	Sim	Sim
Twitter	Incerto	Sim	Se você quiser, por precaução.

 

Empresas

	Foi afetado?	Já existe uma correção?	Você precisa trocar sua senha?
Apple	Incerto	Incerto	Se você quiser, por precaução.
Amazon	Não	Não	Não
Google	Sim	Sim	Sim
Microsoft	Não	Não	Não
Yahoo	Sim	Sim	Sim

 

E-mail

	Foi afetado?	Já existe uma correção?	Você precisa trocar sua senha?
AOL	Não	Não	Não
Gmail	Sim	Sim	Sim
Hotmail / Outlook	Não	Não	Não
Yahoo Mail	Sim	Sim	Sim

 

Lojas e eCommerce

	Foi afetado?	Já existe uma correção?	Você precisa trocar sua senha?
Amazon	Não	Não	Não
Amazon Web Services	Sim	Sim	Sim
eBay	Incerto	Incerto	Se você quiser, por precaução.
GoDaddy	Sim	Sim	Sim
Nordstrom	Não	Não	Não
PayPal	Não	Não	Não
Target	Não	Não	Não
Walmart	Não	Não	Não

 

Outros

	Foi afetado?	Já existe uma correção?	Você precisa trocar sua senha?
Dropbox	Sim	Sim	Sim
Evernote	Não	Não	Não
LastPass	Sim	Sim	Não
Minecraft	Sim	Sim	Sim
Netflix	Incerto	Incerto	Incerto
OkCupid	Sim	Sim	Sim
SoundCloud	Não	Sim, por precaução	Se você quiser, por precaução.
Spark Networks (JDate, Christian Mingle)	Não	Não	Não
Wunderlist	Sim	Sim	Sim

*Lista feita pelo site Mashable.

Fontes: Heartbleed.com, Codenomicon, Mashable, StackExchange, NakedSecurity.