Skip to content

MASTG-TEST-0068: Teste de Armazenamentos de Certificados Personalizados e Certificate Pinning

Visão Geral

Análise Estática

Verifique se o certificado do servidor está fixado (pinned). A fixação pode ser implementada em vários níveis em relação à árvore de certificados apresentada pelo servidor:

  1. Incluir o certificado do servidor no pacote do aplicativo e realizar a verificação em cada conexão. Isso requer um mecanismo de atualização sempre que o certificado no servidor for atualizado.
  2. Limitar o emissor do certificado a, por exemplo, uma única entidade e incluir a chave pública da CA intermediária no aplicativo. Dessa forma, limitamos a superfície de ataque e temos um certificado válido.
  3. Possuir e gerenciar sua própria PKI. O aplicativo conteria a chave pública da CA intermediária. Isso evita a atualização do aplicativo sempre que você alterar o certificado no servidor, devido a, por exemplo, expiração. Observe que o uso de sua própria CA faria com que o certificado fosse autoassinado (self-signed).

A abordagem mais recente recomendada pela Apple é especificar uma chave pública de CA fixada no arquivo Info.plist em Configurações de Segurança de Transporte de Aplicativo. Você pode encontrar um exemplo em seu artigo Identity Pinning: How to configure server certificates for your app.

Outra abordagem comum é usar o método connection:willSendRequestForAuthenticationChallenge: do NSURLConnectionDelegate para verificar se o certificado fornecido pelo servidor é válido e corresponde ao certificado armazenado no aplicativo. Você pode encontrar mais detalhes na nota técnica HTTPS Server Trust Evaluation.

As seguintes bibliotecas de terceiros incluem funcionalidade de fixação:

  • TrustKit: aqui você pode fixar definindo os hashes de chave pública no seu Info.plist ou fornecer os hashes em um dicionário. Consulte o README para mais detalhes.
  • AlamoFire: aqui você pode definir um ServerTrustPolicy por domínio, para o qual pode definir um PinnedCertificatesTrustEvaluator. Consulte a documentação para mais detalhes.
  • AFNetworking: aqui você pode definir um AFSecurityPolicy para configurar sua fixação.

Análise Dinâmica

Fixação de certificado do servidor

Siga as instruções da seção de Análise Dinâmica do Teste de Verificação de Identidade de Endpoint. Se isso não resultar no tráfego sendo intermediado (proxied), pode significar que a fixação de certificado está realmente implementada e todas as medidas de segurança estão em vigor. O mesmo acontece para todos os domínios?

Como um teste rápido (smoke test), você pode tentar contornar a fixação de certificado usando objection, conforme descrito em Contornando Certificate Pinning. As APIs relacionadas à fixação que estão sendo interceptadas (hooked) pelo objection devem aparecer na saída do objection.

No entanto, tenha em mente que:

  • as APIs podem não estar completas.
  • se nada for interceptado, isso não significa necessariamente que o aplicativo não implementa fixação.

Em ambos os casos, o aplicativo ou alguns de seus componentes podem implementar fixação personalizada de uma forma que é suportada pelo objection. Consulte a seção de análise estática para indicadores específicos de fixação e testes mais aprofundados.

Validação de certificado do cliente

Alguns aplicativos usam mTLS (TLS mútuo), o que significa que o aplicativo verifica o certificado do servidor e o servidor verifica o certificado do cliente. Você pode perceber isso se houver um erro na guia Alerts do Burp indicando que o cliente falhou na negociação da conexão.

Há algumas coisas importantes a observar:

  1. O certificado do cliente contém uma chave privada que será usada para a troca de chaves.
  2. Geralmente, o certificado também precisaria de uma senha para usá-lo (descriptografá-lo).
  3. O certificado pode ser armazenado no próprio binário, no diretório de dados ou no Keychain.

A maneira mais comum e inadequada de usar mTLS é armazenar o certificado do cliente dentro do pacote do aplicativo e codificar a senha. Isso obviamente não traz muita segurança, porque todos os clientes compartilharão o mesmo certificado.

A segunda maneira de armazenar o certificado (e possivelmente a senha) é usar o Keychain. Após o primeiro login, o aplicativo deve baixar o certificado pessoal e armazená-lo com segurança no Keychain.

Às vezes, os aplicativos têm um certificado que é codificado e o usam para o primeiro login, e então o certificado pessoal é baixado. Nesse caso, verifique se ainda é possível usar o certificado "genérico" para se conectar ao servidor.

Depois de extrair o certificado do aplicativo (por exemplo, usando Frida), adicione-o como certificado do cliente no Burp e você poderá interceptar o tráfego.