The Log4j Zero-Day: What We Know So Far

There’s nothing in the cyber threat intelligence world like having a severe remote code execution (RCE) zero-day drop on a Friday afternoon. In light of this news, here’s a quick rundown of what we know about this: On 10 December 2021, reports began emerging of a new zero-day vulnerability found in the popular Log4j Java library. Many cloud services widely use the Log4j Java library, like Apple, Steam, and applications like the popular video game Minecraft. The vulnerability was tracked as CVE-2021-44228 and given the name “Log4Shell”. This vulnerability was deemed critical due to the ease of exploitation and the significant impact it could cause.

The bad news.

At the time of writing, it is believed that any systems using Apache Struts, Solr, and Druid are likely to be vulnerable. The exploitation of this vulnerability could allow for unauthenticated, remote code execution (RCE), allowing complete control of affected servers of affected systems. Due to the ubiquity of the Log4j package, the possible attack surface for threat actors to target is far-reaching. There have already been reports of organizations seeing attacks in the wild, and there will likely be more in the coming days and weeks.  

But, there is good news.

The latest version of the Log4j software, 2.15, mitigates the vulnerability. Details of which can be found here. We recommend upgrading to the latest version ASAP, and in light of maintenance schedules slowing down for the holidays in a lot of places, putting top priority on updating. If patching cannot be accomplished in a timely manner, the Apache team recommends setting the system property “log4j2.formatMsgNoLookups” to “true” or to remove the JndiLookup class from the classpath for versions newer than 2.10, but prior to 2.15, which should mitigate the vulnerability. 

According to MalwareBytes, there may be additional dependencies, such as updating Java versions or other services, that may make the upgrade slightly complicated. Randori’s Attack Team has provided a link to a Github tool that can check for vulnerable versions, as detailed on their findings. Disclaimer: While we can’t directly vouch for the effectiveness of this tool, it’s best to have information in hand to help in the fight.

As of the time of writing (Friday afternoon), we’ve seen advisories from F5 and Cloudflare stating that their WAF signatures have been updated to include detections for JNDI injection attempts; however, research is ongoing to discover any further vulnerabilities for their applications. Cloudflare took the additional step of rolling out WAF coverage to all customers, including those not using WAFs. Redditors from the r/netsec community have “stickied” a comment in this thread, which is likely to continue updating throughout the next few days. The most notable of these are some detection rules posted on Github, including YARA, as well as notices from Emerging Threats, who have updated their Snort and Suricata rules. Finally, Splunk has also released new detections, as detailed in their latest blog here.

What’s happening now

Soon after disclosing the vulnerability, proof-of-concept (PoC) code was released on GitHub, which could allegedly be used to target the zero-day. Threat actors reportedly began actively scanning the internet for vulnerable systems immediately after the PoC became available, and the Computer Emergency Response Team New Zealand (CERT NZ) warned on the same day that the vulnerability is being “actively exploited” in the wild. The CyberSecurity and Infrastructure Security Agency (CISA) also made a press release, reiterating Apache software users’ importance in mitigating the threat posed by CVE-2021-4428.

As expected, the news of this vulnerability quickly began spreading within cybercriminal communities. One forum user compared the vulnerability to “the bug that produced the Equifax 2017 data breach” (another previous Apache Struts vulnerability) and another compared it to “EternalBlue”, a separate RCE vulnerability. A separate user claimed that the vulnerability works in “80% of actual servers.”

 

Other users began reporting that the POCs were being hastily removed from Github, and they reacted by creating clones of the POC to share with other forum members. Generally, forum users suggested that the vulnerability would likely be “exploited massively” in the short-term future as defenders play catch-up. 

 

 

What to do next

It will be a long weekend for many of us; make sure to take breaks to rest and recover. You’ll need a clear head for the work ahead. 

Here is what we think you should prioritize: 

1. Assess logs to determine if an attacker could execute arbitrary code on your infrastructure. Use IOC associated with these campaigns or “jndi:ldap”.
2. Assess which variables or fields within your application may be parsed by Log4J; if these variables are able to be modified by an attacker then exploitation may be possible. There is significant scope for creative thinking here – if a message in a Minecraft chat can result in a server compromise, then the sky’s the limit. 
3. Reach out to your key suppliers who have access to sensitive information or provide a mission-critical service. Ask them if they are impacted by the Log4j vulnerability and their remediation plan. Guess what? They’ll likely say they are still investigating, which is true, so make sure to follow up with them. 
4. Ensure that you are capturing lessons learned as you progress through your incident response activities. Was your logging setup correctly? Did you have access to those logs? Did you have a software Bill of Materials that helped you quickly understand the vulnerable assets’ scope and impact?
5. Finally, if you’re already a Digital Shadows (now ReliaQuest) client, we’ve published a Public Intelligence alert for this event, which includes relevant, up-to-date information on the latest activity regarding this event and new updates. In addition, we created some Shadow Search (now ReliaQuest GreyMatter Digital Risk Protection) queries you can use below.

Shadow Search (now ReliaQuest GreyMatter Digital Risk Protection) RECOMMENDATIONS

INDICATOR QUERY:  

type=[indicator feeds] AND (“log4j” OR “CVE-2021-44228” OR “Log4Shell”)

INFORMATION ABOUT THE VULNERABILITY VIA THREAT INTEL FEEDS: 

(“log4j” OR “CVE-2021-44228” OR “Log4Shell”) type=[blog posts] OR type=[intelligence incidents] date=[now-7d TO now]

INFORMATION ABOUT THE VULNERABILITY VIA WEB SOURCES: 

(“log4j” OR “CVE-2021-44228” OR “Log4Shell”) type=[web sources] date=[now-7d TO now]

QUERY FOR DISCUSSIONS ON FORUMS, CHATS, AND MARKETPLACES: 

(“CVE-2021-44228” OR “Log4j” OR “Log4Shell”) AND (type=[Forum posts] OR type=[Chat messages] OR type=[Marketplace listings])

QUERY FOR INFORMATION ON THE VULNERABILITY: 

(“CVE-2021-44228” OR “Log4j” OR “Log4Shell”) AND (type=[Vulnerabilities & Exploits])