thedevappsecguy/log4j-mitigation-cve-2021-44228--cve-2021-45046--cve-2021-45105--cve-2021-44832Log4J 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.
Le funzionalità JNDI di Apache Log4j <=2.14.1 usate nella configurazione, nei messaggi di log e nei parametri non proteggono dagli endpoint LDAP controllati dall'attaccante e altri endpoint correlati a JNDI. Un attaccante che può controllare i messaggi di log o i parametri dei messaggi di log può eseguire codice arbitrario caricato da server LDAP quando la sostituzione dei message lookup è abilitata. A partire da log4j 2.15.0, questo comportamento è stato disabilitato per impostazione predefinita.
Nelle release >=2.10**, questo comportamento può essere mitigato impostando la proprietà di sistema log4j2.formatMsgNoLookups oppure la environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. Per le release >=2.7 e <=2.14.1, tutti i pattern PatternLayout possono essere modificati per specificare il convertitore di messaggi come %m{nolookups} invece del semplice %m.
Per le release >=2.0-beta9 e <=2.10.0, la mitigazione consiste nel rimuovere la classe JndiLookup dal classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
2. Correzione di pom.xml:
Aggiorna la dipendenza in pom.xml e sostituiscila con la versione più recente disponibile nella sezione dependencies: https://search.maven.org/artifact/org.apache.logging.log4j/log4j/2.15.0/pom
<dependencies>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.14.1</version>
<!-- Swap with the below to prove it's fixed -->
<!-- <version>2.17.0</version>-->
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.14.1</version>
<!-- Swap with the below to prove it's fixed -->
<!-- <version>2.17.0</version>-->
</dependency>
</dependencies>
Riferimento: https://github.com/justincormack/log4jpoc/blob/main/pom.xml#L18
3. Azure App Service (Windows e Linux):
Se possibile, i clienti dovrebbero aggiornare Log4j alla versione v2.15.0 e ridistribuire le applicazioni. Questa è la mitigazione primaria consigliata. Se non si è in grado di ridistribuire l'applicazione, nelle versioni di Log4j 2.10 e successive si può mitigare questo comportamento impostando la proprietà di sistema “-Dlog4j2.formatMsgNoLookups=true”. Su App Service, è possibile impostare questa proprietà creando un'app setting chiamata JAVA_OPTS con un valore di “-Dlog4j2.formatMsgNoLookups=true”. L'app setting JAVA_OPTS viene passata all'applicazione Java all'avvio. Se l'app setting JAVA_OPTS è già impostata, basta aggiungere “-Dlog4j2.formatMsgNoLookups=true” al valore esistente. Se si utilizza Log4J versione 2.9 o inferiore, questa mitigazione tramite proprietà di sistema non funzionerà e si dovrebbe aggiornare a v2.15.0.
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings <setting-name>="<value>"
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings JAVA_OPTS="-Dlog4j2.formatMsgNoLookups=true"
4. Applicazioni containerizzate
Per le applicazioni containerizzate, se la versione di Log4j 2 in uso è 2.10.0 o successiva, esiste una variabile d'ambiente o un'opzione da riga di comando Java che puoi usare per disabilitare il comportamento di sostituzione non sicuro. Puoi aggiungere la riga:
ENV LOG4J_FORMAT_MSG_NO_LOOKUPS=true
Riferimento al Dockerfile: https://github.com/lhotari/Log4Shell-mitigation-Dockerfile-overlay/blob/master/Dockerfile
Al tuo Dockerfile, oppure puoi aggiungere il flag equivalente "-Dlog4j.formatMsgNoLookups=true" al comando che esegui nel tuo container, ad esempio:
CMD ["java", "-Dlog4j.formatMsgNoLookups=true", "-jar", "..."]
Puoi anche configurare la variabile d'ambiente a runtime, il che può essere più semplice; ad esempio per Kubernetes potresti aggiungere queste righe alla tua configurazione.
spec:
containers:
- name: ...
image: ...
env:
- name: LOG4J_FORMAT_MSG_NO_LOOKUPS
value: "true"
5. Azure Functions:
La configurazione della proprietà di sistema dipenderà dalla tua scelta di opzione di hosting: dedicato, premium o consumption. Come promemoria, la mitigazione primaria consigliata è aggiornare Log4J a 2.15.0 e ridistribuire l'applicazione. Se per qualsiasi motivo non puoi farlo, puoi applicare la proprietà di sistema.
- Funzioni Dedicated e Premium:
Crea un'app setting chiamata JAVA_OPTS con un valore di “-Dlog4j2.formatMsgNoLookups=true”. Se hai già impostato l'app setting JAVA_OPTS, aggiungi semplicemente “-Dlog4j2.formatMsgNoLookups=true” al valore esistente.
- Funzioni Consumption:
Linux: crea un'app setting chiamata “languageWorkers__java__arguments” con un valore di “-Dlog4j2.formatMsgNoLookups=true”. Windows: crea un'app setting chiamata “languageWorkers:java:arguments” con un valore di “-Dlog4j2.formatMsgNoLookups=true”. **Nota: l'aggiornamento dell'app setting riavvierà le app Web e Function, il che potrebbe influire sulle prestazioni di cold start. Se stai utilizzando Log4J versione 2.9 o inferiore, questa mitigazione tramite proprietà di sistema non funzionerà e dovresti aggiornare a v2.15.0.
6. Hotpatch per Apache Log4j
Come funziona? Questo strumento inietta un agente Java in un processo JVM in esecuzione. L'agente tenta di correggere il metodo lookup() di tutte le istanze caricate di org.apache.logging.log4j.core.lookup.JndiLookup per restituire incondizionatamente la stringa “Patched JndiLookup::lookup()”. Questo è progettato per affrontare la vulnerabilità di esecuzione remota del codice CVE-2021-44228 in Log4j senza riavviare il processo Java.
Se hai la possibilità di ridistribuire i tuoi processi Java, puoi anche usarlo come agente statico, il che significa che puoi includere questa patch nel tuo runtime senza doverti autenticare direttamente sui tuoi server.
Github : https://github.com/corretto/hotpatch-for-apache-log4j2
7. Come Defender for Cloud trova le macchine colpite dalle vulnerabilità Log4j
Usando l'inventario, hai due potenti modi per determinare la tua esposizione:
Inventario software
Risultati della valutazione delle vulnerabilità
8. Rilevamento sui log di Azure Sentinel e WAF:
Ricerca di Log4j CVE-2021-44228 su Azure WAF
Corrispondenza Azure WAF per la vulnerabilità Log4j (CVE-2021-44228)
9. Configurazione del plug-in Maven per vietare le versioni vulnerabili di log4j2 nelle build future:
Configurazione del plug-in Maven da inserire nel tuo POM padre per evitare qualsiasi utilizzo di versioni log4j2 obsolete, alcune delle quali soggette all'RCE CVE-2021-44228
(“Log4Shell”), CVE-2021-45046 e CVE-2021-45105).
Riferimento: https://gist.github.com/gunnarmorling/8026d004776313ebfc65674202134e6d
<!-- plug-in configuration to put into your parent POM for avoiding any usages of
outdated log4j2 versions, some of which are subject to the RCE CVE-2021-44228
("Log4Shell"), CVE-2021-45046, and CVE-2021-45105. Make sure to check for the
latest version of log4j2 at
https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core -->
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<id>ban-bad-log4j-versions</id>
<phase>validate</phase>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<bannedDependencies>
<excludes>
<exclude>org.apache.logging.log4j:log4j-core:(,2.17.0)</exclude>
</excludes>
</bannedDependencies>
</rules>
<fail>true</fail>
</configuration>
</execution>
</executions>
</plugin>
...
Contributi:
Siamo lieti di ricevere contributi dalla community. Linee guida per i contributi:
-->Per favore, fai una PR.
-->Assicurati di includere una fonte di riferimento per avere più contesto
Potrebbero esserci diversi ambienti e altri modi per risolvere , sentiti libero di aprire una pull request :
Riferimenti:
https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/
https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/
https://github.com/justincormack/log4jpoc
https://www.rumble.run/blog/finding-log4j/
https://www.veracode.com/blog/research/exploiting-jndi-injections-java
https://github.com/lhotari/Log4Shell-mitigation-Dockerfile-overlay
https://docs.oracle.com/javase/jndi/tutorial/getStarted/overview/index.html
https://logging.apache.org/log4j/2.x/security.html
https://aws.amazon.com/blogs/opensource/hotpatch-for-apache-log4j/