Blackpoint Cyber continues to actively monitor the Apache Log4j remote code execution (RCE) vulnerability currently exploited in the wild. Note that this vulnerability is being tracked as CVE-2021-44228 and colloquially known as “Log4Shell”. As Blackpoint and the community collect more intel and mitigation strategies surrounding this threat, we will keep you informed in this threat blog post and through our social media channels.
In this ongoing blog post, we summarize:
- Key Takeaways – What does this mean for our partners?
- Recommendations/Mitigation Steps – How to protect yourself and your clients
- Threat Intelligence – Latest updates from Blackpoint SOC
On Friday, December 10, 2021, a previously unknown zero-day vulnerability targeting Java logging library Apache Log4j was actively exploited in the wild. Now tracked as CVE-2021-44228, the implications of this vulnerability are still actively being researched.
What Does This Mean to Our Partners?
This zero-day allowed unauthenticated remote code execution (RCE) if the user was running the application and accessing the Java logging library. It enabled attackers to gain full control of affected servers. An attacker who could control log messages or log message parameters could then execute arbitrary code loaded from LDAP servers when message lookup substitution was enabled. Given the widespread use of this library and how easy the vulnerability is to exploit, its impact was noted as severe.
Several proof of concepts (POC) have since been released and exploitation is currently being observed. This vulnerability impacts the majority of Java applications and must be patched immediately to prevent exploitation from remote unauthenticated attackers.
How to Protect Yourself and Your Clients
We urge our readers to patch as soon as possible. Many applications have pushed patches for their software. We highly recommend that organizations upgrade to the latest version of Apache Log4j 2 (2.17.0) for all systems and applications.
Patching should be prioritized. If patching is not possible, here are some possible mitigations:
- In Log4j 2 versions 2.10 to 2.14.1, set the system property “log4j2.formatMsgNoLookups” to “true” to disable the vulnerable features.
- For releases 2.0-beta9 to 2.10.0, remove the JndiLookup class file from the classpath in log4j-core. Example path: (/log4j/core/lookup/JndiLookup.class)
- Outbound Egress Filtering to prevent suspicious LDAP and RMI outbound traffic.
The following list of external links has been thoroughly reviewed by Blackpoint SOC and serves as a general recommendation for next steps after patching as well as ongoing, collaborative threat intel coming in from the greater infosec community.
From Blackpoint Cyber:
We have observed two IPs across our customer base that are attempting exploitation of vulnerable servers. We recommend that you block these IPs immediately:
GreyNoise has published a list of IPs observed scanning for this vulnerability found here:
From National Cyber Security Centrum (NCSC-NL):
The NCSC-NL has published a list of all known vulnerable and non-vulnerable software impacted by the Log4J vulnerability found here:
Datto has released their Log4Shell Enumeration, Mitigation & Attack Detection Tool that can be used to scan and uncover software impacted by this vulnerability:
N-able has released a tool that scans for potentially vulnerable software found here:
From Florian Roth (via GitHub):
The Log4shell-Detector tool created by author Florian Roth may be found here: