ICS Protocols Make New GE D20 RTU Still Insecure By Design

The GE D20MX RTU is the latest example of a brand new, top of the line ICS field device that can be easily be compromised because the ICS protocols it supports are insecure by design. Who cares about security features, and even vulnerabilities, if an attacker can use device and protocol features to compromise the availability and integrity of the device and process being monitored and controlled?

Give GE some credit that the protocol stack is much more robust and not easily crashed with fuzzing. GE also has removed the previously identified methods to upload rogue firmware and added some security around firmware upload/download.

Even more important is the GE D20MX is running on a modern platform that can be upgraded. Pity the owner/operators who bought the previous D20 model in recent years. The old platform running 80′s and 90′s components and software was a dead end. It could not be secured even if GE wanted to. The D20MX platform should be upgradable for secure protocols and other security improvements in the future.

Upgrades will be necessary as the current ICS protocols the D20MX are insecure by design. For new readers we refer to ICS products as “insecure by design” if a vulnerability is not required to compromise the product because product and protocol features provide all an attacker would need.

An example in the newly released D20MX is related to the IEC-60870-5-104 protocol. Below is a screen capture from the D20MX 104 DPA (Slave) manual.

GE D20MX

The 101 and 104 protocols allow transfer of files.  Most vendors use this feature of 101/104 for transferring event reports, but there are not limitations on what is transferred. An attacker could transfer configuration files, and it looks like a file can be uploaded into any Information Object Address. We are told that the flash code image cannot be transferred via this protocol and the table is in error. It’s worth a test though.

And of course the kicker is the 101 and 104 protocols do not support an authentication mechanism. To develop a proof-of-concept, you’ll need to find a copy of the 60870-5-101 spec series ($$$) or even easier do a packet capture showing how file transfer over that protocol works.

Other supported protocols have variations of this insecure by design protocol problem. We didn’t see evidence in the manual or literature of support for DNP3 Secure Authentication, one of the few ICS protocols with integrated security. Hopefully this upgrade will be available soon.

So who is to blame for this pervasive problem? Probably everyone.

The vendors can and do claim they will offer secure protocols when customers ask for it, but a product like the D20MX promotes its security features and CIP compliance rather than the fact it is insecure by design. If called on this by a savvy customer, they fall back on a flawed defense in depth argument and other security guidance that essentially says don’t let the bad guys get to our RTU. You would hope a vendor would implement a secure protocol and then stress to security conscious customers to use it. This is not however in their best business interest.

The asset owner should be, and often is, smart enough to understand their PLC, RTU and other controllers are insecure by design. A very small percentage chooses to address this issue, and it has not been enough to drive the vendors for solutions. Most operations teams are supported in this malfeasance by the fact that everybody else is doing the same thing … living with an ICS that lacks integrity and can easily be taken down.

The asset owner is also supported by a conspiracy of silence perpetrated by the automation press, vendors, industry organizations and government organizations (DHS et al). They all say critical infrastructure is essential, but they never actually say out loud these insecure by design devices and protocols need to be replaced or upgraded now. Watch my NOW mini-keynote to get more rant on this.

The glass is half full view of all this is that the GE D20, an important, widely deployed field device, now joins RA’s ControlLogix, Siemens’ S7 and many other systems that at least have the hardware platform that could be secured in the future.

2 comments to ICS Protocols Make New GE D20 RTU Still Insecure By Design

  • Most vendor DNP3 products don’t even get conformance tested anymore, let alone security tested. Some customers do ask for these features, but the vendor already owns them for the life of the product and is no rush to implement it.

    Do we really want many vendors independently implementing a complex standard on very limited budgets? I doubt managers will give the engineers enough time to do the required amount of testing. I am more and more convinced that robust OSS is the only quick way forward with SA adoption.

    If there’s something out there for free that’s provably more secure and robust than your own implementation, what excuses do you have?

    -Adam

  • Not only the file transfer is not authenticated in the 60870-5-101/104 protocol, but also all other commands like read or set point. 60870-5-101/104 (and DNP3) can be crypthographically secured by IEC 62351-5, which is basically TLS. However, I don’t know any device on the market yet which supports IEC 62351-5 (maybe the D20MX is the first?).

    A well-known vendor told me, the implenmented 62351-5 in on small scale SCADA system. No customer wanted to buy that feature. But if there is no RTU / controller on the market with 62351-5 support that is quite comprehensible.

Leave a Reply