Ordr Recognized in Gartner Market Guide for CPS Protection Platform Read more here!

Last week we posted about the Log4j vulnerability, advised all organizations to continue patching, and shared that Ordr was not impacted. We also provided an overview of Ordr features that you can use to detect and protect against attacks leveraging Log4j.

In this blog, we will dive into the details of how attackers are taking advantage of this vulnerability. The Russia-based Conti ransomware gang, for example, is exploiting Log4j via vulnerable VMware networks that have not yet been patched. We will look closely at the details of how you can use the Ordr System Control Engine’s (SCE) existing functionality and newly released enhancements to detect and protect against the Log4j vulnerability.

First, here’s a summary of how Log4j attacks progress in a network:

  1. An attacker sends a simple HTTP GET request, or a well-crafted protocol message, to the target server. The request is a “User-Agent” header which includes a URL for a JNDI lookup, or a message with the exact string, JNDI for non-web protocols.
  2. The request is passed to the Log4j library for logging.
  3. The Log4j library attempts a JNDI lookup as directed by the URL. The URL directs this request to an LDAP server that is under the attacker’s control.
  4. The LDAP server responds with directory information with a protocol header that includes a Java class to execute. The JNDI library instantiates and executes the class, which has the same system-level privileges as the server software that included the Log4j/JNDI libraries.
  5. The successfully injected malware can then do whatever the attacker wants.  Risks include ransomware, exfiltration of sensitive data, and any other malware function.

What can Ordr do for you?

Identifying vulnerable targets

Ordr uses multiple methods to detect targets for Log4j. These include monitoring of SPAN or network traffic to detect attacks or probing a device with active scans to identify vulnerable devices. These are logged in the Ordr Security Dashboard Threat Card as a “special category” created to track Log4j attacks.

IDS based attack detection

The Ordr platform includes an integrated intrusion detection engine that monitors traffic to detect malware and attack attempts. Ordr sensors continuously monitor both North-South and East-West traffic for signs of malicious activity or violations of security policies.  This provides real-time visibility into instances of potential network compromises and insights into any lateral movement attempts made by an attacker.

Anomaly detection

The Ordr platform also includes a machine learning-based behavioral analytics engine. This method is used to confirm a possibility of attack, not a confirmation of an attack. It is recommended this information be analyzed, along with other potential events Ordr has added, for Log4j detection. Ordr SCE analyzes and baselines the traffic based on expected behavior, and any deviation from this normal traffic is marked as anomalous on the system. This model works well for all devices that have predictable traffic patterns. For example, a medical device running limited traffic patterns that suddenly displays new communication patterns should be considered potentially anomalous and be investigated.

Vulnerability probing

Ordr has introduced new vulnerability detection software for Log4Shell. This new scanner takes advantage of Ordr SCE’s knowledge of the devices being scanned. IoT and medical devices require special consideration to avoid interfering in their operation.  This capability is not available in most vulnerability scanning products which will aggressively probe all ports in the ranges of IP addresses they are configured to scan. This type of heavy-duty scanning could be detrimental to the operation of the medical devices that could be providing patient care or IoT automation functions.

Unlike typical IT scenarios where security teams can run a set of scripts to see what kind of Log4j version is built into the server, healthcare operations do not have the privilege to run scripts directly on heavy iron, like CT/X-ray equipment, as well as patient monitoring devices. With Ordr’s scanner, you can select only specific devices to be scanned at a time. It is also typical that a hospital standardizes on a specific make/model, and all that is required is to run this test on only one of them to understand the software decomposition. Ordr generates a report after the scan to show a list of devices that are vulnerable to Log4j.

How does the Ordr scanner work?

  • Devices are selected by IP, device type, or various search mechanisms.
  • The Ordr scanner runs on Ordr sensor, and does not need full credential access.​
  • The Ordr scanner injects a string in the packet that triggers a call back to the sensor if a vulnerability is present.
  • The Ordr scanner performs scans on open ports of HTTP, FTP, telnet, and Syslog; It generates a report after the scan is run.

Detecting callbacks to C&C sites

The Ordr platform includes the ability to track and visualize communications to malicious attacker domains; in this case, Log4j attacker domains.

Tracking malicious communications

The Ordr platform subscribes to reputable threat intelligence feeds and is available to every customer today. These feeds detect many of the callbacks to Log4j IPs and domains, but do not associate the family with that. To overcome this problem, Ordr has built a mechanism to scout the internet for all callbacks available for Log4j domains and Ips, and has built a mechanism to update the callbacks dynamically at each customer deployment. The feature provides a two-fold advantage: it covers more callbacks than any of the subscribed threat feeds cover, and it associates the Log4j family to these IP addresses for easy tracking.

Ability to track communications on malicious ports

Another feature available in the Ordr product is tracking communications to the internet based on ports and protocols. As most of the studies have suggested, most of the callbacks for Log4j uses 1389, 2202, and 39536 ports. A simple rule available in Ordr SCE will track every communication to Public IP addresses not owned by the enterprise and mark it as malicious if it matches the rule. All these communications can be viewed on individual devices or under “Blocked Port” on the security page.

Visibility to Log4j traffic patterns

Traffic analysis engine

Ordr SCE provides the ability to visualize problematic traffic centrally in the Group Traffic Analysis tool.   This screen features a constellation plot that shows the recognized groups and individual bubbles.  To make tracking of Log4j easy, Ordr has created a new bubble specific to Log4j, and all communications from inside the enterprise can be viewed with a single click.

In the example below, the operator clicked on the Log4jRCE Sites bubble. The only traffic lines plotted were to the Workstations and Medical Devices group.  This means that other groups such as Servers are not yet active with Log4Shell traffic.

Policy profiles to track communications

Users are given an option to create a policy profile to track communications from a discrete set of devices. In the case of Log4j, it is recommended to create a new policy profile to track devices that are potentially vulnerable to Log4j. In this case, start with servers and expand it to other potential devices.  After creating the policy profile, Ordr SCE evaluates every flow from these devices as a base and marks new communication as malicious. These are color coded based on the risk of the communication.

Highlighting infected devices using a risk score

Ordr assigns a risk score for every device in the network based on the events detected for that device. Each event described above will change the risk score of the device based on the criticality of the event. In the case of Log4j, devices with attributes such as a vulnerable system, where an exploit is identified or if the device is communicating to Log4j callback will have a risk score of critical. The risk score gets adjusted based on the events detected and the criticality of the device.

Ordr has deep integration with firewalls and NAC vendors. Users will have an option to quarantine connected devices based on their risk level, or if they detect a Log4j security event or behavior anomaly. They all point to a possibility of an attack in the enterprise.

In summary, Ordr has one of the most comprehensive features to detect the Log4j vulnerability and protect against exploitation. For more information, please reach out to us at info@ordr.net or request a demo here.

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. You can reference the details here: https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

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
  1. 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.