Vulnerabilità di sicurezza: quante ne esistono. Ma se si parla di PA chi le segnala rischia grosso

Gli attacchi informatici sono all’ordine del giorno perché i dati custoditi da aziende, Pubblica Amministrazione (PA), professionisti e privati sono oro per i criminali.
C’è lo spionaggio industriale e c’è ancora la volontà di danneggiare un concorrente ipotizzando l’inadeguatezza dei suoi piani di disaster recovery ma l’obiettivo dei criminali informatici è molto più spesso quello di sottrarre dati personali e informazioni sensibili per trarne direttamente profitto rivendendo il tutto ad altri soggetti o, ad esempio, chiedendo un riscatto per sbloccare i dati crittografati con un algoritmo forte (non fattorizzabile) e una chiave che viene celata alla vittima (funzionamento dei ransomware).

In un altro articolo abbiamo spiegato quanto è davvero sicuro un algoritmo crittografico prendendo come spunto RSA: algoritmi come RSA-2048 e RSA-4096 che utilizzano chiavi crittografiche rispettivamente a 2048 e 4096 bit non sono stati fattorizzati e non lo saranno ancora per molti anni anche considerando i progressi che si stanno facendo nell’utilizzo di risorse computazionali che coinvolgono ad esempio batterie di GPU di fascia alta, oggi facilmente disponibili sul cloud, e i computer quantistici dei quali si parla sempre più spesso e con crescente interesse.

Abbiamo cos’è un attacco informatico, come nasce e come spesso il problema che genera l’incidente con la conseguente violazione dei dati personali (data breach) abbia origine all’interno dell’azienda o dell’ente pubblico bersaglio dell’aggressione. Ne parliamo più avanti.

Vulnerabilità di sicurezza sul Web: quando una piattaforma diventa aggredibile dall’esterno

Open Web Application Security Project (OWASP) è un progetto che ha preso vista ormai più di vent’anni fa, nel 2001, e ha come obiettivo quello di realizzare linee guida, strumenti e metodologie per migliorare la sicurezza delle applicazioni.

In altri articoli abbiamo visto che la minaccia per l’integrità, la riservatezza e la disponibilità dei dati può arrivare dall’interno dell’organizzazione stessa: se i privilegi utente non sono assegnati in modo corretto, se sono condivise che non dovrebbero esserlo, se la rete non fosse intelligentemente segmentata, se non si utilizzassero strumenti di sicurezza a livello centralizzato, un malware in esecuzione su una singola workstation (ad esempio attivato inconsapevolmente da un dipendente o da un collaboratore, anche collegato da remoto tramite VPN) potrebbe iniziare a muoversi lateralmente. La diffusione nella rete locale può quindi causare gravi danni e permettere a soggetti remoti di prendere il controllo dell’infrastruttura impossessandosi dei dati ivi gestiti.

Talvolta le vulnerabilità di sicurezza affliggono anche le piattaforme Web utilizzate da aziende e PA: lacune nello sviluppo possono consentire a soggetti non aventi titolo di impadronirsi di informazioni riservate o danneggiare i dati gestiti.

La OWASP Top Ten è una sorta di classifica riconosciuta a livello globale che mira a sensibilizzare programmatori, personale aziendale, decisori e opinione pubblica sull’importanza di rendere sicure le applicazioni identificando alcuni dei rischi più critici.

Quando abbiamo parlato di DevOps abbiamo visto quanto sia oggi sempre più importante la filosofia di sviluppo software DevSecOps: gli aspetti legati alla sicurezza hanno infatti assunto un ruolo sempre più centrale.
Effettuando con cura le verifiche di sicurezza durante la fase di sviluppo si ottengono evidenti benefici in termini di costi perché si possono prevenire o comunque ridurre al minimo i rischi di incidenti a posteriori.

A fine 2021 OWASP evidenziava le seguenti problematiche come quelle più rilevanti durante lo sviluppo di qualunque software:

1) Broken Access Control. Meccanismi di controllo degli accessi realizzati in maniera superficiale o imperfetta possono permettere agli utenti di accedere a risorse che non dovrebbero vedere con i diritti dei quali sono in possesso. Queste lacune di sicurezza tipicamente portano alla divulgazione non autorizzata delle informazioni, alla modifica o alla distruzione dei dati, all’esecuzione di funzioni che dovrebbero essere indisponibili per l’utente.

2) Problemi di cifratura dei dati. Quando si sviluppa un’applicazione si devono valutare le esigenze per la protezione dei dati in transito e a riposo (con questo secondo termine si fa riferimento ai dati salvati su un’unità di memorizzazione, anche per esigenze di backup).
Password, numeri di carte di credito, cartelle cliniche, informazioni personali e segreti aziendali richiedono una protezione aggiuntiva, soprattutto se i dati ricadono sotto la regolamentazione di leggi specifiche come il Regolamento generale sulla protezione dei dati (GDPR) o altre normative “ad hoc”.

3) Injection. Attacchi di questo tipo, anch’essi molto comuni, si possono manifestare quando i dati forniti dall’utente non sono validati, filtrati o sanificati rimuovendo ad esempio eventuali caratteri che possono essere utilizzati per alterare il comportamento dell’applicazione inviando una normale richiesta da client.
Gravi problemi si presentano quando i dati in input vengono gestiti direttamente dall’applicazione in esecuzione sul server (si pensi a codice SQL o comandi specifici).
Gli aggressori che pongono in essere attacchi injection esaminano la struttura degli URL e la sequenza di operazioni poste in essere usando richieste GET/POST via JavaScript.

4) Design non sicuro. Con insecure design si fa riferimento a un’ampia categoria che raccoglie diverse debolezze di sicurezza.
Un design sicuro di un’applicazione può avere difetti di implementazione che portano a vulnerabilità sfruttabili dagli aggressori. Un design insicuro non può essere corretto con un’implementazione perfetta poiché non sono stati implementati i controlli di sicurezza necessari.

5) Errori nelle configurazioni di sicurezza. Con security misconfiguration OWASP si riferisce al mancato utilizzo di misure di sicurezza appropriate in qualsiasi parte dello stack applicativo o a permessi configurati in modo improprio sui servizi cloud.

In questo caso sono abilitate o installate funzioni non necessarie (ad esempio porte, servizi, pagine, account o privilegi non necessari), gli account di default sono attivi e presentano password predefinite, vengono utilizzate impostazioni di sicurezza negli application server, nei framework, nelle librerie, nei database che non assicurano un adeguato livello di protezione.

In questa categoria di vulnerabilità ci sono quelle collegabili a software non aggiornati con l’applicazione delle patch di sicurezza, l’utilizzo di server Web che inviando header o direttive non sicure.

6) Utilizzo di componenti non aggiornati. OWASP richiama l’attenzione sulla necessità di controllare tutti i componenti software utilizzati nei vari progetti software. Usare sistemi operativi, server web, DBMS, applicazioni, API, ambienti di esecuzione e librerie non aggiornati con tutte le ultime patch può mostrare il fianco ad eventuali aggressioni, soprattutto se la superficie d’attacco fosse particolarmente esposta. Un esempio recente è la vulnerabilità scoperta nel componente Log4j, ampiamente utilizzato in molteplici progetti e aziende.

7) Identification and Authentication Failures. La verifica dell’identità dell’utente, l’autenticazione e la gestione delle sessioni sono fondamentali per proteggersi dagli attacchi.
Aggressioni possono presentarsi se l’applicazione permette attacchi automatici come il credential stuffing (l’attaccante possiede una lista di coppie nome utente e password validi).

La sicurezza e l’integrità dei dati è inoltre sotto scacco quando l’applicazione risultasse vulnerabile ad attacchi brute force o ad altre aggressioni automatizzate, con l’uso di password predefinite, di meccanismi non sicuri per il recupero delle password dimenticate, con la memorizzazione di password in chiaro o con funzioni di hashing deboli.

Problemi possono presentarsi se viene esposto l’identificativo della sessione, se tale dato viene riutilizzato dopo un login avvenuto con successo, se la sessione dell’utente e i token di autenticazione non vengono invalidati dopo il logout o trascorso un certo periodo di inattività.

8) Mancata verifica dell’integrità del software. I servizi erogati da un software possono poggiare il loro funzionamento su risorse provenienti da più locazioni.
Se il software si serve di risorse messe a disposizione da fonti non attendibili (che possono quindi essere modificate dagli aggressori) la sicurezza dell’intera applicazione può venire meno.

9) Security Logging and Monitoring Failures. Quando gli eventi verificabili come i login, i login falliti e le transazioni importanti non vengono registrati; i messaggi di allerta ed errori non generano log; l’utilizzo dei log è gestito solo localmente e non sono adottate misure utili a segnalare tempestivamente tentativi di attacco in tempo reale l’applicazione può risultare maggiormente esposta a tentativi di aggressione.

10) Server-Side Request Forgery. Vulnerabilità di questo tipo (SSRF) si verificano ogni volta che un’applicazione web recupera una risorsa remota senza validare l’URL fornito dall’utente. L’aggressore può forzare l’applicazione a inviare una richiesta verso un indirizzo arbitrario anche quando è utilizzato un firewall, una VPN o un meccanismo ACL per gli accessi di rete.

AgID stessa pubblica le linee guida per lo sviluppo di software sicuro.

La segnalazione responsabile delle vulnerabilità

Per incentivare i ricercatori a segnalare responsabilmente e in modo privato eventuali vulnerabilità di sicurezza, le aziende più importanti hanno da tempo avviato programmi bug bounty.
Agli studiosi che informano gli sviluppatori circa l’esistenza di vulnerabilità software precedentemente sconosciute vengono corrisposte somme in denaro di entità variabile.
È un approccio win-win che permette all’azienda sviluppatrice di avere il tempo materiale per sanare una vulnerabilità di sicurezza e al ricercatore di ottenere un adeguato riconoscimento in denaro per il tempo dedicato all’individuazione della nuova vulnerabilità.

Le piattaforme utilizzate dalla Pubblica Amministrazione soffrono anch’esse di vulnerabilità che possono in alcuni casi portare alla compromissione di dati personali o quanto meno alla divulgazione all’insaputa dei diretti interessati.
I problemi alla base di questo tipo di incidenti sono essenzialmente quelli evidenziati da OWASP e sono riconducibili a gravi “leggerezze” commesse nelle varie fasi di sviluppo e testing delle applicazioni.

Può quindi capitare ancora oggi che alterando uno o più dati presenti in un URL o trasmessi a seguito di una richiesta GET o POST si abbia accesso a informazioni riservate che non dovrebbero essere palesi.
Quegli stessi ricercatori che si occupano di sicurezza e che partecipano a programmi bug bounty privati si chiedono come debbano comportarsi nel caso di piattaforme sviluppate o comunque gestite dalla PA.

La risposta è che purtroppo ad oggi lo Stato non incentiva la segnalazione responsabile delle vulnerabilità di sicurezza scoperte nelle applicazioni e nelle piattaforme degli enti pubblici.
Posto che a differenza di quanto accade nel privato un’eventuale remunerazione economica da parte dello Stato – come avviene nel caso dei programmi bug bounty – potrebbe aprirebbe la strada ad altri problemi, riteniamo che chi scopre problematiche di sicurezza nelle piattaforme usate dalla PA dovrebbe essere aiutato e incentivato a farlo.

Cosa accade oggi in Italia? Che chi scopre vulnerabilità nei siti della PA o rende pubblica la problematica incassando una denuncia per violazione di sistemi informativi o si volta dall’altra parte temendo appunto ritorsioni legali (art. 615-ter c.p.).
Risultato? Colui che scopre falle gravi tende a tenere tutto per sé o peggio ancora rivende le informazioni sul mercato nero esponendo a rischi di aggressione i dati altrui che invece andrebbero tutelati.

Come spiega l’avvocato Fulvio Sarzana, il concetto di hacking etico, con la conseguente diffusione responsabile dei dettagli sulle vulnerabilità di sicurezza, non è attualmente riconosciuto nel nostro Paese e ricorda, tra i tanti, il caso di un ricercatore che aveva scoperto una vulnerabilità in un software.

Dopo aver segnalato il problema alla software house sviluppatrice per poi rivolgersi a un’associazione che tutela i consumatori solo a seguito dell’inerzia del produttore nel correggere la vulnerabilità, il ricercatore è stato chiamato in giudizio con l’apertura di un procedimento a suo carico per violazione di sistemi informativi e diffamazione.

Come osserva Sarzana, legale dell’imputato, il Giudice ha archiviato il procedimento osservando che è “prassi consolidata l’invito rivolto dai titolari delle aziende a comunicare loro la presenza di bug (errori di sistema) all’interno del loro apparato da parte di chi ne abbia conoscenza“.
Nel decreto di archiviazione si legge inoltre che “l’indagato ha inviato una serie di missive allo staff dell’azienda sviluppatrice e solo a seguito dell’inerzia della medesima di voler correggere la vulnerabilità del sistema, si è deciso a render noto, a tutela dei consumatori, la presenza di un simile errore a distanza di un mese dalla sua segnalazione. La condotta non integra pertanto, sulla scorta di quanto chiarito, il delitto di cui all’art. 615-ter c.p., inquadrandosi la stessa nella metodologia comune della divulgazione responsabile avendo peraltro l’indagato medesimo contattato prima l’azienda coinvolta proprio per consentirle di emendare l’errore entro un lasso di tempo, che può variare da trenta giorni a
un anno, a seconda della gravità e della complessità della vulnerabilità“.

In altre parole il Giudice ha citato espliciti riferimenti in materia di hacking etico e ne ha condiviso gli aspetti fondamentali ma come ha ben sottolineato Sarzana la “divulgazione responsabile” delle vulnerabilità in Italia porta all’avvio di vertenze legali nella stragrande maggioranza dei casi. Con tutte le spese, lo stress e i rischi che l’indagato si trova a dover affrontare.

All’alba della nascita della nuova Agenzia per la Cybersecurity nazionale diretta da Roberto Baldoni (Agenzia per la sicurezza cibernetica) ci sembra manchi un tassello importante.
L’Agenzia si occuperà di prevenzione e mitigazione degli incidenti legati alla sicurezza informatica (data breach; di concerto con il CSIRT, a sua volta integrato nella nuova realtà italiana), di collaborazione e cooperazione internazionale per la cybersecurity, di valorizzazione delle competenze come sistema Paese, di indipendenza tecnologica dell’Italia e dell’Europa.

Qual è il pezzetto del puzzle che a nostro avviso manca all’appello? Proprio un intervento del legislatore che introduca il concetto di hacking etico e stabilisca con chiarezza ed autorevolezza le modalità e gli strumenti che i ricercatori possono utilizzare per segnalare responsabilmente vulnerabilità e problemi di sicurezza scoperti nelle piattaforme realizzate da privati o da/per la Pubblica Amministrazione.