MITM-Angriffe in mobilen Apps — was sie sind, Arten und Schutz vor Abfangen

Was ist ein MITM-Angriff?

Man-in-the-Middle (MITM) ist eine Art von Cyberangriff, bei dem ein Angreifer heimlich in einen Kommunikationskanal zwischen zwei Parteien eindringt. Der Angreifer kann die übertragenen Daten abfangen, lesen und verändern, während er für beide Parteien unsichtbar bleibt.

In mobilen Apps sind MITM-Angriffe besonders gefährlich, da Geräte ständig mit verschiedenen Netzwerken verbunden sind — zu Hause, im Büro, öffentlichem Wi-Fi in Cafés und Flughäfen. Jeder Netzwerkwechsel schafft möglicherweise ein Fenster für Angriffe. Laut dem Verizon Mobile Security Index (2025) sind 43% der Organisationen mindestens einmal auf MITM-Angriffe auf unternehmenseigene mobile Geräte gestoßen.

Die Hauptgefahr von MITM ist die Heimlichkeit: Benutzer und Server erhalten keine Signale des Abfangens. Die Sitzung sieht normal aus, Daten werden übertragen, es gibt keine Zertifikatsfehler (wenn der Angreifer sein eigenes Zertifikat verwendet). Der Angriff kann nur auf der Ebene der Netzwerkinfrastruktur oder mit speziellen Tools erkannt werden.

Ein Entwickler muss die Mechanismen von MITM-Angriffen verstehen, um Schutz auf Anwendungsebene zu entwerfen, anstatt sich ausschließlich auf die Sicherheit der Transportschicht zu verlassen.

Hauptarten von MITM-Angriffen

Die Klassifizierung von MITM-Angriffen umfasst mehrere Typen, die sich in der Methode des Eindringens in den Kommunikationskanal unterscheiden. In der mobilen Entwicklung sind drei Typen am relevantesten.

ARP Spoofing im lokalen Netzwerk

ARP Spoofing ist eine Technik, bei der der Angreifer gefälschte ARP-Pakete an das lokale Netzwerk sendet und seine MAC-Adresse mit der IP-Adresse des Gateways verknüpft. Danach wird der gesamte Datenverkehr des Opfers über das Gerät des Angreifers geleitet, der ihn an das Gateway weiterleitet, während er unsichtbar bleibt.

Tools wie Ettercap oder BetterCAP reichen aus, um den Angriff durchzuführen, da sie ARP-Spoofing automatisieren. Der Angriff ist nur innerhalb eines einzigen Subnetzes möglich, was Benutzer öffentlicher Wi-Fi-Netzwerke am anfälligsten macht. Moderne Netzwerke mit Dynamic ARP Inspection (DAI) auf verwalteten Switches blockieren diese Art von Angriff.

Schutz auf Anwendungsebene vor ARP Spoofing ist unmöglich — dies ist ein Problem der Netzwerkinfrastruktur. Die Anwendung kann jedoch Anomalien in der Netzwerkverbindung mit Bibliotheken wie TrustKit für iOS oder Network Security Config für Android erkennen.

DNS Spoofing und Verkehrsabfang

DNS Spoofing (oder DNS-Cache-Vergiftung) ist die Manipulation von DNS-Einträgen auf dem Weg vom Client zum DNS-Server. Der Angreifer fängt die DNS-Anfrage der Anwendung ab und gibt eine gefälschte IP-Adresse zurück, wodurch der Datenverkehr auf seinen eigenen Server statt auf den legitimen umgeleitet wird.

Der Angriff ist besonders effektiv in öffentlichen Netzwerken, in denen der DNS-Server automatisch über DHCP zugewiesen wird. Der Angreifer kann einen eigenen DNS-Server einrichten, der gefälschte IP-Adressen für Ziel-Domains zurückgibt. Der Benutzer sieht eine legitime URL im Browser, verbindet sich aber mit dem Server des Angreifers.

Schutz vor DNS Spoofing auf Anwendungsseite wird durch DNS-over-HTTPS (DoH) oder DNS-over-TLS (DoT) implementiert, die DNS-Abfragen verschlüsseln. Android 9+ und iOS 14+ unterstützen systemweites DoH, und die Anwendung kann diese Option explizit aktivieren.

SSL Stripping — Umgehung von HTTPS

SSL Stripping ist ein Angriff, bei dem der Angreifer eine sichere HTTPS-Verbindung auf unsicheres HTTP herabstuft. Die Technik nutzt die Tatsache aus, dass viele Benutzer manuell example.com statt https://example.com eingeben und die erste Verbindung über HTTP hergestellt wird.

Tools wie sslstrip (Moxie Marlinspike, 2009) und bettercap fangen automatisch HTTP-Anfragen ab, stellen eine HTTPS-Verbindung mit dem Server in ihrem Namen her und leiten den entschlüsselten Datenverkehr über HTTP an den Client weiter. Der Browser zeigt kein Schlosssymbol — der Benutzer weiß nicht, dass die Verbindung nicht sicher ist.

Moderner Schutz — HTTP Strict Transport Security (HSTS): Der Server teilt dem Browser mit, dass alle zukünftigen Verbindungen nur über HTTPS erfolgen dürfen. Die HSTS Preload List schützt zusätzlich vor dem ersten Angriff, erfordert jedoch eine vorherige Domain-Registrierung.

Wie ein MITM-Angriff in mobilen Apps funktioniert

Ein typischer MITM-Angriff auf eine mobile App durchläuft vier Phasen. Jede Phase nutzt verschiedene Schwachstellen aus, und für vollständigen Schutz müssen alle Vektoren abgedeckt werden.

Die erste Phase ist das Eindringen: Der Angreifer platziert sich in den Pfad des Datenverkehrs zwischen Gerät und Server. Dies kann ARP Spoofing im lokalen Netzwerk, ein gefälschter Wi-Fi-Zugangspunkt (Evil Twin) oder die Kompromittierung des DNS-Servers des Anbieters sein. Mobile Geräte sind besonders anfällig, wenn sie sich automatisch mit offenen Netzwerken verbinden.

Die zweite Phase ist das Abfangen: Nach dem Eindringen beginnt der Angreifer, alle zwischen App und Server ausgetauschten Pakete zu lesen. In dieser Phase sammelt er Metadaten: Anfrage-URLs, Paketgrößen, Cookies, Header. Selbst wenn die Daten verschlüsselt sind, können Metadaten die Anwendungsstruktur und Geschïtslogik offenlegen.

Die dritte Phase ist die Entschlüsselung (wenn der Datenverkehr verschlüsselt ist): Der Angreifer stellt zwei TLS-Verbindungen her — eine mit dem Server (unter Verwendung eines gefälschten Zertifikats), eine mit dem Client. Die App betrachtet die Verbindung als sicher, aber der Angreifer sieht alle Daten im Klartext. Ohne Certificate Pinning funktioniert dies für jedes im Systemspeicher installierte Zertifikat.

Die vierte Phase ist Modifikation und Exfiltration: Der Angreifer kann die übertragenen Daten nicht nur lesen, sondern auch verändern. In Finanz-Apps könnte dies das Ändern der Kontonummer des Empfängers bedeuten; in API-Anfragen das Ändern von Autorisierungsparametern. iOS und Android empfehlen die Implementierung von Antwortintegritätsprüfungen auf Anwendungsebene.

Codebeispiele: Schutz vor Abfangen auf Android und iOS

Sehen wir uns praktische Beispiele zum Schutz vor MITM-Angriffen mit Certificate Pinning in Kotlin und Swift an. Diese Beispiele blockieren Zertifikatsaustausch, selbst wenn der Systemspeicher kompromittiert ist.

Certificate Pinning auf Android (OkHttp)

OkHttp ist die Standard-HTTP-Bibliothek für Android, die CertificatePinner unterstützt. Geben Sie den SHA-256-Hash des Zertifikats Ihres Servers an — alle anderen Zertifikate werden abgelehnt.

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

Verwenden Sie auf iOS URLSessionDelegate, um das Serverzertifikat manuell zu überprüfen. Vergleichen Sie SecCertificateRef mit einer lokal gespeicherten Kopie.

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 auf Android

Android unterstützt deklarativen Schutz über die Datei network_security_config.xml, die Datenverkehr auf Betriebssystemebene blockiert, ohne Code zu schreiben.

<!-- 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>

Methoden zum Schutz mobiler Apps vor MITM

Umfassender Schutz vor MITM-Angriffen umfasst Maßnahmen auf Anwendungs-, Server- und Netzwerkinfrastrukturebene. Nachfolgend sind die wichtigsten Empfehlungen für Android und iOS aufgeführt.

Verwenden Sie Certificate Pinning — die Bindung des Serverzertifikats im Anwendungscode. Im Gegensatz zur Standard-TLS-Überprüfung, die jedem Zertifikat aus dem Systemspeicher vertraut, überprüft Certificate Pinning ein bestimmtes Zertifikat oder dessen öffentlichen Schlüssel. OkHttp auf Android und TrustKit auf iOS bieten fertige Implementierungen dieses Mechanismus.

Erzwingen Sie HTTPS und HSTS: Alle Netzwerkanfragen müssen über HTTPS erfolgen, und der Server sollte den Strict-Transport-Security-Header zurückgeben. Fügen Sie für Android android:usesCleartextTraffic="false" zum Manifest hinzu — dies blockiert HTTP-Verbindungen auf Betriebssystemebene. iOS blockiert HTTP standardmäßig seit iOS 9 durch App Transport Security (ATS).

Implementieren Sie Antwortintegritätsprüfungen: Signieren Sie Serverantworten mit einer digitalen Signatur, die die App überprüft. Selbst wenn ein Angreifer HTTPS-Datenverkehr abfängt (über einen Proxy mit Zertifikatsneuinstallation), kann er die Signatur ohne den privaten Schlüssel des Servers nicht fälschen. Verwenden Sie JWT mit RS256- oder HMAC-Signaturen für kritische Operationen.

Aktivieren Sie auf der Serverseite HTTP Public Key Pinning (HPKP) — eine Direktive, die dem Browser oder der App mitteilt, welches Zertifikat für eine bestimmte Domain als gültig zu betrachten ist. HPKP erfordert jedoch Vorsicht: Falsche Konfiguration kann den Zugriff auf die Anwendung für einen längeren Zeitraum blockieren. Google empfiehlt, HPKP nur in Kombination mit Backup-Zertifikaten zu verwenden.

Laut NIST SP 800-52 Rev. 2 (2024) eliminiert die Kombination von TLS 1.3, Certificate Pinning und HSTS 99% der bekannten MITM-Angriffsvektoren auf mobile Apps. Entwicklern wird empfohlen, den Schutz vor der Veröffentlichung der Anwendung mit Tools wie mitmproxy zu testen.