Giovedì 17 settembre sono stato ospite al TG1, nel servizio della giornalista Silvia Balducci – che ringrazio per l’opportunità – sulla PEC governativa compromessa e le conseguenze dell’attacco di tipo MiTM alla mailbox che ha permesso ai criminali informatici di ricevere documentazione privata dei correntisti della banca Revolut.
Durante l’intervista al TG1 ho parlato dei rischi che corrono gli interessati di un databreach nel momento in cui i loro dati vengono divulgati e quindi potenzialmente utilizzati contro di loro.
Truffe più credibili e mirate
Il primo rischio è ricevere tentativi di phishing, telefonate o messaggi costruiti su dettagli veri. Chi conosce il nome della banca, un’operazione effettuata anche in criptomoneta Bitcoin ad esempio, un recapito e magari possiede la copia di un documento può presentarsi in modo molto più convincente come operatore dell’assistenza, funzionario o investigatore.
Una richiesta urgente di “verificare il conto” ad esempio, o tipicamente di “mettere al sicuro i fondi” o potenzialmente anche “validare una transazione in criptovalute mai in realtà fatta” può così sembrare plausibile.
Gli stessi dati potrebbero essere usati per tentativi di estorsione, soprattutto quando rivelano aspetti della vita finanziaria che la persona considera privati. La disponibilità dei documenti aumenta le possibilità di raggiro, ma non significa che ogni tentativo andrà a buon fine soprattutto se chi è stato coinvolto nel data breach è consapevole dei rischi e pronto a gestirli.
Il rischio di vedersi attribuire attività altrui
Il secondo rischio è il furto d’identità. I criminali potrebbero tentare di usare i dati e le copie dei documenti delle vittime per aprire account, registrare domini o attivare servizi da impiegare in successive frodi. Il CERT-AGID ha documentato, in altre campagne, il tentativo di utilizzare documenti sottratti anche per creare un’identità digitale SPID a nome della vittima: questo è uno scenario di rischio, non la prova che nel caso Revolut tali registrazioni siano già avvenute.
Se uno di quegli account venisse usato per truffare terzi, i dati di registrazione potrebbero condurre inizialmente alla persona a cui è stata sottratta l’identità e la vittima rischierebbe quindi di dover spiegare e documentare un’attività che non ha mai svolto. È il senso dell’espressione “capro espiatorio”: comparire nei primi riscontri di un’indagine non equivale ovviamente a essere responsabili, ma può comportare conseguenze concrete e difficili da gestire.
Il rischio di estorsione
Chi è vittima di data breach spesso rischia di diventare oggetto di estorsione nel momento in cui i criminali minacciano non solo chi ha causato il data breach (quindi nel caso specifico, la banca) ma anche i proprietari dei dati sottratti di divulgarli a meno di non ricevere un pagamento, tipicamente in criptomoneta (Bitcoin, Ethereum ma più spesso Monero o ZCash).
In caso di richieste estorsive il suggerimento è quello di rivolgersi immediatamente all’Autorità Giudiziaria e sporgere querela.
Cosa può fare chi è coinvolto nel data breach
Chi riceve una comunicazione relativa alla violazione dovrebbe conservarla e verificare quali categorie di dati lo riguardano. È prudente controllare con attenzione movimenti e comunicazioni del proprio conto, attivare gli avvisi disponibili e diffidare delle richieste inattese, anche quando citano informazioni esatte.
Per contattare la banca o un ente, è meglio usare l’app o i recapiti ufficiali già conosciuti, senza seguire link o numeri forniti nel messaggio ricevuto, non fidarsi di nessun contatto ricevuto ma essere sempre i primi a contattare.
Se sono stati divulgati documenti d’identità – come nel caso di Revolut – un buon consiglio è quello di prenotare presso il proprio Comune e segnalarle l’illecita diffusione e la necessità di procedere alla sostituzione, in modo che qualunque atto venga svolto con il vecchio documento sarà semplice dimostrare la propria estraneità, dato che il documento non esiste più ed è stato sostituito da uno nuovo.
Se emergono account, richieste o operazioni mai autorizzate, occorre conservarne le prove, contestarle tempestivamente presso il servizio interessato e rivolgersi alle autorità: anche il CERT-AGID raccomanda di segnalare il furto (o meglio, la diffusione illecita) di dati personali (come carta d’identità, foto, dati bancari, etc…) alla Polizia Postale, magari tramite una denuncia/querela, in diversi infine consigliano di presentare una segnalazione anche al Garante della Privacy.
Ogni volta che ricevo una messaggio del genere mi viene da pensare che forse stiamo vanificando buona parte dello scopo per cui abbiamo cifrato il documento e secondo me varrebbe la pena riflettere sui potenziali scenari di rischio.
Se infatti inviamo un file cifrato via email e, subito dopo, mandiamo la password alla stessa casella, la protezione aggiunta è piuttosto limitata, anzi direi quasi nulla.
Pensiamo ad esempio a una casella compromessa: chi riesce ad accedere alla posta troverà probabilmente sia il messaggio con il documento sia quello successivo con la password. Lo stesso vale se inviamo un file cifrato tramite WhatsApp e poi scriviamo la password nella stessa chat.
Ci sono poi situazioni molto più comuni e meno “cyber”: in aziende, studi professionali ed enti è normalissimo trovare caselle email e PEC condivise tra più persone… mandando documento e password alla stessa casella, tutti quelli che possono leggere l’una possono leggere anche l’altra.
Oppure può semplicemente capitare di sbagliare destinatario: se mando alla persona sbagliata prima il documento e subito dopo la password, aver utilizzato due messaggi diversi cambia poco, mentre se avessi inviato la password al cellulare o altro contatto diretto del destinatario, avrei reso “inerte” l’allegato cifrato.
Una buona abitudine è quindi separare realmente la consegna del documento da quella della password, su due canali diversi, ad esempio documento cifrato alla PEC o alla mail dell’ufficio e password comunicata direttamente alla persona interessata, tramite un recapito già conosciuto e verificato.
Come canale secondario vanno benissimo Whatsapp, SMS, telefonata vocale a numero noto (non basta ricevere una telefonata, anche da numero in chiaro) e non è così importante che sia cifrato anche il secondo canale se è ben separato dal primo, basta sia diverso e noto, il più possibile legato al soggetto che ha effettivamente diritto di visionare i dati cifrati.
Così una PEC condivisa può ricevere tranquillamente il documento senza che tutti possano aprirlo e un eventuale accesso abusivo alla casella non fornisce automaticamente anche la password e persino un errore nell’indirizzo del destinatario ha conseguenze più limitate.
Ovviamente anche il secondo canale può essere compromesso e ogni situazione ha il proprio threat model, però almeno, a quel punto, per ottenere documento e password bisogna riuscire ad accedere a due canali distinti.
Poco importa come viene cifrato il dato, anche se chiaramente per un singolo documento (ad esempio una perizia informatica in PDF con contenuti riservati) l’ideale è la cifratura embedded, nel PDF, nel Docx, che permette l’apertura diretta anche su smartphone semplicemente inserendo la password ogni volta.
Per insiemi di file, meglio optare per un 7zip (o eventualmente uno zip, ma anche un Rar va bene) cifrato in maniera simmetrica con AES256 e cifratura anche dei nomi file, anche se chiaramente si deve poi suggerire al ricevente d’installare – se già non lo ha fatto – il software di compressione/decompressione 7zip.
Notare che talvolta su MacOS le App per decomprimere non decifrano correttamente gli archivi cifrati, un software che in genere funziona senza problemi è Keka e lo si può suggerire a chi riceve il nostro messaggio se ha un Apple, tra l’altro scaricandolo dal sito web è gratuito, da App Store ha un costo minimale.
Parlando poi di GDPR e “accountability”, sicuramente mandare un file cifrato ci protegge anche da eventuali problematiche che dovessero occorrere al documento e agli eventuali dati personali in essi contenuti e responsabilizza di molto chi lo riceve. Ad esempio se dovesse diffondere il documento, dovrebbe divulgare anche la chiave, prendendosi la responsabilità della divulgazione mentre a noi non potrà mai essere contestata una diffusione e talvolta “dispersione” di qualcosa di cui abbiamo inviato la chiave soltanto a un soggetto specifico.
Suggerirei quindi, in conclusione, di sostituire la frase sopra con “I documenti sono cifrati e la password verrà comunicata al destinatario tramite un canale separato e sicuro”, si fa anche bella figura. 😊
Sembra un gioco, ma è il risultato di un’anomalia di rendering che abbiamo individuato con il team Forenser analizzando un documento PDF che si comportava in maniera diversa a seconda del software utilizzato per aprirlo.
Tutto è partito da alcune fotografie che, aprendo un PDF con Anteprima (Preview) su macOS, apparivano come semplici riquadri grigi. Lo stesso identico documento, aperto sullo stesso Mac con Foxit Reader, Acrobat Reader o con altri renderer proprietari (anche semplicemente con il browser se usa un suo renderer come ad esempio Google Chrome) mostrava invece correttamente le immagini.
Paradossalmente, aprendo il file su MacOS o iOS con un viewer che non utilizzi il renderer Apple si vede un’immagine nell’anteprima (quando si sfoglia il folder per cercare il file) e poi un’altra una volta aperta la stessa immagine nel viewer, con un evidente disorientamento dell’utente.
Analizzando progressivamente il problema siamo riusciti a circoscriverlo alla gestione di particolari immagini JPEG 2000 contenute in un container JPX da parte del renderer Apple utilizzato da Preview/PDFKit, usato ad esempio proprio in Preview/Anteprima su MacOS oppure su iOS su iPhone o iPad.
Due byte fanno la differenza
Il testcase più interessante è costituito da due PDF praticamente identici: stessa struttura, stesso /JPXDecode, stesso spazio colore CMYK e, soprattutto, lo stesso identico codestream JPEG 2000.
La differenza è di appena due byte nella File Type Box (ftyp) del container: con il valore JP2 nel campo ftypl’immagine viene correttamente visualizzata da Preview, mentre con il valore JPX si ottiene un riquadro grigio in Preview: in sostanza, nelle due posizioni interessate abbiamo cambiato semplicemente il carattere 2 (0x32) nel carattere x (0x78) ma il codestream JPEG 2000 resta identico.
Questo ovviamente non significa che JPX sia un formato errato: JPX è previsto dallo standard JPEG 2000 Part 2 e il PDF contempla espressamente /JPXDecode, quindi non possiamo parlare di bug, è più corretto parlare – almeno fino a eventuali chiarimenti da parte di Apple – di una anomalia di interoperabilità/rendering riproducibile in Preview/PDFKit.
Parliamo quindi di una differenza di rendering riproducibile su questi file. Il testcase, da solo, non consente di attribuire una precisa violazione dello standard al renderer Apple, anche perché il solo brand non certifica la conformità del container.
Dal riquadro grigio al “PDF di Schrödinger”
A quel punto mi sono chiesto: se il comportamento è così prevedibile e controllabile, possiamo sfruttarlo per fare in modo che lo stesso PDF mostri due contenuti totalmente differenti a seconda del renderer? Che so, tipo un cane e un gatto?
La risposta è sì e siamo riusciti a fare qualcosa d’interessante anche per l’informatica forense e la pdf forensics, che poi non è altro che l’attività di perizia informatica su PDF: abbiamo costruito un PDF che contiene un cane e un gatto, ma che mostra soltanto o uno o l’altro come unica immagine del documento in base al sistema utilizzato per aprirlo.
Aprendolo con Preview/PDFKit nell’ambiente interessato dall’anomalia compare il cane, mentre utilizzando un renderer che gestisce correttamente l’oggetto JPX compare invece il gatto: niente JavaScript, niente rilevamento dello User-Agent e nessun contenuto scaricato da Internet.
Stesso PDF, stessi byte, persino stesso valore hash ma due rappresentazioni visive differenti, da qui il nome, inevitabile, di “PDF di Schrödinger”: un pdf che contiene contemporaneamente cane e gatto.
Allego qui si seguito il “PDF di Schrodinger”, confermando che è sicuro da aprire perché non contiene javascript, action, codifiche, automatismi ma semplicemente due immagini JPG con due codifiche diverse, anticipando che è probabile che sl sito web vediate comunque un gatto, ma una volta scaricato (su MacOS/iPhone) vediate invece un cane.
Il pdf con la doppia immagine produce valore hash MD5 a62b826ada901ee1e13b1940d37255e5, SHA256 bc7e7bbb478e9f082d265e27cc43b286f7a5f4dde42a6a5ab37bc6702f25c714 e – per i più attenti alla sicurezza informatica – ha le seguenti caratteristiche:
Title: Il PDF di Schrodinger - Cane o gatto? Author: Paolo Dal Checco Creator: Paolo Dal Checco Custom Metadata: no Metadata Stream: yes Tagged: no UserProperties: no Suspects: no Form: none JavaScript: no Pages: 1 Encrypted: no Page size: 700 x 700 pts Page rot: 0 File size: 256358 bytes Optimized: no PDF version: 1.5
Perché è interessante per la digital forensics?
La curiosità tecnica nasconde un problema tutt’altro che teorico: in una perizia informatica, due consulenti potrebbero verificare di avere esattamente lo stesso documento, con il medesimo hash, e tuttavia visualizzare contenuti differenti perché utilizzano software o sistemi differenti.
L’hash dimostra l’identità della sequenza di byte, non l’identità della rappresentazione prodotta dal renderer, questa è una cosa di cui in digital forensics si deve tenere conto e l’esperimento del cane e del gatto rende semplicemente macroscopico questo concetto.
Implicazioni su contratti, immagini nascoste, truffe
Le implicazioni possono riguardare non soltanto la PDF Forensics, ma potenzialmente anche documenti contrattuali, firme digitali, verifiche documentali e scenari malevoli nei quali la diversa rappresentazione di uno stesso documento potrebbe essere sfruttata intenzionalmente.
Non è difficile immaginare come una simile anomalia possa essere sfruttata per truffe, per contratti che vengono mostrati in modo diverso al destinatario rispetto al contenuto “nascosto”, all’invio d’immagini nascoste che si vedono solo con una particolare codifica.
Ad esempio, abbiamo sperimentato l’apposizione di una firma digitale e di una marca temporale al documento e, come si può immaginare, la rappresentazione grafica della firma può comparire insieme al cane oppure al gatto, a seconda del renderer.
Questo non significa che la firma digitale selezioni una delle due immagini e firmi quella: la firma riguarda i dati della revisione firmata, cioè l’intero documento, non i pixel mostrati sullo schermo, ma il punto critico è un altro: la verifica dell’integrità del documento non dimostra, da sola, quale rappresentazione il firmatario abbia effettivamente visto prima di firmare, perché… dipende da quale sistema ha utilizzato per la firma.
Per chi svolge analisi forensi, la conseguenza pratica è semplice: non bisogna dare per scontato che ciò che mostra un singolo viewer coincida necessariamente con tutto ciò che il PDF contiene. Nei casi dubbi è opportuno documentare software, versione e ambiente utilizzati e confrontare il documento attraverso renderer indipendenti.
Come evitare il problema
Nella coppia di test bastano due byte differenti per cambiare la visualizzazione dell’immagine nel PDFKit verificato. Nel PDF di Schrödinger, invece, non cambia neppure un byte tra un’apertura e l’altra: lo stesso documento mostra il cane o il gatto a seconda di come viene renderizzato.
In attesa di un eventuale intervento sul renderer Apple, per chi produce PDF destinati a essere visualizzati su piattaforme differenti la soluzione prudenziale è evitare container JPX quando le funzionalità specifiche di JPEG 2000 Part 2 non sono necessarie, preferendo JP2 o formati maggiormente interoperabili e verificando sempre il PDF finale con più renderer.
FTK Imager, nella versione 8.3.0.27, è stato appena reso disponibile per il download gratuito sul sito Exterro, che ormai da qualche anno ha ereditato il software da Accessdata continuandone lo sviluppo, riportiamo quindi qui di seguito il link di download, le informazioni strategiche sulle patch applicate e le differenze con le precedenti versioni di FTK Imager.
FTK Imager, il “coltellino svizzero” dell’informatica forense
Definito il “coltellino svizzero” della digital forensics, utilizzato da quasi 20 anni dagli informatici forensi di tutto il mondo, FTK Imager permette di creare copie forensi di dischi, supporti rimovibili e volumi logici, visualizzarne il contenuto prima dell’acquisizione, esportare file e cartelle e calcolare gli hash necessari per verificarne l’integrità.
La versione 8.3 non introduce particolari novità funzionali, ma le release notes contengono una correzione piuttosto interessante dal punto di vista della sicurezza.
Vulnerabilità di sicurezza su XML e UFDR sanata
Exterro dichiara nelle Release Notes di aver risolto la vulnerabilità FCR-72008, attraverso la quale l’elaborazione di XML malevoli contenuti in file Cellebrite UFED UFDR poteva portare alla esfiltrazione di file, presumibilmente dalla macchina sulla quale veniva eseguito FTK Imager.
Il testo esatto, che ritrovate al punto 1 delle Release Notes, è “Resolved a vulnerability where execution of malicious UFDR XMLs could lead to file exfiltration. (FCR-72008)“.
Gli UFDR (UFED Report) sono file comunemente utilizzati nell’ecosistema di mobile forensics Cellebrite per contenere e trasferire in una sorta di rapporto utilizzabile da chiunque (anche chi non possiede il software Cellebrite licenziato) il prodotto delle acquisizioni di dispositivi mobili e possono includere un file dal nome “report.xml” utilizzato per descrivere e organizzare i dati presenti nel report.
Exterro non fornisce ulteriori dettagli tecnici sulla vulnerabilità: non specifica quali versioni precedenti siano coinvolte, quali file potessero essere letti o con quali modalità potesse avvenire l’esfiltrazione ma cita solo, nelle relesase notes associate a questa versione di FTK Imager, che hanno “resolved a vulnerability where execution of malicious UFDR XMLs could lead to file exfiltration. (FCR-72008)“.
Il termine utilizzato da Exterro – file exfiltration – merita infine particolare attenzione: una workstation forense può contenere contemporaneamente dati provenienti da procedimenti differenti, copie forensi, esportazioni e portable case, report forensi, documentazione riservata e informazioni relative ad altri incarichi. Consideriamo poi che, per il tipo di attività svolto dagli informatici forensi, gli strumenti in ambito digital forensics vengono frequentemente utilizzati con privilegi elevati.
Questo non significa che FCR-72008 consentisse necessariamente di accedere a tutti questi dati: le informazioni pubblicate da Exterro non permettono di stabilire quali file fossero accessibili né quali fossero i limiti della vulnerabilità, ma il problema e il termine “malicious UFDR XMLs” insieme a “file exfiltration” evidenzia perfettamente perché una workstation forense debba essere considerata un ambiente nel quale vengono continuamente elaborati input potenzialmente ostili e quindi mantenuta offline, protetta, separata o comunque con controlli di sicurezza più stringenti di altri sistemi di lavoro.
La descrizione fornita da Exterro però fa pensare a una possibile vulnerabilità legata al parsing XML, ad esempio della famiglia XXE (XML External Entity), attraverso la quale un XML opportunamente costruito può in determinate condizioni provocare l’accesso a file locali e persino la loro trasmissione verso sistemi remoti: non ci sono però elementi sufficienti per affermare che FCR-72008 fosse effettivamente una XXE, quindi per ora rimane soltanto un’ipotesi tecnica.
La vulnerabilità evidenziata è però interessante soprattutto perché ricorda un aspetto a volte sottovalutato nell’informatica forense: i dati che analizziamo non sono necessariamente passivi e non è la prima volta che questo tipo di vulnerabilità viene messa in risalto. Siamo abituati a utilizzare write blocker, copie forensi e hash per evitare di modificare il reperto, ma dobbiamo considerare anche il problema opposto: proteggere la workstation forense dal materiale che stiamo analizzando. Un’immagine forense, un archivio, un documento o, come in questo caso, un XML possono essere costruiti appositamente per sfruttare una vulnerabilità del software utilizzato per elaborarli.
Il caso degli UFDR è ancora più interessante perché si tratta di file che possono essere ricevuti da clienti, colleghi, controparti o altri laboratori e che l’informatico forense apre normalmente proprio per svolgere il proprio lavoro ma chi li riceve non necessariamente è abituato agli aspetti di sicurezza.
Da qui l’importanza non soltanto di mantenere aggiornati gli strumenti forensi, ma anche di limitare e controllare le connessioni in uscita dalle workstation di analisi, separare quando opportuno gli ambienti di lavoro e trattare qualunque evidenza ricevuta da terzi come input potenzialmente non fidato.
Certamente è bizzarro che un software di generazione copie forensi di memorie di massa o RAM e apertura delle stesse, come è FTK Imager, sia soggetto a questo tipo di bug, ipotizziamo però che possa essere legato alla versione più “grande” e “completa” del software, quella a pagamento chiamata “FTK Imager Pro”, che invece è dotata di funzionalità di mobile forensics che magari sono state comunque inserite in maniera embrionale anche nel “fratellino” FTK Imager Free.
FTK Imager Free Vs FTK Imager Pro
Avendo tirato in ballo la versione commerciale di FTK Imager, può avere senso ribadire quali sono le differenze con la versione gratuita, con la quale ora pare che condivida anche il sistema di gestione delle licenze CodeMeter, come avremo modo di osservare più avanti quando parleremo della versione FTK Imager Portable o FTK Imager Lite.
Accanto al tradizionale FTK Imager gratuito, Exterro propone ora anche FTK Imager Pro, versione a pagamento che mantiene le normali funzioni di imaging, preview, esportazione, hashing e montaggio delle immagini forensi, aggiungendo però alcune possibilità interessanti soprattutto per attività di triage e acquisizione sul campo. La differenza principale è che la versione Pro permette di effettuare acquisizioni Advanced Logical da dispositivi iOS, rilevare la presenza di cifratura e accedere ai dati cifrati quando sono disponibili le credenziali o le chiavi necessarie. In particolare, Exterro indica la possibilità di riconoscere oltre dieci sistemi di cifratura e, nel caso di BitLocker, di visualizzare o acquisire direttamente i dati decifrati dal dispositivo senza dover prima creare una copia cifrata completa.
Un’altra differenza interessante riguarda il modo di lavorare: mentre FTK Imager Free rimane essenzialmente uno strumento gratuito per acquisire, verificare e visualizzare evidenze digitali, la versione Pro punta maggiormente sul triage, permettendo di esaminare rapidamente il contenuto del dispositivo e procedere poi con un’acquisizione mirata soltanto dei file, delle cartelle o degli artefatti ritenuti rilevanti. L’obiettivo è evitare, quando non necessario, l’acquisizione completa di grandi quantità di dati, riducendo tempi, spazio occupato e successive attività di processing. Exterro propone quindi FTK Imager Pro non tanto come sostituto del classico Imager, quanto come sua estensione verso workflow di acquisizione più selettivi, gestione della cifratura e prime attività sul mondo mobile. Al momento la licenza viene proposta a 499 dollari l’anno per utente, mentre FTK Imager continua a essere utilizzabile gratuitamente e senza licenza.
Le altre correzioni e novità della release 8.3.0.27
A parte i fix sulla gestione dei report UFDR di Cellebrite, FTK Imager 8.3.0.27 corregge anche un problema nella gestione delle password VeraCrypt/TrueCrypt: inserendo una password errata, la precedente versione poteva accettarla senza mostrare il relativo errore.
È stato inoltre aggiornato il vecchio driver “ad_driver.sys”, eliminando dall’installer la versione precedente: è sempre strategico, in informatica forense, utilizzare driver e software aggiornati, quindi ben venga che ogni tanto i produttori pubblichino update.
Come le versioni 8.x.x.x di FTK Imager, anche questa ha una caratteristica che la serie 4.x.x.x non aveva: il software di licensing CodeMeter, di cui viene richiesta l’installazione durante l’installazione di FTK Imager: senza installare CodeMeter o cliccando su CANCEL alla richiesta, il processo d’installazione s’interrompe.
Sono disponibili varie opzioni d’installazione del CodeMeter Runtime Kit v.8.20 in base alle preferenze dell’utente, ma non cambiano l’esito dell’installazione e utilizzo di FTK Imager Free.
Ci si potrà chiedere se la versione FTK Imager funziona comunque in maniera portable (o lite) nonostante la necessità del software di gestione licenze CodeMeter: vedremo che non è un problema, probabilmente Exterro lo richiede per la vicinanza con il software FTK Imager Pro ma abbiamo notato che disinstallando il software di licensing CodeMeter, una volta installato FTK Imager Free, questo continua comunque a funzionare.
Vale la pena aggiornare?
Le patch inserite in questa versione di FTK Imager non sono molte ma sono significative e importanti soprattutto per la sicurezza: per chi utilizza FTK Imager nelle attività di acquisizione e analisi forense, quindi, questa è una versione che vale la pena aggiornare.
Raccomandiamo di aggiornare non tanto per nuove funzionalità, quanto per rafforzare la propria sicurezza e in qualche modo rimarcare anche un buon promemoria operativo: dobbiamo certamente proteggere il reperto dall’analista (e lo facciamo con write blocker, hardware o software) ma anche l’analista e la sua infrastruttura dal reperto.
Link di download di FTK Imager in versione gratuita
Il file archivio zip “FTK Imager 8.3.0.27.zip” contenente l’installatore di FTK Imager in versione 8.3.0.27 produce valore hash MD5 7535e5ff1db098741716d802183798a1, SHA1 8779f5c34877d9aa4af56de5d84906ecbf20eb20 e SHA256 0f717d0d91c94af94107775ae37c2e330cc2a2312a8eecc91a344c8010e82afe.
L’eseguibile “Exterro_FTK_Imager_(x64).exe” produce invece valore hash MD5 8eb09425e8d47406df1f88d335989d81, SHA1 f39f8d3012efa31b033c78eadbd9b953685d26e9 e SHA256 1ec9500126b9b33e79e8178ffa12104377f2b77ddc8fca69d8fa1068d8e360d8.
Consigliamo sempre di verificare che il download di FTK Imager avvenga dal sito ufficiale, dato che il suo utilizzo in informatica forense è strategico ma anche delicato per via dei danni che potrebbe fare un software malevolo o difettoso.
Ricordo che il software FTK Imager è installabile su Windows ma è possibile anche crearne una copia portatile (un tempo veniva chiamata “FTK Imager Lite) che non richiede installazione ma può essere utilizzata direttamente su PC lanciandone l’eseguibile, ad esempio per attività di triage o incident response o ancora per procedere a copia forense “a caldo” di un PC con il sistema operativo Windows avviato.
Spesso si procede copiando la versione “FTK Imager Portable” (generata autonomamente secondo le istruzioni che troverete più avanti) su di una pendrive, così da poterla poi utilizzare su qualunque PC senza necessità d’installazione.
Quando installerete FTK Imager su di un PC con Windows, troverete le librerie DLL necessarie per la sua esecuzione all’interno della cartella “C:\Program Files\AccessData”: tali librerie sono sufficienti per eseguire il tool FTK Imager in modalità portable anche su altri PC senza installarlo, ma avviandolo direttamente da una pendrive o da una risorsa di rete.
Per poter estrarre la versione FTK Portable, è sufficiente copiare tutta la cartella d’installazione, volendo la si può anche comprimere così da poterla più agevolmente portare sul campo, così da evitare di sporcare il sistema con una nuova installazione.
La Polizia Postale ha pubblicato di recente sul sito web e su Linkedin un documento di allerta sugli attacchi 0click su Whatsapp, dando finalmente concretezza e “istituzionalità” a un fenomeno di cui parliamo ormai da mesi.
Il team Forenser è stato infatti tra i primi a identificare gli attacchi comparsi a maggio, analizzarli e persino riprodurli riuscendo a replicare la sessione di un account di test che simula la vittima, leggere i messaggi cifrati scambiati con i contatti e inviarne al posto suo.
Si tratta infatti di uno scenario che lo Studio d’Informatica Forense della società Forenser Srl aveva già analizzato e segnalato a Meta nei mesi precedenti, durante la prima ondata di maggio, seguita poi da una seconda e ora una terza.
Ricordo le caratteristiche dell’attacco 0click alla chiave di sessione di Whatsapp, ottenute mettendo a confronto i diversi casi raccolti nei mesi:
tutti i casi rilevati riguardano iPhone (dal modello 8 al 14, incluse le varianti X, XR, XS, 11, SE, 12 e 13) su cui è installata un versione di iOS 16 nelle sue diverse release;
gli attaccanti scrivono in chat ai contatti della vittima, dal numero WhatsApp della vittima stessa, chiedendo di disporre bonifici;
gli attaccanti sembrano avere accesso alle sole chat recenti, ovvero a quelle con cui la vittima ha interagito da poco;
nessun dispositivo collegato è visibile nella sezione “Dispositivi collegati” (o “Linked devices”) delle impostazioni di WhatsApp;
le vittime non riportano di aver compiuto alcuna azione di pairing particolare: non hanno fornito codici, non hanno inquadrato QR code, non hanno autorizzato accessi, da qui il tipo di attacco definito “zero click” o “0-click”, cioè che non richiede neanche un click da parte della vittima per essere portato a segno.
Per queste ragioni è stato sin da subito evidente che non si trattasse di un classico episodio di ghost pairing (nel quale l’attaccante induce la vittima a scansionare un QR code o a condividere un codice di verifica): l’assenza di qualsiasi interazione richiesta all’utente fa propendere per una compromissione di tipo 0-click, cioè per un’infezione che non richiede alcun intervento da parte della vittima e che colpisce direttamente lo smartphone o l’app WhatsApp.
Dopo la segnalazione a Meta, che ha preso in seria considerazione la comunicazione prodotta da Forenser, il team ha proseguito la ricerca e replicato in laboratorio lo scenario osservato, riuscendo a riprodurre lo scenario 0-click. Su dispositivi di test, un client su PC ha acquisito la sessione della vittima, letto le chat recenti e inviato messaggi come titolare dell’account: questo è il passaggio sperimentale che sviluppa quanto documentato nel precedente articolo.
Ricordo che l’attacco colpisce smartphone iPhone con versioni obsolete di iOS di Apple, delle quali per alcune versioni Apple distribuisce versione con patch (iOS 16.7.16 per i dispositivi fermi a iOS 16 e iOS 17.7.11 per i dispositivi fermi a iOS 17) ma spesso gli utenti – per mancanza di spazio o di tempo – non aggiornano.
Per chi pensa che i dispositivi che supportano iOS 16 siano pochi o vecchi, qui di seguito possiamo osservare come modelli anche recenti supportano iOS 16 e spesso anzi non vengono aggiornati, rimanendo su tale versione anche precedente alla 16.7.16 che sarebbe certamente più sicura perché contiene diverse patch di sicurezza.
Matrice iOS o iOS Matrix con versioni sistema operativo e modello iPhone
Un aspetto importante, quando si parla di dispositivi ancora esposti a vulnerabilità che riguardano iOS 16 o iPadOS 16, è distinguere tra i modelli che possono ancora eseguire queste versioni e quelli che, invece, non possono proprio – anche volendo -essere aggiornati a una major release successiva.
Per quanto riguarda gli iPhone, iOS 16 è compatibile con un intervallo piuttosto ampio di dispositivi, che parte da iPhone 8, iPhone 8 Plus e iPhone X e arriva fino alla generazione iPhone 14, comprendendo quindi anche iPhone XR, XS e XS Max, iPhone SE di seconda e terza generazione e tutte le serie iPhone 11, 12 e 13. All’interno di questo insieme, però, solo iPhone 8, iPhone 8 Plus e iPhone X sono rimasti definitivamente sulla famiglia iOS 16, perché non supportano iOS 17 e versioni successive. Per questi modelli, quindi, iOS 16 rappresenta effettivamente l’ultima major release disponibile.
Il discorso è simile per gli iPad, anche se la frammentazione tra generazioni è maggiore. iPadOS 16 è compatibile con numerosi modelli, a partire da iPad di quinta generazione, iPad mini di quinta generazione, iPad Air di terza generazione e diverse generazioni di iPad Pro. Anche in questo caso, però, soltanto alcuni dispositivi sono rimasti confinati a iPadOS 16: in particolare iPad di quinta generazione, iPad Pro da 9,7 pollici e iPad Pro da 12,9 pollici di prima generazione.
Questo significa che il numero di dispositivi potenzialmente ancora presenti su iOS o iPadOS 16 non coincide con il solo insieme dei modelli “bloccati” a quella versione ma è ben più ampio. Una quota, probabilmente minoritaria ma non trascurabile, può infatti essere costituita anche da dispositivi più recenti che supportano versioni successive del sistema operativo ma che, per scelta dell’utente, mancato aggiornamento o particolari condizioni d’uso, continuano ancora oggi a eseguire una release della famiglia 16.
Matrice iPad OS o iPad OS Matrix con versioni sistema operativo e modello iPhone
Ricordiamo infatti che, nella realtàmolte persone non aggiornano i loro sistemi perché hanno paura che questi rallentino, scaldino o consumino più spesso la batteria. Non aggiornano perché hanno paura di fare dei danni. Non aggiornano perché non hanno tempo per farlo o a volte semplicemente non hanno abbastanza spazio sul loro iPhone per poter completare correttamente l’aggiornamento, che a volte magari parte e non si conclude correttamente o non parte neanche.
In sostanza, ci sono milioni di persone che rimangono con sistemi operativi obsoleti per diversi motivi e quindi vulnerabili, spesso non aggiornati neanche alle versioni con le patch che Apple continua a produrre, anche per i dispositivi più vecchi.
Il problema, che non emerge dai report che circolano, è che è vero che l’attacco alla sessione Whatsapp di Meta per ora sfrutta CVE su versioni obsolete di iOS, ma potrebbe benissimo funzionare anche con versioni più recenti nel caso in cui circolassero 0click anche per quelli
Purtroppo l’impostazione di una verifica a due passaggi 2FA e il check dei dispositivi connessi non serve a limitare né rimuovere l’infezione: l’unica precauzione è aggiornare la versione di iOS, se possibile portandola alla 26.
Se già infetti aggiornare può non essere sufficiente – dato che c’è stata sottrazione della session di WhatsApp – ed è necessario anche ripristinare il telefono allo stato di fabbrica, oltre che reinstallare Whatsapp in versione aggiornata.
L’articolo completo della società d’informatica forense di Torino, con aggiornamenti e ulteriori dettagli sull’attacco a Whatsapp di cui ha parlato di recente la Polizia Postale, è visionabile online sul sito della società Forenser.
