There was first shock and then sympathy for ICS-CERT Acting Director Marty Edwards’ statement at WeissCon that only software bugs are treated as vulnerabilities by ICS-CERT. The important converse of this statement is any exploitable security weaknesses that are intentionally part of the design would not be addressed by ICS-CERT.
Starting with the sympathetic argument, almost all ICS protocols lack effective source and data integrity controls. If the PLC receives a plaintext, unauthenticated command, it will act on it. An attacker with logical access and a protocol client can turn things on and off, change settings, stop unsolicited response and cause all sorts of havoc. Treating the lack of security protection in the protocol as a vulnerability would mean that ICS-CERT would need an advisory on virtually every field device sold over the past twenty years.
This may explain the lack of attention paid to the Siemens S7 protocol-related exploits in Beresford’s vulnerabilities. An exploited password authentication scheme on ladder logic change commands is listed as an exploit, but no password or other authentication required on write commands is not considered a vulnerability by ICS-CERT. This makes no sense, and results in the often uttered phrase in the ICS space that “I don’t need a vulnerability to compromise a PLC because they are insecure by design”.
Is a hard coded password a vulnerability? Is an unprotected administrative or debugging back door a vulnerability? Both of these examples are not software bugs. They were specified, implemented and working as designed.
There is another case first brought up by DHS and INL prior to ICS-CERT – the Boreas Vulnerability. They highlighted that many field devices had no source or data authentication on firmware upload. As I’ve noted numerous times, Daniel Peck did a proof of concept exploit demo of this at S4 for a couple of PLC’s.
It makes little sense for ICS-CERT or any owner/operator to ignore insecure by design, especially if it is the easiest way to exploit the device. Do we really want vendors focusing on caulking the windows when there is no roof on the building? This is not an argument for vendors to stop fixing vulnerabilities arising from software bugs; it is an argument to also put a roof on the building and no longer be insecure by design.
So what should ICS-CERT do?
My suggestion is ICS-CERT should issue advisories for protocol vulnerabilities and other common vulnerable by design issues and then reference them in any product specific advisories as applicable. So there would be a Modbus TCP advisory, a DNP3 advisory, an unauthenticated firmware upload advisory, a Siemens S7 advisory, etc. The Beresford vulnerability advisories would focus on the software bugs but also reference the Siemens S7 advisory.
If these protocol and common vulnerability advisories existed owner/operators could take the next step of asking their vendors which of these advisories apply to their products, certainly during procurement. This would also be a great session for a user group meeting. What advisories apply and what is the vendor doing to address them in the product plan?
I’ll be on the ICS-CERT vulnerability panel at ICSJWG. This is not what I will talk about directly, but it is related.
Image by misteraitch