# This is an example of exploiting [CVE-2021-44228](
## A [Log4J2]( RCE vulnerability


## I'm not responsible for this code. PLEASE **do not use maliciously**

This vulnerability allows you to execute arbitrary code by logging a malicious message on the target machine.  
For example, you can use it in **[Minecraft](** by sending a chat message, and the server/player machine will log the chat message and execute your code.   
[LiveOverflow/CVE-2021-44228 video](   

The message has to contain a placeholder `${}` with instruction to load a remote object
`jndi` API. It will load the object through an `ObjectFactory`  

- __LDAP__ `ldap://x.x.x.x:port/...`
- __HTTP__ `http://x.x.x.x/...`
- __DNS__ `dns://x.x.x/...`
- etc...  


If the ObjectFactory is not present in the client, it won't do anything.   
Except for resolving the server.  
With that, you can leak environment variables:  


### What is this hype about this RCE?
[why so overhyped?](  
*If my understanding is correct it provides an interface to JNDI*

What can be exploited

JNDI JDAP is an object lookup API.  
You can get a Java object from a server.  
It sends Object data, and the `ObjectFactory` name, which should build the object on the client.  
It can be exploited multiple ways.  
If LDAP is enabled to trust external code, we only need to give the URL to a malicious ObjectFactory.  
`com.sun.jndi.ldap.object.trustURLCodebase = true`  
Or there is another Java vulnerability. JDK-8196902  
Combined with that, it will really became an RCE.  
Multiple POC repos do this on GitHub. For example [tangxiaofeng7/CVE-2021-44228-Apache-Log4j-Rce](  

If this is set to false (by default it is set to false), we can look for an exploitable `ObjectFactory` in the target codebase,  
Or exploit JNDI in a different way.  

Further reading about JNDI Injection:  
[JNDI injection](  
[Veracode Research/rogue-jndi](

## In the example:
`RCEExample` is a function what log the malicious message.  
Just press run to run it...  

`LoggerFactory` is an `ObjectFactory` what will log, whatever it gets...  
If you build [marshalsec](, you can ask it to use `LoggerFactory`

1. `java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer ""`
2. Run `rce.RCEExample` and see the exploit (the logger).
3. You can debug this project and place a breakpoint in `LoggerFactory`, see the objects.

## Secure your program
Your program is not affected **IF** it does **only** log built-in messages.  
If the program can log text from any data file, or from the network, **it is vulnerable**.      
But you should fix it anyway...  

The best, you can do, update to [Log4J2 2.15.0+](  
If it is not possible for some reason, disable **JNDI** lookup by the following **Java** argument: `โ€Dlog4j2.formatMsgNoLookups=True` to mitigate the vulnerability.  

If you're a **Minecraft** server administrator, follow the official guide: [**IMPORTANT MESSAGE: SECURITY VULNERABILITY IN JAVA EDITION**](