
Log4J CVE-2021-44228 : Cheat Sheet per la mitigazione
Aggiornamento - 28-dic-2021
CVE-2021-44832: Apache Log4j2 vulnerabile a RCE tramite JDBC Appender quando un attaccante controlla la configurazione.
Corretto in Log4j 2.17.1 (Java 8), 2.12.4 (Java 7) e 2.3.2 (Java 6)
Aggiornamento - 17-dic-2021
Durante la notte, è stato divulgato da Apache che anche la versione 2.16 di Log4j è vulnerabile a un attacco Denial of Service con impatto di crash completo dell'applicazione; la gravità è classificata come Alta (7.5). È stato emesso CVE-2021-45105 e una nuova versione corretta (2.17) è stata pubblicata da Apache, con consiglio di aggiornamento.
Contesto:
La discussione su Internet era in fermento per una vulnerabilità zero-day (in grado di produrre esecuzione remota di codice) nella popolare libreria di logging Log4J di Apache per Java. Questa particolare vulnerabilità, tracciata come CVE-2021-44228 con il punteggio CVSS massimo di 10 “critico”, risiede nella funzionalità di lookup di Log4J, combinata con JNDI (Java Naming and Directory Interface). Il problema è diffuso perché molti sviluppatori non erano consapevoli che Log4J fosse pericoloso da usare con input non filtrati.
L'impatto più significativo è che un attaccante può fare in modo che una stringa raggiunga il logger e che, quando viene elaborata da Log4J, esegua codice arbitrario. I primi esempi di questo attacco utilizzavano il percorso ${jndi:ldap}, che poteva portare al caricamento di codice arbitrario da un URL remoto. Questo percorso è parzialmente mitigato dall'uso di runtime Java più recenti che bloccano per impostazione predefinita il class loader basato su URL. Purtroppo, una versione moderna di Java potrebbe non essere sufficiente per prevenire lo sfruttamento, poiché l'applicazione stessa può esporre classi che possono essere utilizzate per eseguire codice arbitrario.
L'architettura JNDI:

Mitigazioni per diversi ambienti:
Aggiornamento - 17-dic-2021
Vulnerabilità di sicurezza CVE-2021-45105
Dettagli:
Le versioni 2.0-alpha1 fino a 2.16.0 di Apache Log4j2 non proteggevano dalla ricorsione incontrollata dovuta ai lookup auto-referenziali. Quando la configurazione di logging utilizza un Pattern Layout non predefinito
con un Context Lookup (ad esempio, $${ctx:loginId}), gli attaccanti con controllo sui dati di input della Thread Context Map (MDC) possono creare dati di input dannosi che contengono
un lookup ricorsivo, causando uno StackOverflowError che terminerà il processo. Questo è noto anche come attacco DOS (Denial of Service).
Mitigazione:
Dalla versione 2.17.0 (per Java 8), solo le stringhe di lookup nella configurazione vengono espanse in modo ricorsivo; in qualsiasi altro
utilizzo, viene risolto solo il lookup di primo livello e i lookup annidati non vengono risolti.
Nelle versioni precedenti, questo problema può essere mitigato assicurando che la configurazione di logging faccia quanto segue:
In PatternLayout nella configurazione di logging, sostituire i Context Lookup come ${ctx:loginId} o $${ctx:loginId} con i pattern della Thread Context Map (%X, %mdc, o %MDC).
In alternativa, nella configurazione, rimuovere i riferimenti a Context Lookup come ${ctx:loginId} o $${ctx:loginId} quando provengono da sorgenti esterne all'applicazione, come header HTTP o input utente.
Aggiornamento - 13-dic-2021
** Log4j(Release 2.16.0 – 2021-12-13) ha due funzionalità migliorate:**
---------------!!Altamente consigliato aggiornare alla versione più recente disponibile poiché i message lookup sono disabilitati per impostazione predefinita.!!------------
https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0
Disabilita JNDI per impostazione predefinita. Richiede che log4j2.enableJndi sia impostato su true per consentire JNDI.
Rimuovere completamente il supporto per i Message Lookup
Nuovo aggiornamento:
------------------CVE-2021-45046-----------------
Apache Log4j2 Thread Context Message Pattern e Context Lookup Pattern vulnerabili a un attacco denial of service.
Mitigazione:
Log4j 1.x non è colpito da questa vulnerabilità.
Log4j 2.x: implementare una delle tecniche di mitigazione indicate di seguito.
Gli utenti di Java 8 (o successivo) dovrebbero aggiornare alla release 2.16.0.
Gli utenti che necessitano di Java 7 dovrebbero aggiornare alla release 2.12.2 quando sarà disponibile (lavori in corso, prevista a breve).
In alternativa, rimuovere la classe JndiLookup dal classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Nota: solo il file JAR log4j-core è colpito da questa vulnerabilità. Le applicazioni che utilizzano solo il file JAR log4j-api senza il file JAR log4j-core non sono colpite da questa vulnerabilità.
------------------CVE-2021-44228-------------------
Mitigazione
Log4j 1.x non dispone di Lookup, quindi il rischio è più basso. Le applicazioni che utilizzano Log4j 1.x sono vulnerabili a questo attacco solo quando usano JNDI nella
configurazione. Un CVE separato (CVE-2021-4104) è stato registrato per questa vulnerabilità. Per mitigare: controlla la configurazione di logging per assicurarti che non ci sia JMSAppender configurato.
Le configurazioni Log4j 1.x senza JMSAppender non sono colpite da questa vulnerabilità.
Log4j 2.x: implementare una delle tecniche di mitigazione indicate di seguito.
Gli utenti di Java 8 (o successivo) dovrebbero aggiornare alla release 2.16.0.
Gli utenti che necessitano di Java 7 dovrebbero aggiornare alla release 2.12.2 quando sarà disponibile (lavori in corso, prevista a breve).
In alternativa, rimuovere la classe JndiLookup dal classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Nota: solo il file JAR log4j-core è colpito da questa vulnerabilità. Le applicazioni che utilizzano solo il file JAR log4j-api senza il file JAR log4j-core non sono colpite da questa vulnerabilità.
1. Apache Log4j:
Nelle release >=2.10** e
Per le release >=2.0-beta9 e <=2.10.0
2. Correzione pom.xml:
3. Azure App Service (Windows e Linux):
4. Applicazioni containerizzate:
5. Azure Functions:
6. Hotpatch per Apache Log4j
7. Come Defender for Cloud trova le macchine colpite dalle vulnerabilità Log4j
8. Rilevamento sui log di Azure Sentinel e Azure WAF
9. Configurazione del plug-in Maven per vietare le versioni vulnerabili di log4j2 nelle build future
1. Apache Log4j:
CVE-2021-44228: le funzionalità JNDI di Apache Log4j2 non proteggono dagli endpoint LDAP controllati dall'attaccante e altri endpoint correlati a JNDI.
Versioni interessate: tutte le versioni log4j-core >=2.0-beta9 e <=2.14.1.