Log4Shell at industrial enterprises

What is Log4Shell?

Log4Shell is an improper input validation vulnerability. Its exploitation could lead to confidential data leakage, denial-of-service, and remote code execution attack scenarios. Essentially, if there is an application running on the network that handles data received from an untrusted source and logs some of that data using a vulnerable version of Log4j, you potentially have malicious code execution in the context of that application.

• To be vulnerable, an application does not have to accept input directly from a malicious party (i.e., it does not have to be a vulnerable internet-facing service, such as an Apache web server). It could well be a business or industrial application running on the network, which in some way, e.g., through a chain of other applications and/or data storages, accepts a string that originally came from an untrusted source.
• In this case, the only condition that has to be satisfied for a vulnerable application to be exposed to an attack is that the application should have access to a server controlled by the attacker. It could be a server accessible over the internet (the most common scenario) or a compromised host on the attacked network (e.g., in the case of a targeted attack).

How does this work?

Java is a powerful tool, designed to make application development faster and more efficient. However, there are weaknesses lurking behind its obvious strengths. Sometimes the price that has to be paid for versatility and easier code development is the loss of quality and security control.

With Log4j2, the developer can allow users to define not only what is to be logged but also how (in what format) and, most importantly, from what source the data to be logged should be taken. A java class stored in a remote location can be used as the source of data. And the class can be looked up and found using JNDI (Java Naming and Directory Interface), a unified interface designed to work with various directory services, such as LDAP (Lightweight Directory Access Protocol), DNS (Domain Name System), RMI (Remote Method Invocation), and some others.

As a result, a malicious actor could have a specially crafted Log4j JNDI lookup string passed to a vulnerable application (as mentioned above, it doesn’t matter how this is done). If the string passed contains the path to a malicious java class stored on a server controlled by the attacker, that’s all the attacker needs to ensure that the malicious code is downloaded from the server and executed in the vulnerable application’s context.

What’s going on?

This is a very grave situation.

The main issue is the sheer scale of the problem: the vulnerability affects a very large number of products to varying degrees, each in its own way. Identifying all vulnerable assets on a network can be a challenge, especially in geographically distributed heterogeneous environments of large industrial organizations.

The second issue is that there isn’t a single simple solution that fits all organizations and all their vulnerable systems. While some systems may allow fast patching, many others (particularly high-load and/or mission-critical systems) are very hard to patch quickly and various mitigation measures have to be taken to protect them.

The third issue is that this is not a vulnerability affecting a specific product or even a readily available common OEM component that is used in more or less the same ways in different end products (such as a licensing service). The vulnerability affects a widespread software development technology used in different ways in an enormous number of different applications. As a consequence, all of these applications are also vulnerable in different ways, multiplying potential attack scenarios manyfold.

And finally, fixing the vulnerability in the technology itself has proved difficult: a couple of days after the developer had released patches, a new attack vector was identified. It works in some cases where logs are formatted using parameters saved in the Thread Context Map that the attacker was able to define (with the help of the technique that was used in the earlier attack variant). A few more vectors were found and disclosed later on. Luckily, they are not as critical, but one also affects Log4j1 (an earlier version of the framework that was previously believed to be unaffected by Log4Shell). To exploit the vulnerability, an attacker needs write access to the Log4j configuration file. The latest finding disclosed by researchers, which has to do with Log4j2, also involves its configuration. In addition to all its other features, Log4j allows users to configure the log to be saved in a relational database rather than a file. This is done through the JDBC interface using the JDBCAppender technology. Log4j does not properly check the string value defining the JDBC data source (which stores the database connection parameters), enabling an attacker to point at a remote malicious class instead. This results in malicious code stored on the server controlled by the attacker being executed using the same JNDI mechanism that was abused in the initial version of the attack. The attacker needs either to have write access to the configuration file or to get MITM (the configuration file may also be located remotely).

For all we know, this may not be the end of the story.

We can see that malicious actors have realized how difficult it will be to protect many of the vulnerable systems quickly and are trying to capitalize on the situation. Criminal gangs that spread commodity malware have started opportunistic mass-scale campaigns based on the most common attack scenarios.

Organizations normally protect themselves from such threats using traditional security measures, including network perimeter protection and endpoint security solutions. As a rule, these solutions work in automatic mode and have low skill requirements.

The problem now faced by network security tools is that data that is subsequently included in the logged parameters of vulnerable applications is sent using requests whose syntax is quite permissive, resulting in a big variety of possible malicious network traffic that makes it difficult to create simple detection rules covering all possible cases. As for endpoint protection, many affected systems, especially high-load and/or mission-critical ones, may have none because of the “compatibility and performance issue” delusions, which are still very common among IT and, especially, OT staff.

More sophisticated actors will use attack vectors tailored to their targets and their specific systems. Protecting from such threats is always a challenge and is often more art than technology.

How does this affect the industrial sector?

As regards the industrial sector in general, its IT systems are as much affected as those in many other sectors: they use the same and equally vulnerable web services, financial and business applications.

Unfortunately, OT systems appear to be almost as vulnerable as IT systems, as evidenced by many vulnerability advisories recently published by vendors of ICS products. Many of the vulnerable products are widely used in the electric power sector, including:

• distributed control systems for power generation facilities;
• products for monitoring field equipment (transformers);
• Asset Management products;
• products used to control electric car charging stations;
• various products for system operators;
• other supporting products, many of which can be integrated with SCADA.

The problem also significantly affects computers and organizations in engineering: many products for modeling, simulation and collaboration of developer teams that are widely used by industrial enterprises to develop new products, as well as the PLM (Product Lifecycle Management) and CAD/CAM systems which are not only used to design and develop new products but also in the production process (e.g., to program CNC machines). The vulnerability also affects many building management systems, including physical security systems.

We also believe that many ICS may be vulnerable because of widely used common components, such as popular license management software used in many ICS products (unfortunately, product vendors have not yet released patches or security advisories and we cannot provide more details due to responsible disclosure considerations). Some Java implementations of the OPC UA protocol stack are also vulnerable.

Overall, based on an analysis of our telemetry data, at least 10% of all industrial control systems globally may be affected by the Log4Shell vulnerability because they use vulnerable software.

Other risk areas for OT systems that are currently hard to assess are associated with using:

• vulnerable software which is not required for the facility’s operation (and which may often be installed in violation of information security policies);
• Industrial internet of things and smart energy applications, many of which, it turns out, were developed using the vulnerable technology.

Although it is still difficult to say to what extent vulnerable ICS systems are exposed to potential attacks, we hope that, unlike IT infrastructures, most vulnerable OT systems cannot accept inputs coming from untrusted sources.

What measures can we recommend to protect from this threat?

• To the extent possible, identify all systems that are based on the vulnerable technology.
• Remove all software that is not strictly necessary and implement regulations and technical measures that prevent it from being installed or used.
• To the extent possible, patch what can be patched or at least apply mitigation measures recommended by the vendor.
• Use proper network segmentation where possible.
• Make sure that internet access is available only to those systems that actually need it.
• Protect whatever can be protected with modern (preferably those designed specifically for industrial systems) endpoint protection solutions. Make sure these solutions are properly configured: the databases are kept up-to-date to the maximum extent possible, there are no areas excluded from protection, all protection components are enabled and cannot be disabled by an attacker who has gained access to the system.
• Make sure your network perimeter solutions can detect and protect against the most common attack types/patterns (get access to a respectable Threat Intelligence source to be sure you know what to protect from).
• Threat Intelligence sources can also help identify the more sophisticated attack scenarios that are relevant to your systems and give you clues about the selection of specific ways of protecting against them.