ICS-CERT Publishes Siemens SICAM Advisory

Today the DHS ICS-CERT published a control system security advisory describing a denial-of-service vulnerability in Siemens SICAM products. The vulnerability was reported by Adam Crain of Automatak LLC. Siemens has produced a firmware update to mitigate the vulnerability. There is no indication that Adam has been provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that a relatively unskilled attacker could remotely exploit this vulnerability to cause a denial of service. The Siemens Security Advisory reports that the vulnerability exist in the SM-2558 and SM-2556 IEC 60870-5-104 COM Modules used in the SICAM products.

Siemens announced their advisory on TWITTER® last Friday.

ICS-CERT Publishes Three Advisories

This afternoon the DHS ICS-CERT published three advisories in control systems from Schneider, Kepware and Software Toolbox.

Schneider Advisory

This advisory describes a buffer overflow vulnerability in the Schneider Invensys SRD Control Valve Positioner. The vulnerability was reported by Ivan Sanchez from Nullcode Team. Schneider has produced a new version of the software that mitigates the vulnerability, but there is no indication that Sanchez has verified the efficacy of the fix.

ICS-CERT reports that a local user is required to load a malformed DLL file before the vulnerability is exploitable. A successful exploit could result in arbitrary code execution. Schneider reports that once the DLL file is loaded the vulnerability is remotely exploitable. They don’t mention anything about loading a ‘malformed DLL file’; it is apparently a DLL file that is part of the software package.

Kepware Advisory

This advisory describes a resource exhaustion vulnerability reported by Crain and Sistrunk (back in December 2013 according to Adam Crain) in the Kepware DNP Master Driver. Kepware has produced a new version that mitigates the vulnerability, though there is no indication that Crain or Sistrunk have verified the efficacy of the fix.

ICS-CERT reports that a moderately skilled attacker could remotely exploit this vulnerability to crash the OPC Server.

The ICS-CERT discussion of the vulnerability appears to imply that a similar vulnerability might be found in other implementations of the DNP3 protocol. It notes that there is a DNP3 Application Note addressing the situation.

This looks like it was one of two remaining unresolved DNP3 vulnerabilities listed on the Project Robus website.

Software Toolbox Advisory

This advisory is a near duplicate of the Kepware advisory discussed above except that it involves the Software Toolbox Top Server. If this is, in fact, the second unresolved DNP3 vulnerability listed on the Project Robus site, I kind of suspect that these two vendors may be the only two with this specific implementation issue. Crain-Sistrunk would have looked for this in other implementations; they are kind of thorough that way.

Coordinated Disclosure is Complicated

The problem of when to publicly disclose discovered vulnerabilities in control systems is a much debated topic. Theoretically, I think that everyone in the control system vender and owner world would prefer to see researchers coordinate their disclosures so that the vendor has a chance to correct the vulnerability and the owner/operators have a chance to fix their systems before the vulnerability becomes public knowledge. But even when a researcher is committed to coordinated disclosure things can get complicated.

Coordinated Disclosure or Not

Yesterday Adam Crain, a well-known and well documented researcher, posted an interesting blog entry on his web site. In it he discusses a method of dealing with recalcitrant vendors that apparently make no effort to correct a vulnerability in their product that has been identified by an independent researchers and coordinated with both the vendor and ICS-CERT.

Historically (an odd term to use is in this young field) one of the reasons given by many grey hat researchers for not coordinating disclosures is that vendors have ignored them or failed to take action to correct identified vulnerabilities. In general the control system industry has gotten much better at responding to coordinated disclosures. This has been a major contributor to the decline in the number of Alerts that ICS-CERT has had to publish recently.

Unresponsive Vendors

But for every trend, there is an outlier. In this case it appears that Adam has identified one such outlier. Now Adam and his partner Chris Sistrunk have been the poster children for the coordinated disclosure process with the series of DNP3 vulnerabilities in 28 products that they have reported over the last year or so. They have been active proponents of fuzz testing of control system components, but they have been scrupulous in coordinating the disclosure of their serious vulnerability discoveries with vendors and ICS-CERT. But, even Adam and Chris have their breaking point.

Hidden Components

What is particularly disconcerting in this case is that this is not a vulnerable device that can be exposed to the community and provide owner/operators with the choice of how to deal with their vulnerable systems. In this case the identified vulnerability is in software library that may have been used by any number of vendors in developing the software and firmware for a wide range of control system products.

And the system owner/operators have no way knowing if that library has been used in any of their devices, so there is no way for them to protect their systems or even know if their systems need protecting. Okay, I suppose there is a way; Adam has made his fuzzing tool available free of charge and an energetic and system savvy owner could probably use the tool to find the hidden vulnerabilities. I’ll have to ask Adam about how likely is that his fuzzer would find these particular vulnerabilities in an off-line control system (NOTE: Never fuzz test a live control system).

This is an ongoing problem in the control system community (okay in the entire Cybersecurity community) where few organizations have the necessary talent or time to produce every line of code in-house that goes into their control system components. When a control system device (or software) vender buys (or uses open source) software they also get any vulnerabilities in that software. Identifying those underlying vulnerabilities and tying them to all other uses of that code is complicated at best.

We, the ICS security community, need to develop a methodology for identifying and tracking down all of the vulnerable iterations of code that are identified in one place as being vulnerable and used in other systems and applications. The ICS ISAC SARA program is designed to address part of this problem, but I am not sure that it will be capable of going deep enough into the architecture of control systems to really help alleviate this problem.

Continuing the Fight

Adam, of course, is not going to rely solely on outsiders to get this problem fixed. While he has still not publicly identified the particular vulnerability he is doing more than just writing this blog post of his about this specific vender. He is also taking the information to the ICS community; outing the vendor as one of the uncooperative ones. Not only is he attempting to use community coercion to encourage cooperative compliance, but he is in effect warning other vendors that there may be a bug in their systems that needs to be addressed.

I wish him the best of luck, but I don’t expect to see much action, at least publicly. Very few vendors have gotten to the point that they self-identify vulnerabilities in their systems (Siemens is a major exception) even if the vulnerability comes in with outside code.

UPDATED 4-17-14 7:30 CDT - Adam's blog post got an interesting response  (see first comment) from the company involved. They did not like him outing them. Too bad. If they had just talked with ICS-CERT and Adam this whole thing would never have blown-up like this.

Follow-up on Schneider Advisory

There has been an interesting Twittversation about these vulnerabilities since I did my earlier post.

Carsten Eiram (@carsteneiram) provided a link to the original vulnerability report that Risk Based Security published after Schneider apparently published their original (though no longer available) advisory back in March of last year. While that report is not exactly ‘exploit code’ it certainly contains enough information that a reasonably competent hacker should be able to write their own.

Adam Crain (@jadamcrain; of DNP3 Fuzzing Fame) asked: “Any idea what took @ICS-CERT so long on this one?” This is certainly a good question since it has now been over a year since Schneider first publicly reported the vulnerability.

The delay is almost certainly related to the fact that Schneider is fixing the problem system by system. While the problem is reportedly in the common ModbusDriverSuite, the implementation of that suite in each of the eleven products is likely slightly different. According to the most recent Schneider advisory (dated September 13^th, 2013) they don’t intend to issue product updates just for this vulnerability; the fix will be included in the next product update.

I suspect that either ICS-CERT finally got fed up with the slow pace of updates or they received some recent communication from Schneider that indicated that Schneider had effectively decided not to fix the other eight products. Either would certainly explain the following comment in yesterday’s ICS-CERT Advisory:

“Schneider Electric has no immediate plan [emphasis added] for updating the other identified software products.”

In any case, Schneider has left customers owning the below listed software in an unenviable position. Their control system has a publicly identified security vulnerability that there is only a network limitation fix available; a fix that individual customers may or may not be in a situation to be able to put into place.

• TwidoSuite Versions 2.31.04 and earlier (available next month?);

• PowerSuite Versions 2.6 and earlier;

• SoMove Versions 1.7 and earlier;

• SoMachine Versions 2.0, 3.0, 3.1, and 3.0 XS;

• UnityLoader Versions 2.3 and earlier;

• Concept Versions 2.6 SR7 and earlier;

• ModbusCommDTM sl Versions 2.1.2 and earlier;

• PL7 Versions 4.5 SP5 and earlier and

• SFT2841 Versions 14, 13.1 and earlier.

Maybe this push by ICS-CERT will speed up the process. Or maybe enough complaints from customers will provide the necessary impetus. Finally regulators that have cyber security controls available may want to ensure that folks with these systems are taking special precautions.

ICS-CERT Updates Latest Crain-Sistrunk Advisory

This afternoon the DHS ICS-CERT updated the latest single product advisory for a DNP3 vulnerability reported by Adam Crain and Chris Sistrunk that was originally published less than two weeks ago. The updated information explains the vulnerability differences when the devices is used in two different modes; serial communications and IP communications modes.

ICS-CERT now separates the improper input validation vulnerability into two separate vulnerabilities with their own CVE # (IP -  CVE-2013-2787; Serial - CVE- 2013-2818) and different CVSS v2 base scores (IP – 7.1; Serial – 4.7) based upon the different modes of access. The higher base score for the IP installation is based upon the fact that the vulnerability is remotely accessible.

ICS-CERT also notes that the skill level necessary to exploit the vulnerabilities is different, noting that it takes less skill (moderate) to exploit the IP based installation as compared to the high skill level required to exploit the serial based implementation vulnerability. It appears that they base that distinction solely on the fact that physical contact with the device is required for a serial exploit.

I’m not sure that I agree with the exploit skill level assessment. It takes different skills to defeat physical security than to gain network access, but I’m not sure that I would call it higher skills. There are certainly more people out there with the ability to penetrate a remote facility protected by fences and cameras (I can certainly do that as can most ex-infantry soldiers, gang bangers and B&E specialists to name a few; hell an 80-year old nun did it earlier this year at a nuke weapons installation) than can penetrate network defenses to access to a port on a device.

It seems to me that this is an attempt to understate the potential threat to electric (gas and water) transmission systems that employ these devices. There has been a lot of discussion in the cybersecurity press about the physical vulnerability of these types of devices at remote sites. Those discussions describe the ease of plugging a device into a serial port and how uncomplicated TCP packet can be used to put the outstation into an endless loop. This type of attack would make it impossible to control the control systems at that outstation until the system was reset.

Other than those concerns, the new updated does more accurately describe how the vulnerability can be exploited and the different ways the vulnerability can be exploited based upon how the device is employed.

It’s Official – The Crain-Sistrunk Vulnerabilities Are the Real Deal

On Friday a blog post over at NYTimes.com explains the Crain-Sistrunk vulnerabilities and how they are a danger to the electrical grid. As you would expect with such a technically literate organization, the blogger (Nicole Perlroth) got a lot of the details a little bit wrong (and she loves periods way too much), but the post has the broad outline of the process and the potential threat generally correct.

But missing the small stuff is of little consequence, the big thing is that the New York F***ing Times is telling the world that this is a problem. If you see it in the Times, Virginia, you know that it is true. And besides the politicians are now aware of the problem, probably never having heard of DigitalBond or ThreatPost or the other technical discussion groups where there was more (and more correct) information available about the problem at an earlier date.

What will be interesting to see is how soon it will be before Congress will call a hearing to look into the problem. Looking at the CFATS issues of a year and a half ago as a forecasting tool, I suspect that someone will call a hearing in March. That is unless there is a significant portion of the electrical grid shut down by some script kiddy in the meantime. Then it will be June or July before Congress starts to demand answers about why no one told them about the problem before the attack.

Of course (Severe Sarcasm Alert) the technically qualified part of DHS (ICS-CERT, look Nicole, no periods) has been right on top of this since being approached by Adam and Chris. They have gone out of their way to make sure that electrical grid and water system owners have been fully advised about the seriousness of the threat. Nine of the 16 vendors have rushed patches into the market place and are leading a coordinated evangelical campaign to get each and every vulnerable device patched or replaced. And the other seven vendors are so consumed with making things right with their product that they have inadvertently forgotten to tell owners of their products about the vulnerability (End of Severe Sarcasm Alert).

No, none of that has been done. ICS-CERT has published advisories for the vulnerabilities that have had patches developed by the vendor, but it seems as if they forgot their 45-day limit for withholding vulnerability alerts to allow vendors to get patches in place. I assume that the seven no-patch available vendors are working on the issue and that is why ICS-CERT is holding off on publishing the alerts. Even the master ICS-CERT advisory issued last week makes the problem sound minor and might as well say “hey man, no worry, it’s all good” for all of the concern that it will raise..

Now Crain and Sistrunk have not published exploits for their vulnerabilities so that may also contribute to the ICS-CERT justification for remaining mute on the uncorrected vulnerabilities. I would like to suggest that given the simplicity of the exploit as described in the ThreatPost and DigitalBond posts (enter a poorly secured remote substation, plug in your communications tool into an open serial port and send almost any message to the master station and the local system gets a brain freeze and no electricity goes down the line) that those posts should count as publication of exploits requiring ICS-CERT to issue alerts so that the facility owners holding equipment from those 7 vendors will be aware of the fact that they were specifically targeted.

Oh well. Let me step down from my soap box, catch my breath and comb my hair. Maybe I caught someone’s attention, but probably not. I’ll try again later this week.

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.

ICS-CERT Publishes Two Advisories

In the midst of a dysfunctional government’s fiscal fiasco the DHS ICS-CERT published two control system security advisories yesterday, one a DNP3 advisory for Alstom e-Terracontrol and another HMI advisory for Wonderware InTouch.

Alstom Advisory

This advisory is for an improper input validation vulnerability reported by Adam Crain and Chris Sistrunk in a coordinated disclosure (#9 of 25 listed on the Project Robus web page). Alstom has produced a patch to mitigate this vulnerability and Adam and Chris have verified the efficacy of that patch.

ICS-CERT reports that a moderately skilled attacker could remotely exploit this vulnerability to execute a denial of service attack on the system.

Wonderware Advisory

This advisory is for an improper input validation vulnerability reported by Timur Yunusov, Alexey Osipov, and Ilya Karpov of the Positive Technologies Research Team in a coordinated disclosure. Wonderware has produced an updated version of InTouch that mitigates this vulnerability and the team from Positive Technologies has verified the efficacy of the new version. ICS-CERT had released this advisory to the US-CERT secure Portal library on October 03, 2013.

ICS-CERT reports that a relatively low skilled attacker could exploit this vulnerability to gain access to system information or execute a denial of service attack. ICS-CERT says that this vulnerability cannot be remotely exploited; they note that the “exploit is only triggered when a local user runs the vulnerable application and loads the malformed XML files” {page 2}. It seems clear that a remote exploit would be possible through a social engineering attack.

According to the Positive Technologies web site that organization reported this vulnerability to Invensys on 12-16-13 along with three other vulnerabilities in the same system. Those reported vulnerabilities were:

• PT-2013-40: Resource Exhaustion;

• PT-2013-38: Multiple SQL Injection vulnerabilities; and

• PT-2013-37: Multiple Cross Site Scripting (XSS).

Positive Technologies reported that Invensys publicly reported all four vulnerabilities on October 6^th. It is not clear why ICS-CERT did not include these other, more serious, vulnerabilities in this advisory especially since Positive Technologies reports that the same Invensys update fixed all four vulnerabilities. The Wonderware notifications are only available to registered system owners so I cannot verify the Positive Technologies claims.

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.

Aegis Update and Vulnerability Debate

Adam Crain has a very interesting blog post over at Automatak.net providing additional information about his Aegis project (earlier blog post on Aegis). The Aegis Consortium is an important new business model for researchers and for that reason alone this post is worth reading. More importantly, he is adding an important new dimension to the disclosure debate.

Background

Adam is relatively new to the control system security field, but he has already made a significant mark. His first vulnerability discovery was reported by ICS-CERT in June of this year and he already has 8 ICS-CERT advisories with his name on them (along with Chris Sistrunk). All of these have been coordinated disclosures. His Project Robus lists 17 additional vulnerability disclosures that are wending their way through the coordinated disclosure process.

All of the disclosures that have been made public to date have dealt with vulnerabilities in various implementations of the DNP3 protocol. I assume that a number of the pending vulnerability disclosures will also involve that protocol. Adam is quick to note that the problem isn’t with the DNP3 protocol, but with the various implementations by the affected vendors. In fact he goes so far as to say “we have yet to find a proprietary DNP3 implementation without an issue”.

Fuzzer Tool Release

Adam developed the fuzzer tool that he used (again along with Chris and a new associate Adam Todorski) to find these 25 vulnerabilities. Now fuzzer tools are not new in the cybersecurity realm, and I don’t know what make his different than others, but his tool certainly has an impressive early track record. Adam has promised that he will publicly release his fuzzer in March at the SANS NA ICS Security Summit.

Again, I have no idea how user friendly his fuzzer is, but presumably anyone with a modicum of cybersecurity research experience will be able to use this tool to find new vulnerabilities in control system applications. Adam has demonstrated its efficacy with DNP3 so any vendor with a DNP3 application has cause to be concerned that currently undiscovered vulnerabilities in their systems might not remain undiscovered for long after this tool is released.

Now a fuzzer is just a tool, not inherently good or bad. A security researcher like Adam puts it to good use identifying vulnerabilities in a system and reporting them to the vendor. A vendor can use it to find and correct the same vulnerabilities. And a terrorist can use it to find a way to gain system access and control for part of a control system attack.

With this in mind, Adam is offering vendors and researchers access to his fuzzer before its public release; for a fee. After all Adam needs to make a living just like anyone else and he should be able to profit from his talents and efforts.

Vulnerabilities are Available

Some will complain that Adam is making the job of the black hat hacker that much easier by making this tool publicly available. I would seriously disagree. With making this tool available to vendors and other white hat researchers ahead of time, Adam is decreasing the potential attack surface that is vulnerable to attack.

Any criticism of Adam’s making this tool publicly available ignores a very important point in the vulnerability disclosure debate. Adam did not put these vulnerabilities in the DNP3 implementations; he just made them easier to find. They were put there by vendors that did not do an adequate job of testing their product before they made them available to the public. It is the vendor, not the researcher, who is responsible for the vulnerabilities.

Now it is hard to blame the vendor when the owner/operators have already given them a free pass for any vulnerabilities that exist in their systems. We as a user community have accepted the almost universal vendor terms of service that declaim that the vendor is not responsible for any defects in their product and that they don’t warrant its use for any particular application. As long as we give vendors a free pass on the quality of their products, we have little room to complain about the existence of vulnerabilities or researchers who find them.

Tools for Testing DNP3 – Aegis Platform

I got an interesting email from Adam Crain today. It was part of a continuing message chain, but he tossed off a new subject:

“FYI, I just announced the release of the DNP3 fuzzer at SANS SCADA in March 2014”

He then provided a link to a new page on his Automatak.com web site - http://www.automatak.com/aegis/.

Adam and his compatriot, Chris Sistrunk, have demonstrated a talent for finding vulnerabilities in DNP3 applications. They have made a name for themselves in the last couple of weeks from their being listed as the responsible researcher on 8 ICS-CERT advisories. I don’t know the details of their disclosure agreements with the affected vendors, but I seriously doubt that they have made much, if any, money off of these disclosures.

BTW: There are now 17 ‘pending’ disclosures on the Project Robus web site; two more than earlier this week. So, contrary to my earlier supposition, they haven’t stopped their testing efforts.

This is the problem that most ‘ethical researchers’ have run in to; there is little or no money to be made from coordinated disclosures. This is one of the reasons that so many cybersecurity researchers have turned to selling vulnerabilities on either the black or grey markets; it’s a way to pay the bills and keep food on the table. The rub, of course, is that these markets put owner/operators at risk.

Adam, it seems has come up with a slightly different marketing angle. Instead of selling vulnerabilities he is effectively going to sell tools he develops to find vulnerabilities. It is not explicitly pointed out on his web site, but his email makes clear that he is looking to vendors and utility owner/operators to be members of his “consortium of industrial control system (ICS) stakeholders” thus staying on the side of ‘ethical hackers’.

BTW: I made the comment in an earlier blog post that other ICS protocols might undergo examination by Crain-Sistrunk. A side-bar on the AEGIS page points out that there is a “Modbus master/slave” under development. I suspect that we will shortly begin seeing ICS-CERT advisories pointing out vulnerabilities in Modbus related applications. Fortunately (sarcasm warning) there aren’t too many of those out there. In fact, some of those 17 pending disclosures might be Modbus related instead of DNP3. Some people would be happy to see that.

It will be interesting to see how well Automatak does with this project. I hope that he succeeds, we need more owner/operator-friendly hacker business-models.

ICS-CERT Publishes Another Crain-Sistrunk Advisory

Today ICS-CERT published an advisory for a buffer overflow vulnerability on the MatrikonOPC SCADA DNP3 OPC Server. Actually the document published today is a revised version of an advisory published on the US-CERT secure Portal back on August 2^nd. The vulnerability was reported by Adam Crain and Chris Sistrunk in a coordinated disclosure.

The Advisory

ICS-CERT reported that the vulnerability can be remotely exploited by a moderately skilled attacker to execute a DOS attack. MatrikonOPC insists that an exploit would require “in-depth technical knowledge of the DNP3 protocol and the specific vulnerability in the MatrikonOPC software”. I guess (sarcasm alert) that Adam and Chris were just lucky to be able to find the ‘specific vulnerability’.

MatrikonOPC has developed a new version of the OPC Server for DNP3 that eliminates this vulnerability. ICS-CERT reports that Adam has verified the efficacy of the update.

The Update

As I noted earlier this publicly available version of the advisory is actually an update of the earlier, limited release version. There are two changes listed in the update; a more detailed explanation of the mechanism of the vulnerability and an additional suggested mitigation to prevent the vulnerability from being remotely accessible.

The update notes that the server only stops communication because of this vulnerability after receiving a malformed DNP3 packet from a device. In an unusual move ICS-CERT added additional language indicating that Adam and Chris suggested that an additional mitigation measure would be to block “DNP3 traffic from traversing onto business or corporate networks through the use of an IPS or firewall with DPN3-specific (sic) rule sets”.

This is actually a pretty specific expansion of a standard ICS-CERT recommendation to protect control systems from unauthorized access via the use of a firewall or IPS. It is not surprising that Adam and Chris would focus on DNP3 communications since this is an area that they have been spending a great deal of time investigating here recently. It might be interesting if they were to post on the Automatak blog a more detailed discussion about the types of DNP3 rule sets that would provide additional control system protections for DNP3 servers in general.

ICS-CERT Publishes Deceptively Simple Advisory

Today the DHS ICS-CERT published an advisory for twin improper input validation vulnerabilities in products from Triangle MicrWorks. The vulnerabilities were reported by Adam Crain and Chis Sistrunk in a coordinated disclosure.

The Advisory

ICS-CERT reports that the twin vulnerabilities exist separately in serial and IP communications. The serial version is only locally exploitable and the IP version may be remotely exploited. ICS-CERT reports that a higher skill level is required to exploit the serial version of the vulnerability because “physical access to the device or some amount of social engineering is required”. I’m not sure why social engineering skills are considered to be a ‘high skill level’ unless they have determined that advanced social engineering skills are required for the serial exploit.

According to ICS-CERT the successful exploit of either version of the vulnerability could result in a denial of service situation because the software could be sent “into an infinite loop” requiring a manual reset.

Triangle MicroWorks has produced an update and release notes to resolve the vulnerabilities. Actually a causal review of the release notes makes it clear that much (32 pages of much) more than just this vulnerability was fixed in this update. It makes good sense to fix multiple problems in a single update, but I have to wonder if the release was delayed to fix these security vulnerabilities or if the release of the security fix was delayed to fix other problems as well. ICS-CERT reports that Adam has validated the efficacy of the update.

The Rest of the Story (apologies to Paul Harvey)

I got an interesting email from Adam pointing out that this is a bigger issue than it may look like in the advisory. Adam notes:

“Note that this is a source code library. TMW has > 50% market share. We don't know where this code is deployed/sold and DHS lacks authority to force disclosure.”

Now this is not an uncommon problem. In fact, I have mentioned similar situations with a number of software vulnerabilities as have others. Fortunately (sarcasm alert) this is only a denial of service vulnerability. It’s not like it allows an attacker to execute arbitrary code, so it’s not a real problem (end sarcasm alert).

Adam makes a good point about the lack of authority of DHS, except that he’s making that lack of authority too specific in his complaint. Let’s face it, outside of the federal government, DHS (and most emphatically including ICS-CERT) has no cybersecurity authority to compel industry to do anything. At most they have the gentle power of persuasion and the threat of disclosure to try to modify the behavior of the advised (as opposed to regulated) industries.

If this had been an uncoordinated disclosure, Adam would have had exploit code posted on a web site somewhere and other researchers could have explored other DNP3 applications to see if the same exploit could be found on other systems. Without that that other researchers will just have to look at a variety of TCP packets to see what works on the Triangle MicroWorks supported systems  and then evaluate the rediscovered exploits (or maybe new ones, you never can tell) on other systems. That probably won’t be a significant delay.

This raises a couple of interesting questions:

How many of the ‘other’ researchers will notify the vendor in a coordinated disclosure versus selling the vulnerability to the highest bidder?

Has Triangle MicroWorks notified each of it customers that the vulnerability is affecting their systems?

How many of the downstream vendors do not have the  application expertise to adapt the Triangle MicroWorks update to their own system.

ICS-CERT Publishes Two Advisories – Schneider and Top Server

Today the DHS ICS-CERT published two control system advisories; one for an encryption vulnerability in the Schneider Electric Trio J-Series Radios and one for an input validation vulnerability in the Software Toolbox TOP Server DNP Master OPC product.

Schneider Vulnerability

This advisory concerns a self-reported hard-coded encryption key vulnerability (NOTE: The Schneider web site reports that this vulnerability was reported by an unnamed security researcher). Some versions of the firmware in the Trio J-Series License Free Ethernet Radio does not properly generate an AES encryption key. Schneider reports that simply upgrading to a newer version of the firmware does not necessarily correct the problem.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit this vulnerability to take control of the communications network and the control system attached to it. Schneider reports that they have updated firmware, that properly applied, will mitigate the problem. There is no indication that the original researcher has validated the update.

NOTE: Schneider identified this problem and solution in May and posted it on their web site on August 8^th. That delay was almost certainly due to attempting to notify customers of the problem. The delay in the ICS-CERT reporting of this issue is not explained.

TOP Server Vulnerability

This advisory concerns an improper input validation vulnerability on the TOP Server DNP Master OPD product identified by Adam Crain and Chris Sistrunk. Oh, hell, just read my Kepware blog post of last week; this advisory is for the same vulnerability in the same system, it’s just marketed under a different label. Adam pointed this out to ICS-CERT but they would not add it to the earlier advisory. Adam and Chris get credit for another coordinated disclosure because they pushed ICS-CERT to publish this advisory so that the TOP Server owners would understand that this vulnerability applied to them.

This is an ongoing problem with hardware, software and firmware sold under different names or included in other systems. As more of these types of vulnerabilities are reported blackhats will begin to realize that systems are vulnerable because owners don’t realize that available patches and upgrades apply to their equipment. ICS-CERT needs to step up and be proactive in these types of situations and not have to be pressured into acting by concerned researchers.

BTW: The Project Robus web site takes credit for this advisory and reports that there are now 17 disclosures pending.

ICS-CERT Publishes Kepware DNP Advisory

Today the DHS ICS-CERT published an advisory for an improper input validation vulnerability in the Kepware Technologies DNP Master Driver. The vulnerability was reported by Adam Crain and Chris Sistrunk in a coordinated disclosure.

ICS-CERT reports that a moderately skilled attacker could exploit this vulnerability to conduct a denial of service attack or possibly execute arbitrary code on the system. Kepware has produced an updated version of the software that has been validated by Crain and Sistrunk.

The Project Robus page now shows four DNP3 related ICS-CERT advisories published that were based upon work by Adam and Chris with 15 advisories ‘pending’. Based upon Adam’s work on the open source implementation of DNP3 that I discussed yesterday, I would bet that a number of the ‘pending’ advisories will also deal with DNP3 vulnerabilities. It might behoove vendors that utilize the DNP protocol to start taking a hard look at their potential vulnerabilities. 

Grant Support

I got an interesting email from Adam Crain asking for my support in his grant application for work supporting the open source implementation of the DNP3 protocol. Since this work apparently includes work on the security side of that project I figure that providing moral support and encouragement via this blog is the least that I can do. I am also soliciting additional support for Adam’s work from readers of this blog.

Open Letter

To Whom it May Concern:

I understand that Adam Crain is applying for a Homeland Open Security Technology grant to continue his security related work on the open source implementation of the DNP3 protocol. I would like to express my support for Adam’s continued work in this area and encourage your organization to provide some of the financial assistance that will make that possible.

In an era when many when may security researchers are supporting their work by selling to the highest bidder the vulnerabilities that they uncover Adam continues to share the vulnerabilities that he discovers with the system vendor so that the vulnerabilities can be corrected and the owners can be protected against attacks. Providing grant support for Adam’s work on the DNP3 protocol will help to ensure that Adam can also continue his coordinated disclosure policy on his other related work.

Patrick Coyle

Chemical Facility Security News

Grant Deadline

The deadline for the grant submission is tomorrow so any support that can be provided would be greatly appreciated. You can either post supporting comments here or send me emails (pjcoyle@aol.com) of support that I will forward to Adam.

Robus – More ICS Vulnerability Reports to Come

Thanks to Chris Jager (via Twitter®) for pointing me at the web site of Robus, the collaboration of  Adam Crain and Chris Sistrunk that has already brought us the latest ICS-CERT advisory on SEL. This is a deceptively simple web site with only a single page and the only external links going to the ICS-CERT web site, the LinkedIn® profiles of the two principles and the web site of Automatak, their corporate sponsor.

The real interesting part of the site is the listing of the ICS-CERT advisories that there research has been responsible for initiating. There are currently three advisories listed and the word pending shown a number of times. Yesterday when I first saw this site there were 12 ‘pendings’, this morning there are 16; each one reflects (as I understand it) coordinated disclosures for ICS vulnerabilities that have already been made.

It looks like we are going to be hearing a lot from these two young men.

Keeping in mind that free suggestions are typically worth what you pay for them; I have two suggestions for the web site. First put a date on each ‘pending’ signifying when the disclosure was actually made; this could help the industry track the general responsiveness of vendors. Second establish an internal standard (the ICS-CERT 45 day limit for instance) for a reasonable time to fix a vulnerability and then add the vendor’s name to the pending listing. This could be followed by a second time limit to add the generic vulnerability description to the pending listing.

BTW: Suggested reading: Here be Dragons

ICS-CERT Publishes SEL Advisory

This afternoon the DHS ICS-CERT published an advisory for dual improper input validation vulnerabilities in the Schweitzer Engineering Laboratories’ (SEL) real-time automation controllers (RTAC). The vulnerabilities were reported by Adam Crain of Automatak and Chris Sistrunk in coordinated disclosures.

ICS-CERT reports that these vulnerabilities (one for serial connections and a separate one for IP-based connections; NOTE links will not work for a day or two) could be remotely exploited by a moderately skilled attacker, executing a denial of service attack. SEL has developed a CD-ROM based upgrade packet to mitigate the vulnerabilities. ICS-CERT reports that Crain and Sistrunk have validated the efficacy of the upgrades.

I tried to review the SEL information on these vulnerabilities, but it was not directly available on their web site. Instead SEL allows people with corporate email accounts to sign up to receive distributed information on SEL security notices. Anyone owning any SEL control system equipment should sign up for this service.

ICS-CERT Issues Three Advisories – Two for Siemens

After a three-week breather advisories start coming hot and heavy from ICS-CERT. There are two Siemens’ advisories (one self-reported) and a coordinated disclosure advisory for IOServer.

Siemens Scalance

The first advisory addresses two Siemens’ reported two vulnerabilities in their Scalance W-7xx product family. They are:

• Key management errors, CVE-2013-4651, hard-coded SSL certificate;

• Improper authentication, CVE-2013-4652, network access required.

NOTE: CVE Links may not be active for a couple of days.

ICS-CERT notes that a relatively low skilled attacker could remotely exploit these vulnerabilities to conduct a man-in-the-middle attack or take over complete control of the system. Siemens has produced an update that mitigates the vulnerability (since they self-reported they get to self-validate). The Siemens-CERT advisory also provides a work-around for the second vulnerability.

Siemens WinCC

The second advisory addresses two vulnerabilities reported by Timur Yunusov and Sergey Bobrov of Positive Technologies in a coordinated disclosure. The vulnerabilities are:

• Cross-site request forgery, CVE-2013-4911,

• Url redirection to untrusted site, CVE-2013-4912,

NOTE: CVE Links may not be active for a couple of days.

According to the Siemens-CERT advisory, both vulnerabilities require that a web be activated on the affected devices during set up. The attacker must then use a social engineering attack to get a user to access a malicious web page.

ICS-CERT notes that a moderately skilled attacker could remotely exploit these vulnerabilities to compromise the integrity (execute arbitrary code?) and availability (DoS attack?). Siemens has produced a product update that mitigates the vulnerabilities and has validated the fix (oops, that should have been the researchers, Yunusov and Borov, doing the validation).

IOServer Advisory

The third advisory of the day reports on an improper input validation vulnerability in the IOServer Master Station product reported by Adam Crain of Automatak and Chris Sistrunk in a coordinated disclosure.

ICS-CERT notes that a moderately skilled attacker could remotely exploit this vulnerability to execute a denial of service attack. IOServer has produced a Beta Driver (beta2042.exe) that mitigates these vulnerabilities. There is no indication that the researchers have validated the efficacy of the updated driver. NOTE: an even more recent Beta Driver is available.

ICS-CERT Publishes IOServer Advisory

This afternoon the DHS ICS-CERT published an advisory concerning an improper input validation vulnerability in the IOServer’s DNP3 driver reported by Adam Crain of Automatak and independent research Chris Sistrunk in a coordinated disclosure.

ICS-CERT reports that a moderately skilled attacker could craft a remotely exploitable attack using this vulnerability resulting in a denial of service attack. IOServer has provided an updated version of the software (http://www.ioserver.com/beta2040.exe) which has been confirmed by Crain and Sistrunk to correct the problem.

NOTE: I’m not sure that I would like clicking on an .EXE file for a file on a different web site. Personally, I would prefer to click to a page that provides some sort of explanation of what the changed software would do before I would be comfortable clicking on the executable file.