Skip to content

Comunicação de Rede em Aplicativos Móveis

Quase todo aplicativo móvel conectado à rede depende do Protocolo de Transferência de Hipertexto (HTTP) ou de sua versão segura, HTTPS (que usa a Segurança da Camada de Transporte, TLS), para trocar dados com endpoints remotos. Se não for implementada de forma segura, essa comunicação pode ser vulnerável a ataques baseados em rede, como sniffing de pacotes e ataques de Máquina no Meio (MITM). Neste capítulo, exploramos possíveis vulnerabilidades, técnicas de teste e práticas recomendadas para proteger a comunicação de rede de aplicativos móveis.

Conexões Seguras

Já passou o tempo em que era razoável usar apenas HTTP em texto claro, e geralmente é trivial proteger conexões HTTP usando HTTPS. O HTTPS é essencialmente HTTP sobreposto a outro protocolo conhecido como Segurança da Camada de Transporte (TLS). O TLS realiza um handshake usando criptografia de chave pública e, quando concluído, cria uma conexão segura.

Uma conexão HTTPS é considerada segura devido a três propriedades:

  • Confidencialidade: o TLS criptografa os dados antes de enviá-los pela rede, o que significa que eles não podem ser lidos por um intermediário.
  • Integridade: os dados não podem ser alterados sem detecção.
  • Autenticação: o cliente pode validar a identidade do servidor para garantir que a conexão seja estabelecida com o servidor correto.

Avaliação de Confiança do Servidor

As Autoridades de Certificação (CAs) são parte integrante de uma comunicação segura entre cliente e servidor e são predefinidas no armazenamento de confiança de cada sistema operacional. Por exemplo, no iOS, há mais de 200 certificados raiz instalados (consulte Documentação da Apple - Certificados raiz confiáveis disponíveis para sistemas operacionais Apple).

As CAs podem ser adicionadas ao armazenamento de confiança, seja manualmente pelo usuário, por um MDM que gerencia o dispositivo corporativo ou por meio de malware. A questão então é: "você pode confiar em todas essas CAs e seu aplicativo deve depender do armazenamento de confiança padrão?". Afinal, há casos bem conhecidos em que autoridades de certificação foram comprometidas ou enganadas para emitir certificados para impostores. Uma linha do tempo detalhada de violações e falhas de CAs pode ser encontrada em sslmate.com.

Tanto o Android quanto o iOS permitem que o usuário instale CAs adicionais ou âncoras de confiança.

Um aplicativo pode querer confiar em um conjunto personalizado de CAs em vez do padrão da plataforma. Os motivos mais comuns para isso são:

  • Conectar-se a um host com uma autoridade de certificação personalizada (uma CA que ainda não é conhecida ou confiável pelo sistema), como uma CA autoassinada ou emitida internamente em uma empresa.
  • Limitar o conjunto de CAs a uma lista específica de CAs confiáveis.
  • Confiar em CAs adicionais não incluídas no sistema.

Sobre Armazenamentos de Confiança

Estendendo a Confiança

Sempre que o aplicativo se conectar a um servidor cujo certificado seja autoassinado ou desconhecido pelo sistema, a conexão segura falhará. Esse é normalmente o caso de CAs não públicas, por exemplo, aquelas emitidas por uma organização, como um governo, corporação ou instituição de ensino, para seu próprio uso.

Tanto o Android quanto o iOS oferecem meios para estender a confiança, ou seja, incluir CAs adicionais para que o aplicativo confie nas CAs internas do sistema mais as personalizadas.

No entanto, lembre-se de que os usuários do dispositivo sempre podem incluir CAs adicionais. Portanto, dependendo do modelo de ameaça do aplicativo, pode ser necessário evitar confiar em quaisquer certificados adicionados ao armazenamento de confiança do usuário ou até ir além e confiar apenas em um certificado ou conjunto de certificados específico predefinido.

Para muitos aplicativos, o "comportamento padrão" fornecido pela plataforma móvel será seguro o suficiente para seu caso de uso (no raro caso de uma CA confiável pelo sistema ser comprometida, os dados manipulados pelo aplicativo não são considerados sensíveis ou outras medidas de segurança são tomadas que são resilientes mesmo a tal violação de CA). No entanto, para outros aplicativos, como aplicativos financeiros ou de saúde, o risco de uma violação de CA, mesmo que raro, deve ser considerado.

Restringindo a Confiança: Fixação de Identidade

Alguns aplicativos podem precisar aumentar ainda mais sua segurança, restringindo o número de CAs em que confiam. Normalmente, apenas as CAs usadas pelo desenvolvedor são explicitamente confiáveis, enquanto todas as outras são desconsideradas. Essa restrição de confiança é conhecida como Fixação de Identidade, geralmente implementada como Fixação de Certificado ou Fixação de Chave Pública.

No OWASP MASTG, nos referiremos a esse termo como "Fixação de Identidade", "Fixação de Certificado", "Fixação de Chave Pública" ou simplesmente "Pinning".

A fixação é o processo de associar um endpoint remoto a uma identidade específica, como um certificado X.509 ou chave pública, em vez de aceitar qualquer certificado assinado por uma CA confiável. Após fixar a identidade do servidor (ou um determinado conjunto, também conhecido como pinset), o aplicativo móvel subsequentemente se conectará a esses endpoints remotos somente se a identidade corresponder. Retirar a confiança de CAs desnecessárias reduz a superfície de ataque do aplicativo.

Diretrizes Gerais

A OWASP Certificate Pinning Cheat Sheet fornece orientações essenciais sobre:

  • quando a fixação é recomendada e quais exceções podem se aplicar.
  • quando fixar: no tempo de desenvolvimento (pré-carregamento) ou no primeiro encontro (confiança no primeiro uso).
  • o que fixar: certificado, chave pública ou hash.

As recomendações tanto do Android quanto do iOS correspondem ao "melhor caso", que é:

  • Fixar apenas em endpoints remotos onde o desenvolvedor tem controle.
  • no tempo de desenvolvimento via (NSC/ATS)
  • fixar um hash do SPKI subjectPublicKeyInfo.

A fixação ganhou uma má reputação desde sua introdução há vários anos. Gostaríamos de esclarecer alguns pontos que são válidos, pelo menos, para a segurança de aplicativos móveis:

  • A má reputação deve-se a razões operacionais (por exemplo, complexidade de implementação/gerenciamento de pin) e não à falta de segurança.
  • Se um aplicativo não implementar a fixação, isso não deve ser relatado como uma vulnerabilidade. No entanto, se o aplicativo deve verificar contra MAS-L2, ele deve ser implementado.
  • Tanto o Android quanto o iOS tornam a implementação da fixação muito fácil e seguem as melhores práticas.
  • A fixação protege contra uma CA comprometida ou uma CA maliciosa instalada no dispositivo. Nesses casos, a fixação impedirá que o sistema operacional estabeleça uma conexão segura com um servidor malicioso. No entanto, se um invasor tiver controle do dispositivo, ele pode facilmente desativar qualquer lógica de fixação e, assim, ainda permitir que a conexão aconteça. Como resultado, isso não impedirá um invasor de acessar seu backend e abusar de vulnerabilidades do lado do servidor.
  • A fixação em aplicativos móveis não é a mesma que a Fixação de Chave Pública HTTP (HPKP). O cabeçalho HPKP não é mais recomendado em sites, pois pode levar os usuários a ficarem bloqueados no site sem qualquer maneira de reverter o bloqueio. Para aplicativos móveis, isso não é um problema, pois o aplicativo sempre pode ser atualizado por meio de um canal fora de banda (ou seja, a loja de aplicativos) caso haja problemas.

Sobre as Recomendações de Fixação em Android Developers

O site Android Developers inclui o seguinte aviso:

Cuidado: A Fixação de Certificado não é recomendada para aplicativos Android devido ao alto risco de futuras alterações na configuração do servidor, como mudar para outra Autoridade de Certificação, tornando o aplicativo incapaz de se conectar ao servidor sem receber uma atualização de software do cliente.

Eles também incluem esta observação:

Observe que, ao usar a fixação de certificado, você deve sempre incluir uma chave de backup para que, se for forçado a mudar para novas chaves ou alterar CAs (ao fixar em um certificado de CA ou um intermediário dessa CA), a conectividade do seu aplicativo não seja afetada. Caso contrário, você deve enviar uma atualização para o aplicativo para restaurar a conectividade.

A primeira declaração pode ser interpretada erroneamente como dizendo que eles "não recomendam a fixação de certificado". A segunda declaração esclarece isso: a recomendação real é que, se os desenvolvedores quiserem implementar a fixação, eles devem tomar as precauções necessárias.

Sobre as Recomendações de Fixação em Apple Developers

A Apple recomenda pensar a longo prazo e criar uma estratégia adequada de autenticação de servidor.

Recomendação do OWASP MASTG

A fixação é uma prática recomendada, especialmente para aplicativos MAS-L2. No entanto, os desenvolvedores devem implementá-la exclusivamente para os endpoints sob seu controle e ter certeza de incluir chaves de backup (também conhecidas como pins de backup) e ter uma estratégia adequada de atualização do aplicativo.

Saiba mais

Verificando as Configurações TLS

Uma das funções principais do aplicativo móvel é enviar/receber dados por redes não confiáveis, como a Internet. Se os dados não estiverem adequadamente protegidos em trânsito, um invasor com acesso a qualquer parte da infraestrutura de rede (por exemplo, um ponto de acesso Wi-Fi) pode interceptar, ler ou modificá-los. É por isso que protocolos de rede em texto claro raramente são aconselháveis.

A grande maioria dos aplicativos depende do HTTP para comunicação com o backend. O HTTPS encapsula o HTTP em uma conexão criptografada (o acrônimo HTTPS originalmente se referia a HTTP sobre Secure Socket Layer (SSL); o SSL é o predecessor obsoleto do TLS). O TLS permite a autenticação do serviço de backend e garante a confidencialidade e integridade dos dados de rede.

Configurações TLS Recomendadas

Garantir a configuração TLS adequada no lado do servidor também é importante. O protocolo SSL está obsoleto e não deve mais ser usado. Além disso, o TLS v1.0 e o TLS v1.1 têm vulnerabilidades conhecidas e seu uso foi descontinuado em todos os principais navegadores até 2020. O TLS v1.2 e o TLS v1.3 são considerados a melhor prática para transmissão segura de dados. A partir do Android 10 (nível de API 29), o TLS v1.3 será habilitado por padrão para comunicação mais rápida e segura. A mudança principal com o TLS v1.3 é que a personalização de suites de cifra não é mais possível e todas elas são habilitadas quando o TLS v1.3 está habilitado, enquanto o modo Zero Round Trip (0-RTT) não é suportado.

Quando tanto o cliente quanto o servidor são controlados pela mesma organização e usados apenas para comunicação entre si, você pode aumentar a segurança reforçando a configuração.

Se um aplicativo móvel se conecta a um servidor específico, sua pilha de rede pode ser ajustada para garantir o mais alto nível de segurança possível para a configuração do servidor. A falta de suporte no sistema operacional subjacente pode forçar o aplicativo móvel a usar uma configuração mais fraca.

Terminologia de Suites de Cifra

As suites de cifra têm a seguinte estrutura:

Protocol_KeyExchangeAlgorithm_WITH_BlockCipher_IntegrityCheckAlgorithm

Essa estrutura inclui:

  • Um Protocolo usado pela cifra
  • Um Algoritmo de Troca de Chaves usado pelo servidor e pelo cliente para autenticação durante o handshake TLS
  • Uma Cifra de Bloco usada para criptografar o fluxo de mensagens
  • Um Algoritmo de Verificação de Integridade usado para autenticar mensagens

Exemplo: TLS_RSA_WITH_3DES_EDE_CBC_SHA

No exemplo acima, a suite de cifra usa:

  • TLS como protocolo
  • Criptografia assimétrica RSA para autenticação
  • 3DES para criptografia simétrica com modo EDE_CBC
  • Algoritmo de hash SHA para integridade

Observe que no TLSv1.3 o Algoritmo de Troca de Chaves não faz parte da suite de cifra, em vez disso, é determinado durante o handshake TLS.

Na listagem a seguir, apresentaremos os diferentes algoritmos de cada parte da suite de cifra.

Protocolos:

Algoritmos de Troca de Chaves:

Cifras de Bloco:

Algoritmos de Verificação de Integridade:

Observe que a eficiência de uma suite de cifra depende da eficiência de seus algoritmos.

Os seguintes recursos contêm as suites de cifra recomendadas mais recentes para uso com TLS:

Algumas versões do Android e iOS não suportam algumas das suites de cifra recomendadas, portanto, para fins de compatibilidade, você pode verificar as suites de cifra suportadas para versões do Android e iOS e escolher as suites de cifra suportadas mais altas.

Se você quiser verificar se seu servidor suporta as suites de cifra corretas, há várias ferramentas que pode usar:

  • nscurl - consulte Comunicação de Rede iOS para mais detalhes.
  • testssl.sh que "é uma ferramenta gratuita de linha de comando que verifica o serviço de um servidor em qualquer porta para o suporte de cifras TLS/SSL, protocolos, bem como algumas falhas criptográficas".

Finalmente, verifique se o servidor ou proxy de terminação no qual a conexão HTTPS termina está configurado de acordo com as melhores práticas. Veja também a OWASP Transport Layer Protection cheat sheet e as Qualys SSL/TLS Deployment Best Practices.

Interceptando o Tráfego de Rede por MITM

Interceptar o tráfego de aplicativos móveis é um aspecto crítico do teste de segurança, permitindo que testadores, analistas ou pentesters analisem e manipulem as comunicações de rede para identificar vulnerabilidades. Uma técnica-chave nesse processo é o ataque de Máquina no Meio (MITM) (também conhecido como "Homem no Meio" (tradicionalmente), "Adversário no Meio" (por exemplo, por MITRE e CAPEC), etc.), onde o invasor posiciona sua máquina entre duas entidades em comunicação, normalmente o aplicativo móvel (cliente) e os servidores com os quais está se comunicando. Ao fazer isso, a máquina do invasor intercepta e monitora os dados que estão sendo transmitidos entre as diferentes partes.

Essa técnica é dupla:

  • Normalmente usada por invasores maliciosos para interceptar, monitorar e potencialmente alterar a comunicação sem que nenhuma das partes (aplicativo ou servidor) esteja ciente. Isso permite atividades maliciosas, como espionagem, injeção de conteúdo malicioso ou manipulação dos dados que estão sendo trocados.
  • No entanto, no contexto do OWASP MASTG e do teste de segurança de aplicativos móveis, usamos isso como parte de nossas técnicas para permitir que o testador do aplicativo revise, analise ou modifique o tráfego para identificar vulnerabilidades, como comunicação não criptografada ou controles de segurança fracos.

O método de interceptação específico usado depende dos mecanismos de segurança do aplicativo e da natureza dos dados que estão sendo transmitidos. Cada abordagem varia em complexidade e eficácia, dependendo de fatores como criptografia e a capacidade do aplicativo de resistir à interferência.

Aqui está uma visão geral das técnicas de interceptação em diferentes camadas de rede:

Técnica de Interceptação Ferramentas de Exemplo Observação
API hooking (HttpUrlConnection, NSURLSession, WebRequest) Frida Modifica como os aplicativos lidam com solicitações de rede.
Hooking de funções TLS (SSL_read, SSL_write) Frida, SSL Kill Switch Intercepta dados criptografados antes que cheguem ao aplicativo.
Interceptação por proxy Burp Suite, ZAP, mitmproxy Requer que o aplicativo respeite as configurações de proxy.
Sniffing de pacotes tcpdump, Wireshark Captura todo o tráfego TCP/UDP, mas não descriptografa HTTPS.
MITM via ARP spoofing bettercap Engana os dispositivos para enviarem seu tráfego pela máquina do invasor, mesmo quando a rede não é controlada pelo invasor.
AP Wi-Fi Rogue hostapd, dnsmasq, iptables, wpa_supplicant, airmon-ng Usa um ponto de acesso totalmente controlado pelo invasor.

Você pode encontrar mais informações sobre essas técnicas em suas páginas de técnica correspondentes:

Observação sobre fixação de certificado: Se o aplicativo usar fixação de certificado, as técnicas acima podem parecer falhar assim que você começar a interceptar o tráfego, mas você pode contorná-la usando métodos diferentes. Consulte as seguintes técnicas para obter mais informações: