Consulente Informatico Forense specializzato in Perizie Informatiche e Consulenze Tecniche di Parte e d'Ufficio per privati, avvocati, aziende, Tribunali e Procure.
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.
Il Tribunale di Milano ha accertato la responsabilità professionale di un avvocato e la corresponsabilità del consulente tecnico autore della consulenza tecnica posta alla base dell’azione, a seguito di una causa civile instaurata contro un istituto di credito sulla base di una documentazione risultata insufficiente e di una consulenza tecnica ritenuta gravemente inadeguata.
Con la sentenza n. 6677 dell’11 agosto 2026, il Tribunale di Milano ha in particolare disposto la risoluzione dei rapporti professionali e condannato il legale alla restituzione dei compensi percepiti, oltre al risarcimento dell’ulteriore danno riconosciuto, rilevando nella motivazione anche la corresponsabilità del consulente autore della perizia tecnica sulla quale era stata fondata l’azione giudiziaria.
Secondo quanto emerge dalla decisione, infatti, la causa contro la banca era stata intrapresa senza aver preventivamente acquisito tutti gli elementi documentali che lo stesso legale considerava indispensabili per sostenerne le ragioni e facendo sostanzialmente affidamento su una consulenza tecnica di parte priva di una base documentale sufficiente e risultata metodologicamente e concettualmente errata, come già emerso nel giudizio dinanzi al Tribunale di Lucca anche attraverso le valutazioni del CTU ivi nominato.
Spiace ovviamente per le conseguenze patite dai professionisti – avvocato e consulente tecnico, nel caso specifico un commercialista incaricato di redigere la perizia econometrica – ma la sentenza offre uno spunto importante non soltanto per i legali, ma anche per chi opera quotidianamente nell’ambito della prova digitale quale il consulente informatico forense.
Prima di formulare conclusioni in una perizia informatica e, a maggior ragione, prima di instaurare un giudizio, occorre infatti sempre valutare quali evidenze siano effettivamente disponibili, quali possano essere acquisite direttamente dai sistemi del cliente – ove opportuno mediante copia forense – e quali debbano invece essere tempestivamente richieste a soggetti terzi: log di accesso e di traffico, tracciati e record bancari, tabulati, dati detenuti dai provider, informazioni presenti sui dispositivi e ogni altra evidenza tecnica potenzialmente rilevante.
Attenzione alla documentazione probatoria
La sentenza, sotto questo profilo, è particolarmente significativa perché evidenzia che la causa era stata instaurata senza disporre di documenti che lo stesso legale aveva indicato come indispensabili per sostenere le proprie conclusioni.
Il Tribunale ricostruisce infatti una sequenza temporale particolarmente eloquente: la documentazione bancaria era stata formalmente richiesta poco prima dell’introduzione della controversia, ma l’atto di citazione era stato predisposto senza attenderne l’acquisizione. La consulenza tecnica sulla quale l’azione si fondava era quindi stata elaborata senza disporre di una parte essenziale dei documenti contrattuali necessari a verificare proprio le anomalie che si sostenevano esistenti.
Il problema, dunque, non consiste semplicemente nell’aver perso una causa – tra l’altro, in tal senso, i professionisti hanno obbligo di mezzi e non di risultato – bensì l’avere formulato conclusioni tecniche e aver costruito su di esse una strategia processuale senza disporre degli elementi documentali necessari per verificarne preventivamente la fondatezza.
Anche questo è un principio che può essere agevolmente trasposto nell’ambito dell’informatica forense: un’ipotesi tecnica può essere ragionevole e meritevole di approfondimento, ma non per questo può essere trasformata in una conclusione peritale se i dati disponibili non consentono di dimostrarla o, quantomeno, la difficoltà va rappresentata ad avvocato e cliente/committente, che valuteranno – in particolare il legale – se ha comunque senso produrre un elaborato tecnico a supporto della strategia difensiva, anche se magari debole o basato su insufficienti elementi probatori.
Occorre distinguere chiaramente tra ciò che i dati dimostrano, ciò che rendono probabile, ciò che è soltanto compatibile con essi e ciò che, in assenza di ulteriori elementi, rimane una semplice ipotesi e, come vedremo più avanti, anche ciò che può confutare o indebolire la tesi difensiva.
La volatilità della prova digitale
Questo aspetto assume ancora maggiore rilievo nel mondo della prova digitale, spesso caratterizzata da una significativa volatilità, dovuta al fatto che per questioni di data retention, i dati spesso durano pochi giorni, settimane o quando va bene mesi, poi scompaiono.
Alcuni log vengono conservati soltanto per periodi limitati; determinati dati possono essere sovrascritti; account, servizi cloud e dispositivi possono cambiare stato; un computer o uno smartphone possono essere sostituiti, formattati, aggiornati, assegnati a nuovi soggetti o persino rotti o persi; un servizio online può modificare i propri sistemi di logging o le proprie politiche di conservazione, gli account possono scadere, essere chiusi o disabilitati.
Informazioni disponibili all’inizio della controversia potrebbero quindi non esserlo più quando viene disposta una CTU, magari mesi o anni dopo: per questo motivo non è sufficiente domandarsi quali prove serviranno durante il processo, è necessario valutare anche quando quelle prove debbano essere acquisite e preservate.
In alcuni casi potrebbe essere opportuno procedere immediatamente a una copia forense del dispositivo o dei dati – anche remoti, in cloud, su account online – disponibili; in altri occorrerà inviare tempestivamente una richiesta di conservazione o acquisizione a un soggetto terzo; in altri ancora sarà necessario valutare insieme al legale quali strumenti processuali possano consentire di ottenere dati non direttamente accessibili alla parte.
Legittimità di acquisizione e utilizzo di evidenze digitali
Esiste poi un secondo problema, distinto dalla mera conservazione tecnica dell’informazione: anche quando il dato continua materialmente a esistere, non è detto che possa essere acquisito o prodotto nel procedimento in qualunque momento. Mai dimenticare che disponibilità tecnica, possibilità pratica di acquisizione forense, producibilità in Giudizio, ammissibilità e utilizzabilità processuale non sono necessariamente la stessa cosa.
Un dato che sarebbe stato possibile ottenere e produrre tempestivamente può risultare molto più difficile – o in alcuni casi impossibile – da introdurre nel processo quando siano già maturate determinate preclusioni, questo rende ancora più importante il coordinamento tra legale e consulente tecnico nelle fasi iniziali della controversia: il consulente deve sapere non soltanto quali informazioni potrebbero avere valore tecnico, ma anche quali siano le esigenze e le tempistiche processuali entro le quali devono essere identificate, acquisite e messe a disposizione del difensore.
Acquisire ma valutare cosa produrre in Giudizio
Esiste però anche il problema opposto: non sempre acquisire indiscriminatamente grandi quantità di informazioni e riversarle integralmente nel procedimento costituisce la scelta migliore. Una corretta attività forense dovrebbe certamente preservare le fonti rilevanti nella maniera più completa possibile, ma acquisizione, analisi e produzione processuale sono momenti differenti.
È perfettamente possibile – e spesso opportuno – acquisire integralmente una fonte digitale per garantirne la conservazione e l’autenticità, per poi individuare attraverso l’analisi gli elementi effettivamente pertinenti alle questioni oggetto del procedimento.
Prima di produrre documentazione tecnica occorre inoltre conoscerne realmente il contenuto: capita più frequentemente di quanto si possa immaginare che un’e-mail, un file di log, uno screenshot, i metadati di un documento o una porzione di una timeline contengano elementi che non rafforzano la ricostruzione inizialmente prospettata ma, al contrario, la indeboliscono, la contraddicono oppure offrono alla controparte una diversa chiave interpretativa dei fatti.
Il compito del consulente tecnico non è ignorare questi elementi, al contrario, una seria analisi forense deve individuarli, contestualizzarli e segnalarli al legale, affinché quest’ultimo possa valutare consapevolmente la strategia processuale e informare correttamente il cliente.
Un consiglio, in tal senso, è quello di acquisire separatamente le evidenze digitali, in modo da poterle poi eventualmente scorporare, produrne soltanto una parte (ad esempio quella positiva) ed escluderne un’altra (ad esempio quella negativa, superflua o neutra) senza che ciò che viene prodotto in causa possa subirne un’influenza.
La qualità dell’evidenza digitale
Un ulteriore insegnamento riguarda il rapporto tra completezza dell’evidenza e forza delle conclusioni: la sentenza prende in esame una perizia che aveva quantificato differenze economiche molto rilevanti pur in assenza di documenti contrattuali che risultavano necessari per verificare alcune delle anomalie ipotizzate. Il problema metodologico, in termini generali, è evidente: quanto più incompleto è il dato di partenza, tanto maggiore deve essere la cautela nella formulazione delle conclusioni.
Nell’informatica forense lo stesso principio vale in modo trasversale: l’assenza di una parte dei log, l’indisponibilità del dispositivo originario, una timeline incompleta, la mancanza di dati lato server o l’impossibilità di validare un artefatto possono non impedire ogni valutazione, ma vi è il rischio che incidano sul livello di confidenza attribuito alla conclusione.
Una relazione tecnicamente corretta dovrebbe quindi dichiarare con chiarezza quali fonti sono state esaminate, quali non erano disponibili, quali assunzioni sono state necessarie e con quale grado di certezza o probabilità può essere sostenuta ciascuna conclusione, anche se sta sempre poi al legale valutare come giustificare l’inserimento di una prova piuttosto che un’altra, specificando eventuale indisponibilità, mancata opportunità o semplicemente non motivando l’assenza dei dati non prodotti.
La valutazione preliminare delle evidenze digitali
Per questo motivo, una corretta strategia processuale dovrebbe partire, nei casi nei quali la componente tecnica ha un peso significativo, da una vera e propria valutazione preliminare delle evidenze digitali, fatta dal legale con lo stretto supporto del consulente informatico forense.
Ricordiamo che avvocato e consulente tecnico di parte devono, per massimizzare la possibilità di vittoria e minimizzare quella di soccombenza, collaborare per pesare ogni singola evidenza digitale e l’opportunità (o il rischio) di utilizzo in causa.
Questa fase preliminare permette di comprendere non soltanto quali siano gli elementi favorevoli, ma anche quali prove manchino, quali non siano più acquisibili, quali presentino limiti tecnici e quali possano addirittura essere incompatibili – se non contrarie – con la ricostruzione prospettata dal cliente.
Il consulente tecnico e la tesi difensiva
Questo è probabilmente questo uno degli insegnamenti più interessanti che la vicenda può offrire a chi svolge attività di consulenza tecnica: il ruolo del consulente di parte non dovrebbe essere quello di costruire a posteriori una spiegazione tecnica compatibile con la tesi del proprio cliente, ma di sottoporre quella tesi a verifica.
Ciò significa ricercare gli elementi che la sostengono, ma anche quelli che potrebbero smentirla: verificare ipotesi alternative, esplicitare le assunzioni sulle quali si fondano le conclusioni, distinguere i fatti accertati dalle inferenze e dalle semplici possibilità tecniche.
Una perizia di parte metodologicamente debole – o formulata sulla base di dati insufficienti – non soltanto rischia di essere confutata dal CTU o dal consulente della controparte, ma può finire per compromettere l’intera impostazione della controversia.
Ancora più rischiosa è una consulenza nella quale le conclusioni siano state formulate prima di aver acquisito e analizzato le evidenze necessarie a verificarle, a meno che ovviamente tale formulazione non sia condivisa dal legale per strategia processuale e si decida di utilizzarla pur in mancanza di solide basi probatorie.
Il rapporto tra avvocato e consulente tecnico
La sentenza contiene anche un passaggio di particolare interesse sul rapporto tra competenza giuridica e competenza tecnica: il Tribunale osserva infatti che l’avvocato non poteva semplicemente sostenere di non essere in grado di verificare le valutazioni specialistiche contenute nella perizia.
Non si pretende naturalmente che il legale sostituisca il consulente tecnico nello svolgimento delle analisi tecniche, ma che eserciti almeno quel controllo necessario a verificare che le conclusioni sulle quali intende fondare l’azione siano basate su dati oggettivi, specifici e sufficientemente documentati.
Il principio è importante perché definisce correttamente i due ruoli: il consulente tecnico deve rispondere della metodologia utilizzata, dei dati analizzati, delle inferenze formulate e dei limiti delle proprie conclusioni mentre l’avvocato deve comprendere quale sia il valore probatorio di quelle conclusioni, verificarne la coerenza con la strategia processuale e chiedere gli approfondimenti necessari prima di farne il fondamento di un’azione giudiziaria.
Questo dovrebbe ricordare che lato legale e tecnico non sono due attività indipendenti che si incontrano soltanto al momento del deposito di una relazione tecnica, ma di competenze differenti che dovrebbero dialogare fin dalle prime fasi della controversia.
Quando le prove digitali non sono sufficienti
C’è infine un altro passaggio della sentenza che merita particolare attenzione: il Tribunale richiama espressamente il dovere dell’avvocato di informare, sollecitare e, ove necessario, dissuadere il cliente dall’intraprendere o proseguire un giudizio dall’esito probabilmente sfavorevole.
Il punto è che affinché il legale possa assolvere correttamente questo compito, quando il contenzioso dipende in misura significativa da questioni informatiche deve poter disporre di una valutazione tecnica sufficientemente affidabile, chiara, onesta e completa, al punto da includere, magari in via riservata, anche note sugli elementi mancanti o persino contrari alla linea difensiva.
Questo significa che anche il consulente dovrebbe avere la capacità – e l’indipendenza professionale – di dire che i dati disponibili non consentono di raggiungere la conclusione desiderata dal cliente o, peggio ancora, che parte delle prove potrebbe smontare la tesi legale.
Un risultato negativo, inconcludente o incompatibile con l’ipotesi iniziale non costituisce necessariamente il fallimento dell’attività forense: può invece essere proprio l’informazione che consente al legale e al cliente di evitare un contenzioso privo di sufficienti basi probatorie, l’importante è essere chiari, anticipare le possibili mosse/contestazioni di controparte, pensare a cosa il legale potrebbe dover conoscere per poter fare le sue valutazioni.
Dove scaricare la Sentenza del Tribunale di Milano
È possibile ottenere il download gratuito della Sentenza n. 6677 dell’11 agosto 2026, proc. RG 45156/2021 del Tribunale di Milano presso la Banca Dati di Merito del Ministero della Giustizia accedendo al portale BDP Giustizia all’indirizzo https://bdp.giustizia.itaccedendo con SPID o CIE: il servizio è gratuito per tutti i cittadini italiani e si possono scaricare direttamente i PDF di sentenze, decreti e ordinanze provenienti dal SICI.
All’interno della Banca Dati sono disponibili gratuitamente per la ricerca, la consultazione e il download degli abstract e i provvedimenti civili (sentenze, decreti e ordinanze) provenienti dal Sistema Informatico del Settore Civile (SICI) dal 01/01/2016 ad oggi.
La Banca Dati BDP del Ministero della Giustizia non include i provvedimenti relativi a famiglia, minori e stato persona ed è stata progettata per fornire un accesso agevole e affidabile a provvedimenti pubblicati in ambito civile.
Per scaricare direttamente la Sentenza n. 6677 dell’11 agosto 2026, proc. RG 45156/2021 del Tribunale di Milano e avviare il download del PDF del documento pubblico è sufficiente collegarsi alla banca dati BDP e inserire i dati della sentenza:
Distretto: MILANO
Ufficio: TRIBUNALE DI MILANO
Numero: 6677
Anno: 2026
A questo punto è sufficiente cliccare sul bottone Ricerca per ottenere la sentenza desiderata.
In alternativa, si può accedere direttamente alla Sentenza n. 6677 dell’11 agosto 2026, proc. RG 45156/2021 del Tribunale di Milano (NRG 45156/2021 deposito minuta 11/08/2026, pubblicazione 11/08/2026) cliccando direttamente su questo link, conformato per ottenere la sentenza specifica senza aprire i risultati della ricerca.
Conclusioni
In base a quanto abbiamo rilevato con l’analisi della sentenza, possiamo concludere che prima di iniziare una causa è fondamentale che l’avvocato, anche grazie al supporto del consulente tecnico, abbia piena consapevolezza non soltanto delle prove favorevoli, ma anche di quelle mancanti, non più acquisibili, tecnicamente insufficienti, ambigue o addirittura contrarie alla tesi che si vorrebbe sostenere, valutando con lucidità il rischio processuale che ne deriva e mettendo il cliente nella condizione di assumere una decisione realmente informata.
La digital forensics, in altre parole, non dovrebbe servire soltanto a produrre una perizia informatica quando la causa è già iniziata, ma dovrebbe intervenire prima, per verificare se esistano realmente evidenze sufficienti per iniziarla e, soprattutto, per comprendere con quali limiti quelle evidenze consentano di sostenere la ricostruzione che si intende portare in giudizio.
Nota metodologica
Le considerazioni in materia di prova digitale contenute in questo articolo costituiscono un’estensione tecnico-professionale dei principi e dei fatti esaminati nella sentenza n. 6677 dell’11 agosto 2026, proc. RG 45156/2021, Tribunale di Milano.
Precisiamo che il provvedimento riguarda una controversia in materia bancaria e una perizia econometrica, non una perizia informatica e il consulente coinvolto nella causa non è un consulente informatico forense bensì un commercialista: i riferimenti a copia forense, log, dati dei provider, dispositivi, volatilità e analisi delle evidenze digitali sono quindi applicazioni generali ai contesti di informatica forense che ho voluto utilizzare per contestualizzare il problema in un’area che ritengo compatibile con quanto descritto in sentenza, non si tratta di affermazioni testuali del Tribunale su tali specifici strumenti, come si può peraltro verificare scaricando la sentenza originale dal sito della Banca Dati di Merito del Ministero della Giustizia.
