New SCADA Vulnerability Enables Remote Control of ICS Networks
- Oct 26, 2016 9:30 pm GMTOct 26, 2016 9:24 pm GMT
- 1917 views
As part of our ongoing R&D efforts we occasionally discover vulnerabilities in industrial controllers (PLCs, RTUs, DCS etc.) and software tools. Recently, Indegy Labs team discovered a vulnerability in Unity Pro, Schneider Electric’s flagship software application for managing and programming industrial controllers. Before we get into the specifics, it’s important to point out that unlike in IT networks, a vulnerability is not necessarily required to compromise controllers in an ICS network. That’s because:
- Industrial controllers lack authentication
- Industrial communication protocols lack encryption
Surprising as it might sound, anyone who has access to the control network, also has unfettered access to all of its industrial controllers. This means that anyone who can ping a controller, can probably send a it stop command or reprogram the device to cause operational disruptions.
Nonetheless, some vulnerabilities can pose exceptional risk to ICS networks.
The vulnerability in Unity Pro allows any user to remotely execute code directly on any computer on which this product is installed, in debug privileges. The vulnerable software tool is present in every control network in the world that uses Schneider-Electric controllers. Regardless of the SCADA/DCS applications in use, if Schneider Electric controllers are deployed, this software will be used on the engineering workstations. This makes this attack relevant across virtually any process controlled by these PLCs. Since Schneider Electric is one of the largest industrial control equipment providers, this vulnerability is a major concern.
As a result of Indegy’s responsible disclosure, Schneider Electric has published an important secuirty notification and developed a new release of its product which fixes this vulnerability.
The Unity Pro software platform runs on Microsoft Windows machines. The vulnerability found affects all versions of this software, including the latest one. It resides in one of its components named ‘Unity Pro PLC Simulator’, that is used to test industrial controllers’ code prior to executing it on the controllers themselves. The control code projects are compiled as x86 instructions and loaded onto the PLC Simulator using a proprietary format named ‘apx’.
Since these x86 instructions are later executed ‘as is’ by the simulator, an attacker can direct their control flow to execute arbitrary malicious code. As bothersome as this might sound (being a somewhat ‘classical’ data/code mixture), the knock-out is that receiving .apx files from a remote location to execute them on the simulator is natively supported by the Unity Pro software platform!
Schematic Industrial control network architecture
To implement the attack, no patching of the simulator process at any stage is needed, only the .apx file is being patched.
To build such an .apx file, the attacker needs to create a large project file with enough random binary PLC code, and then replace it with the combination of bridgehead shellcode and malicious payload. To preserve the integrity of the file, the attacker then needs to overcome several checksum calculations. Finally, the specially crafted project file is downloaded to the simulator remotely over a TCP port, which is open by default. There are few available implementations allowing one to download an .apx file to a simulator or a controller without wrapping it with the file format used by Unity Pro (though this path could be taken as well, which will result in a weaker attack). The latter is done by imitating Unity Pro’s communication protocol with the controllers.
The vulnerability in the simulator component of Unity Pro enables attackers to natively access industrial controllers and use a manipulated .apx file to execute malicious code. Since the delivery of the .apx file is an engineering control-plane activity, executed over a proprietary protocol, it is difficult to identify and detect.
The use of proprietary protocols for control-plane activities is a common yet misunderstood practice in ICS networks. Unlike IT networks where data-plane and control-plane activities are executed over the same communication protocols, in ICS networks different protocols are used for these activities.
Widely known protocols like MODBUS, PROFINET and DNP3, are all data-plane protocols. However, this is not where dangerous manipulations to ICS/SCADA networks and industrial controllers take place. The control-plane activities, which include all engineering and management activities performed on controllers (PLCs, RTUs) are executed over proprietary, vendor specific protocols which are unnamed, undocumented, and unmonitored.
To identify such attacks and ensure the integrity of critical control devices, the proprietary control-plane protocols of ICS networks must be monitored.
The simulator process, running with administrative privileges, binds Modbus port to 0.0.0.0.
Patched APX file with shellcode to run Calc.exe (Original file on the left, patched on the right)
Post-exploitation. Calc.exe running, spawned as simulator child-process (calc was passed from the attacking computer as well, so arbitrary code can be executed)