CyberX has discovered critical vulnerabilities in a popular software framework used in potentially hundreds of thousands of IIoT and industrial control system (ICS) devices.
The vulnerabilities affect all devices incorporating CODESYS Web Server v2.3 and prior, which is part of the CODESYS “WebVisu” visualization software developed by 3S-Smart Software Solutions GmbH. CODESYS is a hardware-independent middleware layer for programming IIoT and industrial control system (ICS) devices such as Programmable Logic Controllers (PLCs) and Human Machine Interfaces (HMIs).
The devices are used in nearly all critical industrial infrastructure environments including power plants, manufacturing plants, oil & gas installations, chemical and pharmaceutical factories, and building automation systems that control HVAC and elevator systems.
Attackers could exploit the vulnerabilities to install back-doors, perform industrial cyberespionage, deploy ransomware, and execute cyber-sabotage operations to disrupt production or cause catastrophic safety failures and environmental damage. (Similarly, Stuxnet exploited a total of 7 vulnerabilities to destroy Iranian centrifuges.)
Last week, ICS-CERT published an advisory (ICSA-17-087-02) validating the vulnerabilities that CyberX uncovered and assigning them a CVSS risk score of 9.8 out of 10, which is considered “CRITICAL.” The extreme risk score applies because an attacker with low skill can remotely exploit these vulnerabilities over the network — without requiring credentials — and because they provide the attacker with all-powerful Remote Code Execution (RCE) capabilities.
The two vulnerabilities are:
- CVE-2017-6027: A specially crafted web server request may allow the upload of arbitrary files to the CODESYS Web Server without authorization, which may allow remote code execution.
- CVE-2017-6025: A malicious user could overflow the stack buffer by providing overly long strings to functions that handle the XML. Because the function does not verify string size before copying to memory, the attacker may then be able to crash the application or run arbitrary code.
There are several ways for cyberattackers to reach CODESYS-based devices to exploit the new vulnerabilities:
- The Mirai Approach: Use Shodan to look for vulnerable devices that are directly connected to the Internet; then upload malicious files followed by sending specially-crafted packets to cause the buffer overflow.
- The Stuxnet Approach: Leverage insiders or contractors that connect directly to the Operational Technology (OT) network via a laptop or USB drive that has been infected with malware that exploits the vulnerabilities.
- The Black Energy Approach: Send phishing emails to employees of targeted firms; compromise their PCs on the IT network; and then pivot to the OT network via unauthorized connections between IT and OT networks. Attackers can also pivot to the OT network by exploiting vulnerabilities in firewalls separating IT and OT networks, or by exploiting vulnerable firewall rules.
The CODESYS framework was first developed in 1994 by 3S-Smart Software Solutions.
Similar to widely-used open source components such as Linux, it’s popularity stems from being based on an industry standard (IEC 61131-3) and supporting most major programming languages, CPU families (x86, MIPS, ARM, etc.), and industrial networking protocols (Modbus, PROFINET, Ethernet/IP, etc.).
The company’s website states that more than 1 million CODESYS-based devices are sold each year — from more than 400 manufacturers including major vendors such as Hitachi — but it’s impossible to determine how many of them are using this particular component.
3S-Smart Software Systems released a new version of CODESYS in 2006 (v3) but the company’s website states that “many devices that are programmable with CODESYS V2.3 are [still] being used daily.”1
“Forever Day” Vulnerabilities
Device manufacturers can download a patch from the vendor (V.220.127.116.11) — but this won’t help end-user organizations in the short-term. The patching process is complicated by a number of factors:
- Unlike a zero-day in a particular device from a given manufacturer, this vulnerability exists in a common framework embedded in many devices from multiple manufacturers. In that sense, it’s more similar to the Apache STRUTS and Heartbleed vulnerabilities. (The widespread use of a vulnerable component also increases the attack surface and therefore the appeal to cyberattackers.)
- Each device manufacturer must first apply the CODESYS patch to their own code, then recompile the firmware, and then send a firmware update to their end-users. The CODESYS patch can’t be installed by end-user organizations.
- Most devices require firmware to be “reflashed,” which is a lengthier and more complicated process than standard software updates on your phone or PC.
- Devices typically reside in environments that run continuously — such as transformer stations, steel mills, and sewage treatment plants — and can only be interrupted occasionally for maintenance updates.
As Dan Goodin described in an ArsTechnica article a few years ago, “the complexity of fixing security bugs in industrial control systems has led to the term ‘forever day vulnerabilities’ because manufacturers often consider the process too difficult to carry out in many environments or on older products.”
Not if, But When?
According to international ICS cyber expert Joe Weiss, “there have been many stories about cyber vulnerabilities of critical infrastructure with the tagline – not if, but when. However, there already have been many targeted cyber attacks against critical infrastructures, from attackers ranging from disgruntled individuals to nation-states … [these attacks] have been identified in Australia, Brazil, Canada, China, France, Germany, Iran, Israel, Lithuania, Netherlands, Poland, Qatar, Russia, Saudi Arabia, South Korea, UK, Ukraine, and Venezuela.”
Joe concludes by saying that “there is a need to focus on resilience and recovery as malware is already in many control system networks.” He also writes that the tagline for stories about targeted ICS attacks should be “not when, but how much damage” rather than “not if, but when.”
How We Found These Vulnerabilities
CyberX’s industrial cybersecurity platform monitors IIoT and ICS networks in some of the largest industrial environments worldwide.
Many of our customers use CODESYS-enabled automation devices in their OT networks. Our Threat Intelligence Research team began investigating the code in our lab and once we uncovered the vulnerabilities, immediately submitted them to ICS-CERT as part of our responsible disclosure process. CyberX has not identified any known exploits or active campaigns targeting this vulnerability.
Mitigating the Risk
Remediating these vulnerabilities is a difficult process that may take years to do right, so here are a few obvious best practices for mitigating the risk in the meantime:
- Ensure ICS systems and devices are never directly exposed to the public Internet.
- Isolate ICS systems and devices from corporate IT networks using firewalls. Keep the firewalls patched and check regularly for vulnerable firewall rules.
- Create subnets to isolate vulnerable ICS devices from other systems and devices on OT networks, in order to minimize the impact of a potential compromise.
- Implement continuous, real-time network monitoring and behavioral anomaly detection to quickly identify suspicious or unauthorized activities on your OT network.
1 The device directory on the CODESYS website no longer shows which products are using v2.3, but when we look at archived versions of the company’s website via the Wayback Machine, we find that, as of mid-2016, about 55% of all products listed in the company’s device directory were using the vulnerable version (WebVisu V2.3).