The Log4j zero day vulnerability (CVE-2021-44228) is a remote code execution (RCE) vulnerability that allows malicious actors to take complete control of vulnerable devices and execute arbitrary code.
The Log4j 0-day vulnerability has to date, been detected in more than 3 million vulnerable instances. Researchers also found that nearly 68,000 vulnerabilities were present in cloud workloads and containers within the EMEA and the United States, underlining the need for organisations to monitor running containers for flaws like Log4j.
Apache Log4j Critical vulnerability
When a critical vulnerability in the Apache Log4j library became apparent, cybersecurity teams desperately tried to patch affected systems as quickly as possible. However, the flaw has the potential for a far more wide-reaching scope than previously thought.
According to some reports, malicious actors have leveraged Apache’s Log4j flaw to target more than 40% of corporate networks globally. Nearly a third of all web servers have been compromised worldwide since the vulnerability was discovered on December 10, 2021. Let’s take a closer look at the newly discovered Log4j zero day vulnerability and mitigation guidance.
The Log4j zero day vulnerability
The Log4j 0-day vulnerability, coded in Java, is OpenSource software created by Apache Software to run across Windows, macOS, and Linux. The software enables users to create a built-in record of activity to track data within their programs or to troubleshoot issues.
Alejandro Mayorkas, the United States Secretary of Homeland Security, tweeted that Log4j was “one of the most critical cyber vulnerabilities ever encountered” and urged organisations of “all sizes” to evaluate guidelines on the Apache Log4j zero day vulnerability.
Security experts note that nearly all modern digital infrastructures today adopt OpenSource software, and the average application now uses 528 different OpenSource components. Security teams are now facing a common issue where they are having difficulties countering the vulnerability discovered within OpenSource software.
What are hackers exploiting?
Log4j is used in most java applications. Therefore, the number of devices that could be affected is approximately 2.5 – 3 billion worldwide. A large number of attacks have also been detected that exploit the Log4j vulnerability involved in cryptocurrency mining.
Logj4 allows attackers to remotely run code and gain access to data on the affected machine. It also allows them to encrypt or delete files on the affected device and store them for ransomware demands.
How to counteract Logj4
Users are advised to update their Log4j to version 2.16.0 and above immediately. But there are other fixes suggested. Let’s take a closer look at the advice given:
- Update your organisation’s servers.
- Log4j 1.x mitigation: Log4j 1.x has not been impacted by this vulnerability.
- Log4j 2.x mitigation: Log4j 2.x has been impacted, and users should follow one of the following:
- Java 8 (or later) users must upgrade to release 2.16.0.
- Java 7 users should upgrade to release 2.12.2.
- Users can also try to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
- Only the log4j-core JAR file is impacted. Applications using the log4j-api JAR file without log4j-core JAR file have not been affected.
Firewall protection
A good mitigation technique is to use outgoing firewall rules on servers to prevent attacks. If the server is able to make DNS lookups when hackers scan for vulnerable instances of log4j, it will trigger the DNS lookup. Although malicious actors are easily able to bypass firewalls, they can block the outgoing connections of an attack and provide a certain level of security.
Attack and hotfix your servers
Using exploit code to attack running servers to fix a vulnerability should only be used as a last resort when nothing else helps. It is only required at the point where other mitigations cannot be applied. There are two OpenSource projects to hotfix the servers:
- Log4jHotPatch
Log4jHotPatch injects a Java agent into a running JVM process. The agent will attempt to patch the lookup method of all loaded org.apache.logging.log4j.core.lookup.JndiLookup instances to unconditionally return the string “Patched JndiLookup::lookup()”. It will address the CVE-2021-44228 remote code execution vulnerability in Log4j without restarting the Java process. It will also address CVE-2021-45046.
2. Logout4Shell
Logout4Shell will fix the vulnerability by using the bug against itself. As stated above, this should only be used as a very last resort if all other mitigation techniques fail.
Finally, organisations should always keep in mind that if they are using any Log4j component, then it may have been affected by the Log4j 0-day vulnerability. However, always work on the premise that it has been affected and patch accordingly.
Get in touch with RiskXchange to learn more about Log4j zero day vulnerability and how to protect yourself.