Útoky MITM v mobilních aplikacích — co to je, typy a ochrana před zachycením

Co je útok MITM?

Man-in-the-Middle (MITM) — typ kybernetického útoku, při kterém se kyberzločinec tajně infiltruje do komunikačního kanálu mezi dvěma stranami. Kyberzločinec může zachycovat, číst a upravovat přenášená data, přičemž zůstává pro obě strany neviditelný.

V mobilních aplikacích jsou útoky MITM obzvláště nebezpečné, protože zařízení se neustále připojují k různým sítím — domácím, kancelářským, veřejným Wi-Fi v kavárnách a na letištích. Každé přepnutí sítě potenciálně vytváří okno pro útok. Podle Verizon Mobile Security Index (2025) se 43 % organizací alespoň jednou setkalo s útoky MITM na firemních mobilních zařízeních.

Hlavní nebezpečí MITM — skrytost: uživatel a server nedostávají signály o zachycení. Relace vypadá normálně, data jsou přenášena, nedochází k chybám certifikátu (pokud útočník používá vlastní certifikát). Detekce útoku je možná pouze na úrovni síťové infrastruktury nebo pomocí specializovaných nástrojů.

Vývojář musí rozumět mechanismům útoků MITM, aby navrhl ochranu na úrovni aplikace, nikoli se spoléhal výhradně na bezpečnost transportní vrstvy.

Hlavní typy útoků MITM

Klasifikace útoků MITM zahrnuje několik typů lišících se metodou infiltrace do komunikačního kanálu. V mobilním vývoji jsou nejrelevantnější tři typy.

ARP Spoofing v lokální síti

ARP Spoofing — technika, při které útočník posílá falešné ARP pakety do lokální sítě, čímž spojuje svou MAC adresu s IP adresou brány. Poté je veškerý provoz oběti směrován přes zařízení útočníka, který jej předává bráně, přičemž zůstává neviditelný.

K provedení útoku stačí nástroje jako Ettercap nebo BetterCAP, které automatizují ARP-spoofing. Útok je možný pouze v rámci jedné podsítě, proto jsou nejzranitelnější uživatelé veřejných Wi-Fi sítí. Moderní sítě s dynamickou ARP inspekcí (DAI) na spravovaných přepínačích tento typ útoku blokují.

Ochrana na úrovni aplikace před ARP Spoofingem není možná — to je problém síťové infrastruktury. Aplikace však může detekovat anomálie v síťovém připojení pomocí knihoven jako TrustKit pro iOS nebo Network Security Config pro Android.

DNS Spoofing a zachycení provozu

DNS Spoofing (nebo DNS Cache Poisoning) — padělání DNS záznamů na cestě od klienta k DNS serveru. Útočník zachytí DNS požadavek aplikace a vrátí falešnou IP adresu, čímž přesměruje provoz na svůj server místo legitimního.

Útok je obzvláště účinný ve veřejných sítích, kde je DNS server přidělován automaticky přes DHCP. Útočník může nakonfigurovat vlastní DNS server, který vrací falešné IP adresy pro cílové domény. Uživatel vidí v prohlížeči legitimní URL, ale připojuje se k serveru útočníka.

Ochrana před DNS Spoofingem na straně aplikace je realizována pomocí DNS-over-HTTPS (DoH) nebo DNS-over-TLS (DoT), které šifrují DNS požadavky. Android 9+ a iOS 14+ podporují systémový DoH, aplikace může tuto možnost explicitně zapnout.

SSL Stripping — obcházení HTTPS

SSL Stripping — útok, při kterém útočník sníží zabezpečené připojení HTTPS na nezabezpečené HTTP. Technika využívá skutečnosti, že mnoho uživatelů ručně zadává example.com místo https://example.com, a první připojení je navázáno přes HTTP.

Nástroje jako sslstrip (Moxie Marlinspike, 2009) a bettercap automaticky zachycují HTTP požadavky, navazují HTTPS připojení se serverem vlastním jménem a předávají dešifrovaný provoz klientovi přes HTTP. Prohlížeč nezobrazuje ikonu zámku — uživatel neví, že připojení není zabezpečené.

Moderní ochrana — HTTP Strict Transport Security (HSTS): server informuje prohlížeč, že všechna budoucí připojení musí být pouze přes HTTPS. HSTS Preload List navíc chrání před prvním útokem, ale vyžaduje předchozí registraci domény.

Jak funguje útok MITM v mobilních aplikacích

Typický útok MITM na mobilní aplikaci prochází čtyřmi fázemi. Každá fáze využívá různé zranitelnosti a pro úplnou ochranu je nutné zablokovat všechny vektory.

První fáze — infiltrace: útočník se nachází na cestě provozu mezi zařízením a serverem. Může to být ARP Spoofing v lokální síti, falešný Wi-Fi bod (Evil Twin) nebo kompromitace DNS serveru poskytovatele. Mobilní zařízení jsou obzvláště zranitelná při automatickém připojování k otevřeným sítím.

Druhá fáze — zachycení: po infiltraci začne útočník číst všechny pakety, které si aplikace a server vyměňují. V této fázi shromažďuje metadata: URL požadavků, velikost paketů, cookies, hlavičky. I když jsou data zašifrována, metadata mohou odhalit strukturu aplikace a obchodní logiku.

Třetí fáze — dešifrování (pokud je provoz šifrován): útočník naváže dvě TLS připojení — jedno se serverem (pomocí falešného certifikátu), druhé s klientem. Aplikace považuje připojení za bezpečné, ale útočník vidí všechna data v otevřené podobě. Bez Certificate Pinning to funguje pro jakýkoli certifikát nainstalovaný v systémovém úložišti.

Čtvrtá fáze — úprava a exfiltrace: útočník může nejen číst, ale také upravovat přenášená data. Ve finančních aplikacích to může znamenat změnu čísla účtu příjemce, v API požadavcích — změnu parametrů autorizace. iOS a Android doporučují implementovat kontrolu integrity odpovědí na úrovni aplikace.

Příklady kódu: ochrana před zachycením na Android a iOS

Podívejme se na praktické příklady ochrany před útoky MITM pomocí Certificate Pinning v Kotlin a Swift. Tyto příklady blokují nahrazení certifikátu i při kompromitovaném systémovém úložišti.

Certificate Pinning na Android (OkHttp)

OkHttp — standardní HTTP knihovna pro Android, která podporuje CertificatePinner. Zadejte SHA-256 hash certifikátu vašeho serveru — všechny ostatní certifikáty budou odmítnuty.

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

Na iOS použijte URLSessionDelegate pro ruční ověření certifikátu serveru. Porovnejte SecCertificateRef s lokálně uloženou kopií.

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

Android podporuje deklarativní ochranu prostřednictvím XML souboru network_security_config.xml, který blokuje provoz na úrovni operačního systému bez psaní kódu.

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

Metody ochrany mobilních aplikací před MITM

Komplexní ochrana před útoky MITM zahrnuje opatření na úrovni aplikace, serveru a síťové infrastruktury. Níže jsou uvedena hlavní doporučení pro Android a iOS.

Používejte Certificate Pinning — připojení certifikátu serveru v kódu aplikace. Na rozdíl od standardního TLS ověření, které důvěřuje jakémukoli certifikátu ze systémového úložiště, Certificate Pinning kontroluje konkrétní certifikát nebo jeho veřejný klíč. OkHttp na Android a TrustKit na iOS poskytují hotové implementace tohoto mechanismu.

Vynuťte HTTPS a HSTS: všechny síťové požadavky musí jít přes HTTPS a server musí vracet hlavičku Strict-Transport-Security. Pro Android přidejte android:usesCleartextTraffic="false" do manifestu — to zakáže HTTP připojení na úrovni operačního systému. iOS ve výchozím nastavení zakazuje HTTP od iOS 9 prostřednictvím App Transport Security (ATS).

Implementujte kontrolu integrity odpovědí: podepisujte odpovědi serveru digitálním podpisem, který aplikace ověřuje. I když útočník zachytí HTTPS provoz (přes proxy s přeinstalací certifikátu), nebude moci padělat podpis bez soukromého klíče serveru. Používejte JWT s RS256 nebo HMAC podpisy pro kritické operace.

Na straně serveru zapněte HTTP Public Key Pinning (HPKP) — direktivu, která říká prohlížeči nebo aplikaci, který certifikát považovat za platný pro danou doménu. HPKP však vyžaduje opatrnost: nesprávná konfigurace může zablokovat přístup k aplikaci na dlouhou dobu. Google doporučuje používat HPKP pouze v kombinaci se záložními certifikáty.

Podle NIST SP 800-52 Rev. 2 (2024) kombinace TLS 1.3, Certificate Pinning a HSTS odstraňuje 99 % známých vektorů útoků MITM na mobilní aplikace. Vývojářům se doporučuje otestovat ochranu pomocí nástrojů jako mitmproxy před publikováním aplikace.