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.

Reader Comment – Defending DVCP

A long-time reader and noted security researcher (I’ve mentioned his name many times here) Chris Sistrunk left a valuable comment on yesterday’s post about Marina Krotofil’s presentation, Damned Vulnerable Chemical Process (DVCP). Chris reminds us that an attack like Marina described will take a great deal of time and multiple trips to your system before the actual cyber-physical attack can be initiated. This provides plenty of opportunity to detect and prevent the attack if you are paying close attention to your control system (see his comment for more details).

But even before we start the kind of monitoring that Chris describes we need to take the same kind of look at our control system as we do the rest of our chemical process in our process hazard analysis (PHA). This will help us to identify those controls that could place our facilities at the most risk if/when a cyber-attack should take place.

In a well conducted PHA we look at each step in our process in great detail to look at all of the things that could go wrong. We look at each variable and ask question about what would happen if it were too high, too low, too fast or too slow, etc. For those events that could have catastrophic consequences (or were very likely to happen with lesser consequences) we put compensating controls in place to help prevent those occurrences. The more severe the consequence, the more compensating controls we put into place.

Given the new cybersecurity environment, we should now consider extending that process down to the controller level when we identify high consequence vulnerabilities in our chemical processes. When we determine, for instance, that a high temperature will lead to a catastrophic consequence we need to take a detailed look at the sensors and controllers that directly impact temperature control.

This detailed look would include the specific vulnerabilities associated with those devices. For example, are these devices that can have their programming changed by anyone with access to the device (Dale’s unsecure by design PLCs)? If so, we would want to take special precautions to limit access to that device.

Where process safety rules require multiple mitigating measures we could use multiple sensors for instance with a ‘tell me three times’ requirement familiar to rocket scientists. Or we could use stand-alone safety systems, air-gapped from both the control and IT networks, and provided with an uninterruptable power supply to provide the ultimate control system protection.

We shouldn’t forget Chris’ monitoring requirements. In fact, for those really sensitive portions of the process where the really bad things can happen (the things that go boom in every process engineer’s nightmares) we might want to ensure specific log checks for the most critical devices controlling that portion of the process.

In short, we really want to make safety and security two sides of the same coin. After all the goal of each is to keep chemical processes within the narrow confines necessary to keep employees and the community safe and healthy.

BTW: An anonymous commenter provided a YouTube link for Marina’s talk (without the annoying 15 minute delay at the start) - https://www.youtube.com/watch?v=TPUzNMcFb4A  

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.

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.

Google+ Comment – 09-09-13 – DNP Work

Jake Brodsky, a long time reader and prolific cross-the-web commentor on all things control-system-security, left an interesting Google+ comment on a ‘BTW’ comment I made in last night’s post on the latest Crain-Sistrunk ICS-CERT advisory. I made a toss-off comment about Adam and Chis working on a re-write of the DNP protocol. Jake made the following clarification:

“Speaking as Chairman of the DNP Users Group, I would like to clarify that the protocol is sound. Crain and Sistrunk are working with the technical committee on development of more robust test procedures. I will have more to say about this later.”

As always I appreciate the clarification. With an open source product like DNP developing vigorous test procedures is almost more important than refining the protocol. This is especially true if it helps to catch implementation errors like those that Adam and Chris have been pointing out in the last couple of months.

One of the challenges for gadflies like myself (with limited technical expertise) is that it is hard to tell if a series of reported problems with an open source product like DNP is the result of a basic flaw in the product or if the problem is in the implementation in applications.

Adam and Chris have pointed out a number of improper input validation vulnerabilities in applications that are DNP based. Because they all have been coordinated disclosures and no exploit code is available, it is hard to tell how similar the vulnerabilities actually are. If they are inherent in the DNP protocol, then DNP needs to be fixed. If they are implementation based vulnerabilities, there may still need to be revisions made to DNP to make it more difficult to make these types of errors.

I know that Jake is a hard-working man with a strong personal and professional interest in control system security. Adam and Chris obviously have a good understanding of this specific DNP issue. With the three of them (and others I’m sure) at work on the issue, I’m sure that the DNP protocol and its various implementations will be more secure at the end of the day. That is all that anyone can ask of any product.

Another Crane-Sistrunk DNP Advisory from ICS-CERT

Today the DHS ICS-CERT published a control system advisory for an improper input validation vulnerability in the SUBNET Solutions Inc. SubSTATION Server software application. The vulnerability was reported by Adam Crane and Chris Sistrunk in yet another coordinated disclosure.

ICS-CERT reports that a moderately skilled attacker could remotely exploit the vulnerability to execute a denial of service attack. SUBNET Solutions has produced an upgraded version of the software that is available by contacting the company. ICS-CERT reports that SUBNET has self-certified the efficacy of their revision.

BTW: There are still 15 ‘pending’ vulnerability reports on the Project Robus web site; the number does not seem to be increasing. As I understand it Adam and Chris have taken a brief sabbatical from identifying new vulnerabilities to help re-write portions of the DNP protocol to help eliminate these problems. Hopefully when that is done they will select a new target for their interests.

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. 

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.