For weeks leading to early December 2021, Log4Shell has been the only news in my Twitter feed. I haven’t got much experience with the Java ecosystem lately and have only used Log4j on my projects back in college. Although people are quick to point out the massive attack surface that this vulnerability is exposed to.

John Hammond released a video on YouTube demonstrating the exploit on a Minecraft server. This picqued my interest. It’s a game that my younger cousins play. Their servers may be vulnerable. And that is just one example.

What is Log4Shell and Log4j

The Apache Log4j is a Java logging package. It is used by many applications and dependenices by software providers.

CVE-2021-44228 dubbed Log4Shell is described by the National Vulnerability Database as follows,

Apache Log4j2 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0, this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.

It’s severity score? 10.0! 🤯

To know more about Log4Shell and Log4j, I highly recommend Solar, exploiting log4j authored by John Hammond himself.

Demonstration

The setup is as follows:

1. The target machine running Apache Solr 8.11.0
2. LDAP Referral Server (marshalsec) - bottom right terminal
3. A netcat listener - top left terminal
4. Secondary server hosting the JNDI reference - bottom left
5. Client to invoke the request with the parameter as entry point

As the room pointed out, this is just one of the many possible techniques.

Conclusion

I would like to echo John Hammonds note on this vulnerability,

“Please use the information you learn in this room to better the security landscape. Test systems you own, apply patches and mitigations where appropriate, and help the whole industry recover. This is a very current and real-world threat – whether you are a penetration tester, red teamer, incident responder, security analyst, blue team member, or what have you – this exercise is to help you and the world understand and gain awareness on this widespread vulnerability. It should not be used for exploitative gain or self-serving financial incentive (I’m looking at you, beg bounty hunters)

Additionally, please bear in mind that the developers of the log4j package work on the open source project as a labor of love and passion. They are volunteer developers that maintain their project in their spare time. There should be absolutely no bashing, shame, or malice towards those individuals. As with all things, please further your knowledge so you can be a pedestal and pillar for the information security community. Educate, share, and help.”

Mitigation

For the Solar target, the system-wide configuration may be changed to disable logging message formatting until such time that patching will be a viable solution.

# /etc/default/solr.in.sh
... 
SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true"

The patch that fixes this vulnerability is available starting from the 2.16.0 release.

For detection, I am personally following the progress of the log4shell-detector project — credits to the contributors.

I am treating this as a living document and will continuously update once I learn about this subject more.