A verdade é que somente informações acessadas através do OpenSSL podem ser roubadas pelo atacnate, se ele tiver sorte. Ou seja, somente o que a vítima acessar via SSL (por exemplo, páginas ou documentos que visualize ou faça o download via https) no momento em que o atacante explora o bug.
Isto acontece porque o bug do Heartbleed faz com que o servidor OpenSSL responda requisições do protocolo Heartbeat com trechos de memória de tamanho indicado pelo atacante, que pode ser de 1 até 64KB. Ou seja, o protocolo de Heartbeat do TLS foi desenvolvido para que o cliente e o servidor fiquem mandando dados entre eles para manter a conexão ativa: um lado manda a requisição de heartbeat, com uma string qualquer, e o outro lado manda, como resposta, a mesma string de volta. Segundo a RFC, o payload (resposta) é formado pelo conteúdo do request ("the receiver MUST send a corresponding HeartbeatResponse message carrying an exact copy of the payload of the received HeartbeatRequest").
Desta forma, o solicitante envia uma quantidade de dados (chamada de "payload", e que deve ser devolvida) e informa qual é o tamanho desse conjunto de dados, mas informa um número maior do que o tamanho real, até no máximo 64*1024. Por exemplo, ele envia a mensagem "teste" e, em vez de dizer que o tamanho é 5, diz que são 65.535 caracteres. Assim, por causa do bug, o OpenSSL não verifica o tamanho real, acredita no que foi informado e, ao tentar devolver a mensagem original ("teste", neste exemplo), ele extrai blocos de memória do servidor e devolve isso tudo. O OpenSSL usa o memcpy (que é inseguro) para jogar um bando de dados de memória como a resposta do heartbeat. E, nessa hora ele poderia acessar outras áreas de memória do processo, dependendo de como o servidor está alocando a memória.
Assim, a cada vez que explora o bug, o atacante recebe de presente um bloco de memória de, no máximo, 64 KB (64 Kbytes, que corresponde a 65.535 caracteres). Logo, o atacante pode ficar rodando o seu script que explora o bug e, assim, vai extrair centenas ou milhares de blocos de memória até não aguentar mais (fácil, já tem script para fazer isso). Em seguida ele tem que juntar todos esses blocos de memória e caçar as informações que deseja no meio disso tudo.
É importante notar que o atacante terá acesso somente a área da memória heap do processo OpenSSL. Ele não vai ter acesso a memória de todo o servidor !!! Isto porque não tem como o leak de memória do OpenSSL dar acesso a memória de outros processos. Isso não está claro em nenhum lugar, mas nos sistemas operacionais modernos cada processo tem sua área de memória virtual. Antigamente todos os processos compartilhavam a mesma visão da memória, mas isso não acontece mais. Somente vulnerabilidades no kernel do S.O. permitem acessar áreas de outros processos.
O advisory minúsculo do OpenSSL só cita "reveal up to 64k of memory", enquanto o site do Heartbleed.com (que está mais para fazer FUD do que para dar detalhes técnicos de qualquer coisa) não fala em nenhum momento qual área de memória pode ser acessada pelo bug (ele só fala que "The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software." Ou seja, ele fala que afeta a "memória do sistema"). A página do CVE também não diz muitos detalhes, apenas fala que "allows remote attackers to obtain sensitive information from process memory" (isto é, acessa a área de memória do processo) e nem o Bruce Schneier ajudou muito: "Basically, an attacker can grab 64K of memory from a server. The attack leaves no trace, and can be done multiple times to grab a different random 64K of memory." Ou seja, pela grande maioria do que se lê por aí, não dá para ter certeza de como o bug afeta os sistemas vulneráveis.
E afinal das contas, o que o atacante pode conseguir?
- Os dados da sua sessão SSL ativa, que estavam sendo tratados em memória: Se, por azar, você estava logado na hora que o hacker roubou os blocos de memória do servidor e, naquele momento, os dados da sua sessão estavam sendo tratados em memória, aí o atacante pode ter conseguido roubar seus dados que estavam sendo criptografados naquele momento. Basicamente, são os conteúdos das páginas que você estava navegando: dados de usuário e senha se você acessou a página de login naquele momento, ou o cookie de sessão. No pior caso o atacante teve a sorte de capturar o bloco de memória referente a conexão aonde o usuário fez o login e ele roubou a senha. Ou você estava acessando seu GMail ou o webmail da empresa e o atacante leu um trecho de 64K do seu e-mail.
- Se ele tiver muita sorte, o hacker conseguiu roubar blocos de memória que tinham a chave privada de criptografia: aí ele consegue levantar um servidor falso com o certificado digital igual ao seu ou, se ele tiver cópia de todo o tráfego, ele consegue descriptografar tudo. Mas, para isso, ele vai ter que interceptar todo o tráfego de rede do servidor (deve fazer isso online ou ter uma cópia dos pacotes de rede em um arquivo). Mais cedo ou mais tarde a chave privada vai vazar, mesmo por que o TLS no lado do servidor precisa da chave privada em memória para fazer o handshake do TLS. E aí nessa hora a chave pode vazar.
- O atacante conseguiu roubar blocos de memória que tinham a chave de criptografia de sessão de alguma sessão SSL. Aí, além de ter que capturar o tráfego para conseguir decifrar algo, a chave de sessão é uma chave simétrica que vale só para um acesso específico. Isso é muito menos calamitoso do que o caso anterior.
Resumindo o que foi dito acima, o atacante pode ter a sorte de capturar os dados criptografados através da sua sessão SSL. O mais arriscado são os nomes de usuário e senhas e, eventualmente, as chaves privadas associadas ao certificado digital do servidor. Mas o maior problema relacionado ao roubo do certificado não é alguém usar isso para decriptografar os seus dados: o maior risco é usarem estas chaves privadas para criarem certificados digitais para sites fraudulentos, e assim, atacar usuários com mensagens de phishing. Dá para fazer uma bela festa com isso...
Nenhum comentário:
Postar um comentário