Understanding log4j2 vulnerability (CVE-2021-44228)

On Dec 09, 2021, the cyber world has witnessed a new critical vulnerability in the popular Java-based logging package Log4j. This critical vulnerability enables attackers to implement code on a remote server, a so-called Remote Code Execution (RCE). The exposure is named log4Shell and published as CVE-2021-44228 with a CVSS v3 at the highest risk score of 10. This provides attackers with the opportunity to execute unfamiliar commands on the remote server.

With the frequent use of Java and Log4j, this latest addition in the cyber vulnerabilities is likely to be the most severe s on the Internet since both Heartbleed and ShellShock. This blog post aims to provide viewers with the required workaround to understand the log4j2 vulnerability (CVE-2021-44228).

What is Log4Shell?

Log4Shell can be said as a most severe vulnerability (CVE-2021-44228, CVSSv3 10.0) affecting various versions of the Apache Log4j 2 utility. On Dec 09, 2021, this was discovered by Chen Zhaojun of Alibaba Cloud Security Team, which impacts Apache Log4j 2 versions 2.0 to 2.14.1. This critical vulnerability is being exploited wildly, and hackers aggressively scan cyberspace for defenseless assets.

This vulnerability is getting used in a lot of cloud services, tools, enterprise applications, and different frameworks like Apache Druid, Apache Struts 2, Apache Flink. It uses additional search plugins to get access to various information. Without sufficient security measures and companies depending on simple antiviruses, one cannot mitigate such severe vulnerabilities. Businesses need to have some cyber security consultation and advisory services on their panel to get expert hands on the work.

Impact of Log4Shell:

The Log4j 2 library is very commonly used in enterprise Java software. Because of this deployment method, this is very hard to quantify the impact quantify. Just like other high-profile exposures such as Shellshock and Heartbleed, it is believed there will be a growing amount of vulnerable products exposed in the weeks to come. What’s more insidious is that software that uses Java but doesn’t need the Internet can also be susceptible as data gets passed from system to system.

How to mitigate the Log4Shell vulnerability?

  • The vulnerability was triggered because the message lookup substitution was allowed, permitting the hacker to take control of the log message or log parameters. The best way to mitigate the vulnerability is by upgrading to the log4j v2.15.0, which disables the lookup behavior. CVE-2021-4428 impacts the log4j version 2.0-beta9 and <= 2.14.1 and is patched in the latest update.
  • If the upgrade is not possible, try setting up the system property of Java parameter log4j.formatMsgNoLookups to true rather than false. Likewise, the remediation can be done by eliminating the JndiLookup class from the classpath. This can be attained by running a command like;

               zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

  • For business people who don’t know how much of their custom-developed applications are vulnerable, they need a cybersecurity company in Pakistan to help them identify whether log4j2-core libraries are used or not.
  • If you are not sure which servers and other 3P apps are using Log4j, try logging in to your server and using a search query like find / -name “*log4j*2*” to pinpoint if a vulnerable version of log4j is in use.
  • Configure your WAF rules to block the JNDI calls. Refer to your WAF documents or contact your vendor for more details. This establishes in-depth defense, don’t just depend on WAF.
  • Using Graylog or Splunk, set up alerts on JNDI calls and instantly block the offending IP addresses.

Leave a Reply

Your email address will not be published. Required fields are marked *