Full Report
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.
Analysis Summary
Based on the provided context regarding the "Log4Shell" vulnerability (CVE-2021-44228) and its specific impact on Industrial Control Systems (ICS) and Operational Technology (OT), here is the summarized vulnerability report.
# Vulnerability: Log4Shell in Industrial Control Systems
## CVE Details
- **CVE ID:** CVE-2021-44228
- **CVSS Score:** 10.0 (Critical)
- **CWE:** CWE-502 (Deserialization of Untrusted Data) / CWE-917 (Improper Neutralization of Special Elements used in an Expression Language Statement)
## Affected Systems
- **Products:** A vast range of ICS/OT applications including SCADA systems, HMI (Human-Machine Interfaces), Historians, Engineering Workstations, and industrial management software.
- **Versions:** Apache Log4j versions 2.0-beta9 to 2.14.1.
- **Configurations:** Systems running Java-based environments where the Log4j library is used for logging and where the system can process strings from untrusted sources (e.g., user inputs, MQTT messages, HTTP headers).
## Vulnerability Description
Log4Shell is a critical flaw in the Apache Log4j library. It stems from the way "Log4j2" handles log messages containing a specific syntax: `${jndi:protocol://server/a}`. When such a string is logged, the library uses the Java Naming and Directory Interface (JNDI) to fetch a resource from a remote server (e.g., via LDAP, RMI, or DNS). If an attacker can control the input being logged, they can force the application to download and execute a malicious Java class, leading to Remote Code Execution (RCE).
## Exploitation
- **Status:** **Exploited in the wild.** Proof of Concept (PoC) code is widely available and trivial to execute.
- **Complexity:** Low
- **Attack Vector:** Network (Remote)
## Impact
- **Confidentiality:** Total (Full access to system data)
- **Integrity:** Total (Full control over system operations)
- **Availability:** Total (Can lead to system shutdown or process disruption)
## Remediation
### Patches
- **Apache Log4j:** Update to version 2.17.1 or higher (for Java 8).
- **Vendor Specifics:** Users must monitor industrial vendor advisories (e.g., Siemens, Schneider Electric, Rockwell Automation, ABB) for product-specific firmware or software updates.
### Workarounds
- Set the environment variable `LOG4J_FORMAT_MSG_NO_LOOKUPS` to `true`.
- Remove the `JndiLookup` class from the classpath:
`zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class`
- Upgrade Java Runtimes to versions that have `com.sun.jndi.ldap.object.trustURLCodebase` set to `false` by default.
## Detection
- **Indicators of Compromise:** Evidence of outbound LDAP/RMI traffic from ICS servers to unknown external IP addresses.
- **Detection methods:**
- Scan log files for the string pattern `${jndi:`.
- Use Nmap scripts or specialized ICS security tools to identify vulnerable versions of the library in the environment.
- Monitor for unauthorized `java.exe` or `javaw.exe` child processes (e.g., spawning `cmd.exe` or `sh`).
## References
- Apache Security Advisory: hxxps[://]logging[.]apache[.]org/log4j/2.x/security.html
- Kaspersky ICS CERT: hxxps[://]ics-cert[.]kaspersky[.]com/publications/reports/2021/12/30/log4shell-at-industrial-enterprises/
- CISA Log4j Resource Center: hxxps[://]www[.]cisa[.]gov/uscert/apache-log4j-vulnerability-guidance