L’allarme scattato per la vulnerabilità CVE-2021-44228 che affligge Apache Log4J rimbalza per il Web, turbando i sonni di amministratori IT e responsabili di cyber security. Semplice paranoia? No. A dimostrarlo sono i dati che arrivano da tutti i ricercatori di sicurezza, che in pochi giorni hanno registrato milioni di tentativi di attacco (e chissà quanti altri passati inosservati) basati sull’exploit che sfrutta il bug di Log4j.
A rendere particolarmente insidiosa la vulnerabilità di Log4j sono diversi elementi. Il primo riguarda le caratteristiche stesse del componente affetto dal bug. Si tratta infatti di una libreria utilizzata per gestire i log in ambiente Java e che è inclusa in migliaia (forse milioni) di servizi e applicazioni. A differenza di una falla di sicurezza in un’applicazione, di conseguenza, Log4Shell (come è stata battezzata la tecnica di attacco che sfrutta il bug) può colpire un numero imprecisato di software. Il secondo elemento di pericolosità riguarda il fatto che il Proof of Concept (PoC) che lo sfrutta, cioè il codice che consente di portare l’attacco, è stato reso pubblico ed è di conseguenza disponibile per chiunque. Il terzo, infine, è la facilità con cui è possibile far partire l’attacco: basta inviare una particolare stringa allo user agent di Log4j per prendere il controllo del server o del sistema che sfrutta la libreria. Insomma: siamo di fronte a una vulnerabilità che impatta su un numero impressionante di macchine e che consente di portare attacchi a tappeto con una facilità disarmante. Tanto più che dopo il primo allarme riguardante la versione 2.14 e il rilascio della patch alla versione 2.15, sono emerse a stretto giro due nuove vulnerabilità della libreria, che hanno portato al rilascio di una versione 2.16 e, successivamente, della definitiva 2.17.
Lo tsunami di attacchi a cui anche Cyberoo sta assistendo potrebbe essere solo la punta dell’iceberg. L’affaire Log4j, infatti, è probabilmente destinato a impegnare tutti ancora per molto tempo. Prima di tutto perché individuare la falla è tutt’altro che semplice. Log4j è solo una delle centinaia di librerie che di solito sono integrate in un’applicazione e non sempre la sua presenza è documentata. In altre parole, Log4j è un “mattoncino” usato dai programmatori con tale frequenza che la sua presenza viene data per scontata o addirittura, è dovuta al fatto che la libreria è integrata in un modulo o componente intermedio che è stato utilizzato per lo sviluppo dell’applicativo. L’unico modo per individuarne la presenza è ricorrere a tecniche di Cyber Security Intelligence (Cyberoo ha già predisposto gli strumenti adeguati) per individuare la vulnerabilità sui sistemi aziendali. Chi non avvia questi processi, corre il rischio di “tenersi in casa” una falla di sicurezza pericolosissima. Non solo: il modus operandi adottato da molti pirati informatici non prevede un immediato sfruttamento della vulnerabilità per portare attacchi “visibili”. Anzi, la maggior parte dei cyber criminali opera ormai con una logica ispirata al brokering degli accessi, aprendo backdoor all’interno delle reti compromesse per poi rivenderle sul mercato nero ad altri pirati informatici.
A rendere più complessa la situazione, oltre alla difficoltà di individuare le applicazioni interessate dal bug in Log4j, c’è il fatto che la versione vulnerabile della libreria è ancora integrata in numerosi package di sviluppo per ambiente Java. Nel solo repository Maven Central, uno dei più utilizzati dagli sviluppatori, ci sarebbero più di 35.000 package che contengono versioni vulnerabili della libreria Log4j . Il rischio, in pratica, è che la falla di sicurezza si presenti anche in nuove applicazioni per il cui sviluppo sono stati utilizzati strumenti non aggiornati. La strategia per contrastare il fenomeno, in questo caso, prevede l’adozione di rigorosi processi di DevSecOps in fase di sviluppo delle applicazioni. Insomma: la situazione è critica ma gli strumenti per contrastare il rischio di attacchi ci sono. E questa è una buona notizia.
Per ulteriori informazioni sulla specifica vulnerabilità puoi utilizzare il contatto di cui sotto, indicando nell'oggetto: "log4shell" e nome azienda.
Risorse addizionali
- Descrizione ufficiale Mitre CVE