I team di security che stanno cercando di mitigare l'esposizione delle proprie aziende alla vulnerabilità Log4j, soprannominata Log4Shell, hanno molte sfide da superare. Il problema principale, infatti, è che si tratta di una falla trasversale, che è indipendente dal fornitore e che colpisce sia il software proprietario sia quello open source. Per questo coinvolge tutti i settori privati e professionali di tutti i Paesi.

A ricordare il coinvolgimento dell’Italia è Salvatore Marcis, Technical Director Trend Micro Italia, che sottolinea come “Anche in Italia sono già stati individuati aggressori che sfruttano la falla per installare coin miner, Cobalt Strike per ransomware e altro ancora. Le aziende devono sempre prestare la massima attenzione ai bollettini di security, mantenere i sistemi sempre aggiornati e, per contrastare lo sfruttamento delle vulnerabilità, dotarsi di sistemi di virtual patching”.

Combattere questa nuova minaccia tuttavia sarà arduo. Molte aziende saranno costrette a monitorare costantemente gli Indicatori di Compromissione: CERT-AGID li ha pubblicati in un file di testo accessibile da questa pagina. L’ente italiano, tuttavia, ha precisato che nonostante l’impegno per tenere il file aggiornato sarà difficile rendere questo elenco totalmente esaustivo, data la semplicità con la quale la falla può essere sfruttata.

Tutti sono a rischio

Ricordiamo che la vulnerabilità CVE-2021-44228, che ha un indice di gravità di 10 su 10, non richiede particolari abilità per essere sfruttata ed è presente praticamente in ogni ambiente IT. Quasi tutti i fornitori di sicurezza informatica stanno pubblicando dati drammatici. Oltre ai dati già noti diffusi da Check Point Software Technologies, riprendiamo a titolo di esempio quelli pubblicati dal fornitore di cyber security Veracode, che ha l'88% dei clienti con una versione di Log4j in uso e il 58% con una versione vulnerabile nei propri ambienti.

Un’altra aziende di sicurezza, Armis, mercoledì ha riferito che circa il 35% dei suoi clienti era sotto attacco attivo tramite la falla Log4Shell, e il 31% aveva una minaccia correlata a Log4j su dispositivi non gestiti. La superficie d’attacco è talmente vasta e gli exploit sono talmente versatili che gli attaccanti possono fare praticamente di tutto: installare coin miner, ransomware, trojan di accesso remoto, web shell e botnet malware. Sembra che non ci siano limiti alle opportunità criminali fornite dalla situazione.

Gli esperti di Armis hanno anche fornito il dettaglio delle risorse finora più bersagliate negli ambienti IT: server, macchine virtuali e dispositivi mobili. I rischi sono enormi se si pensa che nelle reti OT il 49% dei dispositivi compromessi sono macchine virtuali e il 43% sono server. Altri dispositivi mirati nelle reti OT includono telecamere IP, dispositivi HMI (Human Machine Interface) e sistemi SCADA.

La sfida

Una delle principali sfide che le aziende stanno cercando di fronteggiare è comprendere la proporzione della propria esposizione alla minaccia. Infatti, la vulnerabilità può essere presente sia sulle risorse Internet, sia sui sistemi interni e di back-end, negli switch di rete, nei SIEM e in altri sistemi di gestione, nelle app sviluppate internamente o da terze parti, nei servizi SaaS e cloud, e in ambienti che potrebbero persino restare sconosciuti.

Le interdipendenze tra differenti applicazioni e componenti sono tali per cui anche se un componente non è direttamente afflitto dalla vulnerabilità, può esserne influenzato in maniera indiretta. Questo è dovuto in parte a come sono configurate le infrastrutture e a quali componenti hardware e software integrano. Ma è anche una questione insita nel funzionamento stesso di Java, che rendere difficile identificare le applicazioni interessate.

Sul tema sono intervenuti gli esperti di Noname Security, che spiegano come un archivio Java (JAR) potrebbe racchiudere tutte le dipendenze, inclusa la libreria Log4j, di un particolare componente. Ma quello stesso archivio JAR potrebbe contenere un altro archivio JAR che, a sua volta, potrebbe contenere un altro archivio JAR: un modello a scatole cinesi che può seppellire la vulnerabilità talmente a fondo da renderne pressoché impossibile la rilevazione.

Questo scenario mette in risalto ancora una volta l'importanza di un inventario digitale. A questo proposito Francesco Armando, Technical Account Manager per l’Italia di Qualys, conferma che "i moderni ambienti informatici hanno una natura dinamica e complessa che rende quanto mai probabile la possibilità di non vedere asset connessi o meno all’architettura aziendale. Gli asset presenti fisicamente in azienda possono essere utilizzati direttamente o tramite strati di virtualizzazione erogati da hypervisor e spesso questi ambienti si estendono a loro volta in ambienti cloud (IaaS, PaaS) e i device mobili paiono spesso ubiqui, come se fossero contemporaneamente in diversi posti. Lo scenario non è semplificato dall’avvento dell’Internet of Things. Reti IP connettono il lato OT (operation technology) con quello tipicamente IT, facendo convergere ancora più dati, processi e sistemi. Nella migliore delle ipotesi tutti questi sistemi hanno inventari e cataloghi di applicazioni proprietari e separati. Molto spesso si trovano asset che non sono censiti e nella miglior delle ipotesi qualche persona di buona volontà sta cercando di tenerne traccia in un foglio di calcolo".

Per non parlare del fatto, evidenziato da Netskope, che Log4j è popolare anche fra dispositivi IoT e sistemi legacy che vengono mantenuti in attività per motivi di compatibilità con prodotti obsoleti. Questo significa che - anche nel caso in cui si comprendesse che un'applicazione è vulnerabile - non sarebbe scontato aggiornarla.

API e app

L’elenco dei problemi non è finito. Noname Security ricorda anche che la vulnerabilità Log4j può interessare anche gli ambienti API (Application Programming Interface). I server API che contengono la vulnerabilità costituiscono un vettore di attacco che piace ai cyber criminali perché molte aziende hanno una visibilità limitata sul loro inventario di API e sul comportamento di queste ultime.

Non sono al sicuro nemmeno le realtà che non fanno direttamente uso di framework di registrazione Log4j, perché potrebbero utilizzare API di terze parti attendibili, ma che contengono la falla Log4j, esponendosi comunque al rischio di attacco. Concludendo, non usare Java non garantisce di essere al sicuro perché la libreria fallata potrebbe essere incorporata in qualsiasi software di terze parti.

È per questo motivo che in molte aziende è in corso il mapping di tutti i server che eseguono API con qualsiasi servizio Java, compresi quelli di terze parti. Il guaio è che l’installazione delle patch non sempre è disponibile perché non tutti i fornitori le hanno pubblicate.

Trend Micro ha creato uno strumento di scansione rapido basato sul web per identificare le applicazioni server che potrebbero essere interessate da Log4Shell: si può trovare a questo link.