La comunità della sicurezza IT ha lavorato duramente la scorsa settimana per indagare su una vulnerabilità critica e facile da sfruttare in un componente Java estremamente popolare chiamato Log4j, presente in milioni di applicazioni e prodotti. Da quando la falla è stata scoperta per la prima volta e gli aggressori hanno iniziato a sfruttarla, i ricercatori di sicurezza hanno scoperto ulteriori problemi di sicurezza in Log4j e vari modi per aggirare alcune delle mitigazioni proposte.

L’aggiornamento del componente interessato all’ultima versione, attualmente 2.16.0 per Java 8 e versioni successive e 2.12.2 per Java 7 e versioni precedenti (non ancora rilasciate), è il modo migliore per mitigare le due vulnerabilità identificate finora: CVE -2021-44228, noto anche come Log4Shell, che porta all’esecuzione di codice remoto, e CVE-2021-45046, che può causare una condizione di denial-of-service.

Sfortunatamente, l’applicazione immediata delle patch non è praticabile in tutti gli scenari. I prodotti pacchettizzati di fornitori di terze parti potrebbero contenere versioni vulnerabili della popolare libreria di registrazione che gli utenti non possono modificare senza aggiornare l’intero prodotto e quindi si deve sperare che siano i fornitori a rilasciare gli aggiornamenti.

Le applicazioni e i server critici per l’azienda potrebbero non essere in grado di riavviarsi immediatamente o le applicazioni potrebbero essere eseguite in container per i quali è necessario creare nuove immagini container. Come con la maggior parte delle vulnerabilità, le mitigazioni alternative sono molto utili per i team di sicurezza, ma è importante comprendere i loro limiti e il falso senso di sicurezza che alcune di esse possono indurre.

Rimozione della classe JndiLookup

Questa vulnerabilità è causata dal modo in cui Log4j utilizza una funzionalità Java denominata JNDI (Java Naming and Directory Interface) progettata per consentire il caricamento di oggetti Java aggiuntivi durante l’esecuzione del runtime. JNDI può essere utilizzata per caricare tali oggetti da servizi di denominazione remoti su diversi protocolli. L’exploit originale utilizzava LDAP (Lightweight Directory Access Protocol), che è il più comune, ma ne sono supportati anche altri: DNS (Domain Name System), RMI (Remote Method Invocation), NDS (Novell Directory Services), NIS (Network Information Service) e CORBA (Common Object Request Broker Architecture).

Un modo per correggere la vulnerabilità è disabilitare l’uso dei message lookups JNDI, che è ciò che fa Log4j 2.16.0. Tuttavia, questo può anche essere ottenuto essenzialmente rimuovendo l’intera classe JndiLookup, che implementa questa funzionalità, da un pacchetto Log4j interessato. Poiché i componenti Java sono essenzialmente archivi ZIP, gli amministratori possono eseguire il seguente comando per modificare e correggere un’istanza di pacchetto vulnerabile:

zip -q -d log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.class

Hotpatch utilizzando un agente Java

L’hotpatching è il processo di distribuzione di una patch a un processo in esecuzione senza doverlo riavviare. Java supporta la modifica al volo del byte-code che è già in esecuzione in una Java Virtual Machine (JVM) tramite un’API di strumentazione e i cosiddetti agenti Java. Un agente Java è essenzialmente un file JAR (Java Archive) che può essere collegato dinamicamente a una JVM durante il runtime.

In risposta alle vulnerabilità Log4j, il team di Corretto di Amazon Web Services ha sviluppato un agente Java che tenta di correggere il metodo lookup() di tutte le istanze org.apache.logging.log4j.core.lookup.JndiLookup caricate per restituire la stringa “Patched JndiLookup::lookup()” invece di connettersi a un server remoto.

L’agente è disponibile su GitHub e può anche essere distribuito come container effimero su un pod Kubernetes esistente per applicare patch ad applicazioni già in esecuzione in altri container. I container effimeri sono supportati in Kubernetes v1.16 e versioni successive.

Sfruttare la vulnerabilità stessa per prevenirne temporaneamente lo sfruttamento

È possibile sfruttare la vulnerabilità stessa sui server interessati per apportare determinate modifiche al sistema e all’applicazione che impedirebbero un ulteriore sfruttamento. I ricercatori della società di sicurezza Cybereason hanno sviluppato questo exploit di immunizzazione e i ricercatori di LunaSec lo hanno ulteriormente migliorato e ospitato su un server live come servizio pubblico.

Uno scenario tipo per questo exploit sono tutti quei prodotti di fornitori di terze parti (applicazioni pacchettizzate, dispositivi e appliance embedded) che non hanno ancora patch disponibili o prodotti vulnerabili che hanno raggiunto la fine del ciclo di vita e non riceveranno mai un aggiornamento ufficiale. L’utilizzo dell’exploit contro se stesso potrebbe essere una soluzione praticabile a breve termine.

malware

È importante capire che l’utilizzo di questa pratica comporta alcuni importanti avvertimenti. Innanzitutto, il fix è temporaneo perché le modifiche apportate dall’exploit si applicano al processo Java in esecuzione e verranno ripristinate al riavvio della JVM. Ciò significa che l’immunizzazione deve essere riapplicata se il server viene riavviato. In secondo luogo, sebbene il metodo sia stato testato su varie configurazioni e sistemi, è possibile che non funzioni su tutti e che su alcuni possa causare arresti anomali. Il ripristino da un arresto anomalo potrebbe comportare un riavvio del server, quindi non è una buona idea eseguirlo su sistemi critici in cui i tempi di inattività non sono un’opzione.

Infine, l’utilizzo di questo fix su server di cui non si ha la proprietà e che non si controllano è probabilmente illegale poiché sfrutta la vulnerabilità, anche se per scopi non dannosi.

Identificazione dei sistemi vulnerabili

Prima che venga sviluppata qualsiasi strategia di risposta e che uno dei suddetti percorsi di mitigazione possa essere utilizzato, le organizzazioni devono prima identificare tutte le applicazioni e i sistemi che potrebbero essere vulnerabili agli exploit Log4j. Non è però una cosa facile da fare, considerando che ogni applicazione può raggruppare la propria istanza di Log4j e potrebbe anche caricarla dinamicamente come parte di qualche altra dipendenza di terze parti.

Diversi elenchi di avvisi sui fornitori di Log4Shell sono gestiti dalla comunità della sicurezza e dai CERT, ma è probabile che siano incompleti. Sfortunatamente, fino a quando le distinte base software (SBOM) non saranno ampiamente adottate dagli sviluppatori di software, i team di sicurezza dovranno affrontare il compito lungo (e soggetto a errori) di identificare i sistemi interessati nelle loro organizzazioni in risposta a ogni nuova vulnerabilità. È probabile che più ricercatori e aggressori inizieranno a cercare vulnerabilità in altri componenti ampiamente utilizzati.

La comunità della sicurezza ha risposto rapidamente sviluppando strumenti open source per automatizzare la ricerca di server e istanze vulnerabili del pacchetto Log4j. Lo strumento log4shell di LunaSec può controllare i file .jar e .war in una directory di progetto e segnalare se sono vulnerabili. Il supporto per le vulnerabilità Log4j è stato aggiunto ad altri scanner e strumenti di vulnerabilità commerciali e open-source.

Mitigazioni insufficienti

Da quando è stata annunciata la prima vulnerabilità Log4j, diverse soluzioni di mitigazione proposte si sono dimostrate inefficaci e non dovrebbero quindi più essere utilizzate.

  • L’aggiornamento della versione Java non è sufficiente. L’exploit iniziale non ha funzionato sulle versioni Java più recenti di 6u212, 7u202, 8u192 o 11.0.2 perché la configurazione predefinita in queste versioni impedisce il caricamento della classe tramite JNDI (Java Naming and Directory Interface) da server remoti. Tuttavia, da allora i ricercatori hanno dimostrato che gli aggressori possono creare payload che sfruttano le classi nel classpath dell’applicazione anziché quelli remoti; per tanto questo metodo questo non impedisce tutti gli attacchi.
  • Il flag formatMsgNoLookups non impedisce tutti gli exploit. I primi consigli di mitigazione, inclusi quelli degli sviluppatori di Log4j, erano di impostare una proprietà chiamata formatMsgNoLookups nelle versioni di Log4j successive alla 2.10 su true o una variabile di ambiente chiamata LOG4J_FORMAT_MSG_NO_LOOKUPS. Ciò si è dimostrato inefficiente dalla seconda vulnerabilità denial-of-service, che funziona anche con questo flag abilitato.
  • Disabilitazione dei message lookups modificando i formati delle istruzioni di registro. Un’altra mitigazione proposta inizialmente era quella di modificare tutti i formati delle istruzioni di registro nell’applicazione da %m, %msg o %message a %m{nolookups}, %msg{nolookups} o %message{nolookups} per disabilitare la funzione di message lookups. Questo metodo però non solo non funziona per le stesse ragioni del flag formatMsgNoLookups, ma è anche pericoloso perché crea un falso senso di sicurezza. È molto facile non aggiornare un’istruzione di registrazione in una dipendenza o reintrodurre un’istruzione %m vulnerabile in un secondo momento senza rendersene conto. Se avete già utilizzato questa mitigazione, non dovreste fare affidamento su di essa.
  • Utilizzo di firewall per applicazioni Web (WAF) per filtrare le richieste malevole. Sebbene sia possibile bloccare gli exploit noti con un firewall per applicazioni Web, è molto difficile catturare tutte le possibili stringhe di exploit. Da quando è stata annunciata la vulnerabilità, i ricercatori hanno dimostrato molti modi per creare payload che aggirerebbero le regole di filtraggio WAF proposte. Detto questo, i fornitori di WAF e IPS aggiornano costantemente le loro firme Log4Shell, quindi questo metodo può essere utilizzato come risposta immediata e temporanea per bloccare exploit noti o come livello di difesa aggiuntivo oltre ad altre mitigazioni. Vale la pena notare che i WAF vengono normalmente utilizzati per risorse esposte pubblicamente, ma esistono percorsi e scenari di exploit interni per questa vulnerabilità che non passerebbero attraverso un WAF per essere bloccati.

Poiché la comunità della sicurezza continua a indagare su questa vulnerabilità e sul suo impatto, è possibile che le strategie di mitigazione esistenti vengano modificate o ritirate. È quindi meglio controllare costantemente la pagina di sicurezza del progetto Log4j e gli avvisi di organizzazioni come CISA per eventuali aggiornamenti.