Log4j Vulnerability Assessment

 

 

 

 

 

 

 

 

 

 

 

 

Cyber researchers and specialists all around the globe have been alerted to a zero-day vulnerability in the Java logging library Log4j. It directly impacts some of the world’s most important services, like Amazon, Twitter, and Apple iCloud.

Log4j is a Java package found in the Java logging systems. It is expected that it was utilized to obtain data since it was vulnerable to unethical access by bad actors and hackers. Because of the flaw, various online systems based on Java are vulnerable to zero-day assaults. It will enable remote code execution (RCE) and malware propagation through susceptible servers if malicious actors exploit it. Because the virus affects businesses and services with millions of clients (and their data), it puts a plethora of servers and devices in danger.

What makes Log4j (CVE-2021-44228) so dangerous?

The discovery of major vulnerability CVE-2021-44228 in the Apache Log4j library was published by a number of information security news publications (CVSS severity level 10 out of 10). This library is used by millions of Java programs to log error messages. To make things worse, attackers are already exploiting this issue. As a result, the Apache Foundation advises that all developers upgrade to version 2.15.0 of the library.

CVE-2021-44228 is a Remote Code Execution (RCE) vulnerability, commonly known as Log4Shell or LogJam. Attackers who successfully exploit it on one of the servers will be able to execute arbitrary code and potentially gain complete control of the system.

The simplicity with which CVE-2021-44228 may be exploited makes it exceptionally dangerous: even amateur hackers can effectively conduct an attack utilizing this vulnerability. According to the researchers, all an attacker needs to do is force the software to submit one string to the log before utilizing the message lookup replacement method to upload their own code into the application.

The vulnerability in Apache Logging Services was found by Chen Zhaojun of the Alibaba Cloud Security Team. The Apache team rated the vulnerability a 10 on the Common Vulnerability Scoring System (CVSS). This indicates that the Log4Shell vulnerability has been evaluated as “Critical.”

What is the IMPACT of the Log4j vulnerability?

The issue affects Log4j 2 versions, which are a popular logging library used by applications all across the world. Logging allows developers to view all of an application’s activities. This open-source library is used by Apple, Microsoft, and Google, as well as corporate applications from CISCO, Netapp, CloudFare, Amazon, and others.

According to Check Point, the open-source Apache Log4j library has been downloaded over 400,000 times from its GitHub repository. What’s more troubling about the security issue is that it has been discovered to be actively exploited in the field, thus the zero-day classification. A zero-day exploit indicates that hackers are actively pursuing the vulnerability while a fix has not yet reached all at-risk computers.

The security vulnerability with Log4j has been designated as CVE-2021-44228, Log4Shell, or LogJam. It is now considered one of the most serious security threats on the internet, as it affects all versions of Log4j. This contains Log4j versions 2.0-beta-9 to 2.14.1. Because Log4j is used by so many systems, this simply leaves a large number of services vulnerable.

The flaw is serious because it might be used to gain control of Java-based web servers and conduct “remote code execution” (RCE) attacks. In other words, the vulnerability might allow a hacker to take control of a machine. According to cybersecurity company LunaSec, what makes the situation so significant is that this library is “ubiquitous” across apps, and the attack provides complete server control and is simple to execute. This vulnerability is rated as serious. According to LunaSec, it is likely to affect services such as Apple’s iCloud and the online gaming provider Steam. In fact, as several users have said on Twitter, merely changing the name of an iPhone in the Settings app to a Java string code allows them to see the program logs.

The Cyber Emergency Response Team (CERT) of New Zealand published a statement warning that the vulnerability may give an attacker complete control of the compromised server and that it is “being abused in the wild.”

What have the impacted IT companies said?

Minecraft, which is owned by Microsoft, was among the first to recognize the problem and published a statement stating that the Java edition of the game was at high risk of being hacked. According to the company’s statement, the issue has been “handled with all versions of the game client patched,” but players will still need to take further precautions to safeguard the game and their own servers.

Google said in a statement that it is “currently analyzing the possible implications of the vulnerability for Google Cloud products and services.” This is a continuing issue, and we will continue to offer updates through our consumer contact channels.” “Successful exploitation of this vulnerability might result in the leakage of sensitive information, addition or change of data, or Denial of Service (DoS),” according to NetApp, which offers data management solutions for the Cloud.

Cisco has stated that several of its products, including the popular Cisco WebEx Meeting server, are vulnerable and that it is investigating if other devices are as well. Cloudflare, a web infrastructure company, has also published a statement recommending customers to update their Log4j versions and install the most up-to-date software patches. VMware issued a statement stating that they, too, have seen exploitation attempts and that the issue impacts many of their core products.

Log4j Mitigation

On December 9, 2021, a zero-day attack (CVE-2021-44228) impacting the popular Apache Log4j application was made public, leading to remote code execution (RCE). This vulnerability is being exploited, and all Log4j users should upgrade to version 2.15.0 as soon as possible. The most current version may already be downloaded from the Log4j download page. Log4j 2.16.0 needs to be upgraded (2.15.0 is vulnerable to exploitation in non-default setups that employ the ThreadContext class with user-supplied input)

For those who are unable to upgrade to version 2.15.0, Updating the system property log4j2.formatMsgNoLookups or the environment option LOG4J FORMAT MSG NO LOOKUPS to true in versions greater than 2.10 will avoid this issue. In the versions 2.0-beta9 to 2.10.0, the JndiLookup class should be deleted from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

If patching is not an option, businesses should adopt the following interim mitigations and constantly monitor affected applications for abnormal behavior. To prevent the problem, rather than upgrading Log4j2, put the following option to true when starting the Java Virtual Machine: log4j2.formatMsgNoLookups;

The presence of JAR files from the log4j library might suggest that a program is susceptible to CVE-2021-44228. The files to be found should follow the following pattern: log4j-core-*.jar;

The location of the matching JAR file may also show which software is possibly susceptible, depending on the installation procedure. If the file is stored at C:ProgramFiles/Application/Namelog4j-core-version.jar on Windows, for example, it suggests that the Application Name should be investigated. The lsof application on Linux may be used to see which processes are presently consuming the JAR file, and it can be used using the following syntax: lsof/path/to/log4j-core-version.jar

Detection guidance in the form of regular expression signatures seems to be too broad in the public domain at the time, and workarounds have also evolved to circumvent it.

Our Log4j Assessment Service

Our VAPT service checks for all vulnerabilities including the Log4j vulnerability. We also provide Log4j Assessment service that involves the following steps:

1. We reach out to customers if they want to check for log4j vulnerability within their environment
2. The next step is to ask for the IPs/URLs on which they want to check. Based on the number we will calculate the effort
3. Next step is to perform the check on the provided scope
4. If we find the vulnerability then a small report will be shared and if not we will share it via email that there is no log4j vulnerability within the provided scope