Atacuri MITM în aplicațiile mobile — ce sunt, tipuri și protecția împotriva interceptării

Ce este un atac MITM?

Man-in-the-Middle (MITM) — un tip de atac cibernetic în care infractorul se infiltrează secret în canalul de comunicare dintre două părți. Infractorul poate intercepta, citi și modifica datele transmise, rămânând invizibil pentru ambele părți.

În aplicațiile mobile, atacurile MITM sunt deosebit de periculoase, deoarece dispozitivele se conectează constant la diferite rețele — acasă, birou, Wi-Fi public în cafenele și aeroporturi. Fiecare schimbare de rețea creează potențial o fereastră pentru atac. Potrivit Verizon Mobile Security Index (2025), 43% dintre organizații s-au confruntat cel puțin o dată cu atacuri MITM asupra dispozitivelor mobile corporative.

Principalul pericol al MITM — stealth-ul: utilizatorul și serverul nu primesc semnale despre interceptare. Sesiunea pare normală, datele sunt transmise, nu există erori de certificat (dacă atacatorul folosește propriul certificat). Depistarea atacului este posibilă doar la nivelul infrastructurii de rețea sau cu instrumente specializate.

Dezvoltatorul trebuie să înțeleagă mecanismele atacurilor MITM pentru a proiecta protecția la nivel de aplicație, fără a se baza exclusiv pe securitatea stratului de transport.

Principalele tipuri de atacuri MITM

Clasificarea atacurilor MITM include mai multe tipuri care diferă prin metoda de infiltrare în canalul de comunicare. În dezvoltarea mobilă, trei tipuri sunt cele mai relevante.

ARP Spoofing în rețeaua locală

ARP Spoofing — o tehnică prin care atacatorul trimite pachete ARP false în rețeaua locală, asociind adresa sa MAC cu adresa IP a gateway-ului. După aceasta, tot traficul victimei este direcționat prin dispozitivul atacatorului, care îl transmite mai departe către gateway, rămânând invizibil.

Pentru efectuarea atacului sunt suficiente instrumente precum Ettercap sau BetterCAP, care automatizează ARP-spoofing-ul. Atacul este posibil doar într-o singură subrețea, de aceea utilizatorii rețelelor Wi-Fi publice sunt cei mai vulnerabili. Rețelele moderne cu inspecție ARP dinamică (DAI) pe switch-uri gestionate blochează acest tip de atac.

Protecția la nivel de aplicație împotriva ARP Spoofing este imposibilă — aceasta este o problemă a infrastructurii de rețea. Cu toate acestea, aplicația poate detecta anomalii în conexiunea de rețea cu ajutorul bibliotecilor precum TrustKit pentru iOS sau Network Security Config pentru Android.

DNS Spoofing și interceptarea traficului

DNS Spoofing (sau DNS Cache Poisoning) — falsificarea înregistrărilor DNS pe calea de la client la serverul DNS. Atacatorul interceptează cererea DNS a aplicației și returnează o adresă IP falsă, direcționând traficul către propriul server în locul celui legitim.

Atacul este deosebit de eficient în rețelele publice, unde serverul DNS este atribuit automat prin DHCP. Atacatorul poate configura propriul server DNS care returnează adrese IP false pentru domeniile țintă. Utilizatorul vede un URL legitim în browser, dar se conectează la serverul atacatorului.

Protecția împotriva DNS Spoofing la nivel de aplicație se realizează prin DNS-over-HTTPS (DoH) sau DNS-over-TLS (DoT), care criptează cererile DNS. Android 9+ și iOS 14+ acceptă DoH la nivel de sistem, aplicația poate activa explicit această opțiune.

SSL Stripping — ocolirea HTTPS

SSL Stripping — un atac prin care atacatorul degradează conexiunea securizată HTTPS la HTTP nesecurizat. Tehnica exploatează faptul că mulți utilizatori introduc manual example.com în loc de https://example.com, iar prima conexiune se stabilește prin HTTP.

Instrumente precum sslstrip (Moxie Marlinspike, 2009) și bettercap interceptează automat cererile HTTP, stabilesc o conexiune HTTPS cu serverul în nume propriu și transmit traficul decriptat clientului prin HTTP. Browserul nu afișează iconița de lacăt — utilizatorul nu știe că conexiunea nu este securizată.

Protecția modernă — HTTP Strict Transport Security (HSTS): serverul informează browserul că toate conexiunile viitoare trebuie să fie doar prin HTTPS. HSTS Preload List protejează suplimentar împotriva primului atac, dar necesită înregistrarea prealabilă a domeniului.

Cum funcționează un atac MITM în aplicațiile mobile

Un atac MITM tipic asupra unei aplicații mobile parcurge patru etape. Fiecare etapă utilizează vulnerabilități diferite, iar pentru protecție completă este necesară blocarea tuturor vectorilor.

Prima etapă — infiltrarea: atacatorul se află pe calea traficului dintre dispozitiv și server. Aceasta poate fi ARP Spoofing în rețeaua locală, un punct Wi-Fi fals (Evil Twin) sau compromiterea serverului DNS al furnizorului. Dispozitivele mobile sunt deosebit de vulnerabile la conectarea automată la rețele deschise.

A doua etapă — interceptarea: după infiltrare, atacatorul începe să citească toate pachetele pe care le schimbă aplicația și serverul. În această etapă, el colectează metadate: URL-urile cererilor, dimensiunea pachetelor, cookies, antete. Chiar dacă datele sunt criptate, metadatele pot dezvălui structura aplicației și logica de business.

A treia etapă — decriptarea (dacă traficul este criptat): atacatorul stabilește două conexiuni TLS — una cu serverul (folosind un certificat fals), alta cu clientul. Aplicația consideră conexiunea sigură, dar atacatorul vede toate datele în clar. Fără Certificate Pinning, acest lucru funcționează pentru orice certificat instalat în depozitul de sistem.

A patra etapă — modificarea și exfiltrarea: atacatorul poate nu doar citi, ci și modifica datele transmise. În aplicațiile financiare, aceasta poate însemna schimbarea numărului de cont al destinatarului, în cererile API — modificarea parametrilor de autorizare. iOS și Android recomandă implementarea verificării integrității răspunsurilor la nivel de aplicație.

Exemple de cod: protecția împotriva interceptării pe Android și iOS

Să examinăm exemple practice de protecție împotriva atacurilor MITM folosind Certificate Pinning în Kotlin și Swift. Aceste exemple blochează substituirea certificatului chiar și în cazul unui depozit de sistem compromis.

Certificate Pinning pe Android (OkHttp)

OkHttp — biblioteca HTTP standard pentru Android care acceptă CertificatePinner. Specificați hash-ul SHA-256 al certificatului serverului dumneavoastră — orice alte certificate vor fi respinse.

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

Pe iOS, utilizați URLSessionDelegate pentru verificarea manuală a certificatului serverului. Comparați SecCertificateRef cu copia salvată local.

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

Android acceptă protecția declarativă prin fișierul XML network_security_config.xml, care blochează traficul la nivelul sistemului de operare fără a scrie cod.

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

Metode de protecție a aplicațiilor mobile împotriva MITM

Protecția complexă împotriva atacurilor MITM include măsuri la nivel de aplicație, server și infrastructură de rețea. Mai jos sunt prezentate recomandările principale pentru Android și iOS.

Utilizați Certificate Pinning — fixarea certificatului serverului în codul aplicației. Spre deosebire de verificarea TLS standard, care are încredere în orice certificat din depozitul de sistem, Certificate Pinning verifică un anumit certificat sau cheia sa publică. OkHttp pe Android și TrustKit pe iOS oferă implementări gata făcute ale acestui mecanism.

Forțați HTTPS și HSTS: toate cererile de rețea trebuie să treacă prin HTTPS, iar serverul trebuie să returneze antetul Strict-Transport-Security. Pentru Android, adăugați android:usesCleartextTraffic="false" în manifest — acest lucru interzice conexiunile HTTP la nivelul sistemului de operare. iOS interzice implicit HTTP din iOS 9 prin App Transport Security (ATS).

Implementați verificarea integrității răspunsurilor: semnați răspunsurile serverului cu o semnătură digitală pe care aplicația o verifică. Chiar dacă atacatorul interceptează traficul HTTPS (printr-un proxy cu reinstalarea certificatului), nu va putea falsifica semnătura fără cheia privată a serverului. Utilizați JWT cu RS256 sau semnături HMAC pentru operațiunile critice.

La nivelul serverului, activați HTTP Public Key Pinning (HPKP) — o directivă care indică browserului sau aplicației ce certificat să considere valabil pentru un anumit domeniu. Cu toate acestea, HPKP necesită prudență: o configurare incorectă poate bloca accesul la aplicație pentru o perioadă lungă. Google recomandă utilizarea HPKP doar în combinație cu certificate de rezervă.

Potrivit NIST SP 800-52 Rev. 2 (2024), combinația TLS 1.3, Certificate Pinning și HSTS elimină 99% dintre vectorii cunoscuți ai atacurilor MITM asupra aplicațiilor mobile. Dezvoltatorilor li se recomandă să testeze protecția cu instrumente precum mitmproxy înainte de publicarea aplicației.