A falha Heartbleed, como sugere seu nome, está fazendo muitos corações sangrarem e muita gente perder noites de sono desde que foi revelada. Isso porque o bug, que existe há pelo menos dois anos, afeta milhares ou até mesmo milhões de sites (especula-se que 2/3 da internet), que usam o protocolo de criptografia TSL/SSL.
Tanto a Secure Sockets Layer (SSL) quanto sua irmã mais nova, a Transport Layer Security (TSL) estão presentes na maioria dos serviços que usam criptografia para tentar proteger transações online. No entanto, muitas vezes essas tecnologias utilizam um pacote de código aberto chamado OpenSSL, que contém a brecha na sua estrutura.
“Em uma escala de severidade de 0 a 10, eu diria que esse bug tem 11. Como ele já existe há dois anos, ninguém sabe se ele já estava sendo explorado ou qual o estrago feito”, avalia Camilo Telles, desenvolvedor, gerente de tecnologia e CEO da Agilize.
Realmente não se sabe até onde a brecha pode ter sido explorada. Qualquer um que conhecesse a falha e soubesse explorá-la estava apto a “fuçar” em 64 kb de memória de qualquer informação de cada site quantas vezes quisesse. Nessa, era possível conferir algumas senhas, contas de bancos, ou outros dados sigilosos. E o pior: tudo isso é feito sem deixar rastros.
Sites como Yahoo, Tumblr, YouTube e vários outros muito populares na web são alguns dos que estavam vulneráveis. Essa semana já lançaram a versão corrigida, a OpenSSL 1.0.1g, que corrige o problema. O Yahoo e a Amazon, por exemplo, já atualizaram para a versão segura.
“Consertar o problema é trabalhoso porque ele é compilado dentro de muitos outros projetos. Não é uma questão de atualizar uma biblioteca, é necessário recompilar e reinstalar muita coisa”, explica Fábio Akita, desenvolvedor e co-fundador da Codeminer 42.
Inclusive, Akita fez mais algumas observações técnicas sobre o problema, veja abaixo:
Há cinco conceitos a entender:
1) Algoritmos de hash como md5 ou sha1 servem para pegar qualquer dado, qualquer volume de dados e “digeri-los” em outro dado de tamanho fixo – costumamos chamar isso de “assinatura”. Ela representa um dado. Não é criptografia pois ela não tem volta. Como o resultado é um outro dado de tamanho fixo significa que dois dados podem resultar numa mesma assinatura (colisão). Mas o importante é que, se eu receber esse dado e rodar o hash, o valor resultante é sempre o mesmo. Por isso usamos de assinatura.
2) Par de chaves ou certificados são basicamente dois números primos criados ao mesmo tempo. Em resumo, a característica principal é que um dado criptografado por uma chave só pode ser descriptografada com a outra chave, não com a mesma. Por convenção mantemos uma em segredo sem nunca sair do servidor que a gerou (chave privada) e a outra podemos mandar para o público (chave pública). Todo browser tem instalado dezenas de chaves públicas de diversos Certificate Authorities (CA)
3) Agora podemos usar a chave pública para assinar uma assinatura de algum dado e só a chave privada será capaz de abri-la. Mais do que isso, podemos “encadear” assinaturas criptografadas. Seu servidor web gera um par de chaves. Manda a assinatura da chave pública para uma CA (como Certisign) para “assiná-la” – ou seja: criptografá-la com sua outra chave privada. A beleza é que, quando seu browser pede uma conexão segura, ela recebe a chave pública criptografada pela chave privada da Certisign. Como seu browser já tem instalado a chave pública da Certisign, quando descriptografá-la ele saberá que essa criptografia só poderia ter sido feita pela chave privada da Certisign, e assim tem certeza que foi assinada só lá. É por isso que você pode “confiar” nesse servidor web.
4) De posse da chave pública do servidor web, você gera uma senha normal de criptografia de dois lados (uma senha que serve tanto pra criptografar como descriptografar); criptografa com a chave pública que acabou de receber; e envia ao servidor. Só o servidor poderá abrir, pois só ele tem o outro par da chave. E assim está realizado o “handshake” ou “troca de chaves”. Fazemos isso por que a criptografia de par de chaves (estou usando nomes leigos, claro) custa caro. Criptografia normal de chave única é mais rápida.
5) Esse handshake é renovado de tempos em tempos para que não exista tempo de alguém tentar quebrar a criptografia por força bruta por exemplo. E assim é toda conexão SSL. Agora imagine que é possível ter acesso à chave privada (que nunca sai dos servidores) de vários serviços na web. De redes sociais às próprias CAs (não ouvi falar se as CAs estão vulneráveis ou se chaves raíz foram exploradas, como já foram no passado). Não só você consegue descriptografar as chaves de criptografia, como você pode usar essa chave para assinar coisas, nenhum browser ou aplicativo será capaz de saber que você não é mesmo a Certisign, isso se chama “impersonar”.
Um serviço web que tem chaves SSL, precisa não só atualizar todos os componentes de sistema que usam o OpenSSL problemáticos, como também, em caso de suspeitas de vazamento da chave privada, precisa revogar essa chave e criar outras. Pense como isso é trabalhoso.
Basicamente, como não é um “ataque”, é basicamente “fuçar”, isso não deixa traços. E, como não deixa traços, não é possível saber se alguém já teve acesso a um servidor ou não. E mesmo o serviço trocando as chaves e atualizando tudo, o certo é expirar todas as sessões de usuários e pedir para todos os usuários trocarem suas senhas, pois não dá pra saber se alguém já teve acesso a elas. E, como todo grande serviço – de Gmail a Facebook – usa OpenSSL, dá para entender porque estão chamando isso de “catastrófico”.
