Certificate ou Public Key Pinning
Por Eder Souza
Com a larga adoção da arquitetura web na oferta de ferramentas e serviços para empresas e usuários, surgiu uma grande preocupação que é a interceptação de informações sensíveis enviadas e recebidas por essas ferramentas.
Essa preocupação é decorrente da possibilidade de interceptar as informações mesmo elas sendo enviadas através de uma conexão criptografada utilizando certificados digitais SSL.
A técnica adotada para essa interceptação se chamada MITM (Man in the middle) e utiliza um equipamento que fica posicionado entre o servidor da aplicação e o cliente, com o objetivo de capturar todo o tráfego de dados transmitido entre eles.
Esse equipamento recebe todas as solicitações por parte do cliente e no momento em que é solicitado uma conexão ao servidor de aplicação, esse equipamento intercepta essa solicitação e estabelece essa conexão com o servidor, passando a encaminhar todos os pedidos do cliente a esse servidor e recebendo todas as respostas.
Na outra ponta, o equipamento estabelece a comunicação com o cliente, se passando pelo servidor da aplicação, e encaminha todas as respostas a esse cliente, que não percebe a existência desse equipamento no meio da conexão. A Figura 1, deixa claro como esse esquema funciona.
Segundo a Figura 1, o equipamento do atacante está entre a conexão, inspecionando todos os pacotes enviados e recebidos pelo cliente, mas como isso funcionaria em uma conexão utilizando certificados digitais SSL?
Em teoria, quando o servidor de aplicação utiliza um certificado digital SSL a primeira fase para o estabelecimento de uma conexão entre cliente e servidor é a verificação da autenticação do servidor, que acontece através da validação do seu certificado digital.
Assim, durantes os primeiros passos no estabelecimento da conexão (handshake SSL) e junto com diversas informações enviadas, como por exemplo o conjunto de cifras suportados, o servidor também envia o seu certificado digital SSL.
O cliente, assim que recebe esse certificado, verifica as informações contidas com o objetivo de garantir a identidade do serviço acessado, como por exemplo, o endereço web presente no atributo “Common Name” existente no campo “Subject” do Certificado Digital. A url presente nesse atributo deve ser exatamente a mesma utilizada para efetuar a conexão com o serviço.
Além da validação da url e da data de validade do certificado digital SSL, duas outras verificações fundamentais para garantir a segurança na conexão são efetuadas, a verificação do estado de revogação e a cadeia de confiança.
Para o estado de revogação do certificado digital são utilizados protocolos como a lista de certificados revogados (LCR) ou o Online Certificate Status Protocol (OCSP), onde o cliente consegue identificar se o certificado digital foi revogado pelo seu responsável, não sendo mais possível confiar no certificado apresentado e consequentemente no serviço onde a conexão foi estabelecida.
A Figura 2 tem como objetivo apresentar os detalhes referente ao estabelecimento e uma conexão utilizando os protocolos SSL/TLS.
A outra verificação diz respeito a confiabilidade do certificado digital e envolve conhecer o emissor do certificado digital SSL e reconhecer seus processos para emissão e manutenção dos certificados emitidos.
Na prática essa validação envolve verificar qual foi a AC (Autoridade Certificadora) que emitiu o certificado digital SSL que está vendo avaliado e se o certificado digital desta AC está inserido no repositório de certificados das ACs confiáveis para o cliente.
Com essa última verificação, só deveriam ser aceitos os certificados digitais de serviços que foram emitidos por ACs que possuem seus certificados instalados no sistema do cliente e o repositório de chaves do cliente é fundamental para garantir a autenticidade do serviço e segurança da conexão.
A questão agora é que o ataque de MITM sofreu uma sofisticação e existem diversas ferramentas que já permitem a intercepção desses dados, mesmo com a utilização de uma conexão autenticada e cifrada.
O ataque segue um procedimento bem definido e utiliza essa confiança baseada nesse repositório local e na cadeia de confiança para atacar o cliente.
Na primeira etapa, o atacante precisa criar uma AC e instalar o certificado desta AC no ambiente do cliente com o objetivo de fazer com que esse ambiente passe a confiar em qualquer certificado digital emitido por essa AC maliciosa.
Para obter sucesso nessa etapa, o atacante usa técnicas variadas envolvendo engenharia social e utilização de códigos e pacotes maliciosos e em um momento de descuido ou distração do usuário o certificado malicioso é instalado.
Após essa instalação, qualquer certificado emitido por essa AC maliciosa passa a ser considerado confiável pelo sistema do cliente e agora o atacante precisa somente se posicionar entre o ambiente do cliente e o servidor de aplicação para, em tempo real, emitir os certificados digitais referentes aos sites acessados.
Utilizando essa técnica e tendo a AC maliciosa instalada no ambiente do cliente, o atacante conseguirá se passar por uma entidade confiável e assim, o cliente acreditará que está realmente acessando o servidor da aplicação destino.
Existem diversas ferramentas que permitem esse tipo de ataque, como o SSLSTRIP[1] ou o SSLSPLIT[2] e todas elas permitem a geração e uso de uma AC com a possibilidade de emitir certificados digitais SSL em tempo real e que, aliadas a ferramentas de ataque do tipo Arp Spoofing[3] podem trazer um grande poder ao atacante.
O propósito do Public Key Pinning é combater essas técnicas de MITM através da identificação da mudança da chave pública existente em um certificado emitido para determinado domínio. Com a adoção do pinning, o cliente, além de verificar as informações do certificado digital enviado pelo serviço, também verifica se a chave pública existente no certificado confere com a esperada para esse domínio e se não conferir, uma mensagem alertando sobre os riscos pode ser exibida ao usuário.
Ambientes compatíveis com o Public Key Pinning, segundo a RFC-‐7469[4], possuem localmente armazenados a URL do serviço e o SPKI fingerprint, que é o resultado SHA-‐256 da chave pública existente em cada certificado digital da cadeia de confiança, iniciando pelo certificado do serviço e indo até o certificado raiz ou âncora de confiança.
Desta forma, em um acesso a determinado serviço web, o ambiente do cliente pode validar esse hash contra cada certificado da cadeia e se um deles falhar, uma mensagem é exibida ao cliente e o acesso é imediatamente interrompido.
Para os serviços web que não possuem essas informações presentes, a verificação será executada na forma tradicional, sendo validade, revogação e cadeia de confiança os critérios de avaliação sobre a confiabilidade do acesso.
Diversos browsers já implementaram o Certificate Pinning, como por exemplo o Firefox[5], que iniciou a implementação na versão 32 e protegendo inicialmente endereços como, www.twitter.com, *.addons.mozilla.org, *.cdn.mozilla.org entre outros.
Ainda no Firefox, o próprio usuário pode controlar o comportamento da nova funcionalidade e para isso é só digitar na barra de endereços about:config e quando a janela de configurações avançadas for apresentada é necessário localizar o atributo security.cert_pinning.enforcement_level onde os valores previstos são:
- Pinning desabilitado;
- Permite o MITM (o pinning não é habilitado para as ACs raízes inseridas pelo usuário);
- Pinning sempre habilitado;
- Modo de teste.
Já o Google implementou a funcionalidade a partir do Chrome versão 13 e em 2011, através dessa funcionalidade foi descoberto um ataque[6] contra seus usuários, principalmente os localizados no Irã.
Assim, o Certificate Pinning está se tornando uma importante ferramenta no combate aos ataques de interceptação e permitindo a utilização da internet para o tráfego de informações realmente sensíveis. Se a sua empresa está pensando em desenvolver aplicativos para dispositivos móveis ou qualquer ferramenta web, utilizar a técnica de Certificate Pinning pode livrar a empresa de grandes dores de cabeça com a segurança dos dados.
É isso e até a próxima!
[1] http://www.thoughtcrime.org/software/sslstrip/
[2]https://www.roe.ch/SSLsplit [3]https://github.com/byt3bl33d3r/arpspoof
[4] https://tools.ietf.org/html/rfc7469#section-‐2.4
[5]https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning#Implementation_status
[6]http://googleonlinesecurity.blogspot.com.br/2011/08/update-‐on-‐attempted-‐man-‐in-‐ middle.html
- Mestre em Engenharia de Software pelo IPT-SP, com MBA em Gestão Empresarial pela FGV e especialização em Segurança da Informação pelo IBTA e bacharel em Ciências da Computação pela FAC-FITO.
- Professor do curso de Segurança da Informação do Instituto Brasileiro de Tecnologia Avançada e responsável pelo tema Criptografia e Certificação Digital.
- Atua há quinze anos na área de Tecnologia e Segurança da Informação e atualmente é Diretor Técnico na e-Safer Consultoria.
- Vivência no desenvolvimento de produtos e implantação de soluções de Segurança e Certificação Digital em empresas de grande porte.
- Eder é colunista e membro do conselho editorial do Instituto CryptoID.
Leia outros artigos do Colunista Eder Souza. aqui!
Fale com o Eder por meio dos cometários do site ou se preferir escreva diretamente para ele.
email esouza@e-safer.com.br