Certificate Pinning - Dificultando ataques MITM contra sua aplicação mobile

Com a massificação do uso de smartphones em ambientes wireless (wifi-zones), a viabilidade de ataques do tipo Man-in-the-middle (MITM) também cresceu, fazendo com que a implementação de conexões HTTPS (SSL/TLS) se tornassem obrigatórias por parte das aplicações mobile. Contudo, mesmo com as URLs fazendo uso hardcoded de URLs com HTTPS, em um cenário específico de ataque, é possível que a aplicação tenha suas requisições interceptadas por um atacante! Para mitigar esse cenário a solução é a implementação da técnica Certificate Pinning.

O objetivo deste post é tão somente ilustrar a necessidade do uso desta técnica que já é utilizada por grandes empresas em suas aplicações mobile. Mas antes de falar sobre Pinning, vamos conhecer a técnica utilizada pelo atacante antes e depois da utilização do HTTPS.

Observações:

1 Por ter mais familiaridade, nos exemplos deste post serão utilizados como vítima aplicações Android. Entretanto, a técnica aqui proposta se aplica a qualquer plataforma de desenvolvimento mobile (iOS/iPhone, Windows Phone, etc).
2 Para ilustrar os exemplos deste post, três aplicações com as mesmas funcionalidades foram desenvolvidas, sendo uma utilizando HTTP, outra com HTTPS e a última com HTTPS e certificate pinning.

O Ataque: Man-in-the-middle (MITM)

A natureza do protocolo HTTP não prevê a existência de uma camada de segurança adicional (normalmente baseada em SSL/TLS). Sendo assim, os dados trafegados entre o cliente e o servidor podem ser facilmente interceptados e compreendidos por um atacante posicionado entre os dois extremos da conexão — através de técnicas do tipo man-in-the-middle. Para realizar o ataque, tudo que o atacante precisa é estar conectado em uma "wifi-zone" (rede interna da empresa, cafés, barzinhos, faculdades, shoppings, etc) onde outras pessoas estejam acessando aplicações que trafeguem dados em texto plano (sem SSL/TLS).

Exemplo prático de MITM com arpspoof:

Para exemplificar um sequestro de sessão, vou realizar um ataque com a ferramenta arpspoof e interceptar o tráfego com o proxy web da ferramenta Burp Suite. Neste cenário, a partir do momento que a vítima se autentica em uma aplicação através da rede wifi, o atacante está apto a realizar o ataque. Os seguintes passos ilustram o cenário:

1 - A vítima e o atacante estão conectados na mesma rede wireless;
2 - A vítima se autentica em uma aplicação insegura (que não faz uso de SSL/TLS);
3 - O atacante realiza o arpspoof;
4 - O tráfego da vitima é direcionado para uma ferramenta de proxy (Burp Suite);
5 - O atacante captura todas as informações enviadas e recebidas pela vítima.

Para direcionar o tráfego da vítima(http e https) para a ferramenta de proxy, que escutava na porta 4443, foi necessário adicionar as seguintes regras de firewall:

iptables -t nat -A PREROUTING -p tcp -d exemplo-cert-pinning.herokuapp.com --dport 80 -j REDIRECT --to-ports 4443
iptables -t nat -A PREROUTING -p tcp -d exemplo-cert-pinning.herokuapp.com --dport 443 -j REDIRECT --to-ports 4443

Em seguida o arspoof foi executado:

sudo arpspoof -i wlan0 -t [ip do celular] -r [ip do gateway]

A seguinte imagem ilustra o ataque realizado:

A "Solução": HTTPS - SSL/TLS

Com o intuito de garantir a confidencialidade dos dados em trânsito e, de validar a autenticidade tanto do servidor quanto do cliente (esta última, opcionalmente), foram concebidas algumas extensões para o protocolo HTTP, as quais normalmente são implementadas através dos protocolos SSL/TLS. Deste modo, a utilização desses protocolos — a qual convencionou-se chamar HTTPS — é indicada para proteger os dados trafegados entre o cliente e o servidor.

Assim como os navegadores, os dispositivos móveis também contém uma grande quantidade de Certificate Authorities (CAs) conhecidas e confiáveis, que garantem através de assinatura de chaves, a autenticidade do host cujo certificado foi assinado por uma destas CAs. Após este handshake a aplicação está apta a criar uma conexão segura para transmitir e receber informações do servidor.

A partir deste momento, o ataque realizado anteriormente não seria mais efetivo contra a aplicação que faz uso de HTTPS, o ataque conseguirá interceptar as requisições, contudo as mesmas estarão cifradas e o proxy não poderá exibir seu conteúdo.

Novo cenário de ataque: Inclusão/instalação de novos certificados + MITM

Ainda que todos os dados sejam trafegados através de HTTPS, os dispositivos móveis possibilitam a inclusão/instalação de novos certificados. Esta possibilidade abre uma brecha para que o atacante utilize novamente a técnica man in the middle.

Para realizar este ataque, o atacante deve seguir os seguintes passos, onde apenas o segundo item difere do ataque anterior:

1 - A vítima e o atacante estão conectados na mesma rede wireless;
2 - O atacante induz a vítima a instalar o certificado malicioso no dispositivo;
3 - A vítima se autentica em uma aplicação insegura (que não faz uso de SSL/TLS);
4 - O atacante realiza o arpspoof;
5 - O tráfego da vitima é direcionado para uma ferramenta de proxy (Burp Suite);
6 - O atacante captura todas as informações enviadas e recebidas pela vítima.

Este ataque é possível, devido ao fato do dispositivo verificar no seu repositório de CAs, se alguma corresponde à chave pública enviada na resposta do servidor, que neste cenário não é o verdadeiro servidor e sim o atacante se passando por ele. Diagrama do ataque:

Neste exemplo, o certificado PortSwigger da ferramenta Burp Suite é enviado a vítima por meio de phishing onde a mesma é induzida a instalá-lo. A seguinte imagem ilustra o certificado devidamente instalado:

Ataque e interceptação dos dados do usuário utilizando uma CA maliciosa (gerada pela ferramenta Burp Suite):

Embora não pareça prático, ataques deste tipo ocorrem com frequência, como podemos ver na seguinte notícia:

Hackers targeting non-browser applications with Fake SSL Certificates

A partir deste momento, nossas requisições irão utilizar o TrustManager implementado que possui nossa chave pública hardcoded e faz as devidas verificações de confiança.

A mitigação: Certificate Pinning

Um dos pontos interessantes do ambiente mobile, é que os desenvolvedores podem novamente escrever aplicativos client-side, assim o mesmo não está mais restrito a generalidade dos navegadores, podendo agora optar por não utilizar a validação dos seus serviços através das CAs pré existentes.

Para garantir que a aplicação confie apenas no certificado do servidor, é utilizado a técnica Certificate Pinning — que consiste em fixar (pinning), na aplicação, o certificado ou a chave pública do servidor e o host associado a ele. Dessa forma, mesmo que existam outros certificados no dispositivo (CAs), o utilizado na conexão sempre será aquele que fora fixado.

Ainda pouco utilizado, o Certificate Pinning é uma técnica fácil de ser implementada. A seguir temos um breve detalhamento de como o pinning foi aplicado na nossa aplicação de exemplo para evitar o MITM:

O pinning pode ser realizado de pelo menos duas formas, adicionado seu certificado na aplicação ou utilizando apenas a chave pública dele fixa no código em formato hexadecimal, esta foi a forma escolhida para a nossa aplicação. Pra facilitar nossa missão, o código disponibilizado como exemplo pela OWASP foi utilizada em nossa aplicação.

O primeiro passo foi criar a classe PubKeyManager que implementa a interface X509TrustManager, que é responsável por realizar as verificações de confiança entre os certificados, e terá nossa chave pública hardcoded. A seguinte imagem ilustra a classe:

O método checkServerTrusted será o responsável por realizar, dentre outras, a verificação das chaves públicas (o pinning de fato!), entre a fixa e a enviada pelo servidor. A seguinte imagem ilustra a verificação implementada:

Para obter a chave pública do nosso host de exemplo, podemos utilizar as seguintes linhas de comando, a primeira com a ferramenta openssl para extrairmos nossa chave pública no formato DER e a segunda para gerar o hexadecimal dessa chave:

openssl s_client -connect exemplo-cert-pinning.herokuapp.com:443 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' 
| openssl x509 -noout -pubkey | openssl rsa -pubin -outform DER > ex-cert-pin.der

xxd -ps ex-cert-pin.der

Uma vez que nossa chave encontra-se devidamente adicionada a classe PubKeyManager, o próximo passo será montar nossa requisição HTTPS utilizando nossa implementação da X509TrustManager. A seguinte imagem ilustra parte do código:

Certificate Pinning Wins!

Repetindo os passos do último cenário de ataque, vamos poder comprovar que o nosso pinning foi efetivo.

1 - A vítima e o atacante estão conectados na mesma rede wireless;
2 - O atacante induz a vítima a instalar o certificado malicioso no dispositivo;
3 - A vítima se autentica em uma aplicação segura (que faz uso de SSL/TLS e Pinning de certificado);
4 - O atacante realiza o arpspoof;
5 - O tráfego da vitima é direcionado para uma ferramenta de proxy (Burp Suite);
6 - A aplicação NÃO consegue realizar o handshake SSL (se conectar com o servidor/atacante);
7 - As informações não são enviadas pela vítima;
8 - O ataque falhou!

A seguinte imagem ilustra o ataque realizado, onde podemos perceber que a aplicação informa ao usuário o problema da verificação do certificado:

O seguinte diagrama apresenta o cenário falho do ataque:

Conclusões

O pinning de certificado não é a solução final para proteger a aplicação contra problemas de MITM. Esta técnica pode ser contornada caso o aparelho esteja rooteado, contudo, a mesma se demonstra bastante eficaz para o cenário de ataque aqui demonstrado. Ainda seguindo a metodologia de segurança em camadas, o pinning é mais um obstáculo para ataques de rede.

A implementação desta técnica pode causar alguns empecilhos operacionais. Caso o processo de implementação não seja bem definido e conhecido, problemas podem vir a ocorrer, por exemplo, caso seja realizado a troca do certificado no servidor e as aplicações não sejam atualizadas com a nova chave, ocorrerá uma falha de conexão (certificado inválido) em todas as aplicações.

Sabendo que grandes CAs (Certificate Authorities) já foram comprometidas no passado, como os casos das gigantes Comodo e DigiNotar, e que os dispositivos mobile possuem dezenas delas, por exemplo o Android possui mais de 100 CAs, o pinning de certificado ou chave pública, nos dá novamente um maior controle sobre a confiabilidade da conexão entre nossas aplicações e o servidor, adicionando uma maior segurança para os dados enviados e recebidos pelos usuários da aplicação.

Referências

Próxima parte

Comentários
Aceita-se formatação à la TWiki. HTML e scripts são filtrados. Máximo 15KiB.

 
Enviando... por favor aguarde...
Comentário enviado com suceso -- obrigado.
Ele aparecerá quando os moderadores o aprovarem.
Houve uma falha no envio do formulário!
Deixei uma nota para os admins verificarem o problema.
Perdoe-nos o transtorno. Por favor tente novamente mais tarde.
Marcelo Pessoa | 2015-03-08 15:53:47 | permalink | topo

Massa Antônio, o post ficou bem didático!

Deixou bem clara a importância da técnica de certificate pinning em aplicações mobile, seja ela para Android, iOS, ou para qualquer outra plataforma.