Neste post gostaria primeiramente de comentar sobre a falha de segurança do OpenSSL conhecida como heartbleed e também demonstrar como a mesma pode ser blindada através do uso do Virtual Patching, recurso disponível em diversas ferramentas da Trend Micro como o plugin IDF do Office Scan e o Deep Security.
SOBRE O HEARTBLEED
A vulnerabilidade conhecida como heartbleed está catalogada sob o registro CVE 2014-0160. Trata-se de um bug da biblioteca openssl utilizada por vários sites e sistemas web, mais precisamente em uma de suas extenções chamada hearbeat utilizada para checagem de conexões ativas.
Esta falha foi descoberta em Dezembro de 2011, em Março de 2012 ela estava "In the wild", ou seja, foi utilizada em ataques reais sem que houvesse um patch de correçã, sendo que somente em Abril de 2014 ela foi corrigida.
O resultado desta falha é permitir que o atacante possa fazer a leitura de uma parte da memória ram do servidor, podendo conter credenciais e outras informações enviadas pelo usuário já descriptografadas.
Figura 1
Na figura 1 temos a comunicação TLS padrão:
- Cliente faz a requisição da sessão segura para o servidor;
- O servidor responde com o certificado;
- O cliente checa a validade do certificado e extrai dele a Public Key;
- Cliente gera a Session Key e encripta a mesma utilizando a Public Key do servidor.
- O servidor recebe a Session Key e decripta a mesma com sua Private Key.
- A comunicação segura se inicia utilizando a Session Key.
Figura 2
Na figura 2 temos a comunicação normal feita pelo heartbeat do OpenSSL, onde:
- O cliente envia para o servidor uma mensagem com o intuito de verificar se ele ainda está ativo.
- O servidor recebe a mensagem, extrai o payload de dentro dela e o coloca dentro de uma mensagem de resposta.
- O cliente recebe a mensagem de volta e verifica se o payload é o mesmo enviado inicialmente.
Figura 3
Na figura 3 temos o mesmo diagrama anterior, porém desta vez explorando a falha conhecida como Heartbleed:
- Cliente envia um pacote heartbeat malformado, sendo que é menor do que deveria, porém está camuflado como um pacote maior.
- O servidor recebe o pacote e retira o payload de dentro para enviar a resposta do heartbeat.
- Como o pacote enviado pelo cliente é menor do que deveria, o servidor preenche o pacote com outras informações contidas na memória.
- O cliente recebe o pacote contendo o mesmo payload enviado anteriormente, e além disso os dados que estavam na memória usados para completar o tamanho do pacote, ao olharmos estes dados podemos encontrar chaves TLS/SSL, cookies de autenticação além de credenciais de acesso, incluindo senhas em texto plano.
Explorando a falha
Para explorar a falha montei o seguinte laboratório utilizando o Oracle Virtual Box:
- Vítima: Windows Server 2008 R2 com o Magento Commerce versão 1.9.0.1 rodando no webserver kit Xammp 1.7.7.
- Firewall: PFSense 2.1.3
- Atacante: Kali Linux 1.0.5
Figura 4
Para exploração da falha utilizei um exploit escrito em Python disponível no exploitdb feito pelo Csaba Fitzl, como o ideal será que o ataque fosse executado várias vezes pois de acordo com o momento diferentes informações podem retorna do servidor eu escrevi uma interface utilizando shell script para que o exploit seja executado quantas vezes forem necessárias, o exploit juntamente com a interface que fiz podem ser baixados do link abaixo:
Abaixo o vídeo demonstrando a exploração da falha:
Sobre o Virtual Patching
Agora que vimos como funciona a vulnerabilidade e como explorar a mesma, vamos ver como podemos nos proteger, para isso utilizarei o recurso do Virtual Patching, presente em várias das ferramentas de segurança da Trend Micro, neste caso utilizaremos o Deep Security, para maiores informações sobre o Deep Security recomento o acesso no link abaixo:
Trend Micro Deep Security
O Virtual Patching da Trend Micro Deep Security blinda vulnerabilidades em sistemas críticos até que um patch seja disponibilizado e implementado. Desta forma podemos diminuir o tempo de exposição de um servidor à uma determinada falha enquanto seu desenvolvedor não cria uma correção, além disso quando os sistemas não são mais suportados ou não é possível aplicar patches, o Virtual Patching pode proteger os sistemas indefinidamente. Essa proteção pode prolongar a vida de sistemas e aplicativos legados, além de reduzir as despesas administrativas.
Para mais informações sobre o Trend Micro Virtual Patching recomendo o acesso ao link abaixo:
Trend Micro Virtual Patching
Resolvendo o problema
Para demonstrar o funcionamento do Virtual Patching aproveitarei o mesmo laboratório anterior, porém incluindo mais um host com o sistema operacional CentOS Linux, onde a console do Deep Security estará instalada.
Abaixo o vídeo demonstrando a exploração da falha em seguida a blindagem da mesma feita pelo Virtual Patching:
Referências
http://heartbleed.com/
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0160
http://www.trendmicro.com.br/br/grandes-empresas/solucoes-em-nuvem/deep-security/index.html
http://www.trendmicro.com.br/br/grandes-empresas/desafios/nuvem-virtualizacao/virtual-patching/









