Ordr Response to Log4j Vulnerability

Like many other security and incident response teams, Ordr was busy over the weekend responding to the critical Apache Log4j vulnerability (NIST details here CVE 2021-44228). We want to make sure our customers understand what the Log4j vulnerability is, how it affects them, and how Ordr helps keep their enterprises protected.

What is the critical Apache Log4j Vulnerability?

Log4j is an Apache Java logging library used in many forms of enterprise and open-source software. This includes cloud platforms, web applications, and email services that could be at risk from attackers attempting to exploit this vulnerability.

The Log4j vulnerability (CBE-2021-44228), also known as “Log4Shell,” is a vulnerability that was announced on December 9. The attack vector is extremely trivial for threat actors. A single string of text can trigger an application to reach out to an external location if it is logged via a vulnerable instance of Log4j. It can allow unauthenticated remote code execution and access to servers. There are already active examples of attackers attempting to exploit this Log4j vulnerability in the wild, from installing cryptomining malware, installing Cobalt Strike malware, and of botnets attempting to use it for botnet activities.

Is the Ordr Platform or Ordr operations impacted by Log4j?

No. The good news is that all three areas of Ordr operations–Ordr internal IT, Ordr Data Center/AWS that use various tools and hosts cloud instances of Ordr Systems Control Engine (SCE), and the Ordr SCE that runs on customer premises–are NOT impacted by Log4j.

What Systems/Vendors are impacted by Log4j?

There is a long and growing list of systems and vendors impacted by Log4j.  

What about healthcare organizations and medical devices impacted by Log4j?

While the full scale of affected devices and systems is still being analyzed, healthcare organizations should consider any web-connected medical device vulnerable as they likely use Java-based applications or other Java components.

Identifying medical devices with Log4J vulnerability may require a slightly different approach. In a typical IT scenario, security teams can scan or run scripts on servers to identify what kind of log4j version is being used but in healthcare situations, hospital staff do not have the privilege to run scripts directly on heavy iron devices like CT/X-ray machines as well as patient monitoring devices.In addition, in some cases, it is not feasible to patch these medical systems.

Ordr will also work with medical device manufacturers as they disclose their vulnerability to make sure customers are kept up to date.

Another best practice for healthcare organizations is to monitor device communications from these devices to watch for connections to suspicious IP/URLs. Ordr’s Traffic Analysis and behavioral-based anomaly can provide visualization and baselining of traffic patterns of medical devices. We will monitor external communication to make sure malware is not getting downloaded, exploited through this vulnerability and communicating to attacker C2 domains.

Can we use the Ordr Systems Control Engine to detect systems impacted by Log4j?

Yes. Ordr has comprehensive threat protection capabilities that will detect systems and assets impacted by this vulnerability:

• You can start by using Ordr to first identify all workstations and servers that may be vulnerable.
• Our integrated IDS/threat detection engine has already been updated with signatures to detect active exploits of Log4j.  You can investigate impacted systems that are being exploited.
• Ordr threat intelligence and malicious IP/URL database lookup have already been updated to detect the latest external communications to Log4j IoCs (indicators of compromise)
• You can create an Ordr custom policy profile and use the Ordr behavioral anomaly detection to monitor workstations and servers suspected to have this vulnerability and track their external communication.

Look for more best practices and new enhancements on detecting and protecting against Log4j using Ordr this week.

What can I do to mitigate the Log4j vulnerability’s impact?

While this vulnerability is extremely trivial to exploit, the mitigation is also trivial. For more details, please reference the recommendations provided by the Apache foundation.

1. Identify vulnerable systems on your network, and update. The CVE-2021-44228 Log4j RCE vulnerability was patched in Log4Jv2.15.0 by Apache

2. The vulnerability can also be mitigated in previous releases (>=2.14.1)

• By setting the system property flag “log4j2.formatMsgNotLooku[s” to “true”
• By removing the NdsiLookup class from the classpath
• 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. Note that removal of the JndiManager will cause the JndiContextSelector and JMSAppender to no longer function.

Please note that log4j versions 1.x are not affected by this vulnerability. Also, JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector.

For more questions on Ordr or the Log4j vulnerability, reach out to us at info@ordr.net, or if you’re a customer, please reach out to your customer success team.

Pandian Gnanaprakasam

Pandian has more than 20 years of product and engineering leadership experience and is also a serial entrepreneur. Before founding Ordr, he was the Chief Development Officer at Aruba, responsible for all of engineering and product management functions. Aruba, an enterprise mobile wireless company, was acquired by HPE for $3 Billion in March 2015. Before Aruba, Pandian served as the head of engineering for Cisco’s multi-billion-dollar Wi-Fi business unit and before that as VP of engineering for low-end switching product lines. He graduated with a master’s degree in Electrical Engineering from IIT, Chennai, India and holds several patents to his credit in various networking technologies.