All’inizio del mese scorso, i ricercatori della sicurezza hanno scoperto una serie di importanti vulnerabilità nel software Java Log4j utilizzato in decine di migliaia di applicazioni web. Il codice è ampiamente utilizzato nei sistemi consumer e aziendali, da Minecraft, Steam e iCloud fino ai sistemi di Fortinet e Red Hat. Un analista stima che milioni di endpoint potrebbero essere a rischio.

Log4j è solo l’ultimo di una serie di attacchi alla supply chain dopo quelli di SolarWinds (che ha avuto un processo di compilazione compromesso) e Kaseya (dove gli aggressori hanno sostituito il codice contenente malware).

Da quando è venuta alla luce la prima vulnerabilità di Log4j, i fornitori di sicurezza e gli analisti hanno pubblicato una grande quantità di informazioni su cosa fare e su come proteggersi. Alcuni hanno previsto scenari quasi apocalittici, mentre altri hanno previsioni meno disastrose. Check Point Software Technologies ha scoperto tentativi di exploit in quasi la metà della sua base di clienti, mentre Contrast Security ha rilevato che il 58% delle applicazioni Java ha versioni vulnerabili, ma solo il 37% utilizza Log4j.

Le quattro versioni Java vulnerabili sono CVE-2021-44228, CVE-2021-45046, CVE-2021-4104 e CVE-2021-45105. La US Cybersecurity and Infrastructure Security Agency gestisce una pagina Web con collegamenti a vari blog di fornitori, insieme a un elenco di applicazioni interessate, e sta cercando di mantenere entrambe aggiornate con eventuali correzioni.

I problemi riguardano diverse funzioni del software di registrazione, inclusi Java Naming and Directory Interface (JDNI) e messaggi di evento JMSAppender, che consentono entrambi l’esecuzione di codice remoto. Ciò che rende così pericolosa questa raccolta di vulnerabilità è che gli aggressori non hanno bisogno di molta esperienza per ottenere questo accesso remoto. L’ultima vulnerabilità si riferisce a una condizione denial-of-service, mentre più recentemente Blumira ha scoperto un nuovo vettore di attacco che amplia la superficie complessiva utilizzando WebSockets.

Sembra insomma che le vulnerabilità di Log4j ci accompagneranno ancora per molto tempo. Ciò che è chiaro è che gli sviluppatore di applicazioni hanno e avranno molto lavoro da fare per trovare, risolvere e prevenire i problemi di log4j a breve e a lungo termine.

Potreste già essere a rischio

Ariel Parnes, COO di Mitiga, suggerisce di “vedere se la vostra organizzazione è stata già hackerata utilizzando Log4j in passato. I criminali potrebbero essere già dentro”. Il responsabile IT John Cronin pone invece delle domande chiave: “Sapete quale dei vostri server utilizza Log4j? Quanto tempo ci vorrà per produrre un elenco di quei server? Potete patcharli con un attimo di preavviso? Avete strumenti automatizzati o qualcuno ha bisogno di accedere a tutti i server e farlo manualmente? Avete un processo per applicare patch ai server di produzione live durante i periodi di picco di utilizzo?” Rispondere a queste domande richiederà certamente uno sforzo.

blog-feature-log4j-vulnerability-orange

Gli analisti della sicurezza hanno scoperto exploit risalenti all’1 dicembre che hanno utilizzato un’ampia gamma di protocolli di rete tra cui LDAP, RMI, DNS e HTTP. Questi exploit hanno installato una varietà di malware, inclusi miner di criptovaluta, una nuova famiglia di ransomware che Bitdefender chiama Khonsari e codice per unirsi alla botnet Mirai. E per finire, diversi ricercatori hanno segnalato exploit provenienti da aggressori sponsorizzati dallo stato in Cina, Corea del Nord, Turchia e Iran.

Il vostro piano di difesa immediato

La vostra prima linea di difesa è l’aggiornamento alle versioni Log4j più recenti. Inizialmente, Apache ha rilasciato una patch che si è rivelata avere ancora delle vulnerabilità. Le versioni più recenti sono Log4j v.2.17.0, se si esegue Java 8 o versioni successive, e Log4j v.2.12.2, se si esegue Java 7 nell’infrastruttura dell’app Web.

Queste patch disattivano JNDI per impostazione predefinita e rimuovono l’accesso alla ricerca dei messaggi, funzioni che sono alla base delle varie vulnerabilità. La disabilitazione di JNDI potrebbe però danneggiare qualcosa nelle vostre app, quindi verificate attentamente prima di implementarla in qualsiasi sistema di produzione. Potreste anche voler interrompere qualsiasi registrazione basata su Java se non ne avete bisogno per nessuna delle vostre applicazioni. Ancora una volta, fate delle prove prima della distribuzione.

Quali strumenti di rilevamento sono disponibili

I fornitori di sicurezza hanno fatto gli straordinari per potenziare i loro strumenti e dovreste approfittare di varie offerte gratuite. Di seguito riportiamo un elenco con diversi scanner che possono essere utilizzati per individuare il codice vulnerabile nelle applicazioni in esecuzione o nei file di origine. Dovreste determinare se quel codice è stato distribuito in qualsiasi istanza di produzione.

Strategie a lungo termine per migliorare la sicurezza del coding

  • Innanzitutto, bisogna comprendere le dipendenze del codice. Log4j è infatti estremamente popolare ed è incluso in numerose librerie Java. Una volta che avete eliminato le versioni precedenti dal vostro codice, dovete indagare su cos’altro state eseguendo che possa dipendere da Log4j.Se utilizzate i framework Apache Struts2, Flume, Dubbo, Kafka, Solr, Druid o Fink, dovrete aggiornare le librerie Log4j all’interno di questi progetti. Se Struts vi suona famigliare, è perché un exploit nel 2017 ha portato alla compromissione dei database di Equifax, con un conseguente leak di dati privati di oltre 140 milioni di clienti. Tanya Janca di WeHackPurple suggerisce inoltre di utilizzare dependencyGraph, Snyk o Dependency-Check di OWASP.
  • Capire come funzionano i firewall delle applicazioni Web (WAF). Se non avete un WAF, ora è arrivato il momento di usarne uno. Se uno qualsiasi dei vostri codici è distribuito dietro un WAF, attivate le sue regole di rilevamento e controllate se il fornitore ha aggiornato le sue regole per coprire tutte le ultime vulnerabilità. Considerate però che da quando è stata annunciata la vulnerabilità, i ricercatori hanno scoperto diversi modi per creare payload offuscati che aggirerebbero le regole di filtraggio di un WAF. Fastly fornisce un’ampia spiegazione su come testare l’efficacia del WAF.
  • Approfittare della mitigazione della vulnerabilità di Log4j e degli strumenti di patch. Diverse aziende hanno già fornito strumenti di mitigazione per Log4j. Cybereason ha messo insieme questo codice. LunaSec lo ha ulteriormente migliorato e lo ha ospitato su un server live come servizio pubblico. Il team Corretto di Amazon Web Services ha sviluppato un agente Java per applicare patch a Log4j L’agente è disponibile su GitHub. Contrast Security propone invece SafeLog4j, che rileva e corregge gli attacchi di bypass WAF. Cisco offre una prova gratuita di 30 giorni del suo Secure Endpoint. Infine, se state usando dei container, avrete bisogno di prodotti di protezione speciali. Ad esempio, Red Hat ha aggiornato Advanced Cluster Security per Kubernetes e Palo Alto Networks ha aggiornato Prisma Cloud.