venerdì,Dicembre 13 2024

Esclusivo, inchiesta Exodus: ecco come funzionava lo spyware

Ieri l’incidente probatorio a Napoli dell’inchiesta su “Exodus”. Ecco cosa scrive il perito della procura sulle intercettazioni illegali.

Esclusivo, inchiesta Exodus: ecco come funzionava lo spyware

Come anticipato da Cosenza Channel, nella giornata di ieri si è svolto l’incidente probatorio dell’inchiesta “Exodus”, coordinata dalla procura di Napoli circa il mal funzionamento del software intercettivo che avrebbe violato ogni regola, captando milioni di conversazioni telefoniche. Tra le società indagate, oltre all’azienda dei Fasano di Catanzaro, c’è anche l’Stm di Pietrafitta, che aveva preso a noleggio lo spyware (LEGGI QUI LE ALTRE SOCIETA’ COINVOLTE). 

Nel corso dell’incidente probatorio, che è servito per cristallizzare una mezzi di prova del processo, il consulente tecnico della procura di Napoli, ha risposto a diversi quesiti circa la capacità di Exodus di penetrare nelle vite private degli italiani, ascoltati involontariamente dalle varie procure italiane, che avevano scelto di affidarsi, a loro volta, alle aziende che utilizzavano quel programma. 

I quesiti e le risposte dell’ingegnere Francesco Picasso

L’ingegnere Francesco Picasso, ha spiegato che «la piattaforma “EXODUS” oggetto di acquisizione e analisi era ospitata presso il fornitore di servizi Amazon AWS (Amazon Web Service): con l’esclusione di alcuni sistemi e servizi marginali rispetto al funzionamento della piattaforma, essa era geograficamente collocata nella regione Amazon AWS us-west-2, in Oregon, U.S.A. L’applicazione web adibita a ricevere e memorizzare i dati ricevuti dai dispositivi sotto intercettazione era in esecuzione sul sistema denominato frontend: tale applicazione contemplava altresì la logica di accesso e gestione dei dispositivi e dei dati da parte degli utenti registrati. L’applicazione provvedeva a salvare i dati ricevuti dai dispositivi oggetto di intercettazione su file all’interno delle apposite cartelle ospitate nel volume da 6TB collegato al sistema di frontend: ogni cartella di primo livello in tale volume, infatti, aveva nome corrispondente all’identificativo, tipicamente l’IMEI, del dispositivo che inviava i dati».

Password in chiaro

La procura di Napoli, in uno dei quesiti posti al perito, ha chiesto Chi poteva accedervi e per mezzo di quali meccanismi di sicurezza e il consulente ha chiarito che «Per potersi collegare all’applicazione di frontend, un utente doveva conoscere il nome della propria utenza e la relativa password: tali due campi erano memorizzati all’interno della tabella users del database. Non era presente un’autenticazione multi-fattore né le utenze della tabella users erano collegate, ad esempio, ad un indirizzo email: infine, le password erano mantenute in chiaro all’interno del database. L’inserimento di una utenza in tale tabella non era possibile dal frontend stesso, pertanto era necessario un intervento manuale, o tramite codice esterno alla piattaforma, per poter aggiungere o rimuovere una utenza da tale tabella: il Perito non è stato in grado di individuare tale meccanismo. 

Come accedere al database

Una seconda tabella, denominata utenti, veniva gestita dalle utenze che avevano accesso “amministrativo” all’applicazione di frontend e potevano autonomamente creare, abilitare, disabilitare altre utenze o gruppi di utenze: le utenze così create prevedevano altresì campi quali nome, cognome, note, gruppo oltre a username e password». Picasso ha poi aggiunto che «vi erano più possibilità di accesso al frontend da parte degli utenti, fermo restando l’utilizzo del protocollo https per potervi accedere. I sistemi appartenenti alla piattaforma utilizzati per poter raggiungere il frontend erano IPSEC ENDPOINT e RPC: entrambi avevano configurati tunnel ipsec verso, rispettivamente, 47 destinazioni e 3 destinazioni. Ogni tunnel ipsec realizza un canale di comunicazione sicuro con uno dei due sistemi exodus». Inoltre, ha evidenziato che «non risulta al Perito che le società avessero a disposizione le credenziali specifiche per l’accesso sistemistico o per l’accesso al database». 

Chi poteva accedere alle intercettazioni?

Circa, l’esistenza della possibilità per l’utilizzatore della piattaforma di accedere ad intercettazioni per le quali non si era data preventiva autorizzazione a suo esame, il perito ha concluso, affermando che «esisteva la possibilità per l’utilizzatore della piattaforma di accedere ad intercettazioni per le quali non si era data preventiva autorizzazione a suo esame».

Un altro dei quesiti posti dalla procura di Paola è stato quello di Risalire ove possibile agli utilizzatori della piattaforma autorizzati dall’autorità giudiziaria e a quelli che operavano in assenza di qualsiasi autorizzazione se esistenti. Sul punto, il perito Picasso ha rilevato che «Sulla base dell’assunto che un’utenza proveniente da un indirizzo IP italiano o da un indirizzo IP appartenente a uno dei sistemi di Exodus corrisponda a un utilizzo legittimo dell’utenza, il Perito ha isolato quelle utenze che si sono connesse al frontend con successo da indirizzi IP esteri: l’ipotesi o, meglio, un punto di partenza, è che esse costituiscano il primo livello di controllo in grado di isolare potenziali utenze abusive o abusate. È evidente come già l’assunto sia debole, sia per quanto concerne l’IP geolocalizzato in Italia sia per gli indirizzi appartenenti ai sistemi exodus: si ricorda come questi ultimi facessero da “ponte” non solo per le connessioni attraverso i tunnel ipsec ma altresì per, sostanzialmente, qualsiasi altro IP pubblico, mascherandone almeno in parte la reale provenienza».

Articoli correlati