How to Tackle the Log4j Vulnerability?

Apache Log4j is an open-source logging package for Java distributed under the Apache Software License. Logging and tracing software, like Log4j, collects and stores activity records on a server.   

A simple example to see Log4j at work is a website’s 404 page. When a user clicks a broken or a bad URL and is directed to a 404-error page, the hosting server logs an event using Log4j with details administrators can use.  

Log4Shell was a zero-day vulnerability in Log4j that existed since 2013 but went unnoticed until 24 November 2021 when Chen Zhaojun of Alibaba Cloud’s security team privately disclosed it to the Apache Software Foundation. The vulnerability was disclosed to the public on the 9th of December 2021. It is said to have affected hundreds of millions of devices, and Financial Times reported that hackers had launched more than 1.2M attacks through this flaw. While multiple patches have been released, businesses that employ Log4j are advised to continue monitoring services and be vigilant of cyberattacks.  

The issue is a zero-day vulnerability, meaning attackers have a head start over those working towards fixing the issue.  

Log4j is a popular open-source software used by companies like Intuit, VMware Inc, and Zendesk Inc. Its widespread use is what makes Log4Shell a major threat. Apache has assigned Log4Shell a CVSS (Common Vulnerability Scoring System) severity rating of 10, the highest possible rating.  

In this article, we explain what the Log4Shell vulnerability is and how businesses that use Log4j can protect themselves against it.  

What is the Log4Shell Zero-Day Vulnerability? 

Log4Shell vulnerability exploits the requests made to LDAP and JNDI servers using Log4j libraries. Attackers can inject and execute rogue Java code on a server or extract data from the server.  

Logs generated in older versions of Log4j 1.x are encapsulated in string format and don’t get parsed, and these versions of the library are possibly not vulnerable to remote code execution.  

Versions 2.0–2.15.0 introduced the new JNDI lookup feature that allows any entered input to be parsed and interpreted by the processing application or server. The vulnerability was apparently introduced with this feature. Applications that run Java, like email servers, databases, IoT devices, etc., are all vulnerable to Log4Shell. 

Regardless of the version being used, run the checks listed in the next section to be certain that your products are not vulnerable.  

The two main exploits being made through this vulnerability are: 

1. Remote Code Execution (RCE), where malicious Java code is executed on the affected server remotely. 
2.  The extraction of sensitive data from affected servers.

Log4Shell allows attackers to pass a specific string run as a command on affected systems and workloads. The Log4j library that is supposed to log the entered string by simply writing it to the log interprets it as a command and executes it.  

For example, if a website’s login page is configured to log details using Log4j, an attacker can enter a line of code in the username field, and the server will execute it instead of just logging it as a string. Every single application and software that has used log4j is potentially vulnerable. 

How to Fix the Log4Shell Exploit? 

Tip 1: Discover potentially vulnerable devices and install the latest security patches immediately. 

1. The Department of Homeland Security (DHS) and the Cybersecurity and Infrastructure Security Agency (CISA) has created the following chart to help you determine if applications or servers with Log4j are vulnerable to Log4Shell. Find out if your products are vulnerable using the chart and the two verification methods:
   1. CISA’s GitHub repository 
   2. CERT/CC’s CVE-2021-44228_scanner

   Source: cisa.gov

2. Once you have identified the vulnerable products, you should go through Apache’s Log4j Security Vulnerabilities page to get more information and find if a workaround is available. If it is, apply it immediately. 
3. CISA advises all businesses to update products using Log4j to the latest version and apply the latest patches released by Apache. They recommend prioritizing mission-critical systems, internet-facing systems, and network servers followed by other affected IT assets.
4. Lastly, if you work with third-party vendors or end-users who may have vulnerable products, work with them, and ensure they execute the above steps to secure both their environment and yours.

Tip 2: Run vulnerability scans and monitor products.

CISA warns that applying the latest versions and patches does not resolve already compromised systems. While these patches aim to eliminate the vulnerability, they do not remove any malicious Java payloads that are already injected or terminate access that is already granted. If Log4Shell already infiltrated your organization, you will need to take additional measures.

1. The first step is monitoring applications, servers, and networks for abnormal behavior.
2. Conduct regular security reviews to identify a security breach. One way is to analyze log files of vulnerable products.
3. The CISA and the FBI also recommend reporting security breaches to them using these links: CISA, FBI. 
4. If you are using an older version and suspect it is compromised, execute the following lines of code:
   log4j2.formatMsgNoLookups=true
   You can also set an environment variable for all the affected versions:
   LOG4J_FORMAT_MSG_NO_LOOKUPS=true
   Lastly, the JndiLookup class can be removed altogether using the command line:
   zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class  to remove the class from the log4j-core.

Tip 3: Explore Real-Time Protection of Log4j with AppTrana – Through its Risk-Based Approach 

Conclusion 

Log4Shell is described as the largest vulnerability in the cyber world. LunaSec, an open-source data security platform told the vulnerability as “a design failure of catastrophic proportions,” and The Washington Post stated that descriptions by security professionals “border on the apocalyptic.”  

As end-users, vendors, or any business that has products using Log4j, your job is to stay vigilant, follow the mitigation steps advised by CISA, and hold the fort until Apache rolls out a fully fixed, stable version. 

Proactively protect yourself against all variants of Log4j vulnerabilities by implementing AppTrana, a risk-based web application firewall. 

Found this article interesting? Follow Indusface on Facebook, Twitter, and LinkedIn to read more exclusive content we post.