OT:ICEFALL Continues: Vedere Labs Discloses Three New Vulnerabilities Affecting OT Products – How to Mitigate
Continuing our OT:ICEFALL research, Vedere Labs has disclosed three new vulnerabilities affecting OT products from two German vendors: Festo automation controllers and the CODESYS runtime, which is used by hundreds of device manufacturers in different industrial sectors, including Festo. As in the original OT:ICEFALL disclosure, these issues exemplify either an insecure-by-design approach— which was usual at the time the products were launched – where manufacturers include dangerous functions that can be accessed with no authentication or a subpar implementation of security controls, such as cryptography.
The table below summarizes the newly disclosed vulnerabilities. The disclosure involved the affected manufacturers and the [email protected], a German security platform for small and medium-sized automation companies.
|CVE ID||Affected Products||Tested Version||Description||CVSS||Potential
|CVE-2022-4048||CODESYS V3||3.5.18||CODESYS V3 before 188.8.131.52 uses weak cryptography for download code and boot applications.||7.7||Logic manipulation|
Festo CPX-CEC-C1 and CPX-CMXX Codesys V2 controllers. CPX-CMXX phased out since 2015
|The affected products allow unauthenticated, remote access to critical webpage functions, which may cause a denial of service.||7.5||
Denial of Service
|CVE-2022-3270||Festo controllers using the FGMC proto col||–||The Festo Generic Multicast (FGMC) protocol allows for unauthenticated reboot of controllers over the network.||9.8||Denial of Service|
These issues are similar to others we have recently disclosed as part of OT:ICEFALL. CVE-2022-4048 is an example of weak cryptography, CVE-2022-3079 exemplifies lack of authentication and CVE-2022-3270 falls in the category of insecure engineering protocols.
We also found that Festo CPX-CEC-C1 controllers and several other Festo devices are affected by known CODESYS vulnerabilities CVE-2022-31806 and CVE-2022-22515 because they are shipped with an unsafe configuration of the CODESYS runtime environment. This is yet another example of a supply chain issue where a vulnerability has not been disclosed for all the products it affects, as we have seen in OT:ICEFALL with CVE-2014-9195 affecting ProConOS.
Below, we discuss each new issue in more detail and provide mitigation recommendations.
Weak cryptography on CODESYS V3
The CODESYS V3 runtime environment offers application encryption to ensure download code and boot applications are encrypted. This encryption can be facilitated by using the Wibu-Systems CodeMeter security dongle (a popular code protection and license management system among OT vendors), in which case the EncryptDownloadCode routine will generate a session key, encrypt it with the dongle key, encrypt the download code with the session key and finally package the encrypted session key and code ciphertext together. This approach suffers from the following issues:
- Session keys are generated using an insecure pseudo-random number generator (PRNG) working off a small and predictable seed. EncryptDownloadCode generates session keys using the dotnet Random Class – which is not a secure PRNG – seeded with the current tick-count, which is predictable and furthermore reduced to 31 bits through a signed integer cast. This session key is then encrypted through interfacing with the dongle component. Next, the session key is used, together with a NULL-IV, to encrypt the download code using AES in ECB mode on a block-by-block basis. Even though the session key is encrypted using the dongle before being shipped with the ciphertext, the session key itself is generated insecurely. Since the effective keyspace is only 31 bits, an attacker can simply brute force the session key to decrypt the downloaded code for manipulation.
- The encryption scheme uses an insecure mode of operation. The code is encrypted in ECB mode without additional cryptographic authentication and integrity over the ciphertext as a whole. This means that both confidentiality and integrity are compromised regardless of session key strength. An illustrative example of the weakness of ECB can be found here.
The impact is that an attacker can trivially decrypt and manipulate protected code.
Three ways to reboot Festo controllers
We identified and reported three ways to reboot Festo programmable logic controllers (PLCs) CPX-CEC-C1 V2 without authentication. By invoking any one of these functions, an attacker with network access to the target device can cause a denial of service condition:
- Accessing the hidden web page cec-reboot.php on Festo CPX-CEC-C1 and CPX-CMXX PLCs. The web page is not documented but can be found on the controller’s filesystem and anyone with network access to a controller can browse to this page, which causes the controller to reboot immediately. This was assigned CVE-2022-3079.
- Sending a specific UDP message to multicast group 184.108.40.206 on port 10002 using the Festo Generic Multicast (FGMC) protocol. This affects several devices that support this protocol, as listed in Festo documentation. The same effect can be obtained with the Festo Field Device Tool, which uses FGMC to communicate with the controller. This was assigned CVE-2022-3270.
- Using the reboot command via the PLC Browser tool. PLC Browser is a text-based monitor for controllers running CODESYS, which allows an operator to issue several commands to the monitored controllers. Reboot is one of the allowed commands sent via a TCP stream when using PLC Browser. The PLC Browser can issue such commands without authentication by default. This vulnerability was already known and previously described by CODESYS advisories as CVE-2022-31806 and CVE-2022-22515. As usual with vulnerabilities on software components (“supply chain” vulnerabilities), there was no indication of which devices were affected by it. Through coordination with Festo and the [email protected], an advisory was published about the effects of those vulnerabilities on Festo controllers and how to mitigate them.
Distribution of CODESYS and Festo devices
The official website of CODESYS describes it as the leading IEC 61131-3 automation suite, running on several million devices of approximately 1,000 models from over 500 manufacturers. Examples of manufacturers using the technology on their products can be found on this link. These devices are used in industries such as manufacturing, energy automation and building automation. Although these devices are typically not supposed to be exposed online, we see almost 3,000 devices running CODESYS when querying the Shodan search engine (“port:2455 operating system“), as shown in the figure below.
Festo CPX is an automation platform for electric and pneumatic systems. CPX-CEC-C1 and CPX-CMXX controllers ran CODESYS V2, while newer versions run CODESYS V3 and provide capabilities for Industry 4.0, such as remote I/O and cloud connection. On the Forescout Device Cloud – a repository of data from 19 million devices monitored by Forescout appliances – we see close to 1,000 Festo controllers, used overwhelmingly within manufacturing.
Mitigation strategy: discover, segment and monitor
Complete protection against these vulnerabilities requires patching devices running the vulnerable firmware (CVE-2022-4048), replacing with newer equipment (CVE-2022-3079) or changing default configurations (CVE-2022-31806 and CVE-2022-22515). Vendor-specific mitigations can be found on the published security advisories:
- CVE-2022-4048: CODESYS security advisory 2022-15
- CVE-2022-3079: FSA-202207 / VDE-2022-0036
- CVE-2022-31896 and CVE-2022-22515: FSA-202208 / VDE-2022-0037
- CVE-2022-3270: FSA-202209 / VDE-2022-0041
Given that patching or replacing OT devices is notoriously difficult due to their mission-critical nature, we recommend the following mitigation strategy:
- Discover and inventory vulnerable devices. Forescout has included these vulnerabilities in the November release of the eyeInspect vulnerability database, so that vulnerable devices on a monitored network can be automatically identified.
- Enforce segmentation controls and proper network hygiene to mitigate the risk from vulnerable devices. Restrict external communication paths and isolate or contain vulnerable devices in zones as a mitigating control if they cannot be patched or until they can be patched.
- Monitor all network traffic for malicious packets that try to exploit known vulnerabilities or possible 0-days. Anomalous and malformed traffic should be blocked, or at least alert its presence to network operators. Forescout has developed an eyeInspect script specifically designed to monitor CODESYS V3 traffic and potentially dangerous operations using the protocol, including changes to a PLC’s logic that would be done by exploiting CVE-2022-4048.