A critical vulnerability in Log4j – the most popular Java logging package – was revealed on December 9th. Dubbed Log4Shell or LogJam (<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228" rel="nofollow" target="_blank">CVE-2021-44228</a>), it’s an unauthenticated, remote code execution (RCE) vulnerability that permits complete takeover of a system that uses Log4j 2.0 (beta9 to version 2.14.1).
Exploitation is as easy as sending the following payload to a vulnerable service:
Due to the immense popularity of this library and the low level of effort required to properly execute this attack, it has gained massive attention in the past few days. AppSec engineers around the world are working 24/7 to identify which services within their codebase are vulnerable – not an easy task.
Application security teams can take several approaches. First look for every service that uses Log4j as a dependency. This is typically achieved using software composition analysis (SCA) tools or by manually scanning your projects’ dependency files.
Another approach is to take automatic remediation steps, such as removing every vulnerable Java class file from project JAR files:
So what is the problem?
In a typical production environment, there are hundreds or thousands of services you should analyze. The challenge here is finding Log4Shell because of the way Java packaging works. It’s possible you have it hiding somewhere in your application and don’t know it. Nor can SCA detect it, because such tools are primarily based upon static analysis and are unaware of the execution context of a given service. This results in a barrage of unsorted alerts and, consequently, a corresponding number of false positives. Additionally, automatic remediation steps are crude and can result in unexpected changes to an application’s behavior.
So how can AppSec teams focus on the most critical alerts?
Let’s take a look at an example.
A sample cluster contains various microservices with the Log4j library installed. Some services are directly exposed to the internet; some include internet-facing flows. Those not exposed to the internet are not directly exploitable but can be exploited indirectly.
When responding to an incident such as Log4Shell, you should focus on the most critical instances posed by it. Thus, you could leverage the power of contextual risk assessment to assess its severity.
Providing an accurate solution to such an attack, Oxeye considers several contextual risk factors by using the flow between microservices and infrastructure configuration data. For example, the following screenshots illustrate several Log4Shell vulnerabilities, with Oxeye assigning each a severity rating based on its contextual risk factors:
Which attack flows are accessible from the internet? Which can be used to exfiltrate sensitive data? How is the container/cluster configured?
Using the contextual risk information provided by Oxeye, you can quickly begin mitigating those vectors that pose the most significant risk to your organization.
With Oxeye, you can respond faster to such vulnerabilities by prioritizing them based on their contextual risk factors – without having to wait for a software patch to be released.
Oxeye can scan and analyze your microservices no matter where they reside. We identify code vulnerabilities and highlight those that are most critical as an integral part of your software development lifecycle (SDLC). We provide a detailed view of risks and severity levels enriched with your environment data – cloud, clusters, and containers – to deliver rich context and clear guidelines for quick remediation. Oxeye filters out false-positive and false-negative results by assessing the context of risks.
Any time a new zero-day vulnerability is discovered, it can be difficult and challenging for impacted organizations to remediate the problem quickly. Connect with our experts for a quick demonstration to see firsthand how Oxeye helps identify and resolve the most critical code vulnerabilities – including zero-day risks.
BAC%20copy%203%403x.png)