ICS-CERT Publishes 2nd Crain-Sistrunk Advisory for MatriconOPC

This afternoon the DHS ICS-CERT published an advisory for MatriconOPC for an improper input validation vulnerability reported by Crain-Sistrunk in a coordinated disclosure. This is the second Crain-Sistrunk vulnerability reported in this service. ICS-CERT notes that MatriconOPC has produced a patch which have been evaluated for efficacy by Adam Crain and has been found to resolve the vulnerability.

The Vulnerability

ICS-CERT reports that a moderately skilled attacker could remotely exploit this vulnerability to cause a denial of service (DoS) loop in the MatriconOPC server (master station). It doesn’t look like this is your father’s DoS attack though:

“This only happens after the server (master station) successfully connects to a device (outstation) that returns a malformed DNP3 packet. The process never recovers and cannot be shut down. The Windows operating system on the master station would have to be rebooted to reestablish communications. After the service has been put in a DoS condition, the configuration tool experiences a read access violation on further reboots.”

This sounds like a DoS that lasts until a service technician arrives on scene to replace the MatriconOPC server.

MatriconOPC Support??

The advisory states that you can get the MatriconOPC Security Notification for this vulnerability from the MatriconOPC Support Center (Follow the link, Click on ‘Product Advisory’ and then Click on the Security Notification. Unfortunately there is no Security Notification for this vulnerability; two for the earlier Dillon Beresford advisory and the one for the earlier Crain-Sistrunk advisory, but none for this advisory.

Another TMW Derived Advisory

Adam Crain added this little tidbit of information about this vulnerability today in a Tweet®:

@jadamcrain @ICSCERT @SCADAhacker Unsafe API design from TMW library results in yet another integration vulnerability.

Adam is referring to the Triangle MicroWorks advisory from last summer (another Crain-Sistrunk DNP3 advisory) that included problems with the DNP3 ANSI C source code libraries, v3.06.0000 through v3.15.0000 that got passed on to whom ever had used vulnerable items from that library.

This means that the particular Crain-Sistrunk DNP3 vulnerability could exist in other vendor products; potentially allowing other products to be semi-permanently shut down with this cute little DoS attack vector. NOTE: I apparently misinterpreted what Adam was saying in his TWEET. See his comment below. [Added 10:30 pm CST]

BTW: This little fact was missed by the ICS-CERT Advisory.

Project Robus Update

I have to confess usually I only get to the Automatak Project Robus site when there is a Crain-Sistrunk advisory published. They are now up to 28 coordinated disclosures on DNP3 vulnerabilities (and this is the 17^th to be published by ICS-CERT) and 1 Modbus TCP vulnerability that we can expectantly wait to see who next falls to the mythical Automatak Fuzzer.

Yet Another Crain-Sistrunk-Todorski DNP3 ICS-CERT Advisory

This afternoon the DHS ICS-CERT published an improper input validation (DNP3) advisory for the Elecsys Director Gateway application. The vulnerability was reported by Crain-Sistrunk-Todorski (newest member of the team) in a coordinated disclosure. Elecysy has developed a patch to mitigate the vulnerability and the patch has been validated by Adam Crain.

ICS-CERT reports that a moderately skilled attacker could remotely exploit the vulnerability to “to affect the availability of the DNP3 master slave communication in Elecsys Director Gateway

Devices”.

In addition to the patch, ICS-CERT notes that: “Because this vulnerability is identified with fuzzing tools, the researchers suggest developers use extensive negative testing during quality control of products.” Hmm. Adam has been saying this on his web site for about six months now; I wonder why ICS-CERT has now picked up the refrain.

BTW: Adam has not changed the count of advisories on the Robus web page. A tweet today mentioned this as a “mini advisory” so maybe this isn’t included in the count of 25 advisories that have been coordinated to-date. Or maybe Adam just got tired of counting coup; no challenge anymore.

ICS-CERT Updates Master DNP3 Implementation Vulnerability Advisory

Just a little over a month ago ICS-CERT took the unusual step of posting a master advisory covering 9 separate advisories for essentially the same input validation vulnerability in different systems. Anyone with rudimentary prognostication skills could have predicted that when ICS-CERT published two more advisories in the series, they would be morally required to update the list of included advisories. They did that today; published the –A version and added Catapult Software and GE to the list.

There are going to be at least 14 more advisories according to the Project Robus web site and Adam Crain admits they stopped counting, so it may be 15 or more yet to come. That ‘or more’ comes from the fact that multiple vendors have used the library identified in the Triangle Microworks advisory and they may/should self-report the vulnerability after they apply the fix developed by Triangle Microworks.

Oh yes, and Crain-Sistrunk are supposed to be presenting at Digital Bond’s S4x14 and will be discussing the fuzzing technique they’ve used to identify these vulnerabilities, so who knows how many other people will start looking for, finding and reporting these vulnerabilities.

We just might get to a –AA or –BB version of this advisory yet.

ICS-CERT Publishes DNP3 Summary Advisory

Today the DHS ICS-CERT took the unusual step of issuing an advisory very briefly summarizing the information that had already been summarized in 9 earlier DNP3 system advisories based upon the work of Adam Crain and Chris Sistrunk. I have addressed the individual advisories here in this blog.

What has undoubtedly driven this unusual publication is the recent discussion about the very real potential consequences of the vulnerabilities that have been taking place over the last couple of days in various cybersecurity venues on the internet. A good example can be found at DigitalBond.com where Dale Peterson describes how easily these vulnerabilities could be used to shut down much of the electrical distribution system in the US.

ICS-CERT does not acknowledge these discussions as the reason for the issuance of this advisory. In fact, they completely ignore the scope of the problem that is being discussed quite widely in the control system security community. If one were to read just this advisory, it would seem that this is just the common, garden-variety denial of service advisory that we have been seeing for the last couple of years.

Part of this is due to the lack of grandstanding by Adam and Chris. Because of their professional backgrounds, I am sure that they are fully aware of how easily these vulnerabilities could be exploited to bring down electrical (or gas, or water, or whatever SCADA controlled distribution system is using DNP3 based devices) transmission systems. Instead of yelling from the mountain top, they have calmly gone through the coordinated disclosure process and worked with ICS-CERT and the vendors to get patches developed for these systems.

BTW: Have I mentioned lately that there are still 15 Crain-Sistrunk vulnerabilities that have yet to see the light of day? They are still wending their way through the disclosure process, and some of them may do for Modbus what has already been done for DNP3.

So it has taken public discussions by other members of the control system community to get ICS-CERT to react to the real scale of the potential problem. Unfortunately, while ICS-CERT has stepped up to the plate, they waited until the pitched ball was in the catcher’s mitt to feebly wuff the bat vaguely over the plate. This is real surprising from an organization that annually exaggerates the number of attacks on control systems (equating IT attacks on corporate networks as attacks on control systems owned by those companies).

It would have been nice if this advisory had even mentioned that the lax physical security at remote transmission sites would make it easy for an attacker to gain access to the whole SCADA network or shut down key nodes of that network. Then maybe readers of the advisory would begin to see the scale of this vulnerability and why it really did justify a summary advisory that ICS-CERT pretended to issue today.

Looking at the last two advisories to come out of ICS-CERT it is clear that, while ICS-CERT understands the microcosmic aspects of control system security, they either fail to grasp or just plain ignore the macrocosmic scope of control system security problems. Somebody needs to readjust their focus and it won’t be a former DOD lawyer and political crony of the President.

DNP User’s Group Report on Reported Vulnerabilities

Readers of this blog will certainly recall a number of vulnerabilities (the latest for example) that I have reported upon concerning the DNP3 products from a number of different vendors all of which were reported by Adam Crain. Well, Adam was nice enough to point me at a report prepared by the DNP User’s Group about those vulnerabilities and what they mean about the general security of the DNP3 Protocol.

Anyone that is using or thinking of using a DNP3 based produce from any vendor should read this report. It doesn’t provide a lot of details about the individual problems that Adam has identified, but it does reaffirm what both Adam and Jake Brodsky  (and others) have told me about the problems; they are not inherent in the DNP3 protocol, but problems with individual vendor implementations of that protocol.

The most important part of the report, in my opinion, though is found at the end where it discusses SCADA security for DNP3 in general:

• SCADA protocols were designed for use on trusted networks. On untrusted networks, these protocols must be deployed within a system that uses adequate security measures [emphasis added].

• The current DNP3 specification is IEEE 1815-2012, and is available from the dnp.org Document Library.

• DNP3 is one of the few SCADA protocols that already includes built-in security features.

• DNP3 devices should be certified for interoperability, but these certification tests do not necessarily verify robust behavior in all circumstances.

• No single security feature can defend against all types of attacks. Experts suggest using a defense-in-depth security methodology.

Of course, the first and last comments really apply to all ICS protocols and systems.