Last month, a zero-day vulnerability in the extremely popular Log4j logging framework overwhelmed the security community during the already busy end-of-year rush. Just keeping up with Log4j news and updates has been no easy task, let alone fixing the multiple vulnerabilities discovered almost daily. Organizations worked hard to apply patches for the original zero-day vulnerability, only to be forced to repeat the process when additional vulnerabilities appeared.
In this blog, we summarize what has happened, examine the implications of the Log4j vulnerabilities for the future, and outline how organizations can better protect their systems.
What is Log4j?
Log4j is an open source Java logging library developed by the Apache Foundation. It’s a ubiquitous software package, widely used by millions of enterprise applications, cloud services, and web applications. Many services use it as a dependency, and it’s included in various Apache frameworks such as Apache Struts, Solr, Druid, Flink, and Swift.
Summary of Log4j vulnerabilities
On December 9, a critical zero-day vulnerability CVE-2021-44228 was discovered in Log4j that could allow an attacker to remotely execute code. In the weeks that followed the announcement and release of the patch, multiple new vulnerabilities with varying severity levels were found. Each of them caused a new fix to be released, further intensifying organizations’ efforts to update their systems. As both attackers and security researchers continue to focus their attention on Log4j, we can expect this cycle of vulnerability and fix to continue.
The impact of the Log4j vulnerabilities
Given the widespread use of Log4j in modern applications, the impact on organizations worldwide has been huge, and true recovery will take years. The original Log4j issue is estimated to be present in over 100 million instances globally, and many popular services and providers have been affected, including Apple, Twitter, Steam, and Tesla.
Not only does the vulnerability affect millions of applications, its exploitation is easy. All an attacker needs to do is send a malicious code string that gets logged by Log4j. This can allow an attacker to take full control of any vulnerable server and execute remote code execution (RCE) attacks.
Log4j attacks in the wild
Since the disclosure, the Log4j vulnerability is reported to have been massively exploited in the wild. The vulnerability allows RCE and can easily be exploited, with tons of weaponized exploits readily available on GitHub and other public sources.
The Log4j vulnerability is a good example of how attackers can exploit vulnerabilities in popular open source packages and the massive impact that such a vulnerability can have. While organizations are rushing to patch their systems, threat actors are taking advantage of this vulnerability, actively scanning the internet for at-risk systems and launching attacks.
Team Nautilus, Aqua’s research team, analyzed dozens of real-world attacks exploiting the Log4j vulnerability and shed light on some of the malicious techniques used by adversaries. These include known malware, such as the large botnets Muhstik and Mirai; fileless execution; files downloaded from a remote resource and executed straight from memory; and reverse shell executions.
What should you do?
We strongly recommend upgrading to the latest version of Log4j—2.17.1 at the time of writing—as soon as possible. The first step is to identify all the applications using Log4j that are running across your environment. Aqua’s open source scanning tool Trivy can detect vulnerable software libraries and alert on all Log4j vulnerabilities.
Looking at the bigger picture, it’s clear that organizations need to think about how to address this growing trend in which multiple vulnerabilities in a single product are exploited over a short period. After the immediate response, it’s critical to consider how you can manage this type of risk strategically.
These measures can help reduce the risk and impact of similar incidents in the future:
- Secure the software supply chain. As part of solid software supply chain security, software bills of materials (SBOMs) can help organizations identify vulnerable software and get visibility into the use of specific software packages.
- Develop a defense-in-depth security strategy. The Log4 vulnerability illustrates the importance of a defense-in-depth strategy, where security measures are layered across the organization’s environment to ensure that the failure of a single layer does not lead to a full compromise.
- Use drift prevention, a solution that deterministically prohibits any changes to the image after it is instantiated into a container, which prevents the execution of any files dropped during runtime.
- Deploy detection and response solutions, such as Aqua’s Cloud Native Detection and Response (CNDR), which can reveal malicious behavior during runtime. By identifying and alerting to events when unknown vulnerabilities are exploited, they can help detect and prevent zero-day attacks from occurring in production.
Tracking Log4j in your cloud native environment
Just identifying all Log4j vulnerabilities in container images across your environment is a big challenge. Since so many Java applications use Log4j for logging, organizations might unknowingly be using it and could experience a cyber incident even from a non-critical or unexpected application.
Further compounding the problem is the huge diversity of vulnerable systems. Log4j is often used as part of other software or is bundled with black-box appliances, so organizations are unlikely to have a register of all the possibly vulnerable systems.
If you’re looking for a better, faster way to evaluate, identify, and fix Log4j vulnerabilities, especially for containers in production, Aqua has created the Log4j assessment package, a quick and effective evaluation of your cloud native environment and container images for Log4j vulnerabilities.
