1 Update Published – 9-24-20

 Today the CISA NCCIC-ICS published an update for a control system security advisory for products from 3S.

CODESYS Update

This update provides additional information on an advisory that was originally published on January 11^th, 2013. The new information includes:

• Adding CODESYS Control RTE to list of affected products,

• For CVE-2012-6068, replaced the ‘CVSS v2 base score of 10.0’ with the ‘CVSS v3 base score of 9.8’ along with the associated changes in CVSS vector string, and

• For CVE-2012-6069, replaced the ‘CVSS v2 base score of 10.0’ with the ‘CVSS v3 base score of 10.0’ along with the associated changes in CVSS vector string.

The update is a bit more complicated than that as NCCIC-ICS partially updated the format of the advisory to reflect a number of editorial changes made in the last seven years.

Commentary

Okay, a little background is in order on this ancient (in cyber years, but not as ancient in control system years) advisory. The CVE-2012-6068 vulnerability was initially reported by Reid Wightman at AppSec DC in April 2012. Dale Peterson has an excellent write up of the importance of this vulnerability over on DigitalBond. ICS-CERT published an Alert about the vulnerability on April 6^th, 2012 and then updated that Alert on October 26^th, 2012 to reflect the publication of two exploit tools by Reid. Eventually (January 11^th, 2013) ICS-CERT upgraded the Alert to the Advisory that was updated today. Oh, BTW, the 3S advisory for these vulnerabilities is no longer on their Security Reports web page; they only go back to February 14^th, 2017.

It seems a little more than odd that 3S would add a product to the affected product list seven+ years later. They either just now realized that the product was affected even though it was apparently ‘fixed’ at the same time as the other two affected products were, or they knew all along and just did not want to tell anyone about the problem in that product since it had not been identified by Reid. In either case it just emphasizes the apparent lack of concern at 3S about device security. And that is very disconcerting given the number of other vendors that use these affected products.

More on Yokogawa Advisory

There was an interesting Twitversation yesterday about the Yokogawa advisory that ICS-CERT published Thursday. I noted that Yokogawa was to be commended for self-reporting the vulnerabilities. Dale Peterson from DigitalBond noted that the security note published by Yokogawa credited Rapid7 and another researcher with reporting the vulnerability.

Readers of my blog post will recall that I quoted from the Yokogawa report, so I was surprised that I missed their researcher acknowledgement. I opened up the document referenced in Dale’s Tweet® and it surely does credit Juan Vazquez of Rapid 7 and Julian Vilas Diaz with reporting the vulnerability. The only problem is that that report is from March of 2014 and is not the document referenced in the latest ICS-CERT advisory. The report that Dale referenced is related to an ICS-CERT advisory from May of last year.

The new advisory (from either ICS-CERT or Yokogawa) does not provide enough details about the individual vulnerabilities to determine if they are the same vulnerabilities reported last year. A closer look at the two lists of covered products, however, does show that, for some of the listed products at least, newer versions of the products are affected by the newer advisory.

In any case, it is clear that Yokogawa has done a great deal of work internally to identify the wide variety of products affected by these three buffer overflows. That kind of product line investigation takes time and resources and Yokogawa is to be commended for investing that kind of effort in the internal security research effort.

Reader Comment – FDA and Cybersecurity

Last night a long time reader and respected ICS security professional Dale Peterson took exception to my comments about the FDA response to the Hospira Infusion Pump vulnerabilities. He noted (in part, please read his entire comment) that:

“Yes they were late to the party and are not perfect, but they have issued guidance and provided rulings that are quite impressive given the short time they have been working on the issue.”

I will admit that I haven’t paid a great deal of attention to the FDA’s response to cybersecurity issues. I have only done three blog posts on the topic (here, here and here) and made some unfavorable comments in one other post about medical control system advisories from ICS-CERT (here). And I have not looked at the FDA regulations to see what authority the FDA does actually have in this respect. So, I’ll bow to Dale’s (and Billy Rios’) larger experience set with the agency and accept that the FDA may be making an honest effort to get their control system security program up and running.

Having said that, I am still very concerned that the FDA has not been more forthcoming in sharing information with the medical community about the control system security issues with this infusion pump. I understand that a full recall of these devices may put many hospitals, clinics, and doctors in a position of not being able to provide critical medical services, but at the very least there should have been some sort of notice to the medical community published yesterday in conjunction with the ICS-CERT advisory. It’s not like the average hospital IT department routinely monitors the ICS-CERT web site (Hell, I don’t expect that most ICS owners do that; that is the whole point of my blog posts on each advisory).

Now I understand that the federal government has the same problem that most large organizations have (scaled-up due to size of course) that there are too many silos and not enough communication between them. Cybersecurity is just one area where that lack of communication is readily apparent.

ICS-CERT does not have the authority (and certainly not the manpower) to regulate control system security in any sector. The one thing that they are supposed to be doing (by convention anyway, certainly not by law or regulation) is to be coordinating vulnerability disclosure. Most of us have assumed that coordination was between the researcher who discovered the vulnerability and the vendor who needed to resolve the issue. It seems like, in this instance in any case, that that coordination also included some conversations with the FDA since ICS-CERT reported that the FDA was reviewing the new software version. If that coordination with FDA did take place ICS-CERT is to be commended.

The FDA on the other hand, seems to have limited their response to that review process (a valuable and necessary thing in its own right). It seems to me, however, that they have at the very least a moral responsibility and probably a legal responsibility to communicate to the medical community (at least) the medial device vulnerability that potentially puts patients at risk. If there is not a legal responsibility to do so, the Congress needs to act immediately to rectify that situation (won’t happen, I know).

To be fair to the FDA, they are not the only organization that has this problem. You can pick just about any major agency in the federal government that has some dealing with control systems and you will see similar problems. This is the real information sharing conundrum that plagues cybersecurity issues; even when the federal government has information about vulnerabilities and mitigation measures, they don’t do an effective job of sharing that information with people who actually own the systems involved.

Okay, enough for today’s rant. Again, the FDA is apparently attempting to get its act together about medical device control system security; kudos for that. But I remain disappointed in their lack of effort to share what information they do have with the medical community.

More Info on Recent ICS-CERT Advisories

ICS-CERT has been busy this week. They updated an alert on Tuesday and issued two advisories yesterday. In two of those three actions there were some interesting questions raised about some of the information provided, or not provided in their documents. Since then some additional information has been made available.

When is a Vulnerability not a Vulnerability?

 When ICS-CERT declared that two of the vulnerabilities reported on the Schneider Electric systems during the recent S4 Conference in Miami were not actually vulnerabilities, I thought it kind of odd that a security researcher could make that kind of mistake. I mentioned it in passing in my blog post, but figured that someone else with more experience in the technical side of things would tackle the issue. Sure enough, Dale Peterson had something to say about the issue on the Digital Bond's SCADA Security Portal. It is well worth the read, but have a fire extinguisher handy, Dale is hot.

Quality of Write Ups

In last night’s post about the recent Emerson advisory I had some questions about some things that had been left unsaid in the advisory. Fortunately, Joel Langill (the researcher on the Emerson vulnerabilities) and I have had a number of informational exchanges over the last couple of years, so I asked if he would like to comment on those questions. Sure enough he did. He posted a very detailed comment on that blog post that all should read. He answered my questions and gave some good insights into the vulnerability disclosure/response process. It is well worth the read.

Responsible ICS-CERT

ICS-CERT provides the control system community with a valuable service. Among other responsibilities they act as a clearing house for information on vulnerabilities and their mitigations. Given their budget, number of people on staff and their other important tasks, they do a pretty damn good job. But they have to be careful.

People look at what they say and don’t say in their reports. If they say that one part of a mitigation has been verified but don’t mention the verification status of another part, people can only assume that it hasn’t been verified. That doesn’t help the vendor restore confidence in their system.

And if they publish a vendor’s counter-claim on a vulnerability without giving the researcher a chance to respond, they are going to look like they primarily serve the vendors, not the control system community.

No one is going to be happy with ICS-CERT all of the time, but more attention to the detail that they do put into their alerts and advisories would help maintain their status as a valuable resource to all parts of the control system security community, particularly the system owners and operators.

Offensive Cyber Weapons – Construction, Development, and Employment

Thanks to a TWEET® from Thomas Rid yesterday I had a chance to read an article by Dale Peterson in the Journal of Strategic Studies about offensive cyber-weapons. Now if you have been reading Dale’s blog at DigitalBond for the last couple of years like I have, there really isn’t much new information here; but he has brought a great deal of information together here in a way that hasn’t been done before. More importantly, he has brought the information to a completely new audience; an audience that really needs to understand just how easy it is to construct a cyber-weapon to attack industrial control systems.

Insecure By Design

People in the control system security community are certainly aware of Dale’s almost patented phrase ‘insecure by design’. Not surprisingly Dale opens his article with a discussion of this concept. Using the Stuxnet example he explains:

“The purpose of Stuxnet was to load a program onto the Programmable Logic Controller (PLC) that controlled the centrifuges at the Natanz fuel enrichment plant. The attackers developed various Windows exploits in order to gain access to the network that the PLCs were on. But once access was gained, no attack code was required to load the cyber weapon onto the PLCs. The Siemens S7 PLC has no source or data identification so any attacker with access to it can load his own program, tell the process to stop, reboot the PLC, or whatever else is desired.”

Three Weapon Types

Dale addresses the issue of the complexity of industrial control systems being a sort of cyber-defense, by noting that there are three different types of attacks that can be initiated depending on the knowledge the attacker has about the control system. Basically they can be described as:

• Simple Weapon – The “attacker uses the lack of authentication to cause the system to crash or operate incorrectly”;

• Moderately Complex Weapon – The “attacker learns about the process and determines how to destroy a physical component or subsystem that will take time to replace”; and

• Complex Weapon – The “attacker modifies the process in a stealthy manner so a cyber attack is not suspected”.

He goes on to give a brief example of how complex a ‘simple weapon’ can be made using a worm to reprogram firmware in a ControlLogix PLC that produces intermittent process failures. As a process chemist this is my most feared type of attack because random failures will be almost impossible to detect as an attack. Unless the facility engineering team has reason to suspect a cyber-attack they will waste untold man-hours trying to track down the root cause of their apparently unrelated process problems while the facility becomes an economic wreck.

Weapon Deployment

Dale notes that cyber-weapon deployment is actually more difficult in most cases than is the development of the actual attack code. This is because most critical cyber-targets are going to be electronically isolated from the easiest attack vector, the internet. Dale briefly describes a variety of common methods of getting the electronic weapon payload into the targeted system. Unfortunately, to my mind, he only mentions in passing the most likely method to be employed against most Western nations; spear phishing.

Because of the difficulties in gaining electronic access to the most important targets the most effective method of deployment is advanced deployment of the electronic payload and then subsequently activating the weapon at the most opportune time. This requires some sort of ‘command and control’ communications link. Dale spends some time describing some of the techniques that are available to achieve these communications.

The Audience

As I noted earlier, Dale is focusing this paper on a different audience than he normally attracts to his blog or his business. Given the publication, it is obvious that he is targeting the planners and politicians that will be either deploying cyber-weapons or defending against them. With that audience in mind, I think he has achieved a reasonable level of technical detail in his presentation. I think he has successfully avoided the pitfalls frequently encountered when a technical expert describes a problem for a non-technical audience.

Most readers of this blog are not going to find anything new here, but I do recommend that anyone in the control system business; including owners, vendors, and integrators, should send a copy of this article to their legislative representatives in Washington. With cybersecurity being an important political topic in the coming months, this article might help to favorably inform the lawmakers about the real cybersecurity problems facing this country.