Ataques MITM en aplicaciones móviles — qué son, tipos y protección contra la interceptación

¿Qué es un ataque MITM?

Man-in-the-Middle (MITM) es un tipo de ciberataque en el que un atacante se inserta secretamente en un canal de comunicación entre dos partes. El atacante puede interceptar, leer y modificar los datos transmitidos mientras permanece invisible para ambas partes.

En las aplicaciones móviles, los ataques MITM son especialmente peligrosos porque los dispositivos se conectan constantemente a varias redes — hogar, oficina, Wi-Fi público en cafeterías y aeropuertos. Cada cambio de red crea potencialmente una ventana para el ataque. Según el Verizon Mobile Security Index (2025), el 43% de las organizaciones se han enfrentado al menos una vez a ataques MITM en dispositivos móviles corporativos.

El principal peligro de MITM es el sigilo: el usuario y el servidor no reciben señales de interceptación. La sesión parece normal, los datos se transmiten, no hay errores de certificado (si el atacante usa su propio certificado). El ataque solo puede detectarse a nivel de infraestructura de red o con herramientas especializadas.

Un desarrollador debe comprender los mecanismos de los ataques MITM para diseñar protección a nivel de aplicación, en lugar de depender únicamente de la seguridad de la capa de transporte.

Principales tipos de ataques MITM

La clasificación de los ataques MITM incluye varios tipos que se diferencian en el método de inserción en el canal de comunicación. En el desarrollo móvil, tres tipos son los más relevantes.

ARP Spoofing en la red local

ARP Spoofing es una técnica en la que el atacante envía paquetes ARP falsos a la red local, asociando su dirección MAC con la IP de la puerta de enlace. Después de esto, todo el tráfico de la víctima se enruta a través del dispositivo del atacante, que lo reenvía a la puerta de enlace mientras permanece invisible.

Herramientas como Ettercap o BetterCAP son suficientes para realizar el ataque, ya que automatizan el ARP spoofing. El ataque solo es posible dentro de una sola subred, lo que hace que los usuarios de redes Wi-Fi públicas sean los más vulnerables. Las redes modernas con Dynamic ARP Inspection (DAI) en conmutadores gestionados bloquean este tipo de ataque.

La protección a nivel de aplicación contra ARP Spoofing es imposible — esto es un problema de infraestructura de red. Sin embargo, la aplicación puede detectar anomalías en la conectividad de red utilizando bibliotecas como TrustKit para iOS o Network Security Config para Android.

DNS Spoofing e interceptación de tráfico

DNS Spoofing (o envenenamiento de caché DNS) es la sustitución de registros DNS en el camino del cliente al servidor DNS. El atacante intercepta la solicitud DNS de la aplicación y devuelve una dirección IP falsa, redirigiendo el tráfico a su servidor en lugar del legítimo.

El ataque es especialmente eficaz en redes públicas donde el servidor DNS se asigna automáticamente mediante DHCP. El atacante puede configurar su propio servidor DNS que devuelve direcciones IP falsificadas para dominios objetivo. El usuario ve una URL legítima en el navegador pero se conecta al servidor del atacante.

La protección contra DNS Spoofing en el lado de la aplicación se implementa mediante DNS-over-HTTPS (DoH) o DNS-over-TLS (DoT), que cifran las consultas DNS. Android 9+ e iOS 14+ admiten DoH a nivel de sistema, y la aplicación puede habilitar explícitamente esta opción.

SSL Stripping — evasión de HTTPS

SSL Stripping es un ataque en el que el atacante degrada una conexión HTTPS segura a HTTP no seguro. La técnica explota el hecho de que muchos usuarios escriben manualmente example.com en lugar de https://example.com, y la primera conexión se establece mediante HTTP.

Herramientas como sslstrip (Moxie Marlinspike, 2009) y bettercap interceptan automáticamente las solicitudes HTTP, establecen una conexión HTTPS con el servidor en su nombre y pasan el tráfico descifrado al cliente a través de HTTP. El navegador no muestra el icono del candado — el usuario no sabe que la conexión no es segura.

Protección moderna — HTTP Strict Transport Security (HSTS): el servidor informa al navegador que todas las conexiones futuras deben usar solo HTTPS. La lista de precarga HSTS protege adicionalmente contra el primer ataque, pero requiere registro previo del dominio.

Cómo funciona un ataque MITM en aplicaciones móviles

Un ataque MITM típico en una aplicación móvil pasa por cuatro etapas. Cada etapa explota diferentes vulnerabilidades, y la protección completa requiere cubrir todos los vectores.

La primera etapa es la inserción: el atacante se coloca en la ruta del tráfico entre el dispositivo y el servidor. Esto puede ser ARP Spoofing en la red local, un punto de acceso Wi-Fi falso (Evil Twin) o el compromiso del servidor DNS del proveedor. Los dispositivos móviles son especialmente vulnerables cuando se conectan automáticamente a redes abiertas.

La segunda etapa es la interceptación: después de la inserción, el atacante comienza a leer todos los paquetes intercambiados entre la aplicación y el servidor. En esta etapa, recopila metadatos: URL de solicitudes, tamaños de paquetes, cookies, encabezados. Incluso si los datos están cifrados, los metadatos pueden revelar la estructura de la aplicación y la lógica de negocio.

La tercera etapa es el descifrado (si el tráfico está cifrado): el atacante establece dos conexiones TLS — una con el servidor (usando un certificado falsificado), otra con el cliente. La aplicación considera la conexión segura, pero el atacante ve todos los datos en texto claro. Sin Certificate Pinning, esto funciona para cualquier certificado instalado en el almacén del sistema.

La cuarta etapa es la modificación y exfiltración: el atacante no solo puede leer sino también modificar los datos transmitidos. En aplicaciones financieras, esto podría significar cambiar el número de cuenta del destinatario; en solicitudes API, modificar parámetros de autorización. iOS y Android recomiendan implementar verificaciones de integridad de respuestas a nivel de aplicación.

Ejemplos de código: protección contra la interceptación en Android y iOS

Veamos ejemplos prácticos de protección contra ataques MITM usando Certificate Pinning en Kotlin y Swift. Estos ejemplos bloquean la suplantación de certificados incluso si el almacén del sistema está comprometido.

Certificate Pinning en Android (OkHttp)

OkHttp es la biblioteca HTTP estándar para Android que admite CertificatePinner. Especifique el hash SHA-256 del certificado de su servidor — cualquier otro certificado será rechazado.

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 en iOS (URLSession)

En iOS, use URLSessionDelegate para verificar manualmente el certificado del servidor. Compare el SecCertificateRef con una copia almacenada 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 en Android

Android admite protección declarativa a través del archivo network_security_config.xml, que bloquea el tráfico a nivel del sistema operativo sin escribir 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 protección de aplicaciones móviles contra MITM

La protección integral contra ataques MITM incluye medidas a nivel de aplicación, servidor e infraestructura de red. A continuación se presentan las principales recomendaciones para Android y iOS.

Use Certificate Pinning — vinculación del certificado del servidor en el código de la aplicación. A diferencia de la verificación TLS estándar, que confía en cualquier certificado del almacén del sistema, Certificate Pinning verifica un certificado específico o su clave pública. OkHttp en Android y TrustKit en iOS proporcionan implementaciones listas de este mecanismo.

Imponga HTTPS y HSTS: todas las solicitudes de red deben ir a través de HTTPS, y el servidor debe devolver el encabezado Strict-Transport-Security. Para Android, agregue android:usesCleartextTraffic="false" al manifiesto — esto bloquea las conexiones HTTP a nivel del sistema operativo. iOS bloquea HTTP de forma predeterminada desde iOS 9 mediante App Transport Security (ATS).

Implemente verificaciones de integridad de respuestas: firme las respuestas del servidor con una firma digital que la aplicación verifica. Incluso si un atacante intercepta el tráfico HTTPS (a través de un proxy con reinstalación de certificado), no puede falsificar la firma sin la clave privada del servidor. Use JWT con firmas RS256 o HMAC para operaciones críticas.

En el lado del servidor, habilite HTTP Public Key Pinning (HPKP) — una directiva que indica al navegador o aplicación qué certificado considerar válido para un dominio determinado. Sin embargo, HPKP requiere precaución: una configuración incorrecta puede bloquear el acceso a la aplicación durante un período prolongado. Google recomienda usar HPKP solo en combinación con certificados de respaldo.

Según NIST SP 800-52 Rev. 2 (2024), la combinación de TLS 1.3, Certificate Pinning y HSTS elimina el 99% de los vectores de ataque MITM conocidos en aplicaciones móviles. Se recomienda a los desarrolladores probar la protección con herramientas como mitmproxy antes de publicar la aplicación.