LambdaTest’s Response to Log4j Vulnerability [Updated 23.12.2021]

Log4j is a popular Java logging library that has been used for over 12 years, but it was recently discovered to have a security vulnerability that could allow a malicious actor to execute code remotely on the target system. According to MITRE: “The Log4j logging library allows components to be added remotely, making it easier to inject malicious components into an application or product that uses Log4j. This can be abused by attackers to compromise the application (or product) with backdoors.”

MITRE has marked the vulnerability as CVE-2021-44228, considering a critical flaw with the highest CVSS score (10.0). However, the Apache Foundation has issued a security advisory for two more vulnerabilities (CVE-2021-45046 and CVE-2021-45105) that could lead to DOS (Denial of Service) attacks if exploited.

Following the recent security update released by the Apache Software Foundation,  LambdaTest security and engineering teams immediately began investigating the issue and auditing all of the systems for any potential impact. At this time, we have determined that no LambdaTest customer data was exposed through this vulnerability. We have also determined that no customer data has been accessed (or modified) as a result of this vulnerability.

LambdaTest security researchers have detailed their findings on the Log4j vulnerability and provided ways to manage any risks better. 

Log4j 2 Vulnerability

Log4j 2 is the successor to Log4j and Logback. At the time of writing this article, Log4j 2.17.0 is the latest release of Log4j. It is an entirely new implementation that does not maintain any backward compatibility with Log4j 1.x or Logback. However, it fixes some issues in their architectural model and adds many new features, the most notable are mentioned below:

 Who uses these services?

Too many services are vulnerable to this exploit as Log4j 2 is a widely used Java-based logging utility. Additionally, cloud services like Stream, iCloud, and applications like Minecraft have already been found to be vulnerable.

 How dangerous is it?

Anybody using Apache framework services or any Spring-Boot Java-based framework applications using Log4j 2 is likely to be vulnerable.

Attackers who can control log messages or log message parameters can execute arbitrary code on the vulnerable server loaded from the LDAP server when message lookup substitution is enabled.

 As a result, attackers can craft special requests using which utility can be remotely downloaded and the payload is executed.

LambdaTest’s Response to Log4j: Mitigating Risk for Customers

LambdaTest actively follows security vulnerabilities in the open-source Apache “Log4j 2” utility (CVE-2021-44228). We have identified all our applications and services using Log4j 2 and have patched all required Java-based applications. LambdaTest has a dedicated security team which is closely looking into the matter and working with engineering teams to ensure that all security best practices have been implemented on highest priority basis.

Additionally, we are working with all our vendors to monitor other affected services and patch (or remediate) them as required (on an urgent basis).

Our Engineering and InfoSec teams have updated all internal services that directly or indirectly use Log4j. We have been continuously monitoring for exploit attempts and have not detected any attacks against our infrastructure.

In addition, we have deployed adequate measures in place for tracking any suspected attacks that are looking to exploit this vulnerability.

Log4j Mitigation Steps

In order to keep yourself safe, we’ve compiled a list of steps that can be used to mitigate any effects of the Log4j vulnerability.

1. Update System: Version 2.16.0 of Log4j has been released without the vulnerability. You can download it from the Apache official website and update it on your system.
   

   Apache Log4j 2.16.0 is now available. Thanks to the Apache Logging Services Project Management Committee (PMC) for working around the clock to get the release out so quickly!https://t.co/fCVZWwUgN6 #Apache #OpenSource #innovation #community #log4j #security pic.twitter.com/Odhf1xawYl

   — Apache – The ASF (@TheASF) December 13, 2021

2. Disable JNDI Lookups: Add log4j.format.msg.nolookups=true to the global configuration of your server/web applications.
3. Block Malicious Request with WAF: Use WAF (Web Application Firewall) to prevent log file tampering and block malicious requests.
4. Disable Remote Codebases: Disabling remote codebases ensures developer safety at all times.
5. Use DUST web vulnerability scanner to monitor your system: Using DUST web vulnerability scanner will detect and alert application owners to web applications with potential security flaws.

References

Details regarding the vulnerability:

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
• https://logging.apache.org/log4j/2.x/security.html
• https://www.kaspersky.com/blog/log4shell-critical-vulnerability-in-apache-log4j/43124/

Changelog

Here is the record of all notable changes made:

• 2021-12-16: All LambdaTest internal Applications and services using the Log4j vulnerable version were patched to the latest security.
• 2021-12-14: We update with a temporary fix while the update needs some testing. 
• 2021-12-13: Added Cloudflare WAF with Log4j rule to protect exploit and security team monitoring it closely.  
• 2021-12-12: Started updating Log4j to update patched versions protecting against CVE-2021-45046.
• 2021-12-11: Updated communications to reflect any impact to LambdaTest.

You can keep following this page for the most recent updates related to Log4j. If you are a customer and need more information, please contact LambdaTest Support or the Customer Success team.