Control Systems: Insecurity All The Way Down
INL researcher and famed ICS hacker Jason Larsen gave a much-buzzed talk at S4x14 in January that's deserving of more attention.
Jason presented his famous "Triangles" talk, which introduces a novel data spoofing technique that provides realistic sensor jitter in a very tiny amount of code.
You can watch his talk here.
Sorry to run with the Triangle theme, but Jason's talk really illustrates the third point of control systems insecurity.
First, we had Stuxnet, which showed that PLCs have no process control integrity. That is, a PLC can modify process control data as represented to the HMI. Without using a tool like Langner's Control Integrity Checker, you can't really know whether the logic your PLC is running is the logic you're expecting (thus, you can't know if you've had this attack performed against you). The downsides to using the CIC are that a PLC rootkit could hide malicious ladder logic from the checker, and of course CIC has to be implemented for your PLC if your PLC is not made by Siemens.
Next we had my own silly proof-of-concept, the Modbus VCR. The Modbus VCR could be detected easily enough -- either through ARP poison detection or by doing what I call a Process Abnormality Monitor (PAM). PAM as I envisioned it would be a separate read-only system that monitored the Fieldbus protocol to the sensors themselves. It would also monitor the PLC's upper-level protocol. It would alert if there was a discrepancy between the process image as seen on the Fieldbus, and the process image as reported to the HMI or whatever server. It would be an enormous programming and development undertaking though: it would have to be able to parse your project data so that it could map the field device inputs into an identical system state map as what your PLC used.
Also, PAM could be circumvented -- precisely by Jason Larsen's technique. His technique uses a tiny amount of memory (~200 bytes) to generate realistic-looking process jitter inside the sensors themselves. The only way to detect this kind of attack would be to use JTAG against the sensor and verify that its firmware was genuine. This means that an attacker could do what they want to your control system's outputs, and your inputs would make it look like everything was operating normally.
The problems are many.
- Our upper-layer protocols (as reported from the perspective of a PLC or RTU) such as Modbus and DNP3 (without SA) provide no data integrity.
- PLCs themselves lack data integrity; most ladder logic implementations allow for direct manipulation of input variables (a time machine wish would be to force ladder logic programmers to assign manipulated values to virtual inputs).
- Finally, sensors lack integrity. Their firmware can easily be modified to provide false data.
All three are problems that need to be solved. Let's get to work:
- Introduce SSL to upper-layer protocols. This requires only a little bit of willpower on behalf of vendors and end users.
- Hardware really should implement firmware signing, secure boot, and basic hardware security (burning JTAG fuses during manufacturing, for example) for all PLCs and sensors. While it's a little tricker to pull off, it will also protect the vendor's important intellectual property from hardware knockoffs.
We've had the technology to solve these ICS problems for over a decade, but little will to actually implement them. If not now, when?
image by wwarby
TrackBack URL: http://www.cyberpacifists.net/mtype/mt-tb.cgi/596