Threat Intel: Log4j - Critical Zero Day Vulnerability

This blog post has been updated as of Monday, December 20th to reflect that new vulnerabilities related to log4j have been discovered and patched. See the addendums at the end of this post.

A critical zero-day vulnerability was published over the weekend that affects the Apache Log4j library. The vulnerability has received the highest possible CVSS score of 10.0, and is already being searched for and exploited in the wild by threat actors.

What You Need to Know about the Log4j Vulnerability

The vulnerability affects Log4j and its successor Log4j2, which are developed by the Apache Foundation and widely used as part of open-source tools by both enterprise applications and cloud services for logging purposes. Systems and servers that use Log4j between versions 2.0-beta9 and 2.14.1 may all be potentially affected by CVE-2021-44228, which includes many software programs, services and applications written in Java. The vulnerability allows for repeated and reliable unauthenticated remote code execution and can be used to exfiltrate PHI, cause service disruption, or enable a ransomware attack.

Are Devices on Your Network Affected?

Cynerio’s research team is engaging in active investigation to understand the full scope of affected devices, and is working closely with device manufacturers to keep you updated on our precise findings as quickly as possible. Active probing is among the methods that can be used to accurately assess the risk and impact of potentially vulnerable devices.

As there are already a number of attacks in the wild and tools to actively exploit this vulnerability, it is critical that organizations implement multiple security methods to protect against a potential attack, including scanning their entire environment to see which applications may be at risk. When possible, upgrade any uses of the library in your organization to the most recent patched version. Thankfully, Apache has released an update to address this vulnerability, so it is important for hospitals and healthcare delivery organizations to evaluate their infrastructure to determine which systems may be affected and remediate them immediately. Additionally, there are configuration changes such as updating web application firewall rules that can be carried out to protect against an attack as patching is being implemented.

Cynerio Can Help Mitigate the Threat

Cynerio customers have an added layer of protection with our exploitation attempt alerting and our Attack Detection & Response solution, which will notify and provide the tools to respond to an active attacker on their network. We’re proactively working with healthcare organizations to identify affected devices and employ safe, preemptive security practices to help expedite mitigation efforts:

• We can locate and flag every device with known Log4j vulnerabilities, and are also in constant communication with device vendors to identify potentially vulnerable devices.
• We provide step-by-step mitigation plans for any affected device, including links to advisories from the device manufacturers
• We will notify you when patches are released for each affected device
• We help define Zero Trust policies to secure vulnerable devices against unauthorized, unauthenticated or unverified access
• We streamline segmentation implementation across your network and provide the ability to monitor, test, validate, and update policies before they’re enforced, so you can be confident about service continuity

If you have any questions or concerns, please don’t hesitate to immediately contact us at support@cynerio.com.

Update: Since this post was published earlier this week, a new potential attack vector leveraging the Log4j vulnerability has been identified, reported, and patched.

It has been discovered that the fix to address what has been classified as CVE-2021-44228 was incomplete in certain non-default configurations. This means that organizations may still be vulnerable to log4j even if they already updated to Apache version 2.15.0 and now must upgrade to version 2.16.0 (patch available here).

If left unpatched, this vulnerability can allow attackers to create malicious input data using a JDNI (Java Naming and Directory Interface) Lookup pattern that can cause a denial-of-service (DOS) attack. There are multiple reports that attackers are already using these vulnerabilities in the wild. Apache 2.16.0 disables JNDI by default.

As ever, if your hospital or healthcare organization is in need of assistance in identifying which connected devices are susceptible to Log4j please get in touch at info@cynerio.com.

Update 2: Since this post was published and updated last week, a third potential vulnerability has been identified, reported, and patched.

Tracked as CVE-2021-45105,the new vulnerability affects all versions of Apache from 2.0-beta9 to2.16.0. The new flaw may enable remote code execution that could lead to a DOS (Denial of Service) attack. Apache has released a patch for this vulnerability that is available at their website. If you are unable to patch, Apache offers a series of temporary mitigation workarounds here.

In addition, another vulnerability, CVE-2021-4104, has been discovered and affects Log4j v1.2. However, Log4j versions 1.x have reached end of life, are no longer supported, and any security flaws they have going forward will not be fixed, so applications and devices leveraging those versions will need to be updated to Log4j2. If that is not possible, audit your logging configuration to ensure it has no JMSAppender configured, as Log4j 1.xconfigurations without JMSAppender will not be impacted by this vulnerability.

Log4j flaws are already being leveraged by multiple threat actors, including nation-states, to carry out attacks such as ransomware and other malicious activities. Fortunately, the good news is that while Log4Shell was exploitable in the default configuration of the library, these newly discovered vulnerabilities are not, making the likelihood of exploitation much lower by comparison.

To the extent they can, hospitals should upgrade all Log4j instances to v.2.17.0 for Java 8 and v2.12.2 for Java 7. If that is not possible, they should remove the JndiLookup class from the classpath.

Cynerio continues to work closely with healthcare delivery organizations to identify affected devices and implement safe, proactive security measures to help expedite mitigation efforts. If your hospital or healthcare organization needs assistance in identifying which connected devices are susceptible to any Log4j vulnerability, please get in touch at info@cynerio.com.

Update 3: The Health Information Sharing and Analysis Center (Health-ISAC) is keeping a running list of product security updates in response to Log4j by healthcare technology vendors that is being updated daily.