Skip to content
KitploitKITPLOIT
StrumentiExploitsBlog
Log in
Invia
StrumentiExploitsBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
Log4J-Mitigation-CVE-2021-44228--CVE-2021-45046--CVE-2021-45105--CVE-2021-44832 — Log4J CVE-2021-44228 : Cheat Sheet per la mitigazione | Kitploit
Strumenti/GitHubGitHub/thedevappsecguy/log4j-mitigation-cve-2021-44228--cve-2021-45046--cve-2021-45105--cve-2021-44832
Analisi delle VulnerabilitàSicurezza CloudDevSecOpsSicurezza della Supply ChainApprendimento e FormazioneRisorse Curate
GitHubthedevappsecguy/log4j-mitigation-cve-2021-44228--cve-2021-45046--cve-2021-45105--cve-2021-44832

Log4J-Mitigation-CVE-2021-44228--CVE-2021-45046--CVE-2021-45105--CVE-2021-44832

Log4J CVE-2021-44228 : Cheat Sheet per la mitigazione

Vedi Repository
22524 anni faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

Mitigazione-Log4J-CVE-2021-44228,CVE-2021-45046,CVE-2021-45105,CVE-2021-44832

Tieni d'occhio questa pagina poiché il team di Apache Log4j sta divulgando molti altri CVE e correggendo problemi di sicurezza molto rapidamente.

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:

jndiarch

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.

Scarica lo strumento