Questa settimana parleremo dell'evoluzione delle vulnerabilità di Log4j2 e di alcune utili misure di mitigazione che potete utilizzare per proteggervi da esse.
L'evoluzione della vulnerabilità
Le vulnerabilità di "Log4Shell" sono iniziate con la scoperta di una vulnerabilità critica di esecuzione di codice remoto nel modo in cui Log4j2 gestiva i lookup durante la registrazione degli eventi sui sistemi interessati. Questa vulnerabilità critica(CVE-2021-44228) ha ottenuto un punteggio di 10 su 10 nel CVSS. Apache ha dichiarato che le versioni 1.x di Log4j avevano meno probabilità di essere vulnerabili a questa scoperta, poiché JNDI doveva essere deliberatamente abilitato. Apache ha rilasciato la versione 2.15.0 per risolvere questa vulnerabilità.
Dopo che Apache ha rilasciato metodi di mitigazione per gli utenti che non potevano aggiornare Log4j2 alla versione 2.15.0, è stata scoperta un'altra vulnerabilità grazie all'attenzione che questo progetto open source ha ricevuto dall'essere sotto gli occhi di tutti. Questa vulnerabilità(CVE-2021-45046) era inizialmente una vulnerabilità DOS con un punteggio di 3,7 su 10, ma in seguito è stata dichiarata anche una vulnerabilità critica per l'esecuzione di codice e il punteggio è salito a 9 su 10 su CVSS. Apache ha dichiarato che le versioni 1.x non erano vulnerabili e ha consigliato agli utenti di Log4j2 di aggiornare alla versione 2.16.0 per risolvere questo secondo problema. Il metodo di rimozione della classe JNDI Lookup è stato consigliato agli utenti che non possono effettuare l'aggiornamento.
Poi è arrivata la terza vulnerabilità. Sebbene (al 22 dicembre) non vi sia alcun riferimento all'esecuzione di codice remoto nella pagina di sicurezza della versione 2.16.0 di Log4j2, questa vulnerabilità(CVE-2021-45105) ha ottenuto un punteggio di 7,5 su 10 in CVSS e potrebbe causare un attacco di tipo denial of service solo sui sistemi vulnerabili. Apache ha rilasciato la versione 2.17.0 e ha raccomandato agli utenti di effettuare l'aggiornamento per risolvere il problema. Ha inoltre condiviso nuove misure di mitigazione per gli utenti che non possono effettuare l'aggiornamento.
È importante notare che queste vulnerabilità sono state sfruttate o hanno tentato di essere sfruttate durante le fasi di scoperta e mitigazione. Secondo il blog di 360 Netlab, diverse famiglie di malware hanno tentato di propagarsi utilizzando queste vulnerabilità. Gli attori maligni che hanno sfruttato con successo la vulnerabilità sono stati visti impiantare coin miner e installare ransomware. Queste segnalazioni sottolineano l'importanza di mitigare queste vulnerabilità il prima possibile.
Metodi di mitigazione ufficiali
Secondo la pagina di sicurezza di Log4j2, l'aggiornamento del componente alla versione 2.17 attenua i tre problemi di sicurezza noti. Per coloro che non possono aggiornare Log4j2, Apache raccomanda di rimuovere la classe JNDI Lookup dal file log4j2-core-*.jar vulnerabile. Tuttavia, questo non è sufficiente a mitigare la vulnerabilità Denial-of-Service scoperta di recente(CVE-2021-45105). È possibile mitigare questa vulnerabilità DOS modificando il PatternLayout nella configurazione del logging. È possibile leggere la pagina sulla sicurezza di Log4j2 di Apache, collegata all'inizio di questo paragrafo, per conoscere i dettagli di questi metodi di mitigazione.
Individuazione dei componenti vulnerabili
Se si sta eseguendo la scansione di componenti vulnerabili, è possibile utilizzare gli strumenti Log4j realizzati da jfrog. Gli strumenti in questo repository sono utili quando si cercano chiamate di Log4j JNDI Lookup vulnerabili in una base di codice in cui non si è sicuri che un pezzo di codice chiami Log4j per funzionare. Può anche aiutare a determinare lo stato di vulnerabilità dei file locali. È inoltre possibile consultare le regole di utilizzo e sfruttamento di Log4j di Cisco CX Security Labs per eseguire la scansione dei file locali con le regole YARA per determinare se un file contiene classi Java vulnerabili; sebbene questo metodo possa fornire risultati più rapidi, può dare luogo a un maggior numero di falsi positivi; tuttavia queste regole possono aiutare a individuare anche i componenti dipendenti da Log4j.
Il repository Log4Shell Hashes di mubix contiene gli hash MD5, SHA1 e SHA256 dei file log4j2-core vulnerabili alla vulnerabilità critica RCE iniziale(CVE-2021-44228). Infine, è possibile consultare il database del software vulnerabile del CISA (valido solo per CVE-2021-44228) per un elenco completo del software vulnerabile per fornitore.
Protezione dagli attacchi
Se non potete aggiornare la vostra installazione di Log4j2 e se state usando Fail2Ban sul vostro server, la regex Fail2Ban contro Log4Shell di Jay Gooby può aiutarvi a bloccare i tentativi di Log4Shell. Se si utilizza CloudFlare, è possibile utilizzare le sue regole WAF per proteggersi da questi attacchi. Tuttavia, secondo il consiglio del CISA, si consiglia di aggiornare immediatamente a Log4j 2.17.0 o di applicare le mitigazioni consigliate. È inoltre importante fare riferimento alle dichiarazioni del fornitore relative ad altri software che utilizzano Log4j2, poiché alcuni software potrebbero essere forniti in bundle con una versione vulnerabile di Log4j che potrebbe richiedere attenzione.
Ricerca di CIO e scansione
Se state cercando indicatori di compromissione nei vostri log, potrebbe essere difficile determinare se ci sono stati tentativi di sfruttare questa vulnerabilità, soprattutto perché ci sono molti payload diversi che possono essere inviati per sfruttare il noto vettore di attacco JNDI. Un aggressore può codificare le stringhe nel payload, offuscarle o renderle difficili da individuare quando si cercano payload semplici. È qui che Log4Shell-Rex di back2root può tornare utile. Log4Shell-Rex è un'espressione regolare creata per individuare eventuali payload dannosi codificati con metodi diversi. È possibile utilizzarla sui file di registro locali o nel SIEM per confrontare i risultati. Tuttavia, va notato che la ricerca con questa regex (o con qualsiasi altra regex) può generare falsi positivi o falsi negativi.
Potete anche controllare lo strumento Log4j-scan di FullHunt che può aiutare a scoprire e a fare fuzzing per la vulnerabilità RCE(CVE-2021-44228); potete anche usare questo strumento per testare i bypass del WAF per ottenere risultati di scansione più completi.
Ci auguriamo di poter aiutare i nostri clienti condividendo informazioni utili in questi aggiornamenti sulla sicurezza. Come sempre, sentitevi liberi di condividere i vostri pensieri lasciando un commento qui sotto.
Commenti