Caríssimos leitores,
No dia 1 de Abril de 2014, foi comunicado à equipa de segurança do OpenSSL um bug no recurso denominado Heartbeat. Este foi reportado por Neel Mehta da Google Security.
Fazia algum tempo que não se ouvia falar tanto de uma vulnerabilidade de segurança e com um impacto tão brutal na Internet.
O que é o HeartBleed?
Este bug foi batizado como Heartbleed, e está presente em algumas versões do OpenSSL (releases 1.0.1 até 1.0.1f e 1.0.2-beta1) . O OpenSSL é uma biblioteca open source de criptografia, adotada por aproximadamente 2 em cada 3 servidores de empresas para blindar suas comunicações via Internet. É ela a responsável por colocar o S no HTTPS e o cadeado na barra de endereços dos sites seguros, por exemplo.
Esta falha, permite que um adversário capture pedaços de dados carregados na memória num servidor, que corra a versão vulnerável da biblioteca, eventualmente comprometendo informações importantes. Um exemplo disso, são palavras-passe de utilizadores, chaves privadas do servidor, cookies ,etc.
Este erro, foi introduzido com um novo recurso implementado pelo Dr. Robin Seggelmann, um programador alemão, que em muitas vezes já contribuiu com códigos de segurança.
Utilizadores (em geral, administradores de plataformas web) da biblioteca OpenSSL afetados devem atualizá-la para a versão 1.0.1g, lançada em 7 de abril, ou recompilar o OpenSSL com a opção -DOPENSSL_NO_HEARTBEATS. A série 1.0.2 está sendo corrigida no release 1.0.2-beta2. A versão 1.0.1 foi lançada em março de 2012, o que significa que sites e produtos que tenham adotado o OpenSSL 1.0.1 com a extensão Heartbeat ativa podem ter estado vulneráveis nos últimos dois anos.
O Heartbleed explora um recurso interno do OpenSSL chamado “Heartbeat”. Quando o um computador acede a uma plataforma, esta irá responder de volta, para informar o emissor que ele (o receptor/servidor) está ativo e escutando os pedidos. Esta chamada e resposta, é feita através da troca de dados. Normalmente quando o computador faz uma solicitação, o Heart só vai enviar de volta a quantidade de dados solicitadas pelo computador. No entanto, este não é o caso para os servidores atualmente afetados pelo bug. Um indivíduo mal intencionado (hacker) é capaz de fazer um pedido de dados para o servidor (e dos que estão gravados na memória), com um tamanho máximo de 65.536 bytes.
Para os mais leigos, é possível entender esta vulnerabilidade a partir da seguinte figura.
O servidor poderá responder com informação até 65.536 bytes, e como visível na imagem, poderá comprometer a autenticidade da informação dos utilizadores, como do serviço.
Entre os grandes sites de serviços afetados está o Facebook, Google, Yahoo (incluindo serviços populares como Yahoo Mail, Flickr e Tumblr). Como uma das informações que pode ter vazado através do bug Heartbleed é a chave secreta do próprio certificado digital SSL do site https afetado, a recomendação dos especialistas para os administradores destes sites é que revoguem o certificado utilizado no site até o dia em que corrigirem a vulnerabilidade, e emitam um novo certificado.
Segundo o site mashable.com, é recomendado a utilizadores do Facebook, Tumblr, Instagram, Google, Yahoo, Amazon, entre outros, alterarem as suas palavras-passe pessoais, pois estas poderiam ter sido comprometidas.
Ver mais: http://mashable.com/2014/04/09/heartbleed-bug-websites-affected/ .
A estimativa é que a falha tenha atingido cerca de 17.5% dos sites da Internet, cerca de 500 milhões, mas o número pode ser bem maior, pois a falha também afeta outros serviços que podem utilizar a mesma biblioteca, como SMTP, VPN, IMAP e MySQL.
Como funciona o bug HeartBleed?
As mensagens de comunicação SSL/TLS baseiam-se na estrutura SSL3_RECORD, onde a variável length define o tamanho total do pacote da mensagem SSL.
struct ssl3_record_st
{
int type;
unsigned int length; /* How many bytes available */
[...]
unsigned char *data; /* HeartbeatMessage goes here */
[...]
} SSL3_RECORD;
O protocolo Heartbeat por sua vez é bem simples e consiste em dois módulos: [1] requisição heartbeat_request e [2] resposta heartbeat_response, como um addon ao OpenSSL. Essas mensagens são formatadas de acordo com a estrutura HeartbeatMessage:
struct
{
HeartbeatMessageType type;
uint16 payload_length;
opaque payload[HeartbeatMessage.payload_length];
opaque padding[padding_length];
} HeartbeatMessage;
Quando o servidor inicia uma requisição aloca em memória espaço suficiente para o pacote que ele deseja enviar e configura os campos payload_length de HeartbeatMessage e length de SSL3_RECORD:
buffer = OPENSSL_malloc(1 + 2 + payload + padding);
Um atacante por sua vez ao responder informa um valor de payload_length maior que o necessário, que sendo um inteiro unsigned de 16-bits pode ter o valor máximo de 2^16-1, ou seja, 65535 bytes ou 64kb, incoerente com o valor do length do SSL3_RECORD declarado inicialmente.
Por outro lado, o RFC 6250 que trata da extensão Heartbeat ao TLS e DTLS, explicita que “When a HeartbeatRequest message is received […] the receiver MUST send a corresponding HeartbeatResponse message carrying an exact copy of the payload of the received HeartbeatRequest.”, ou seja, “Quando uma mensagem HeartbeatRequest é recebida […] o recipiente DEVE enviar uma mensagem HeartbeatResponse correspondente carregando uma cópia exata do payload que foi recebido pelo HeartbeatRequest.”
Como o servidor não verifica o valor de payload_length, ele responde com bytes da própria memória, que não foram alocadas para o Heartbeat, enviando assim informações fora da área de memória da função, contendo dados aleatórios do processo.
Como o ataque pode ocorrer repetidamente e extrair até 64kb de informação por vez, a falha pode expor informações críticas, como palavras-passe e chaves de criptografia de chave pública, que podem levar a ataques do tipo man-in-the-middle.
Explorando o bug HeartBleed
Tendo ficado percebido o funcionamento do bug, é o momento ideal de efetuar uma experiência prática, de maneira a verificar esta potente vulnerabilidade.
Para explorar esta vulnerabilidade será usado o ambiente Linux – Kali, e dois ficheiros essenciais:
i) Exploit para efetuar o pedido ao servidor.
ii) Servidor (pote de mel) vulnerável.
O exploit é um mero ficheiro em Pyhon, que pode descarregar no final da página, que envia um pedido ao servidor, e verifica se ele está ou não vulnerável. Por outro lado, o servidor é um ficheiro escrito na linguagem de programação Perl, e emula um servidor HTTP com uma ligação segura SSL (HTTPS).
O conteúdo destes ficheiros pouco interessa neste artigo, mas convém referir que não foram escritos pelo autor do artigo.
Para executar o servidor honeypot.pl (pote de mel), será necessário indicar a seguinte linha no terminal: perl honeypot.pl . Em seguida clicar enter e o servidor ficará a correr esperando por um pedido.
Abrindo outro terminal, é necessário executar o exploit. O comando para proceder à sua execução é o seguinte: python exploit.py .
Foi propositado executar o exploit desta maneira, para que seja possível verificar os seus argumentos. Neste caso, basta unicamente definir o IP do servidor 127.0.0.1 (localhost).
Passando à execução do exploit da seguinte maneira: python exploit.py 127.0.0.1 , é possível verificar a resposta do servidor.
Inicialmente o exploit envia dados em massa para o servidor (Hello), e espera igualmente uma resposta longa, com possíveis dados não autorizados. É possível verificar, que no inicio da mensagem de volta do servidor, são enviadas ao utilizador alguns utilizadores e suas palavras-passe. Isto deve-se ao facto, de muito recentemente tais utilizadores se terem autenticado no servidor. Este é o cenário predominante ainda em milhares de servidores atualmente online na Internet.
Como corrigir o HeartBleed
Para colmatar este bug, é necessário atualizar as versões do OpenSSL. As versões do OpenSSL de 1.0.1 até o 1.0.1f (inclusive) são vulneráveis. Versões anteriores à 1.0.1, como a 1.0.0 e 0.9.8, não são vulneráveis. A versão 1.0.1g corrige o bug, portanto não é vulnerável.
Para verificar se os servidores estão vulneráveis, poder-se-á utilizar o seguinte comando no terminal Linux:
$ echo -e “quit\n” | openssl s_client -connect seuhost:443 -tlsextdebug 2>&1| grep ‘TLS server extension “heartbeat” (id=15), len=1′
Existem igualmente aplicações web que podem ser usadas para efetuar igual verificação, por exemplo:
[1] – https://filippo.io/Heartbleed/
[2] – https://lastpass.com/heartbleed/
.
Também é importante gerar novos certificados para servidores que tenham estado vulneráveis.
No caso dos utilizadores finais, é importante a troca de todas as palavras-passe de sites ou serviços que possam ter sido comprometidos. Mas antes de trocar, assegure-se que o provedor do serviço já corrigiu o problema. Consulte novamente o endereço disponibilizado acima, pois oferece uma listagem de todos os serviços afetados.
Por forma a motivar ainda mais o artigo, nada se sabe se esta vulnerabilidade foi ou não largamente explorada. As teorias conspiratórias estão a todo o vapor, e por um motivo: não dá para saber. A falha introduzida por Seggelmann não produzia nenhum log ou registo dos utilizadores do servidor e suas requisições, o que significa que não apenas a vulnerabilidade existe há dois anos, como também não existem qualquer ideia de quem tenha tirado proveito dela.
Ficheiros para download.
Boa continuação!