Intelligenza Artificiale, il cambiamento delle organizzazioni

Tra qualche giorno, il 29 e 30 novembre, presso l'Ufficio Generale Innovazione Difesa - UGID (ex Centro Innovazione della Difesa - CID), nel contesto dell’open-innovation, si terrà la terza Conferenza sull’Innovazione della Difesa 2021 dal titolo: «Intelligenza Artificiale, il cambiamento delle organizzazioni».

Con questa conferenza il network INNOV@DIFESA chiude l’anno di riflessioni sull’argomento, con la certezza di essersi avvicinato all’Intelligenza Artificiale secondo un approccio olistico esaminando, oltre agli aspetti prettamente tecnologici, anche temi che vanno dalla geopolitica sino all’etica e alla filosofia.

Dopo i primi due workshop focalizzati sulle “Implicazioni Etiche, Legali e Psicologiche (aprile 2021) e sulle “Nuove esigenza formative e competenze digitali, e-leadership ed evoluzione dei processi decisionali” (luglio 2021), di cui abbiamo già parlato in un precedente articolo, l’evento conclusivo sul tema del “Cambiamento delle Organizzazioni” si articolerà in due giornate.

Il 29 novembre in due diversi panel saranno approfonditi gli aspetti relativi all'Intelligenza Artificiale in termini di cambiamenti organizzativi e di velocità dei processi decisionali.

In particolare, il primo panel (CAMBIAMENTI ORGANIZZATIVI - Gestione dei dati e adeguamenti organizzativi) sarà moderato dal direttore di Difesa Online, Andrea Cucco e vedrà la presenza, tra gli altri, del Prof. Gaspari, del Prof. Pratesi (EIIS) e dell' Ing.Costaglioli (IMPECO). Nel panel si analizzeranno i riflessi organizzativi dell'impiego della Intelligenza Artificiale e dell'importanza della gestione dei dati, l'oro dell'era digitale, con particolare riguardo a:

- Evoluzioni delle organizzazioni

- Big Data e Data Management

- Sostenibilità delle organizzazioni .

Il secondo panel (VELOCITÀ DEI PROCESSI DECISIONALI - Opportunità e sfide legate all’evoluzione della competizione) sarà moderato dal Prof. Andrea GEREMICCA (EIIS) e vedrà la presenza, tra gli altri, del Prof.Quercia (UniPerugia), dell' Avvocato Magro (UniMarconi), del Prof.Castiello e dell' Ing.Massa (LEONARDO). Nel panel si analizzeranno le opportunità offerte dall'Intelligenza Artificiale in relazione agli aspetti di:

- Data Governance

- Hyperwar

- Digital Space e Cognitive Warfare.

Il 30 novembre nel corso della tavola rotonda (INTELLIGENZA ARTIFICIALE: Intelligenza Artiiciale e Implicazioni per la Difesa), moderata dal Colonnello Claudio ICARDI e con la presenza, tra gli altri, dell' Avvocato PROVVIDERA, dell' Ing. PROIETTI (LEONARDO),

di SIAGRI (POLO), di LEONE (LUISS B.S.) e ORACLE, saranno illustrati ai vertici delle Forze Armate i risultati del ciclo di approfondimento annuale e analizzate le implicazioni per la Difesa.

In particolare si tratteranno le implicazioni dell'utilizzo dell’Intelligenza Artificiale nei seguenti campi:

- Digital Space: opportunità e rischi per la Sicurezza Nazionale

- Evoluzione del quadro giuridico di rierimento

- Implicazioni per la Difesa e ripercussioni nelle dimensioni degli

effetti (fisica, virtuale e cognitiva).

La partecipazione al network INNOV@DIFESA rende possibile condividere e esplorare le sempre rinnovate sfide e le opportunità future stimolando un ampio dibattito, tra il comparto industriale, il pensiero accademico e il mondo militare e contribuendo mirabilmente al rafforzamento dei reciproci legami.

Alessandro Rugolo e Maurizio D'Amato

Lo Smishing, questo sconosciuto

Si avvicina il Black Friday, evento commerciale di origine statunitense ma che per effetto della globalizzazione rappresenta un momento prenatalizio molto atteso anche da noi.

Si avvicina anche il Natale, che a lato di significati ben più elevati ha una caratterizzazione di spinta commerciale importante.

Questi due eventi comportano una propensione psicologica alla spesa, al regalo, all’acquisto. Propensione che si unisce all’enorme popolarità ottenuta negli anni scorsi da servizi di eCommerce e logistica consumer, amplificata dalla recente emergenza che ha ulteriormente diminuito la mobilità verso negozi tradizionali in favore di esperienze di acquisto online.

Questa tempesta perfetta rappresenta una situazione in cui la soglia di allerta nei confronti di truffe è a livelli davvero molto elevati, richiedendo proprio ai consumatori di raffinare la consapevolezza sui rischi per evitare conseguenze spiacevoli.

Il mondo cybercriminale ha infatti ben chiare queste tendenze, così come la necessità di trovare continuamente canali efficaci per scardinare la sicurezza di questa catena del valore a proprio vantaggio.

Una delle tecniche più utilizzate consiste nel prendere di mira l’utente tramite messaggi di social engineering trasmessi direttamente al telefono portatile.

Questi messaggi spesso contengono link malevoli, opportunamente studiati per carpire credenziali importanti per agire in nome e per conto della vittima. Oppure collegamenti a siti che contengono malware in grado di installarsi senza destare sospetti proprio negli smartphone, nei tablet o negli altri dispositivi che la vittima usa per visitare questi siti.

Questa tecnica prende il nome di Smishing, neologismo di recente conio che combina l’acronimo SM – per Short Message, cioè messaggio breve – con la parola Phishing – che indica proprio un attacco che sfrutti una serie di metodi per adescare utenti ignari e convincerli a intraprendere azioni dannose.

Lo Smishing ha alcune caratteristiche distintive, che cercherò di illustrare per aumentare in chi riceve il messaggio la resilienza a questo tipo di attacco – conosciuto secondo un report recente¹ solo da una frazione della popolazione americana tra il 22% e il 34% a seconda dell’età.

Una delle difficoltà principali è proprio determinare l’autenticità di un messaggio di testo, spesso proveniente da mittenti sconosciuti o numeri di telefono non codificati in rubrica.

Ulteriore fattore di rischio è che siamo abituati a vedere ed utilizzare nei messaggi di testo i cosiddetti Short URL, cioè collegamenti a siti strutturati per consumare pochi caratteri, ad esempio bit.ly oppure cutt.ly, seguiti da una breve sequenza di caratteri.

Quando questi indirizzi vengono utilizzati si collegano a sistemi intermedi che redirigono alla destinazione finale, permettendo agli attaccanti di mascherare efficacemente destinazioni malevole con un sistema utilizzato per molti indirizzi validi e leciti.

Stando a Gartner², diverse ricerche rilevano che il tasso di apertura degli SMS è intorno al 98%, rispetto ad un mesto 20% che caratterizza l’email.

Sempre secondo il report citato, gli attacchi di smishing sono aumentati del 328% nel 2020!

Come difendersi quindi?

Una contromisura importantissima è elevare la consapevolezza del rischio e l’allerta in ognuno di noi: se arriva un messaggio che c’è un pacco in consegna o in attesa all’Ufficio Postale con un link per ulteriori informazioni e noi siamo certi di non stare attendendo nulla, ignoriamo il messaggio.

I siti a cui questi link reindirizzano sono spesso cloni degli originali realizzati in modo estremamente accurato, persino nella capacità di effettuare autenticazione forte a più fattori.

L’attaccante infatti conosce il numero del vostro cellulare perché è l’informazione che gli ha permesso di inviarvi il primo messaggio di smishing.

Quindi, immesse le vostre credenziali vi farà credere che il processo di autenticazione richieda un ulteriore passaggio di immissione codice che riceverete – guarda caso – proprio sul cellulare.

Nel frattempo avrete fornito diligentemente ai criminali nome utente e password validi per Amazon, Paypal, Poste e altri servizi.

A volte questi messaggi sono estremamente credibili, puntano sull’instillare nel ricevente un senso di urgenza utilizzando un linguaggio apposito. Ad esempio: “non ricevendo risposta entro 24 ore rispediremo il pacchetto al mittente” oppure “in mancanza di una verifica entro 2 ore procederemo al blocco dell’account”.

Per dare un’ulteriore prospettiva di quanto questa metodologia di attacco sia un crescita, possiamo esaminare il report 2020 del reparto Internet Crime Complaint Center (IC3)³ dell’FBI americana: nel 2020 il numero delle vittime di queste tecniche di attacco – che includono phishing, smishing, vishing e pharming – sono state 240.000; per confronto, le vittime di attacchi virus o malware nello stesso anno sono state 1.400!

Le quattro tecniche menzionate prevedono tutte che l’attacco faccia leva sul social engineering per convincere la vittima ad eseguire azioni. Si differenziano per il mezzo trasmissivo perché phishing utilizza e-mail, smishing i messaggi brevi via SMS, vishing la chiamata vocale, pharming i siti web a cui la vittima viene diretta.

Facciamo molta attenzione quindi – soprattutto in questo periodo – a non accettare messaggini dagli sconosciuti. Se per errore ne scambiassimo uno vero per falso e la persona avesse davvero bisogno di contattarci, farà un altro tentativo o ci telefonerà (visto che ha il numero).

Procedere invece con un clic incauto potrebbe essere la causa di perdite finanziarie, di dati e della serenità di cui la stagione natalizia dovrebbe essere foriera.

Marco Rottigni

1 State of the Phish 2020: https://www.proofpoint.com/sites/default/files/gtd-pfpt-us-tr-state-of-the-phish-2020.pdf

2 https://www.gartner.com/en/digital-markets/insights/the-future-of-sales-follow-ups-text-messages

3 Link per approfondire: https://www.ic3.gov/Media/PDF/AnnualReport/2020_IC3Report.pdf

Trojan Source Attack, di che si tratta ?

Che ne direste se fosse possibile ingannare i compilatori affinché producano dei file binari differenti dalla logica visibile agli occhi umani nel codice sorgente? Vi dimostriamo che fare ciò non solo è possibile, ma facilmente sfruttabile...

Questo si legge nell'introduzione del paper "Trojan source: Invisible Vulnerabilities", recentemente pubblicato dal Prof. Ross Anderson della Cambridge University, autore del testo “Security Engineering”, e da Nicholas Boucher, suo studente di dottorato. 

Incuriositi, come spesso capita nel mondo cyber, abbiamo deciso di approfondire.

Per iniziare, ricordiamo che i programmi scritti con i moderni linguaggi di programmazione hanno necessità di un compilatore, cioè di un altro programma che analizza il testo del nostro programma, ne verifica la correttezza sintattica, e lo traduce in un programma ottimizzato nel linguaggio eseguibile dal calcolatore. Già da questo si comprende la criticità nello sviluppo di un compilatore che potrebbe inserire involontariamente delle vulnerabilità nel programma. Negli anni ’80 già Ken Thomson, uno dei padri di Unix, metteva in guarda da questi rischi nella sua famosa lezione tenuta in occasione del conferimento del “Turing award” (l’equivalente del Premio Nobel per l’informatica) dal titolo evocativo “Reflections on trusting trust”. Il compilatore del linguaggio C è a sua volta un programma scritto in linguaggio C, per cui per potersi fidare del programma eseguibile prodotto dal compilatore occorre non solo fidarsi di chi ha scritto il programma, ma anche fidarsi del compilatore.

Ora, tornando all’articolo di Boucher e Anderson, ripartiamo dal considerare un compilatore come un analizzatore di testo che conosce i termini e la sintassi del linguaggio di programmazione. I caratteri utilizzati per formare il testo hanno necessità di essere codificati in un computer. 

Per capire in cosa consiste questo nuovo genere di attacco presentato da Boucher e Anderson, in primo luogo occorre parlare di codifica e degli standard utilizzati per la codifica.  

Uno degli standard più usati nel tempo nel mondo informatico è l' ASCII, American Standard Code for Information Interchange. La prima edizione di questo standard fu pubblicata nel 1963 e modificata varie volte nel tempo. Impiegava sette bit per codificare 128 differenti caratteri. 

Con lo sviluppo dei sistemi informatici cambiarono le esigenze e fu necessario estendere lo standard ASCII per consentire la codifica di caratteri provenienti da lingue diverse o necessari per specifici ambienti.

Si passò così, gradatamente, allo standard conosciuto come UNICODE. Questo standard consente di codificare 144.697 tra caratteri e simboli vari. Tra questi vi sono alfabeti cosiddetti Left-to-Right (da sinistra a destra, come Italiano, Russo, Inglese...) e Right-to-Left (da destra a sinistra, come Arabo, Ebraico...). Nel caso di Unicode, che è uno degli standard di codifica oggi più largamente utilizzato, per stabilire l’ordine secondo il quale un testo debba essere visualizzato, viene utilizzato un algoritmo chiamato Bidirectional Algorithm (BiDi). 

L'algoritmo BiDi è pensato per gestire automaticamente la visualizzazione del testo attraverso dei caratteri cosiddetti di controllo (override characters) che consentono di specificare esplicitamente come debba essere trattata una specifica porzione di testo (ad esempio Right To Left Override, RLO, specifica di trattare il testo a cui si applica come right-to-left). I caratteri di controllo sono dei caratteri invisibili a schermo che permettono di controllare la visualizzazione di porzioni di testo. Eccone alcuni tra i più usati.

Inoltre i caratteri di controllo possono essere "nidificati", consentendo in questo modo di riordinare la visualizzazione di un testo in modo anche molto complesso.

Ora, se il testo che viene visualizzato a schermo è un codice di un programma, occorre tener presente che in linea di massima la sintassi della maggior parte dei linguaggi di programmazione non consente tipicamente di inserire questi caratteri controllo direttamente all’interno del codice sorgente in quanto altererebbero evidentemente la logica di controllo del programma. Tuttavia, dato che molti linguaggi consentono l’utilizzo di commenti e stringhe, è possibile inserire i caratteri di controllo all’interno dei commenti o delle stringhe e fare si che abbiano un impatto sul codice sorgente in quanto i BiDi ovverrides non rispettano i delimitatori delle stringhe e dei commenti.

Proprio su questa caratteristica tipica delle codifiche odierne si basa il tipo di attacco descritto da Boucher e Anderson. In effetti grazie ai caratteri di controllo è possibile sfruttare la differenza tra quanto visualizzato e quanto realmente codificato e passato a compiler e interpreter per condurre il tipo di attacco "Trojan Source Attack" descritto da Boucher e Anderson.

Boucher e Anderson hanno inoltre dimostrato che tale tipo di attacco è possibile con i più usati linguaggi di programmazione tra cui C, C++, C#, JavaScript, Java, Rust, Go, and Python. 

L’esempio di seguito, in codice Python, mostra che il codice codificato (e dunque eseguito sulla macchina) a sinistra è differente dal codice sorgente (a destra) visualizzato. 

In base a quest’ultimo ci si aspetterebbe di trovare un valore pari a 50 in bank [‘alice’] al termine dell’esecuzione, mentre nella pratica il valore presente sarà ancora pari a 100.

Il fatto che fino ad ora non si abbiano evidenze di questo genere di attacco non ci tranquillizza per il futuro dato che, come noi, anche altri possono aver letto il paper e, magari, preso la decisione di testarne i concetti.

Davide Ariu, Giorgio Giacinto e Alessandro Rugolo,

Per approfondire:

- Trojan Source: Invisible Vulnerabilities;

- 'Trojan Source' bug a novel way to attack program encodings (techxplore.com);

- Trojan Source attack is dangerous for compilers of program languages (gridinsoft.com);

- Trojan Source Attacks;

- GitHub - nickboucher/trojan-source: Trojan Source: Invisible Vulnerabilities;

- The Unicode Bidirectional Text Algorithm - Developer guides | MDN (mozilla.org);

- https://doi.org/10.1145/358198.358210;

- https://www.cl.cam.ac.uk/~rja14/book.html.

Cybercriminali contro Pirati

Viviamo tempi davvero interessanti: esattamente dieci anni fa il Dipartimento della Difesa US ha ratificato il dominio cyber come quinto dominio di arte bellica, ma è stato soltanto pochi anni fa che le peculiarità di questa catalogazione sono emerse in tutta la sua evidenza.

Le tecniche di guerra digitale a livello strategico, operativo e tattico, si sono combinate con caratteristiche uniche di questo dominio – come ad esempio l’asimmetria tra attaccante e difensore oppure la velocità di propagazione; contaminandosi con altri ambiti economici e criminali, fino a rappresentare oggi un unicum che premia questa catalogazione elevandola quasi a singolarità tecnologica.

Questo è il pensiero che mi ha stimolato una notizia riguardante un threat actor particolare, chiamato Lazarus. Threat actor è una denominazione specifica, riservata normalmente agli attori organizzati che – talvolta sponsorizzati da Stati – sono emersi per l’utilizzo di strategie, procedure e tecniche di attacco ben definite e particolari. Lazarus, nello specifico, è un gruppo sponsorizzato dallo Stato Nord-Coreano e attivo dal 2009; secondo altre classificazioni, questo gruppo può essere conosciuto con l’acronimo APT38, Hidden Cobra, ZINC (vedi anche l'articolo di Ciro Metaggiata su Difesa Online).

La notizia parlava di una campagna di attacco abbastanza sofisticata, basata su una versione del software IDA Pro armata con un malware trojan, mirata alla compromissione di ricercatori di cybersecurity.

A prima vista una notizia non troppo eclatante in merito all’ennesimo attacco organizzato verso un target specifico, come se ne sentono molte in questo periodo.

Approfondendo il contesto, però, emergono alcune importanti connotazioni.

IDA Pro è un potente software che permette agli analisti di security di disassemblare qualunque eseguibile, per esempio per capire in che modo sia possibile infettare i sistemi attraverso un malware. 

Questa operazione è chiamata reverse engineering.

Il motivo per cui IDA Pro è diventato popolare tra i ricercatori di sicurezza è dovuta alla potenza della soluzione, che esiste in una versione gratuita con funzionalità decisamente di livello.

Per avvantaggiarsi della potenza della versione completa però, è necessario acquistare la versione Professional, che ha un costo importante. Questo ha portato diversi ricercatori a cercare versioni piratate o comunque non ufficiali della soluzione, creando l’utenza target per l’attacco di Lazarus Group.

Riflettendo su questo aspetto, è particolarmente incomprensibile la scelta di cercare una versione craccata di un software per reverse engineering da parte di chi dovrebbe conoscere molto meglio di altri i rischi a cui va incontro: è infatti più certo che probabile che una versione di software piratata sia infetta con forme di malware più o meno subdolamente celante, ma spesso dagli effetti devastanti.

Non che la mossa di Lazarus Group sia in alcun modo giustificabile, ma la scelta del target da parte dell’attaccante potrebbe non essere per nulla casuale.

Da un punto di vista strategico, infatti, un ricercatore di cybersecurity occupa un posto di estremo rilievo nella “catena del valore”: potrebbe essere infatti un consulente, infettato il quale si avrebbe accesso a più clienti; oppure colpire un incauto analista potrebbe aiutare a violare il sancta santorum della cybersecurity di un’organizzazione, la parte più specialistica della filiera di difesa.

Ecco perché questa notizia dovrebbe portarci a riflettere su questo strano conflitto tra due fronti che solo in apparenza sono opposti, ma che in realtà rappresentano – sebbene per ragioni diverse – elementi dannosi per le aziende e per la security in generale.

Marco Rottigni

Per approfondire: 

https://www.bleepingcomputer.com/news/security/lazarus-hackers-target-researchers-with-trojanized-ida-pro/

https://en.wikipedia.org/wiki/Lazarus_Group

Dalla Corea del Nord, The Lazarus Group. Cyber guerrieri o cyber criminali? - Difesa Online

Tecniche di Automazione dei sistemi di rete

Il riferimento all’ utilizzo di tecniche di automazione ed eventualmente di AI (Artificial Intelligence) è diventato prassi comune nell’ indirizzare molte problematiche di analisi dei dati da cui trarre indicazioni sui comportamenti futuri di sistemi complessi.

In realtà la possibilità per un sistema di reagire autonomamente a eventi particolari in modo da standardizzare il comportamento è qualcosa presente in molti dispositivi da tempo. In queste note esamineremo un esempio delle funzionalità disponibili su alcuni nodi delle reti di impresa (ad oggi tutte basate sul protocollo IP) che permettono :

• Il riconoscimento di uno specifico evento

• La creazione di una policy da applicare in caso si verifichi l’ evento in oggetto

• L’ applicazione della policy al sistema con la seguente modifica del comportamento dello stesso.

Tutti i principali vendor di dispositivi di rete IP (Cisco Systems, Juniper Networks, Arista Networks,…) offrono, con nomi diversi, una tale funzionalità.

Senza entrare nello specifico di ciascun sistema vorrei semplicemente illustrare il principio di funzionamento per offrire un'idea di come esistano, anche nel campo dei dispositivi di rete, strumenti e funzionalità che permettono l’ automazione dei comportamenti dei nodi a fronte di specifici eventi.

La diffusione di questi strumenti potrebbe portare anche a soluzioni che, in sinergia con tecniche di sicurezza basate su AI (vedi articolo DeepInstinct, dalla rilevazione alla prevenzione) permettano di intervenire con efficacia a fronte di specifici problemi evitando che la minaccia o il tentativo di compromissione possa raggiungere i sistemi finali (Server o postazioni di lavoro individuali).

Farò quindi riferimento ad un ipotetico dispositivo di rete. Il nodo in oggetto fornisce un ambiente di sviluppo focalizzato sull’implementazione di funzionalità di automazione.

Molto spesso questo ambiente è sviluppato sulla base di un sistema Linux ottimizzato per essere eseguito su di un processore “ausiliario” all’interno del nodo di rete. Il grande vantaggio di una tale soluzione deriva dal poter sfruttare molte (anche se non tutte) delle librerie e dei linguaggi disponibili in ambito Linux. Oltre a ciò va aggiunta la possibilità, offerta dai costruttori del nodo di rete, di accedere alle principali caratteristiche di utilizzo del nodo stesso da questo ambiente Linux.

E’ possibile quindi accedere a specifici parametri delle interfacce tramite una libreria (fornita dal costruttore) che permette di conoscere, ad esempio, il numero di pacchetti transitati in ingresso-uscita da una specifica porta oppure identificare i pacchetti malformati (troppo grandi o troppo piccoli o con errori,…). Queste funzionalità non si limitano alle caratteristiche dell’interfaccia, ma possono interessare altri sottosistemi del nodo come il livello di routing o alcune delle caratteristiche fisiche del sistema (temperatura, stato delle ventole, etc).

Posso quindi definire uno specifico evento sulla base del verificarsi di una predeterminata condizione : superamento del numero di errori di CRC su di una porta, modifica di una tabella di routing, superamento di un valore di soglia per quanto riguarda la temperatura del sistema, il carico della CPU o l’occupazione della memoria.

A questo punto, l’ evento così definito può essere usato come innesco (trigger) di una specifica azione (policy): disabilitare una porta, mandare un messaggio (con modalità diverse) all’ amministratore di sistema, intervenire sulla configurazione per cambiare una rotta di default e cosi via.

Tutte le azioni possono essere eseguite tramite degli script o dei programmi eseguibili: tipicamente i sistemi offrono la possibilità di utilizzo dei principali linguaggi quindi Python, Perl, Ruby e di un ambiente nativo basato sulla propria interfaccia comandi.

Questa funzionalità apre tutta una serie di possibili implicazioni molto interessanti anche sotto l’ aspetto della sicurezza delle reti.

Qualora fosse possibile, utilizzando strumenti esterni al sistema e basati su AI, nell’ ottica definita dall’articolo citato, istruire opportunamente e comunicare al sistema la presenza di una possibile minaccia identificata, sarebbe possibile intervenire immediatamente (o in tempi estremamente brevi). L’ intervento ipotizzato quindi bloccherebbe la specifica connessione e, al contempo, attuerebbe una specifica policy definita in precedenza intervenendo quindi sulla configurazione stessa del sistema.

In questo modo potrebbe essere possibile, ad esempio, isolare uno specifico dominio, ritenuto non affidabile, garantendo al contempo il mantenimento della connettività a livello globale.

Naturalmente le sinergie tra gli apparati di rete e i sistemi di sicurezza sono oggetto di analisi e sviluppi da parte di tutti i principali vendor che sono in grado di offrire strumenti di identificazione e contenimento delle minacce informatiche, che opportunamente configurati ed utilizzati, risultano essere molto efficaci.

Giorgio Tosi

Lo strano caso del GreenPass di Spongebob

Un paio di giorni fa, mentre stavo facendo colazione, mi arriva un messaggio sullo smartphone che dice “Buongiorno. Parrebbe che abbiano leakato le chiavi per creare i green pass…

Se confermato, significa che in teoria chiunque può produrre GreenPass validi”

La notizia ha attirato immediatamente la mia attenzione, facendomi istantaneamente affiorare un pensiero allarmante: se la notizia fosse vera, avremmo nullificato uno degli strumenti di controllo più importanti su cui si poggiano i piani post-pandemici di ripartenza economica, sociale, umana!

Un istante dopo, un secondo pensiero ancora più terrificante, sebbene composto da sole tre parole: in tutta Europa!

In mezzo al turbinio di processi ed interazioni che caratterizza le mie giornate, ho cercato di dedicare uno slot di attenzione all’evoluzione della notizia, che entro mezzogiorno da un paio di testate online su cui era apparsa si era trasferita al telegiornale nazionale.

La prova offerta era abbastanza tangibile: un QR Code che - se validato con la app ufficiale VerificaC19 - restituiva un green pass valido per… Adolf Hitler, con tanto di data di nascita 1900; data peraltro sbagliata, dal momento che il personaggio nacque in Austria nel 1889.

La problematica, al di là della goliardìa, restava molto grave: come era possibile che avessero trafugato delle chiavi crittografiche valide per la generazione dei GreenPass, che avrebbero dovuto essere gestite in modo assolutamente accurato da entità ministeriali o governative con processi dominati da una sicurezza ai massimi livelli?

Le notizie fittizie, le ipotesi, persino alcune promesse chiaramente improbabili finalizzate forse ad abbassare il livello di allarme si sono rincorse per tutta la giornata, iniziando a combinarsi con un’eco dall’estero dove la problematica appariva su siti noti come ad esempio bleepingcomputer.com.

Anche questi siti parlavano di probabile furto o comunque esfiltrazione di chiavi private, rendendo la cosa ulteriormente preoccupante a causa di alcuni rumors che ipotizzavano che le chiavi trafugate riguardassero diversi Stati Membri dell’Unione Europea.

Il tam tam della notizia si è ulteriormente diffuso, insieme (fortunatamente) alla reazione dei gestori che hanno provveduto a invalidare sia il Green Pass valido a nome di Hitler che alcuni improbabili altri generati nel frattempo, come ad esempio quello di Spongebob Squarepants che riporto di seguito, con relativa prova dell’invalidazione:

 

Il 28 sera la rubrica “Ciao Internet” di Matteo Flora sul canale YouTube ha offerto una spiegazione più plausibile e - francamente - più tranquillizzante da un certo punto di vista: qualcuno ha trovato il modo di abusare delle chiavi.

Più nello specifico, l’abuso sembra essere avvenuto tramite il codice dgca-issuance-web - facilmente reperibile perché condiviso sul sito GitHub dall’Unione Europea - unito a una chiave di firma valida in possesso di un utente.

Il codice in questione rappresenta il programma utile a generare i GreenPass, che sono in tutto e per tutto paragonati a certificati cartacei di avvenuta vaccinazione, di avvenuto tampone oppure di avvenuta guarigione, trasposti in forma digitale.

Analogamente a quanto avviene per i certificati cartacei, i certificati digitali per assumere valore devono essere firmati. Il processo di firma, non potendo utilizzare una penna, utilizza una chiave digitale privata che viene combinata con una chiave digitale pubblica inserita nel certificato. Questa chiave digitale pubblica è l’oggetto di verifica che permette di confermare l’originalità del certificato.

La cosa alquanto improbabile, quindi, è l’utilizzo di una chiave privata valida - dal momento che le chiavi di firma sono date in ragione di una per nazione.

A peggiorare le cose il fatto che alcune nazioni, tra cui l’Italia, non possono invalidare soltanto alcuni certificati firmati con la chiave nazionale… ma dovrebbero invalidare la chiave; operazione che richiederebbe la riemissione dei milioni di GreenPass veri, ufficiali e validi emessi finora; costringendo i titolari a richiederne una copia tramite i noti canali tradizionali: sito online, farmacie, ecc.

La faccenda è evoluta verso una ulteriore spiegazione valida verso le 13:40 del 28 ottobre. Secondo il sito Il Disinformatico infatti, sono stati individuati almeno sei punti di accesso validi a portali in grado di generare GreenPass validi in modalità Anteprima utilizzando dati fittizi che non vengono poi salvati.

Salvando quell’immagine, che rappresenta un certificato valido, è possibile generare i certificati che sono apparsi sul web con proprietari improbabili. Dopo il salvataggio dell’immagine, l’operazione può essere tranquillamente cancellata senza lasciare traccia alcuna dell’avvenuta generazione; di un certificato che resta - comunque - valido.

Quanto sta avvenendo quindi sembra il frutto di una importante, enorme per portata e dimensione, vulnerabilità di processo.

Che combinata con un fattore umano di dubbia liceità ha creato le condizioni per annullare potenzialmente uno dei processi più riusciti per risollevarci dagli effetti devastanti della pandemia.

Nessun furto di chiavi quindi, almeno allo stato in cui le cose sono evolute finora.

Soltanto una pessima igiene digitale nell’implementazione di un processo informatico.

Fatto, questo, che dovrebbe farci riflettere su un aspetto che spesso accomuna molti incidenti informatici, tra cui quello di cui stiamo parlando.

La tecnologia utilizzata per generare i GreenPass è sicuramente solida: combina infatti certificati digitali, visualizzazione di informazioni tramite QR Code che rende il tutto fruibile in modo semplice, uniformità di accettazione ed interoperabilità di implementazione tra più Stati.

La falla, la parte vulnerabile in modo importante, riguarda più il processo di implementazione e la messa in opera. Qui di tecnologico c’è ben poco, perché il tema riguarda la gestione e la messa in sicurezza di un processo.

Da quanto rilevato finora, è evidente che sono stati commessi errori gravi proprio in questa fase.

Un esempio è permettere la generazione di un anteprima del certificato valida a tutti gli effetti, senza fare in modo - ad esempio - che l’anteprima fosse controllabile solo da un’applicazione diversa da quella che avrebbe controllato la versione finale.

Un altro esempio riguarda la gestione della riservatezza.

Se l’emissione di un GreenPass è pertinenza di un organo governativo ufficiale ed afferma una verità incontrovertibile - al pari di un Notaio che certifica un atto di compravendita immobiliare tra due soggetti - avrebbe dovuto essere ristretta ad operatori tracciati, autorizzati, i cui privilegi dovrebbero essere concessi proprio a fronte di un’abilitazione specifica.

Senza contare che qualsiasi applicazione, prima di essere messa in produzione, dovrebbe essere provata a validata proprio da esperti di sicurezza chiamati Penetration Tester. Questi hanno l’obiettivo di studiare le potenziali falle dell’applicazione, ma anche del modo di utilizzarla… e del potenziale modo di abusarne.

Se tutti questi passaggi fossero stati eseguiti preventivamente e rimediati a regola d’arte in caso di falle, oggi non ci troveremmo a fronteggiare un incidente.

Cosa più importante, non dovremmo neppure sostenere i costi della risposta a questo incidente, che rischiano di essere davvero devastanti in termini sicuramente economici ma anche di credibilità di uno strumento di supporto alla ripresa economica e sociale davvero fondamentale.

Marco Rottigni

Analisi dei dati e automazione

Il riferimento all'utilizzo di tecniche di automazione ed eventualmente di AI (Artificial Intelligence) è diventato prassi comune nell’indirizzare molte problematiche di analisi dei dati da cui trarre indicazioni sui comportamenti futuri di sistemi complessi.

In realtà la possibilità per un sistema di reagire autonomamente a eventi particolari in modo da standardizzare il comportamento è qualcosa presente in molti dispositivi da tempo. In queste note esamineremo un esempio delle funzionalità disponibili su alcuni nodi delle reti di impresa (ad oggi tutte basate sul protocollo IP) che permettono

• Il riconoscimento di uno specifico evento

• La creazione di una policy da applicare in caso si verifichi l’ evento in oggetto

• L’ applicazione della policy al sistema con la seguente modifica del comportamento dello stesso.

Tutti i principali vendor di dispositivi di rete IP (Cisco Systems, Juniper Networks, Arista Networks,…) offrono, con nomi diversi, una tale funzionalità.

Senza entrare nello specifico di ciascun sistema vorrei semplicemente illustrare il principio di funzionamento per offrire un'idea di come esistano, anche nel campo dei dispositivi di rete, strumenti e funzionalità che permettono l’ automazione dei comportamenti dei nodi a fronte di specifici eventi.

La diffusione di questi strumenti potrebbe portare anche a soluzioni che, in sinergia con tecniche di sicurezza basate su AI (vedi articolo) permettano di intervenire con efficacia a fronte di specifici problemi evitando che la minaccia o il tentativo di compromissione possa raggiungere i sistemi finali (Server o Postazioni di lavoro Individuali).

Farò quindi riferimento ad un ipotetico dispositivo di rete che offra queste funzionalità. Il nodo in oggetto fornisce un ambiente di sviluppo focalizzato proprio sull’ implementazione di tali funzionalità. Molto spesso questo ambiente è sviluppato sulla base di un sistema Linux ottimizzato per essere eseguito su di un processore “ausiliario” all’interno del nodo di rete. Il grande vantaggio di una tale soluzione deriva dal poter sfruttare molte (anche se non tutte) delle librerie e dei linguaggi disponibili in ambito Linux. Oltre a ciò va aggiunta la possibilità, offerta dai costruttori del nodo di rete, di accedere alle principali caratteristiche di utilizzo del nodo stesso da questo ambiente Linux.

E’ possibile quindi accedere a specifici parametri delle interfacce tramite una libreria (fornita dal costruttore) che permette di conoscere, ad esempio, il numero di pacchetti transitati in ingresso-uscita da una specifica porta oppure identificare i pacchetti malformati (troppo grandi o troppo piccoli o con errori,…). Queste funzionalità non si limitano alle caratteristiche dell’interfaccia, ma possono interessare altri sottosistemi del nodo come il livello di routing o alcune delle caratteristiche fisiche del sistema (temperatura, stato delle ventole, etc).

Posso quindi definire uno specifico evento sulla base del verificarsi di una predeterminata condizione : superamento del numero di errori di CRC su di una porta, modifica di una tabella di routing, superamento di un valore di soglia per quanto riguarda la temperatura del sistema, il carico della CPU o l’occupazione della memoria.

A questo punto, l’ evento così definito può essere usato come innesco (trigger) di una specifica azione (policy): disabilitare una porta, mandare un messaggio (in modalità diverse) all’amministratore di sistema, intervenire sulla configurazione per cambiare una rotta di default e cosi via.

Tutte le azioni possono essere eseguite tramite degli script o dei programmi eseguibili, tipicamente i sistemi offrono la possibilità di utilizzo dei principali linguaggi quindi Python, Perl, Ruby e di un ambiente nativo basato sulla propria interfaccia comandi.

Questa funzionalità apre tutta una serie di possibili implicazioni molto interessanti anche sotto l’ aspetto della sicurezza delle reti. Qualora fosse possibile, utilizzando strumenti esterni al sistema e basati su AI nell’ottica definita dall’articolo citato, istruire opportunamente e comunicare al sistema la presenza di una possibile minaccia così identificata sarebbe possibile intervenire immediatamente (o in tempi estremamente brevi) bloccando la specifica connessione e al contempo intervenire sulla configurazione stessa del sistema attuando una specifica policy definita in precedenza.

In questo modo potrebbe essere possibile, ad esempio, isolare uno specifico dominio, ritenuto non affidabile, garantendo al contempo il mantenimento della connettività a livello globale.

Naturalmente le sinergie tra gli apparati di rete e i sistemi di sicurezza sono oggetto di analisi e sviluppi da parte di tutti i principali vendor che sono in grado di offrire strumenti di identificazione e contenimento delle minacce informatiche, che opportunamente configurati ed utilizzati, risultano essere molto efficaci.

Giorgio Tosi

Per approfondire:

https://www.difesaonline.it/evidenza/cyber/deep-instinct-dalla-rilevazione-alla-prevenzione