Log4Shell, a new, critical zero-day vulnerability that crashed onto the scene last Friday, shows how issues that are hidden in seemingly basic functionality can have major repercussions for enterprise security. When the dust settles from the immediate incident response and remediation, organizations should assess how they can improve their detection and responses, because this vulnerability surely won’t be the last one.
What is Log4Shell (CVE-2021-44228)?
The initial indications of this problem appeared on Twitter early in the day on Friday with accounts of zero-day exploitation of a vulnerability in a popular Java logging framework, Log4j. The core of the problem is that when specifically formatted strings are used, instead of just writing the data to log files, Log4j will interpret them. This can lead to remote code execution (RCE), compromising the target system. Tracked as CVE-2021-44228, the vulnerability has been named Log4Shell and received the highest possible severity rating of 10.
Because logging systems pull data in from a vast array of sources, tracking and patching vectors where this issue can be introduced is a particular challenge. Also, Log4j is often used as part of other software or bundled with black-box appliances, so organizations are unlikely to have a register of all the possibly vulnerable systems.
Throughout Friday, several novel vectors for exploitation were suggested, including attackers setting their browser’s user agent to the exploit string (user agents are often logged by web servers) or changing their home Wi-Fi SSID to exploit cloud services such as those run by Apple.
Additional technical details both on exploitation and defense against this issue are on the blueteamsec subreddit, where they’re running a meta thread to collate information.
Speedrunning the incident process
One of the notable aspects of this issue was how quickly it unfolded. After the initial public threads (generally on Twitter) that provided vulnerability and exploit information, we saw detection and exploitation tooling be introduced within hours. Both plugins for the popular web application scanning tool Burp and new modules for scanning framework nuclei were developed.
Mitigating the issue
While the offensive security industry was fast to move, it was good to see that on the defensive side of the house there were also rapid responses. Akamai provided rules to help block the initial exploitation of the issue as did Cloudflare, showing the benefits of layered defenses employed by many organizations.
For most organizations, responses to this issue will fall into a couple of categories. The initial response should be to use web application firewall (WAF) functionality to provide some protection while other activities are carried out. This will require tuning, because many WAF bypasses have already been noted.
In parallel to this issue, identifying vulnerable software will be necessary for patch efforts to be successful. Vendors such as Oracle and VMware have already provided information on where their products are affected by the issue. However, it will likely take some time for patches to be made available, because they will require testing.
Detecting and mitigating the Log4Shell vulnerability with Aqua
Aqua can identify and block the workloads that have the Log4Shell vulnerability.
In the Aqua platform, you can see all the Log4Shell affected container images and their running workloads in your environment:
In addition, you can create an assurance policy that will mark these workloads as noncompliant and prevent their execution:
Also, you can include the Aqua Scanner as part of your CI/CD processes to identify and block new builds that have the Log4Shell vulnerability, shifting security left.
Mitigation in runtime
If the Log4Shell exploit is used to execute a malicious payload, its post-exploitation will be detected and blocked in runtime with Aqua’s drift prevention, which prevents the execution of files dropped during runtime.
Aqua’s advanced malware protection can detect any known threats loaded by the attackers who exploit the Log4Shell vulnerability. Additionally, Aqua CNDR can detect malicious activity executed by the payload, including cryptomining, execution from memory, and escaping to the host.
Is Aqua affected?
Aqua isn’t affected — we don’t use Java.
All our artifacts were scanned with Aqua’s solutions, and we validated that Log4j is not used in our software.
Avoiding future issues
Once the dust has settled on this issue, organizations should consider how to address the risk of future issues. The complexity of our software supply chains makes it inevitable that we’ll face this kind of security risk again.
Companies can look at several ways to reduce the impact of this kind of issue:
- Good software supply chain security Software bills of materials (SBOMs) could help to identify vulnerable software. Requesting SBOMs from suppliers can help companies get visibility on where specific software packages are in use.
- Defense-in-depth measures While technologies such as WAFs are not a security panacea, having them in place can provide helpful mitigation while slower security activities are undertaken.
- Egress firewalling One of the main exploitation paths for this issue was for the compromised system to make a request to an external system to pull down exploit code. Preventing servers from initiating connections to arbitrary Internet systems can reduce the risk of this issue and many others like it.
Conclusion
The Log4Shell vulnerability is another example of the speed at which cybersecurity moves in the modern world and the necessity of deploying layered security controls to reduce the risks and impacts of vulnerabilities. It also illustrates how seemingly safe software can be a source of novel exploitation techniques.
