Tracking the Start of the Log4j Vulnerability

It was a long weekend for those working in cybersecurity.

On Friday, December 9, a severe remote code vulnerability in Apache's Log4j was announced to the world and tracked as CVE-2021-44228.

Interestingly though, the vulnerability appears to have been around for more than a week before it was publicly disclosed. Matthew Prince, the Co-Founder and CEO of Cloudflare, tweeted this out on Saturday:

Sophos says it has detected hundreds of thousands of attempts to remotely execute code using this vulnerability since its disclosure. The attempts detected have primarily been scans for the vulnerability, exploit tests, and attempts to install coin miners.

You can see how the attempts have increased over time since last Friday based on this chart from Sophos:

Security researchers have discovered malicious cryptominers attempting to leverage the vulnerability, as well as several automated botnets, like Mirai, Tsunami, and Kinsing. Sophos notes that other types of attacks and payloads are likely to follow in the coming days.

How bad is the log4j vulnerability?

The log4j vulnerability will likely have impacts that last much longer than just this last weekend.

After the discovery of the vulnerability, Cybersecurity and Infrastructure Security Agency (CISA) Director Jen Easterly spoke on the severity of the exploit.

"This vulnerability, which is being widely exploited by a growing set of threat actors, presents an urgent challenge to network defenders given its broad use. To be clear, this vulnerability poses a severe risk."

Casey Ellis, the Founder and CTO at Bugcrowd, also shared his thoughts on the situation:

"This is a worst-case scenario. The combination of log4j's ubiquitous use in software and platforms, the many, many paths available to exploit the vulnerability, the dependencies that will make patching this vulnerability without breaking other things difficult, and the fact that the exploit itself fits into a tweet. It's going to be a long weekend for a lot of people.

The immediate action to stop what you're doing as a software shop and enumerate where log4j exists and might exist in your environment and products. It's the kind of software that can quite easily be there without making its presence obvious, so we expect the tail of exploitability on this vulnerability to be quite long."

So, where are we heading with this exploit? Cisco Talos shared what it has observed about the vulnerability and what we will likely see in the next couple of days and weeks:

"This exploit is following a pattern we commonly see in vulnerabilities that emerge unexpectedly. Scattered early incidents from unknown actors have been observed only by looking back in telemetry and demonstrate early adoption by coin miners and botnets. If the pattern holds, and we expect it to, many actors with different objectives ranging from financial to espionage will rapidly adopt this exploit in the coming days to secure access either for immediate use, for resale or for long-term footholds.

We have also observed several obfuscation techniques as threat actors attempt to evade pattern-based detection mechanisms that may have been deployed initially as details of this vulnerability began to emerge. We will likely continue to see additional obfuscation techniques moving forward.

It is also important to note that within our telemetry we have also observed other protocols used to retrieve malicious payloads."

Mitigations for Log4j vulnerability

The severity of the exploit is significant and action must be taken as quickly as possible to reduce the risk posed to your organization.

Apache has already released an updated version, Log4j 2.15.0. However, if it's not possible to update them, Apache recommends the following mitigations:

• "Users of Log4j 2.10 or greater may add -Dlog4j.formatMsgNoLookups=true as a command-line option or add log4j.formatMsgNoLookups=true to a log4j2.component.properties file on the classpath to prevent lookups in log event messages."

• "Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event messages."

• "Remove the JndiLookup and JndiManager classes from the log4j-core jar. Removal of the JndiManager will cause the JndiContextSelector and JMSAppender to no longer function."

It is also recommended that organizations investigate their internal and third-party usage of Log4j to find vulnerable configurations and take remediation actions.

Follow the SecureWorld News page as the log4j situation continues to unfold.