Java fonte di guai, l'88% delle applicazioni è attaccabile

Il pericolo si annida nelle applicazioni Java. Moltissime, quasi una su nove tra quelle utilizzate in azienda (l'88%), contengono almeno un componente vulnerabile, che le espone a potenziali attacchi informatici. È quanto emerso dai test di sicurezza condotti fra aprile 2016 e marzo 2017 da Veracode, società di cybersicurezza sussidiaria di Ca Technologies, su quasi 250 miliardi di righe di codice di applicazioni usate da 1.400 clienti I risultati dei test, confluiti nello studio “2017 State of Software Security Report”, hanno evidenziato una serie di rischi connessi all'uso di componenti open source (fino al 75% del codice di una tipica applicazione è costituto da componenti di questo tipo) e uno scarso livello di controllo e consapevolezza fra le aziende sui propri livelli di sicurezza. Solo il 28% dei clienti di Veracode, infatti, esegue regolarmente analisi al fine di comprendere quali siano i componenti presenti nelle proprie applicazioni.

I problemi riguardano innanzitutto il software non precedentemente testato: il 77% delle app presenta almeno una vulnerabilità in sede di prima scansione, e nel 12% si trattava di un difetto grave. Tra i settori, le organizzazioni governative non possono certo vantare livelli di sicurezza migliori della media, anzi: nell'ultimo scanning hanno ottenuto un tasso di superamento del test di appena il 24,7% e hanno registrato la più alta prevalenza di vulnerabilità altamente sfruttabili, quali cross-site scripting (49%) ed Sql injection (32%).

L’uso di componenti per lo sviluppo applicativo è un pratica diffusa, che consente agli sviluppatori di riutilizzare codice funzionale e, quindi, di accelerare il rilascio del software. Il rovescio della medaglia è che, in caso di vulnerabilità, i cybercriminali hanno davvero vita facile: “L’impiego universale di componenti per lo sviluppo applicativo”, ha commentato il chief technology officer di Ca Veracode, Chris Wysopal, “implica che, quando emerge una vulnerabilità a carico di un componente, essa possa potenzialmente interessare migliaia di applicazioni”. Può dunque bastare un unico exploit per colpire e violare molte applicazioni differenti.

Non mancano le dimostrazioni, purtroppo. Fra i casi eclatanti degli ultimi mesi, un esempio di vulnerabilità di vaste proporzioni a livello di componenti è stato Struts-Shock, scoperto nel marzo 2017. Stando all'analisi di Veracode, il 68% delle applicazioni Java basate sulla libreria Apache Struts 2 persisteva nell'utilizzare una versione vulnerabile del componente anche nelle settimane successive ai primi attacchi. Questa vulnerabilità critica presente nella libreria Apache Struts 2 riguardava decine di milioni di siti Web (35 milioni, secondo Veracode) e ha permesso ai criminali informatici di sferrare delle offensive di tipo Remote Code Execution basato su iniezione di comandi. Tra i bersagli colpiti spiccano i siti dell’Agenzia canadese delle Entrate e dell’Università del Delaware. 

I test di Veracode hanno anche evidenziato che oltre la metà (53,3%) delle applicazioni Java si fonda su una versione vulnerabile dei componenti Commons Collections. Versione risalente al 2016 e oggi notoriamente fallata, ma ancora impiegata in moltissime applicazioni vecchie e nuove.

I tempi di risoluzione delle vulnerabilità sono lunghi (infografica: Ca Veracode)

L'open source è quindi da condannare? No, ma bisogna elevare i livelli di controllo e anche la velocità di risposta alle vulnerabilità scoperte. Dalle analisi di Veracode è emerso che solo il 22% dei difetti gravi è stato risolto in meno di un mese, mentre agli aggressori bastano tempi molto più brevi, pochi giorni, per individuare e sfruttare una debolezza del software. “I team addetti allo sviluppo non smetteranno certo di utilizzare i componenti, ed è giusto che sia così”, ha commentato Wysopal. “Quando però compare un exploit, il fattore tempo è fondamentale. I componenti open source e di terze parti non sono necessariamente meno sicuri del codice sviluppato in casa, ma è essenziale mantenere un inventario aggiornato delle versioni utilizzate per ogni componente”.