log4shell
IWS21

Di seguito vi proponiamo alcune considerazioni di Jonathan Tanner, Senior Security Researcher di Barracuda, sulla vulnerabilità in Log4j sfruttata dagli hacker per lanciare centinaia di migliaia di attacchi nel giro di pochi giorni. L’analisi verte sia sulla necessità di individuare e correggere la vulnerabilità, sia i rischi intrinsechi alle soluzioni open source secondo quanto accaduto con Log4Jj.

Come verificare la vulnerabilità: quali sono i rischi se si sottovaluta

La prima cosa da controllare è se viene usata una qualsiasi versione di log4j precedente la 2.15.0, dipendenze incluse. Maven e  Gradle hanno entrambi la possibilità di stampare l’intero albero delle dipendenze di un progetto, il che permetterà di stabilire se sia stata usata o meno una versione vulnerabile di log4j. Anche con la versione 2.15.0 o successive andrebbe comunque verificato che la proprietà di sistema formatMsgNoLookups non sia impostata su True dato che questa versione non è vulnerabile quando il valore di default passa da True a False. In alcune versioni di log4j, per mitigare la vulnerabilità, questa proprietà può essere impostata manualmente su False. Se l’applicazione non richiede LDAP per il suo legittimo utilizzo è anche possibile bloccare tutto il traffico LDAP con un firewall o un Web Application Filter per prevenire che venga raggiunto il codice remoto nel caso in cui la vulnerabilità venga sfruttata. 

Queste operazioni però controllano solo se log4j è in grado o meno di utilizzare la vulnerabilità RCE. Che il sistema sia o no veramente vulnerabile a un attacco è una questione molto più complicata in assenza di un test simile a quello per la vulnerabilità HeartBleed. Per sfruttare questa vulnerabilità il cybercriminale dovrebbe eseguire un attacco log injection. Riconoscerlo è un processo molto complicato ma essenzialmente ovunque venga registrato l’input di un utente (o potenziale intruso) potrebbe essere vulnerabile a questo exploit.

Pertanto, eseguire un test per un RCE vorrebbe dire trovare il modo di fare una richiesta JNDI LDAP all’interno del log dal contesto dell’utente (ad esempio mediante un sito web o delle API se l’applicazione potenzialmente colpita è un’applicazione web).

Poiché questa vulnerabilità permette la Remote Code Execution, il rischio è alto nel caso in cui la vulnerabilità sia presente. Un criminale potrebbe ottenere l’accesso alla rete e da qui cercare di accedere a dati e risorse critiche. 

Log4j: considerazioni sulla sicurezza dell’open source

Trattandosi di una libreria open source molto popolare, la possibilità di avere applicazioni vulnerabili è certamente alta. In generale, ogni software può essere vulnerabile agli attacchi e spesso il software open source più diffuso può contare su un vasto ecosistema di sviluppatori alla ricerca di eventuali vulnerabilità. Quindi, se è vero che il software open source fa notizia quando si trovano importanti buchi della sicurezza, non significa che sia meno sicuro (e in effetti è assai probabile che sia molto più sicuro di un codice proprietario o di librerie meno popolari). L’uso diffuso semplicemente aumenta la probabilità che queste vulnerabilità siano individuate, non necessariamente che esse esistano.

Quando utilizzano librerie open source le organizzazioni dovrebbero privilegiare grandi progetti, adeguatamente manutenuti e di buona reputazione, come log4j, per le ragioni già viste. Ovviamente, è comunque sempre possibile che ci siano delle vulnerabilità, ma è anche più probabile che la comunità le trovi e produca le patch, oltre che verifichi che il codice sia privo di bug che potrebbero creare vulnerabilità.

Anche per quelle applicazioni non vulnerabili a CVE-2021-44228 o che non usano log4j per il logging, questa vulnerabilità ci ricorda che il log injection è un metodo che i criminali possono usare. Varrebbe la pena di verificare che ogni input da parte dell’utente sia adeguatamente sanificato in ogni applicazione, indipendentemente da quale sistema di logging o linguaggio di programmazione sia stato usato. Mentre altre forme di injection sono molto più diffuse e mirate, la log injection è sempre una forma di attacco e quindi deve rientrare tra le vulnerabilità Top 10  OWASP.

Ulteriori informazioni: Barracuda WAF and WAF-as-a-Service protect against the Apache Log4j Critical Vulnerability