Ataques MITM em aplicativos móveis — o que são, tipos e proteção contra interceptação

O que é um ataque MITM?

Man-in-the-Middle (MITM) é um tipo de ataque cibernético onde um invasor se insere secretamente em um canal de comunicação entre duas partes. O invasor pode interceptar, ler e modificar os dados transmitidos enquanto permanece invisível para ambas as partes.

Em aplicativos móveis, os ataques MITM são especialmente perigosos porque os dispositivos se conectam constantemente a várias redes — casa, escritório, Wi-Fi público em cafés e aeroportos. Cada mudança de rede cria potencialmente uma janela para ataque. De acordo com o Verizon Mobile Security Index (2025), 43% das organizações já encontraram ataques MITM em dispositivos móveis corporativos pelo menos uma vez.

O principal perigo do MITM é o sigilo: o usuário e o servidor não recebem sinais de interceptação. A sessão parece normal, os dados são transmitidos, não há erros de certificado (se o invasor usar seu próprio certificado). O ataque só pode ser detectado no nível da infraestrutura de rede ou com ferramentas especializadas.

Um desenvolvedor precisa entender os mecanismos dos ataques MITM para projetar proteção no nível do aplicativo, em vez de confiar apenas na segurança da camada de transporte.

Principais tipos de ataques MITM

A classificação dos ataques MITM inclui vários tipos que diferem no método de inserção no canal de comunicação. No desenvolvimento móvel, três tipos são mais relevantes.

ARP Spoofing na rede local

ARP Spoofing é uma técnica onde o invasor envia pacotes ARP falsos para a rede local, associando seu endereço MAC ao endereço IP do gateway. Depois disso, todo o tráfego da vítima é roteado através do dispositivo do invasor, que o encaminha para o gateway enquanto permanece invisível.

Ferramentas como Ettercap ou BetterCAP são suficientes para realizar o ataque, pois automatizam o ARP spoofing. O ataque só é possível dentro de uma única sub-rede, tornando os usuários de redes Wi-Fi públicas os mais vulneráveis. Redes modernas com Dynamic ARP Inspection (DAI) em switches gerenciados bloqueiam este tipo de ataque.

A proteção no nível do aplicativo contra ARP Spoofing é impossível — isso é um problema de infraestrutura de rede. No entanto, o aplicativo pode detectar anomalias na conectividade de rede usando bibliotecas como TrustKit para iOS ou Network Security Config para Android.

DNS Spoofing e interceptação de tráfego

DNS Spoofing (ou envenenamento de cache DNS) é a substituição de registros DNS no caminho do cliente para o servidor DNS. O invasor intercepta a solicitação DNS do aplicativo e retorna um endereço IP falso, redirecionando o tráfego para seu servidor em vez do legítimo.

O ataque é especialmente eficaz em redes públicas onde o servidor DNS é atribuído automaticamente via DHCP. O invasor pode configurar seu próprio servidor DNS que retorna endereços IP falsificados para domínios alvo. O usuário vê uma URL legítima no navegador, mas se conecta ao servidor do invasor.

A proteção contra DNS Spoofing no lado do aplicativo é implementada através de DNS-over-HTTPS (DoH) ou DNS-over-TLS (DoT), que criptografam as consultas DNS. Android 9+ e iOS 14+ suportam DoH em nível de sistema, e o aplicativo pode ativar explicitamente esta opção.

SSL Stripping — bypass de HTTPS

SSL Stripping é um ataque onde o invasor rebaixa uma conexão HTTPS segura para HTTP não seguro. A técnica explora o fato de que muitos usuários digitam manualmente example.com em vez de https://example.com, e a primeira conexão é estabelecida via HTTP.

Ferramentas como sslstrip (Moxie Marlinspike, 2009) e bettercap interceptam automaticamente solicitações HTTP, estabelecem uma conexão HTTPS com o servidor em seu nome e passam o tráfego descriptografado para o cliente via HTTP. O navegador não mostra o ícone de cadeado — o usuário não sabe que a conexão não é segura.

Proteção moderna — HTTP Strict Transport Security (HSTS): o servidor informa ao navegador que todas as conexões futuras devem usar apenas HTTPS. A lista de pré-carregamento HSTS protege adicionalmente contra o primeiro ataque, mas requer registro prévio do domínio.

Como um ataque MITM funciona em aplicativos móveis

Um ataque MITM típico em um aplicativo móvel passa por quatro estágios. Cada estágio explora diferentes vulnerabilidades, e a proteção completa requer cobrir todos os vetores.

O primeiro estágio é a inserção: o invasor se coloca no caminho do tráfego entre o dispositivo e o servidor. Isso pode ser ARP Spoofing na rede local, um ponto de acesso Wi-Fi falso (Evil Twin) ou comprometimento do servidor DNS do provedor. Dispositivos móveis são especialmente vulneráveis ao se conectar automaticamente a redes abertas.

O segundo estágio é a interceptação: após a inserção, o invasor começa a ler todos os pacotes trocados entre o aplicativo e o servidor. Neste estágio, ele coleta metadados: URLs de solicitações, tamanhos de pacotes, cookies, cabeçalhos. Mesmo que os dados estejam criptografados, os metadados podem revelar a estrutura do aplicativo e a lógica de negócios.

O terceiro estágio é a descriptografia (se o tráfego estiver criptografado): o invasor estabelece duas conexões TLS — uma com o servidor (usando um certificado falsificado), outra com o cliente. O aplicativo considera a conexão segura, mas o invasor vê todos os dados em texto claro. Sem Certificate Pinning, isso funciona para qualquer certificado instalado no armazenamento do sistema.

O quarto estágio é a modificação e exfiltração: o invasor pode não apenas ler, mas também modificar os dados transmitidos. Em aplicativos financeiros, isso pode significar alterar o número da conta do destinatário; em solicitações de API, modificar parâmetros de autorização. iOS e Android recomendam implementar verificações de integridade de respostas no nível do aplicativo.

Exemplos de código: proteção contra interceptação no Android e iOS

Vamos ver exemplos práticos de proteção contra ataques MITM usando Certificate Pinning em Kotlin e Swift. Estes exemplos bloqueiam a substituição de certificados mesmo se o armazenamento do sistema estiver comprometido.

Certificate Pinning no Android (OkHttp)

OkHttp é a biblioteca HTTP padrão para Android que suporta CertificatePinner. Especifique o hash SHA-256 do certificado do seu servidor — quaisquer outros certificados serão rejeitados.

import okhttp3.CertificatePinner
import okhttp3.OkHttpClient

val certificatePinner = CertificatePinner.Builder()
    .add(
        "api.example.com",
        "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="
    )
    .build()

val client = OkHttpClient.Builder()
    .certificatePinner(certificatePinner)
    .build()

Certificate Pinning no iOS (URLSession)

No iOS, use URLSessionDelegate para verificar manualmente o certificado do servidor. Compare o SecCertificateRef com uma cópia armazenada localmente.

class SessionDelegate: NSObject, URLSessionDelegate {
    func urlSession(
        _ session: URLSession,
        didReceive challenge: URLAuthenticationChallenge,
        completionHandler: @escaping (
            URLSession.AuthChallengeDisposition,
            URLCredential?
        ) -> Void
    ) {
        guard let serverTrust = challenge.protectionSpace
            .serverTrust else { return }

        let pinnedCert = SecCertificateCreateWithData(
            nil,
            pinnedCertData as CFData
        )

        let serverCerts = (0..<SecTrustGetCertificateCount(serverTrust))
            .compactMap { SecTrustGetCertificateAtIndex(serverTrust, $0) }

        if serverCerts.contains { CFEqual($0, pinnedCert) } {
            completionHandler(.useCredential, URLCredential(trust: serverTrust))
        } else {
            completionHandler(.cancelAuthenticationChallenge, nil)
        }
    }
}

Network Security Config no Android

O Android suporta proteção declarativa através do arquivo network_security_config.xml, que bloqueia o tráfego no nível do SO sem escrever código.

<!-- network_security_config.xml -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-07-01">
            <pin digest="SHA-256">AAAAAAAAAAAAAAAAAAAAAAAAAAAA</pin>
        </pin-set>
    </domain-config>
</network-security-config>

Métodos de proteção de aplicativos móveis contra MITM

A proteção abrangente contra ataques MITM inclui medidas nos níveis de aplicativo, servidor e infraestrutura de rede. Abaixo estão as principais recomendações para Android e iOS.

Use Certificate Pinning — vinculação do certificado do servidor no código do aplicativo. Ao contrário da verificação TLS padrão, que confia em qualquer certificado do armazenamento do sistema, o Certificate Pinning verifica um certificado específico ou sua chave pública. OkHttp no Android e TrustKit no iOS fornecem implementações prontas deste mecanismo.

Imponha HTTPS e HSTS: todas as solicitações de rede devem passar por HTTPS, e o servidor deve retornar o cabeçalho Strict-Transport-Security. Para Android, adicione android:usesCleartextTraffic="false" ao manifesto — isso bloqueia conexões HTTP no nível do SO. iOS bloqueia HTTP por padrão desde o iOS 9 através do App Transport Security (ATS).

Implemente verificações de integridade de respostas: assine as respostas do servidor com uma assinatura digital que o aplicativo verifica. Mesmo que um invasor intercepte o tráfego HTTPS (através de um proxy com reinstalação de certificado), ele não pode forjar a assinatura sem a chave privada do servidor. Use JWT com assinaturas RS256 ou HMAC para operações críticas.

No lado do servidor, ative o HTTP Public Key Pinning (HPKP) — uma diretiva que informa ao navegador ou aplicativo qual certificado considerar válido para um determinado domínio. No entanto, o HPKP requer cautela: configuração incorreta pode bloquear o acesso ao aplicativo por um longo período. O Google recomenda usar HPKP apenas em combinação com certificados de backup.

De acordo com NIST SP 800-52 Rev. 2 (2024), a combinação de TLS 1.3, Certificate Pinning e HSTS elimina 99% dos vetores de ataque MITM conhecidos em aplicativos móveis. Recomenda-se que os desenvolvedores testem a proteção com ferramentas como mitmproxy antes de publicar o aplicativo.