Ispezione SSL/TLS e attacchi Man-in-the-Browser

Oggi HTTPS rappresenta oltre il 90% del traffico web, inclusi download di malware, canali C2 ed esfiltrazione dei dati. Gli strumenti di sicurezza perimetrale che non sono in grado di ispezionare TLS vedono soltanto blocchi cifrati, creando un punto cieco che gli attaccanti sfruttano attivamente. L'ispezione SSL/TLS (detta anche intercettazione SSL, SSL bumping o ispezione approfondita dei pacchetti HTTPS) consente ai gateway di sicurezza di decifrare, ispezionare e cifrare nuovamente il traffico HTTPS prima che raggiunga l'endpoint. Questa visibilità è essenziale per il filtraggio dei contenuti web, il DLP e la scansione antimalware negli ambienti in cui la maggior parte del traffico usa HTTPS.

L'ispezione SSL è tecnicamente un attacco man-in-the-middle controllato, eseguito dall'infrastruttura di sicurezza dell'organizzazione. Il processo è il seguente: Passaggio 1: il client stabilisce una connessione TLS con il proxy (usando il certificato del proxy firmato dalla CA aziendale). Passaggio 2: il proxy stabilisce una sessione TLS separata con il server reale, usando il certificato autentico del server. Passaggio 3: il proxy decifra il traffico proveniente dal client, lo ispeziona, quindi lo cifra nuovamente e lo inoltra al server (e viceversa). Il client considera attendibile il certificato del proxy perché il certificato della CA aziendale è preinstallato su tutti gli endpoint gestiti tramite MDM o Group Policy.

Non tutto il traffico dovrebbe essere ispezionato. In genere le organizzazioni escludono le categorie che trasportano dati sensibili dal punto di vista legale o etico: siti bancari e finanziari, portali sanitari, database di ricerca giuridica, URL di certificate transparency e OCSP (per evitare di compromettere la convalida dei certificati) e siti che usano il certificate pinning (che rifiuterebbero i certificati ri-firmati, causando il malfunzionamento dell'applicazione). Le esclusioni vengono gestite come elenco di bypass nella policy di ispezione. In alcune giurisdizioni, le leggi sul monitoraggio dei dipendenti possono limitare l'ispezione della navigazione web personale, rendendo necessaria un'informativa chiara nelle policy di utilizzo accettabile.

Il certificate pinning è una tecnica in cui un'applicazione memorizza nel codice il certificato o la chiave pubblica attesi per uno specifico server e rifiuta di connettersi se il certificato non corrisponde, anche quando il certificato è valido e considerato attendibile dal certificate store della CA del sistema operativo. Questo interrompe l'ispezione SSL perché il certificato ri-firmato dal proxy non corrisponde al valore fissato. Le app mobili (app bancarie e di pagamento) usano spesso il certificate pinning come misura contro gli attacchi MitM. Le aziende devono escludere dall'ispezione le app che usano il pinning, altrimenti ne causerebbero il malfunzionamento. Ciò significa anche che gli attaccanti che vogliono eludere l'ispezione SSL del proprio malware possono implementare il pinning.

Lo SSL stripping è un attacco man-in-the-middle in cui un attaccante intercetta il traffico HTTPS e lo declassa a HTTP, consentendosi di leggere e modificare il contenuto in chiaro. L'attacco funziona sulle connessioni che iniziano come HTTP prima di essere reindirizzate a HTTPS: l'attaccante intercetta la richiesta HTTP iniziale, mantiene una connessione HTTP con la vittima mentre stabilisce una connessione HTTPS con il server legittimo e inoltra il traffico in modo trasparente. Dal punto di vista della vittima, il sito appare come HTTP. HTTP Strict Transport Security (HSTS) difende dallo SSL stripping indicando ai browser di usare sempre HTTPS per un dominio, anche se l'utente digita HTTP.

Un attacco Man-in-the-Browser (MitB) è una forma di trojan bancario che si inserisce all'interno del browser, come estensione dannosa o tramite injection nel processo del browser, e modifica pagine web e transazioni senza che l'utente se ne accorga. A differenza di un MitM di rete, il MitB opera all'interno della sessione cifrata, a livello del browser, perciò TLS non offre alcuna protezione. I malware MitB (Zeus, SpyEye) possono modificare gli importi dei pagamenti, alterare i numeri dei conti dei destinatari, acquisire password monouso e modificare silenziosamente i moduli dopo che l'utente li ha compilati. Le modifiche avvengono dopo la decifratura TLS e prima che l'utente visualizzi la pagina renderizzata.

Il malware MitB si aggancia alle API del browser a livello applicativo. In Windows, inietta codice nei processi del browser (Chrome, Firefox, IE) tramite DLL injection o COM hijacking, quindi si aggancia alle funzioni JavaScript e alle API per la manipolazione del DOM. Quando un utente visita la propria banca, il malware intercetta il codice JavaScript che esegue il rendering della pagina e della conferma della transazione, modificando il conto del destinatario con quello dell’aggressore. Il server vede la transazione corretta; i log HTTPS lato server non mostrano nulla di insolito. L’utente visualizza la conferma corretta, con l’importo previsto, mentre il trasferimento effettivo viene inviato al conto dell’aggressore.

La difesa dagli attacchi MitB richiede controlli stratificati. L’isolamento del browser (Menlo Security, Zscaler Browser Isolation) esegue il rendering del browser in una macchina virtuale cloud remota e trasmette allo schermo dell’utente solo i pixel: il malware non può iniettare codice in un processo del browser eseguito in un ambiente remoto. Verifica delle transazioni: le banche confermano i dettagli della transazione (importo + destinatario) tramite un canale separato (un OTP via SMS che include i dettagli della transazione), in modo che l’utente debba verificare ciò che il server ha effettivamente ricevuto. Un sistema EDR per gli endpoint in grado di rilevare l’iniezione di DLL nei processi del browser può identificare le infezioni MitB. L’allowlisting delle estensioni del browser impedisce l’uso di estensioni dannose.

Le estensioni del browser dannose rappresentano una minaccia significativa per gli endpoint. Le estensioni dispongono di autorizzazioni ampie: possono leggere il contenuto delle pagine, modificare le richieste, intercettare l’invio dei moduli e accedere ai cookie. Un’estensione che si presenta come uno strumento utile (blocco degli annunci, modalità scura) può raccogliere credenziali, iniettare annunci, reindirizzare il traffico o agire come agente MitB. Controlli aziendali: utilizzi Group Policy o MDM per limitare l’installazione delle estensioni a un allowlist approvato. Blocchi l’installazione di estensioni provenienti da fonti diverse dal Chrome Web Store o da Firefox Add-ons. Verifichi regolarmente le estensioni installate sugli endpoint gestiti per individuare violazioni delle policy.

Le organizzazioni che implementano l’ispezione SSL devono affrontare le implicazioni per la privacy dei dipendenti. In molte giurisdizioni e secondo diverse normative sul lavoro, è obbligatorio fornire un’informativa chiara prima di monitorare il traffico cifrato. Buone pratiche: pubblicare una Acceptable Use Policy (AUP) che dichiari esplicitamente che il traffico di rete, incluso HTTPS, può essere sottoposto a ispezione; far accettare l’AUP ai dipendenti durante l’inserimento in azienda; implementare categorie di esclusione per i siti di home banking e quelli medici; conservare i log del traffico decifrato solo per il tempo necessario (in genere 30-90 giorni). Il consulente legale dovrebbe esaminare il programma di ispezione prima della sua implementazione, soprattutto nei Paesi dell’UE, dove il GDPR impone limiti più stringenti al monitoraggio dei dipendenti.

La Certificate Transparency è un framework (RFC 6962) che richiede che tutti i certificati TLS pubblicamente attendibili vengano registrati in log CT pubblici, verificabili e append-only prima che i browser possano considerarli attendibili. La CT consente ai proprietari dei domini di monitorare la presenza di certificati emessi erroneamente: se un aggressore riuscisse in qualche modo a convincere una CA a emettere un certificato per il vostro dominio (come è accaduto con DigiNotar nel 2011), i log CT permetterebbero di rilevarlo quasi in tempo reale. Strumenti come crt.sh consentono ai team di sicurezza di cercare nei log CT tutti i certificati emessi per il proprio dominio. I browser applicano la CT richiedendo una prova dell’inclusione nel log (Signed Certificate Timestamps, SCT) incorporata nell’handshake TLS.

Verifichi la propria comprensione dei concetti di CompTIA Security+ (SY0-701) trattati in questa lezione.

In questa lezione ha appreso che l’ispezione SSL/TLS decifra, ispeziona e cifra nuovamente il traffico HTTPS su un proxy utilizzando un certificato CA aziendale considerato attendibile dagli endpoint gestiti; lo SSL stripping effettua il downgrade da HTTPS a HTTP ed è contrastato da HSTS; gli attacchi man-in-the-browser iniettano codice nel processo del browser al di sopra del livello TLS per modificare le transazioni senza essere rilevati e richiedono, come difese, l’isolamento del browser o la verifica delle transazioni tramite un canale separato. Nella prossima lezione esamineremo la sostituzione dei protocolli non sicuri con i loro equivalenti sicuri.