Log4Shell unauthenticated RCE via JNDI lookups in Apache log4j

Log4Shell is the name given to CVE-2021-44228, disclosed in December 2021 against Apache log4j, the logging library used across an enormous share of the Java ecosystem. log4j-core versions 2.0-beta9 through 2.14.1 resolve "lookup" syntax such as `${jndi:ldap://host/path}` found inside the text of a logged message, by default, with no special configuration required. If any attacker-controlled string (a header, a username, a User-Agent, a form field - anything that ends up in a log statement) reaches a logger call, the attacker can smuggle a JNDI lookup into it and have the JVM reach out to an attacker-controlled directory server, which can in turn hand back a reference that gets deserialized or remotely class-loaded, resulting in unauthenticated remote code execution.

This lab installs log4j-core/log4j-api 2.14.1 - the last build before the fix - behind a small custom HTTP service (`VulnServer.java`) that logs the `X-Api-Version` request header verbatim, standing in for the many real-world products that were found doing exactly this kind of unsanitised logging in December 2021. A flag is dropped at the filesystem root; winning the lab means getting a shell and reading it.

Remote code execution bugs are the ones defenders care about most. This target is useful for testing detection rules and logging.

Product

Apache log4j

Version

2.14.1

Type

RCE

Severity

High

This playbook needs the setup from the earlier steps. Check these first.

• The base VM from Step 01 is built and reachable over SSH.
• You cloned the playbooks repo and set inventory/hosts.ini in Step 02.
• A snapshot named clean-base exists, and the machine is booted from it.

One CVE at a time. Don't run this on top of another playbook. Reset first.

Boot the machine from clean-base, then run the playbook for CVE-2021-44228. It installs log4j 2.14.1, sets up its config and starts the service.

ansible-playbook cve/cve-2021-44228.yml 

A clean run ends with a recap that shows failed=0. If it fails partway, run it again.

The verify tag checks that the service is listening and running the version this CVE affects. Run it from the host.

ansible-playbook cve/cve-2021-44228.yml  --tags verify

You should see target OK.

Java apps use classes to define what a program can do. In Log4J, the "JNDIlookup" class governs JNDI lookups. If this class is removed from Log4J's directory of classes a.k.a., the classpath then JNDI lookups can no longer be performed.

Disallowing JNDI lookups prevents hackers from sending malicious commands, but it can also affect other functions of Log4J and the apps that use it. It can also be difficult to ensure every instance of the class is removed.

Security researchers strongly recommend that organizations prioritize updating all instances of Log4J in their networks to the latest version, or at least version 2.17.1. Patching is the only way to remediate Log4Shell completely.

Restore clean-base. Nothing from this playbook carries over.

VBoxManage controlvm thehackingmachine acpipowerbutton
VBoxManage snapshot thehackingmachine restore clean-base
VBoxManage startvm thehackingmachine

• https://nvd.nist.gov/vuln/detail/CVE-2021-44228
• https://logging.apache.org/log4j/2.x/security.html
• https://www.ibm.com/think/topics/log4shell
• https://www.cisa.gov/news-events/news/apache-log4j-vulnerability-guidance

Playbook and write-up by TheHackingMachine Team.

Want to add your own? See how to contribute.