I white hackers sono i ricercatori che scoprono la vulnerabilità di un software e/o di un sistema informatico. Spesso, quando decidono di segnalarla, devono affrontare minacce legali.
La divulgazione delle vulnerabilità è stata oggetto di un dibattito decennale nella comunità informatica. La difficoltà di questo processo è che deve essere gestito in modo coordinato tra il ricercatore e la società che presenta la vulnerabilità. Un’erronea condivisione con il pubblico dei dettagli di una vulnerabilità (ad esempio prima dello sviluppo della patch) è in grado di sottoporre il sistema a rischio di hackeraggio e chiaramente comportare conseguenze negative per gli utenti.
Per questo, tra direttiva NIS2, che approderà nel corso dell’anno al negoziato in Trilogo (Commissione, Parlamento e Consiglio Ue), prevede tra le proposte l’obbligo per gli Stati membri di stabilire una politica coordinata di divulgazione delle vulnerabilità.
Cyber sicurezza, cosa ci aspettiamo dal nuovo anno dopo un 2021 da “shock”
White hackers e il caso Log4Shell
Il 24 novembre 2021, il team di ricercatori di Alibaba informa l’Apache Software Foundation di una vulnerabilità nel sistema Apache Log4j, il tool di Apache per la gestione del log in ambiente Java (i.e. registrazione sequenziale e cronologica delle operazioni effettuale). Il 26 novembre, il MITRE, una no profit statunitense, nota per aver creato il database CVE per identificare, definire e catalogare le vulnerabilità, assegna alla vulnerabilità il numero identificativo CVE-2021-44228. Il 29 novembre Apache inizia a lavorare alla risoluzione dell’exploit e il 6 dicembre pubblica la prima patch. Tre giorni dopo, la vulnerabilità viene condivisa con il pubblico attraverso un tweet di un ricercatore del team di Alibaba.
La vulnerabilità, meglio nota con il nome di Log4Shell, è stata definita come “la vulnerabilità più critica dell’ultimo decennio” ed ha costretto gli sviluppatori di numerosi prodotti software a rilasciare aggiornamenti o mitigazioni ai loro clienti. Il processo attraverso il quale questa vulnerabilità è stata trovata e divulgata al pubblico ha seguito il così detto processo di divulgazione responsabile.
In un’epoca in cui le vulnerabilità e la loro vendita sul mercato nero sono sempre più diffuse, si sono resi necessari processi decisionali per preservare lo stato di diritto online e responsabilizzare gli organi di governo in materia. I vari Stati membri dell’UE stanno quindi attualmente lavorando alla creazione di politiche nazionali per la divulgazione coordinata delle vulnerabilità (CVD).
White hackers: come funziona il Processo di Divulgazione Coordinata delle Vulnerabilità
Il processo di Divulgazione Coordinata delle Vulnerabilità (CVD) è definito nella norma ISO/IEC 29147: “La divulgazione delle vulnerabilità è un processo attraverso il quale i venditori e ricercatori possono collaborare per trovare soluzioni che riducano i rischi associati alle vulnerabilità di sistema. Questo processo include azioni come la segnalazione della vulnerabilità, il coordinamento e la pubblicazione di informazioni su un’exploit e sulla sua risoluzione.”
Gli obiettivi della divulgazione responsabile delle vulnerabilità includono:
i) garantire che le vulnerabilità identificate siano risolte;
ii) ridurre al minimo il rischio derivante dalle vulnerabilità;
iii) fornire agli utenti informazioni sufficienti per valutare i rischi derivanti dalle vulnerabilità dei loro sistemi.[2]
Alcuni ruoli sono fondamentali per il processo, in particolare:
- Ricercatore: l’individuo o l’organizzazione che identifica la vulnerabilità,
- Venditore: l’individuo o l’organizzazione che ha creato o mantiene il prodotto vulnerabile,
- Distributore: l’individuo o l’organizzazione che deve distribuire una patch o intraprendere altre azioni correttive (spesso il vendor stesso),
- Coordinatore: un individuo o un’organizzazione che facilita il processo di risposta coordinato (per esempio il CSIRTs nazionale).
Partendo dagli standard specificati nella ISO/IEC 30111 e considerando vari modelli di CVD, è possibile identificare le seguenti fasi del processo CVD:[3]
- Scoperta: Uno o più ricercatori scoprono una vulnerabilità utilizzando una delle metodologie disponibili.
- Reporting: Il ricercatore presenta un report sulle vulnerabilità al vendor o, se il vendor non risponde, al coordinatore.
- Validazione e triage: Il report viene validato per garantirne l’accuratezza prima di intraprendere qualsiasi azione pratica di risposta.
- Riparazione: Viene sviluppato e testato un piano di riparazione (i.e. patch).
- Divulgazione pubblica: La vulnerabilità stessa e la relativa patch vengono divulgate al pubblico.
- Distribuzione: La patch viene applicata ai sistemi distribuiti.
Secondo quanto descritto dal centro nazionale belga per la cybersecurity, dopo che il ricercatore ha individuato e segnalato la vulnerabilità, l’organizzazione responsabile rimane, a meno che non sia diversamente indicato, libera di scegliere di sviluppare e implementare una soluzione.
Idealmente, la soluzione dovrebbe essere sviluppata entro 90 giorni.
È importante mantenere al minimo questa scadenza, soprattutto se vi sono rischi per la protezione dei dati personali.
Se l’organizzazione non fosse in grado di risolvere immediatamente il problema, il sistema informatico dovrebbe essere messo temporaneamente fuori servizio.
Se la soluzione è pronta e la vulnerabilità interessasse altre organizzazioni, questa dovrebbe essere comunicata al coordinatore CVD in via prioritaria e prima di qualsiasi divulgazione pubblica. Se una delle parti non risponde, le parti possono rivolgersi al coordinatore designato.[4]
White hackers: il problema della protezione legale dei ricercatori
Esistono numerose sfide legali associate al processo descritto. Gli individui che scoprono una vulnerabilità “spesso devono affrontare minacce legali quando decidono di segnalarla. Queste minacce possono derivare non solo dall’applicazione del diritto civile e penale, ma anche dall’applicazione del diritto commerciale e altri tipi di legislazioni.”[5] Nella maggior parte dei paesi dell’UE, il quadro giuridico non è stato aggiornato per fornire tutele legali ai ricercatori.
Secondo le disposizioni legali esistenti nella maggior parte dei casi, quindi, chiunque rilevi e divulghi una vulnerabilità scansionando un sistema senza previa autorizzazione è vincolato dal diritto penale e da altre disposizioni legislative.
La Convenzione sulla criminalità informatica, infatti, prevede che l’accesso intenzionale a un sistema informatico senza autorizzazione è un reato.
Sia nei casi in cui i ricercatori stiano cercando attivamente le vulnerabilità, sia nei casi in cui le vulnerabilità vengono trovate in modo accidentale durante il normale utilizzo di un sistema, il ricercatore può inavvertitamente accedere a dati critici e quindi incorrere in azioni legali una volta segnalata la vulnerabilità al venditore.
Esempi di ricercatori minacciati di azioni legali dai vendor[6]
Nel 2016, alcuni ricercatori hanno ricevuto una lettera di diffida tre giorni dopo aver segnalato una grave vulnerabilità alla società di consulenza e revisione globale PwC. Un altro ricercatore ha subito un’irruzione nella sua casa ed è stato arrestato dall’FBI dopo aver riferito che una società di software dentale ha lasciato informazioni sanitarie sensibili di 22.000 pazienti a rischio di accesso da parte di terzi.
Nel 2017, un ricercatore ha scoperto una vulnerabilità in un sito web di un Comune in Danimarca che consentiva la raccolta di informazioni personali di qualsiasi cittadino inserendo la data di nascita di quest’ultimo in un modulo. Ha denunciato la vulnerabilità al comune, il quale dopo aver riparato la vulnerabilità lo ha segnalato alla polizia.
Nel 2018, l’FBI ha indagato su uno studente universitario che era stato segnalato dalla società di voto mobile Voatz per aver tentato illegalmente di hackerare la sua applicazione. Nel 2020, i ricercatori del MIT hanno scoperto una vulnerabilità nel sistema di voto elettronico di Voatz che avrebbe consentito ai criminali informatici di alterare, interrompere o esporre il modo in cui un singolo utente ha votato. L’applicazione era già stata utilizzata in diverse elezioni locali e statali negli Stati Uniti. I ricercatori hanno riferito i loro risultati alla Cybersecurity and Infrastructure Security Agency (CISA). La società ha negato la gravità delle vulnerabilità, rilasciando dichiarazioni pubbliche contro i ricercatori. Alla fine, un audit indipendente richiesto da Voatz ha confermato i risultati del MIT.
Per adottare misure che proteggano meglio i ricercatori, i decisori politici hanno iniziato quindi ad analizzare le lacune nei loro quadri giuridici. Varie strade sono percorribili per garantire la protezione dei c.d. white hackers. Per alcuni Paesi sono necessarie modifiche normative. In altri Paesi può essere sufficiente una favorevole interpretazione da parte del giudice penale, in cui si tiene conto della buona fede del ricercatore.
Come si stanno muovendo i paesi europei
Al momento, ancora pochi paesi in Europa hanno adottato misure che garantiscono un ambiente giuridico favorevole alla ricerca delle vulnerabilità e alla protezione degli white hackers.
I Paesi Bassi hanno guidato gli sforzi dell’UE nella definizione del processo di CVD. Il paese dispone di un quadro giuridico adeguato, nonché di procedure chiare per segnalare le vulnerabilità.
Olanda, Francia, Belgio e Lituania sono gli unici quattro Stati membri con una politica nazionale sulla CVD pienamente consolidata.
Altri Stati membri sono sul punto di promulgare una CVD policy; la proposta è esaminata a livello di responsabili politici e testata nell’ambito di progetti pilota. La maggior parte dei paesi europei non ha tuttavia ancora pubblicato alcuna CVD policy.
La situazione corrente è però in continua evoluzione e si prevede che nei prossimi anni tutti i Paesi implementeranno una CVD policy. L’obbligo per gli Stati membri di stabilire una politica coordinata di divulgazione delle vulnerabilità è infatti una delle nuove proposte nella direttiva NIS2, che dal 2022 approderà al negoziato in Trilogo (Commissione, Parlamento e Consiglio Ue).
Come ha dimostrato il recente caso di Log4Shell, una buona gestione del processo di divulgazione è fondamentale, soprattutto per le vulnerabilità altamente critiche; tale proposta è quindi da accogliere molto positivamente.
______________________________________________
Note e bibliografia
Questo articolo fa riferimento a: Pupillo, L., Ferreira, A., & Varisco, G., (2018), Software Vulnerability Disclosure in Europe: Technology, Policies and Legal Challenges, Report of a CEPS Task Force, CEPS Task Force Reports 28 June 2018.
- ISO/IEC, “ISO/IEC 29147:2014 Information technology-Security techniques-Vulnerability disclosure”, 2014. ↑
- “The CERT Guide to Coordinated Vulnerability Disclosure”, by Allen D. Householder, Garret Wassermann, Art Manion and Chris King, Software Engineering Institute, Carnegie Mellon University, August 2017, p. 2. This part of this report draws from this source. ↑
- Centre for Cybersecurity Belgium (2020), Guide to Coordinated Vulnerability Disclosure Policies Part I: Good Practices. Available at: https://ccb.belgium.be/sites/default/files/Guide%20CVDP%20part%20I%20Good%20pratices.pdf ↑
- ENISA, “Good Practice Guide on Vulnerability Disclosure – From challenges to recommendations”, January 2016, p. 7. ↑
- Questa sezione fa riferimento a: OECD, (2021), “Encouraging Vulnerability Treatment: Overview for Policy Makers”, February p. 29. Available at: https://www.oecd.org/sti/encouraging-vulnerability-treatment-0e2615ba-en.htm ↑
