Il blog sulla sicurezza di FireAI

Di FireAI Security & Research Team · Pubblicato

Zero-day su macOS: perché le minacce sconosciute devono comunque «telefonare a casa»

Zero-day su macOS: perché le minacce sconosciute devono comunque «telefonare a casa»

Una falla zero-day è una vulnerabilità di sicurezza sfruttata prima che il produttore abbia una correzione, così chiamata perché i difensori hanno avuto zero giorni per reagire. È la categoria di minaccia più allarmante, perché il consiglio abituale, «tieni aggiornato il software», non si applica ancora: non c’è nulla a cui aggiornarsi. Questo articolo guarda a che aspetto hanno avuto davvero queste falle sulle piattaforme Apple, attingendo ai bollettini di sicurezza di Apple, a Google Project Zero e al Citizen Lab, e poi all’unica cosa che un exploit sconosciuto deve ancora fare dopo aver avuto successo.

Un punto va chiarito subito, perché il marketing attorno a questo tema è spesso fuorviante: nessun firewall ferma un exploit. Né FireAI, né alcun altro. Un firewall non può vedere un’immagine malformata analizzata dentro iMessage o un bug del kernel innescato da una pagina web. Ciò che un firewall può fare è osservare cosa accade dopo, e questo si rivela più importante di quanto sembri a prima vista.

Cosa mostrano davvero i fatti

Apple documenta ogni correzione di sicurezza nella sua pagina Aggiornamenti di sicurezza Apple, e quando una falla era già usata contro persone reali lo dice con una formula standard: «Apple è al corrente di una segnalazione secondo cui questo problema potrebbe essere stato sfruttato attivamente». Leggere quella pagina nell’arco di qualche anno dà un quadro più fondato di qualsiasi titolo di giornale. Google Project Zero tiene un registro pubblico complementare, il suo tracker degli 0-day «in the wild», che elenca gli exploit rilevati in attacchi reali prima che esistesse una patch. Project Zero ha cura di precisare che il tracker contiene solo i casi che sono stati rilevati, per definizione i fallimenti degli aggressori, quindi non può servire a contare quanto sfruttamento avvenga davvero né a confrontare le piattaforme.

Tre casi documentati mostrano la forma del problema.

FORCEDENTRY, 2021

Nel marzo 2021 il Citizen Lab dell’Università di Toronto ha analizzato il telefono di un attivista saudita e ne ha recuperato un exploit che ha chiamato FORCEDENTRY. Era un attacco «zero-click»: un file costruito ad arte, consegnato tramite iMessage, che non richiedeva alcun tocco da parte della vittima e installava lo spyware Pegasus di NSO Group. Il Citizen Lab ha trovato prove del suo utilizzo almeno dal febbraio 2021. Apple ha corretto la falla, CVE-2021-30860 nel parser di immagini di CoreGraphics, il 13 settembre 2021 in iOS 14.8, macOS Big Sur 11.6 e un aggiornamento di sicurezza per Catalina; le sue stesse note di rilascio di Big Sur 11.6 confermano che la falla «potrebbe essere stata sfruttata attivamente».

Google Project Zero ha poi pubblicato un’analisi tecnica che spiega perché questo genere di cose è così difficile da intercettare. Il bug si trovava nel codice di compressione delle immagini JBIG2 usato dentro i PDF. L’exploit di NSO usava gli operatori logici del formato stesso per costruire, a partire da oltre 70.000 comandi di segmento immagine, un piccolo computer funzionante dentro il decodificatore di immagini, e vi eseguiva il resto dell’attacco. Visto da fuori, nulla di tutto questo somiglia a un programma. È un’immagine, aperta da un processo di sistema legittimo e firmato.

Il watering hole di Hong Kong, 2021

A fine agosto 2021, il Threat Analysis Group di Google ha scoperto una campagna di tipo watering hole rivolta ai visitatori dei siti di una testata di Hong Kong e di un gruppo pro-democrazia. Contro i Mac concatenava una falla WebKit già corretta in gennaio con un bug di escalation dei privilegi nel kernel, CVE-2021-30869, ancora non corretto su macOS Catalina; Apple lo ha sistemato il 23 settembre 2021. Il payload, una backdoor che Google ha chiamato MACMA, poteva identificare la macchina, catturare lo schermo, registrare l’audio, registrare le battute della tastiera, caricare e scaricare file ed eseguire comandi del terminale.

Questo esempio è istruttivo perché l’exploit e il payload sono due cose distinte. L’exploit era invisibile: una pagina web. Il payload era un normale programma impiantato che, per essere di qualche utilità ai suoi operatori, doveva stabilire un canale di comando e controllo e portare dati fuori dal Mac. Il rapporto di Google descrive esattamente quell’infrastruttura.

BLASTPASS, 2023

Nel settembre 2023 il Citizen Lab ha segnalato BLASTPASS, un’altra catena iMessage senza clic che consegnava Pegasus, questa volta tramite allegati PassKit contenenti immagini malevole. Apple ha assegnato gli identificativi CVE-2023-41064 e CVE-2023-41061 e ha distribuito correzioni per iPhone, iPad, Mac e Apple Watch. Fatto notevole, sia gli ingegneri di sicurezza di Apple sia il Citizen Lab hanno dichiarato di ritenere che la modalità Isolamento bloccasse questa catena specifica, il che è la prova pubblica più solida che ridurre la superficie di attacco, piuttosto che rilevare l’attacco, è ciò che funziona contro questa classe di minacce.

Perché rilevare l’exploit in sé è così difficile

Mettete i tre casi uno accanto all’altro e lo schema è chiaro. L’exploit arriva come dati (un’immagine, un PDF, una pagina web) e non come un’app. Viene elaborato da codice legittimo, firmato da Apple. Non c’è alcun file che XProtect possa riconoscere, nessun binario non firmato che Gatekeeper possa rifiutare, e spesso nessun nuovo processo che uno strumento di sicurezza degli endpoint possa segnalare, perché il codice ostile gira dentro un processo già considerato affidabile. Il rilevamento, quando avviene, è di solito forense: il Citizen Lab ha trovato FORCEDENTRY esaminando tracce su un dispositivo a posteriori, non grazie a uno scanner che lo abbia colto sul fatto.

Ecco perché il consiglio di Apple alle persone che pensano di essere prese di mira non è «installa un rilevatore» ma la modalità Isolamento, che su macOS Ventura e versioni successive blocca la maggior parte dei tipi di allegato nei messaggi, disattiva tecnologie web complesse, rifiuta le chiamate FaceTime da sconosciuti e impedisce l’installazione di profili di configurazione. Funziona eliminando i percorsi di codice di cui un exploit ha bisogno, al prezzo di una perdita di comodità che Apple dichiara apertamente.

Perché il passaggio di rete è diverso

Un exploit è l’inizio di un attacco, non il suo scopo. Pegasus esiste per inviare messaggi, foto e audio del microfono al suo operatore. Le catture dello schermo e le battute registrate da MACMA non valevano nulla sul disco della vittima. In ogni caso documentato il valore si è concretizzato con traffico in uscita dalla macchina, e nella matrice MITRE ATT&CK per macOS quella fase ha due colonne tutte sue, comando e controllo ed esfiltrazione, perché è un passaggio distinto, osservabile, che gli aggressori non possono saltare.

Questo passaggio ha proprietà che l’exploit non aveva. Proviene da un processo identificabile, dotato di una firma del codice (o, cosa eloquente, privo di firma). Va verso una destinazione con un IP, un nome host e una storia. Usa spesso una porta insolita, un IP grezzo invece di un nome, o un provider di hosting che non ha alcuna relazione con le app presenti sul Mac. Nulla di tutto questo richiede di conoscere la falla usata. Richiede solo di vedere la connessione e di avere il diritto di dire no.

È per questa parte che FireAI è costruito. Le sue regole per app sono legate alla firma del codice del processo che apre la connessione, così un binario impiantato che non è un’app da voi approvata riceve una richiesta di autorizzazione anziché un lasciapassare, con la motivazione del modello on-device mostrata in linguaggio chiaro. I suoi feed di threat intelligence (abuse.ch, Spamhaus, FireHOL, OpenPhish, Phishing Army e la lista aggiornata dei nodi di uscita Tor) sono applicati in locale, così un indirizzo di comando e controllo noto viene rifiutato indipendentemente dal fatto che qualcos’altro sul Mac abbia riconosciuto il payload. Le modalità Sotto attacco e Paranoica irrigidiscono il comportamento predefinito fino a bloccare d’ufficio le app non firmate e le destinazioni sconosciute, e il kill switch taglia Internet mantenendo la rete locale, che è la prima mossa giusta quando sospettate una compromissione e volete preservare le prove.

Cosa tutto questo non copre

L’onestà richiede l’altra metà della lista. Se un payload gira interamente dentro un’app autorizzata, ad esempio dentro un browser che avete già permesso, il suo traffico eredita le autorizzazioni di quell’app e FireAI non farà distinzione. Il traffico cifrato verso una destinazione con una reputazione pulita somiglia a qualsiasi altra connessione. Un feed contiene solo indirizzi che qualcuno ha già segnalato; un server di comando e controllo appena nato non c’è ancora. E FireAI non rileva, non rimuove e non analizza l’exploit o l’impianto: non esamina file né memoria, e non è un antivirus. Su un Mac che ritenete compromesso da un attore di livello statale, il percorso corretto è la guida di Apple sulle notifiche di minaccia e uno specialista forense, non un’impostazione del firewall.

La difesa pratica contro le falle sconosciute è quindi a strati e priva di fascino: applicate gli aggiornamenti di Apple il giorno stesso in cui escono, dato che la maggior parte dello sfruttamento prende di mira falle che hanno già una correzione; attivate la modalità Isolamento se il vostro lavoro vi rende un bersaglio plausibile; mantenete ridotta la superficie di attacco; e controllate quali app sul vostro Mac hanno il permesso di parlare con Internet, così che quando qualcosa di sconosciuto entra comunque, il passaggio che non può saltare sia quello che state osservando.

Il ruolo di FireAI e di HisnLabs

FireAI non può fermare un exploit e non pretende di farlo; ciò che fa è presidiare l’unico passaggio che nessuno dei casi documentati sopra ha potuto saltare, la connessione in uscita, e chiedere, per ogni processo sconosciuto, se quella connessione debba essere permessa del tutto.

FireAI è il prodotto di HisnLabs: un firewall con IA che funziona direttamente sul Mac. Mostra in linguaggio chiaro ogni connessione che le tue app effettuano e ti lascia decidere cosa esce dal tuo Mac — la sua IA lavora in locale, quindi il tuo traffico non viene mai inviato a noi né a nessun altro. Il team di ricerca sulla sicurezza di HisnLabs è quello che mantiene affidabili queste decisioni: cataloga quali domini sono semplice telemetria e quali un servizio reale, traccia il Paese e la rete dietro una connessione e addestra il modello locale (la funzione Autopilot) su schemi di traffico reali, senza che nulla lasci il tuo Mac.

Puoi leggere le scelte tecniche che ci stanno dietro, oppure provare FireAI per 17 giorni, su FireAI, di HisnLabs.

Fonti