Since December 9, 2021, organizations have been working hard to understand their exposure to Log4j remote code execution vulnerability CVE-2021-44228 (also known as Log4Shell) and mitigate associated risks, either through patching or workarounds. Secureworks® Counter Threat Unit™ (CTU) researchers provided an update of the threat on December 15, but the situation has been evolving rapidly.
As hard as network defenders have been working to protect their businesses, threat actors have been rushing to exploit this vulnerability. Mass scanning erupted shortly after the initial patch (2.15.0) was released. Despite the broad range and intensity of the observed exploit attempts, there have been limited cases of exploitation leading to remote code execution. In contrast, CTU™ researchers observed approximately 50 successful intrusions shortly after (and in some cases, prior to) disclosure of the ProxyLogon vulnerability in early 2021.
How does exploitation work?
It’s easy to launch an exploit attempt for Log4Shell. It’s harder to achieve persistent code execution (i.e., “stick the landing”). This is a “blind” exploit, meaning the attacker generally doesn’t have direct visibility into whether it worked. To determine success, they use exploit payloads that make requests to external resources. For example, many of the DNS lookup attacks leverage services like interactsh.com, interact.sh, service.exfil.site, dnslog.cn, and burpcollaborator.net.
In these attacks, a successful exploit attempt triggers a request to an attacker-controlled subdomain. This request enables the threat actor to confirm that the vulnerability can be exploited, at least superficially. It’s like the game of Battleship. After getting a “hit”, the threat actor can refine their attack on the target.
In addition to determining if Log4j exploitation is possible, these services can be used to exfiltrate data. Threat actors are sending commands that attempt to obtain sensitive credentials for the local system or cloud resources, like AWS keys. These credentials could then be used to obtain access via existing remote access solutions.
What’s the path to remote code execution?
Achieving remote code execution is a step further. It requires other system components and configuration settings.
Successful exploitation needs alignment of at least three factors. All of these need to be in place for remote code execution to occur:
- A vulnerable Log4j version that facilities lookups to attacker-controlled URIs
- A vulnerable version or configuration of Java core, which facilitates unchecked execution of malicious code (this requirement can be circumvented)
- The lack of egress filtering, which allows coerced requests to leave the network
The first factor is critical, and the window of exposure has existed for over eight years. The vulnerability affects Log4j 2.0-beta9 (released on September 9, 2013) through Log4j 2.15.0 (released on December 6, 2021). As of this publication, the release of Log4j 2.16.0 on December 13 appears to have closed that window.
The second factor relates to whether malicious Java code downloaded from an attacker’s server following Log4Shell exploitation is able to run. For Java Virtual Machine (JVM) versions released after October 16, 2018 (i.e., 6u211, 7u201, 8u191, 11.0.1), lookup and execution of untrusted code is prevented by the default setting ‘com.sun.jndi.ldap.object.trustURLCodebase = false’. If organizations have kept their JVM installs up to date, the opportunities for exploitation are considerably reduced.
However, CTU researchers have observed emerging evidence of other attack vectors that circumvent this restriction. Apache Tomcat server class ‘org.apache.naming.factory.BeanFactory’ can enable remote code execution after Log4Shell is exploited. Account permissions also play a role. If a compromised process is running under a low-privilege account, then the scope of the compromise may be contained.
The third factor is egress filtering. For organizations and products that leverage a traditional three-tier web application deployment architecture, logging components should be sufficiently segmented so that external requests aren’t permitted. This segmentation prevents responses from exploit attempts from leaving the network, effectively stopping the attack.
What happens next?
As of this publication, most mass-attack attempts are failing because they are not tailored to the target environments. To improve success, threats actors will need to be more selective about their targeting and methodically enumerate target environments. The attack chain must be customized for the Java version, Java configuration, other system settings, and existing security controls.
Offensive security toolkit updates to exploit Log4Shell will make it easier for threat actors to leverage this vulnerability and remotely execute code. The more enumeration work that is done by the tool, the less technical expertise a threat actor needs to conduct a successful attack.
Conclusion
Patching or mitigating your organization’s exposure to this vulnerability is crucial. Network defenders need to protect systems immediately, before threat actors hone their tactics. However, there may be a little more breathing room than originally thought. Unskilled threat actors have been unsuccessful in broadly exploiting this vulnerability. Skilled threat actors, including cybercriminals and government-sponsored threat groups, will likely refine their attacks chains to improve their success rates. Patching must not stop at the perimeter. Leaving vulnerable Log4j versions accessible to internal applications presents an attack surface that an attacker could leverage after obtaining initial access to an environment.
Network defenders must also continue to monitor alerts from existing security controls. Although this vulnerability provides a novel initial attack vector, post-exploitation activity will be similar to other types of attacks addressed by existing security controls.
The advice provided in the December 15 blog post still applies:
- Identify systems with vulnerable versions of Log4j, prioritizing those that are internet-facing. Authenticated scanners are the most straightforward way to perform this check if you have that capability.
- Patch vulnerable systems. If you can’t patch, apply the mitigations provided by Apache, noting that the company has designated some previously suggested mitigations as insufficient.
- Investigate for evidence of compromise on potentially impacted systems. Review server logs, analyze network and host telemetry, and review file systems for indications of new and suspicious file creation. Also monitor alerts from countermeasures that could indicate follow-on activity.
Multiple Secureworks groups, including the CTU research team, Incident Response team, and Secureworks Adversary Group continue to investigate this issue and directly assist customers. In addition, dozens of Secureworks Taegis™ XDR countermeasures and a threat hunting notebook have been created to assist customers. Taegis customers can now detect if this vulnerability is being scanned and if it has been exploited.
For more information about this vulnerability, visit our FAQ. If you need urgent assistance with an incident, contact the Secureworks Incident Response team. For other questions on how we can help, use our general contact form.