1 Advisory Published – 2-4-20

Today the CISA NCCIC-ICS published a control system security advisory for products from AutomationDirect.

AutomationDirect Advisory

The advisory describes an insufficiently protected credentials vulnerability in the AutomationDirect C-More Touch Panels EA9 Series. The vulnerability was reported by Joel Langill of Amentum Mission Engineering & Resilience (nice start for a brand-new company). AutomationDirect has a new version that mitigates the vulnerability. There is no indication that Joel has been provided an opportunity to verify the efficacy of the fix.

NCCIC-ICS reports that a relatively low-skilled attacker could remotely exploit the vulnerability to allow an attacker to get account information such as usernames and passwords, obscure or manipulate process data, and lock out access to the device.

Amentum Disclosure

It will be interesting to see how Amentum deals with these types of vulnerability reports. Some companies publish details (after public disclosure by the vendor). Those details can include proof-of-concept code. Personally, I think that more details than are provided by NCCIC-ICS can be valuable to the community, particularly details on how the vulnerability was found. Responsibly disclosing these details should only take place after a long enough time for the vendor to mitigate the vulnerability and for owners to mitigate the vulnerability. POC information does not really help all that much, but the other information could be useful.

Public ICS Vulnerability Disclosures – Week of 12-03-17

Yesterday Joel Langill pointed out a vulnerability report from ABB that was published over two weeks ago. The report addresses an authentication vulnerability in the ABB Ellipse 8 products. The ABB report notes that the vulnerability exists in the implementation of the Lightweight Directory Access Protocol (LDAP) that would allow an attacker with local network access to sniff the unsecured authentication credentials sent between the Ellipse device and the LDAP/AD server.

As with any vulnerability that is found to exist in an implementation of an industry-wide standard, the question arises; what other vendors are using this vulnerable implementation?

NOTE: The ABB report states that the vulnerability was reported in a “responsible disclosure”, but does not name the researcher making the disclosure.

Public ICS Disclosure – Week of 10-29-17

This week Karn Ganeshen provided proof of concept (POC) information on three previously published ICS-CERT vulnerabilities and Joel Langill provided a link to an ABB KRACK advisory.

POC Information

Karn continues to use the FullDisclosure web site to provide to provide additional information about control system vulnerabilities that he has previously disclosed through the DHS ICS-CERT. This week he has provided POC information on the following control system vulnerabilities:

• Progea Movicon SCADA/HMI – earlier reported here (there was no mention of publicly available POC in the ICS-CERT advisory);

• JanTek JTC-200 – earlier reported here (publicly available POC was mentioned in ICS-CERT advisory); and

• SpiderControl SCADA Web Server – earlier reported here (there was no mention of publicly available POC in the ICS-CERT advisory)

Based upon past experience, I do not expect ICS-CERT to update their vulnerability reports to reflect the fact that POC information is now available. Given the fact that ICS-CERT has reported that relatively low skilled attackers could exploit these vulnerabilities, I think that it is important that owners of these systems has this information available to help them appropriately assess the risks to their systems.

KRACK Vulnerability

Joel’s post on LinkedIn pointed at a cybersecurity advisory from ABB for their  ABB TropOS wireless mesh products concerning the WPA2 Key Reinstallation Vulnerabilities (also known as the Key Reinstallation Attack – KRACK).

As I pointed out in the resulting LinkedIn conversation this is the second vendor specific advisory on the KRACK vulnerability. Unlike the earlier report, ABB includes 7 of the 10 CVE found in the KRACK report, indicating that they have probably reviewed all 10 of the vulnerabilities in their system.

I continue to be disappointed in ICS-CERT for not having published a control system alert for the KRACK problem since these vulnerabilities will affect almost all ICS products that use WPA2 security for wireless communications in their control system products.

Public ICS Disclosure – Week of 10-15-17

We have two publicly disclosed industrial control system product vulnerabilities this week that were not addressed by ICS-CERT; one reported by a security researcher and the other self-reported by the vendor.

HP Vulnerability

On Wednesday Maor Shwartz from SecuriTeam described on FullDisclosure a cross-site scripting vulnerability in the Hewlett Packard Baseline Smart Gig SFP 24 ethernet switch. This product was acquired by HP from 3Com (3Com Baseline Switch 2924 SFP Plus Switch) and is no longer supported, so no fix is forth coming. The SecuriTeam blog provides a proof of concept exploit for the vulnerability.

ABB Vulnerability

On Tuesday Joel Langill, on LinkedIn, pointed out a cybersecurity advisory from ABB on their FOX515T release 1.0 communications equipment. It describes a local file inclusion vulnerability in the embedded web server. This is another out-of-service product with no fix in the works.

Commentary

Joel and I had a brief discussion on LinkedIn about this type of out-of-service vulnerability reporting. I had my typical snarky comment about no one using out-of-service equipment in the ICS realm. Joel had a very interesting reply:

“Like so many of the ICS-CERT advisories. Still wonder why they waste valuable time on disclosures of unsupported equipment. My lab is still a wealth of discovery and exploitation! But I prefer to keep these vulns quiet.”

I have to vigorously disagree with Joel. I think that someone needs to publicize these types of vulnerability reports because so many facilities are actually continuing to use ‘outdated’ control system devices on the ‘if it ain’t broke don’t fix it’ model. Depending on the severity of the vulnerability (and the site-specific risk calculation) the disclosure of these vulnerabilities may be just the ‘it is broke’ incentive that owners need to replace the equipment to avoid the vulnerability. Holding these vulnerabilities in-house (either at a researcher or vendor level) provides little service to owners.

Now, there is a legitimate question if this is an appropriate function for ICS-CERT to perform. I point at them as the default government agency in the control system security realm, but they do not have a specific mandate to do this nor do they have a specific mandate of any kind. They are an agency created out of whole cloth by DHS without specific authorization by Congress. A necessary move, to be sure, but there has been no public discussion of, or political determination of, the specific role of the organization. That really needs to change.

ICS Public Disclosures – Week of 07-08-17

This week we have two public disclosures from vendors. The first is an interesting update of information from ABB and the second is a fresh self-disclosure from OSIsoft.

ABB Update

ABB published their security advisory for their VSN300 Wi-Fi Logger Card; these were earlier reported by ICS-CERT. There was no link to the ABB advisory in the ICS-CERT advisory because it was published two days later. The importance of the ABB advisory is that it includes exploit code for the two reported vulnerabilities; an unusual move for a vendor.

The publication of the exploit code needs to be taken into account in the risk analysis done by owners in their decision as to whether or not they will be updating the Card firmware.

It will be interesting to see if ICS-CERT updates their advisory.

Thanks to Joel Langill for pointing out the publication of this advisory.

OSIsoft Advisory

OSIsoft announced this week the publication of security updates for their PI Integrator For Business Analytics 2016, PI Integrator for Microsoft Azure 2016, and PI Integrator for SAP HANA 2016 products with new versions of all three being made available.

The new versions correct two self-identified vulnerabilities:

• Improper Neutralization of Input During Web Page Generation; and

• Improper Authorization

OSIsoft reports that: “An unauthorized user could gain privileged access to the PI Integrator application and views of PI System data. A miscreant could also store malicious script in the application database and subsequently execute it on the targeted user's machine.”

ICS-CERT Publishes Digi HeartBleed Advisory

Earlier today the DHS ICS-CERT published an advisory for the HeartBleed vulnerability in various products from Digi. I discussed most of this information in my last HeartBleed post. New information: ICS-CERT reports that firmware updates are available “for most vulnerable Digi International devices”, but does not provide a list. The link provided takes one to a generic product support page where you enter your product name or select a key word to search for; neither HeartBleed nor OpenSSL are available terms.

ICS-CERT is again publishing a HeartBleed advisory without updating their Situational Awareness Alert. I almost don’t blame them as they would be quickly going to have to go to double letters to identify new updates if they updated the SA every time new information became available.

It would probably have been better to have had a HeartBleed web page to keep updating with new information on vulnerable, formerly vulnerable, and not vulnerable ICS products. Joel Langill over at SCADAHacker.com takes that type of approach. He is currently listing two ‘new’ ICS related vendors, Certes Networks and Unified Automation, as having products with HeartBleed vulnerabilities.

A reader of this blog, Rob Hulsebos, posted a comment on the LinkedIn Cyber Security in Real Time Systems group providing links to HeartBleed information for Emerson, and Insys.

There is probably more ICS HeartBleed information out there if you have the time to search. It sure would be nice if ICS-CERT were doing that for the community.

ICS-CERT Publishes 2 Advisories

This afternoon the DHS ISC-CERT published to control system security advisories. One was a Crain-Sistrunk DNP3 vulnerability on Televen RTUs and the second was a NULL pointer dereference vulnerability in the 3S CoDeSys Runtime Toolkit. Both were coordinated disclosures.

Schneider DNP3 Advisory

The DNP3 vulnerability was a standard improper input validation vulnerability. According to the Robus web site, this is number 16 of now 28 (they have recently updated the total number) coordinated disclosures that Crain and Sistrunk have made based upon their proprietary fuzzer technology; still 12 more DNP3 vendors to go.

This advisory was originally posted on the CERT secure portal back on January 6^th and it was disclosed on the Schneider Electric web site on December 30^th. Schneider has produced a patch to mitigate the single vulnerability (based upon the CVSS v2 score it is probably the serial version of the vulnerability). There is no mention in the Advisory if Crain-Sistrunk were given a chance to validate the patch.

According to ICS-CERT a relatively low skilled attacker could remotely exploit this vulnerability to execute a denial of service attack.

The internal Schneider version of the advisory (.PDF Download) Schneider did more than just fix this vulnerability in the firmware update. They note that:

“In addition to better checking DNP3 input for malformed packets, the J0 firmware includes features for encryption, authentication, improved logging and DNP3 connection port validation.”

 CoDeSys Advisory

This advisory identifies a vulnerability reported by Nicholas Miles. 3S has developed an update that corrects the vulnerability and Miles has reported that it effectively mitigates the problem.

ICS-CERT report that a moderately skilled attacker could remotely exploit this vulnerability to cause a system crash within the Runtime Toolkit appliecation.

ICS-CERT provide a URL for the CoDeSys download page, but I don’t actually see this update unless it is the SP3 Patch 9 that was released last week (1-24-14), but it sure doesn’t look like it from the details provided.

Missed Vulnerabilities

There have been a couple of TWITTER notices by Joel Langill (@SCADAHacker) about ICS vulnerabilities that have not yet been noticed by ICS-CERT:

@SCADAhacker #ICS Vuln Alert: Emerson Network Power Avocent MergePoint Unity 2016 KVM Directory Traversal Vulnerability http://h4ckr.us/1jDnLt4 

@SCADAhacker #ICS Vuln Alert - #Schneider - Floating License Manager Unquoted Service Path Vulnerability (15/01/2014) http://h4ckr.us/1fpveXu  #SHnews

Twitversation - ICS Security and Medical Devices

Joel Langill (@SCADAhacker), a long time reader, ICS Security Expert and commentor, started an interesting twitversation about the latest ICS-CERT medical device advisory. He started with this Tweet®:

“I think it is a bit strange that @ICSCERT is also handling medical devices. A real stretch for an #ICS. Are they losing focus here?”

Medical Devices vs Industrial Control Systems

In one respect I agree with Joel, while medical device security is important it really isn’t in exactly the same realm as industrial control system security. The scope of the consequences is different by several orders of magnitude; potentially thousands of deaths from a successful attack on a major chemical plant control system while a successful medical device attack would only affect the person wearing the device.

Of course, the Phillips Xper advisory wasn’t about an individual device, this system is used in monitoring systems that potentially handle hundreds of patients at a major hospital. That is still a couple of orders of magnitude different than that chemical plant in the terms of people at risk, but it is much closer to an industrial control system than an implanted device.

But, while the scope of the ultimate vulnerability is much different, the similarities in how the systems work and how they become vulnerable to outside attack are very great. Looking at the ICS-CERT description of the Xper vulnerabilities you could have blocked out the ‘Xper’ name and this could have described revealed vulnerabilities in any number of classical industrial control systems.

ICS-CERT Role

Joel asks if ICS-CERT is losing its focus with advisories like this. Others would argue that it doesn’t have any focus to lose. The important thing to remember here, though, is that this was just an advisory, something that took relatively little effort by ICS-CERT, and that effort was nearly identical to what they do for any coordinated disclosure.

If this had been about a fly-away team going out to investigate this vulnerability the focus question might have been more appropriate. But even so, if the fly-away team were going out to aid in deciphering an attack on an Xper system as part of a criminal investigation, I don’t think anyone would really complain too much.

The other side of this is that while the Xper system is not exactly an industrial control system, in the media realm it is probably more important. Because the vulnerabilities and exploits were so similar to a more classical ICS-CERT advisory, this publication might be more beneficial to raising the public awareness of the potential problem in a way that a Siemens or Rockwell advisory never will; a medical device is personal and more concrete in the eyes of JQ Public.

And think of this. On many occasions I have said that there will not be any significant improvement in ICS security until there is a public incident, a successful attack, that convinces boards, politicians and the public that the problem is real. Pardon this cold and heartless calculation, but a successful attack on an implanted medical device that kills one patient will provide that ‘public incident’ at a much lower societal cost than a successful attack on a chemical plant or the electrical grid.

No Joel, I think that ICS-CERT was right in publishing this advisory. Besides, what else were they doing anyway?

Reader Comment – 03-08-13 – Emerson Responds

I am really happy to note that Jeff Potter [Corrected mispelling of name, 03-09-13 21:15 CST], EPM Director-Security Architecture at Emerson has posted a comment on my blog post about the ICS-CERT alert concerning their DeltaV controllers. Vendor clarification of issues raised here or in the ICS-CERT alerts and advisories is always welcome.

The only potentially negative thing that I said about Emerson was a question about the wording of advisory about when Emerson notified their customers (the ICS-CERT advisory says “will notify”). Jeff clears up the point by noting that their customers were notified before the ICS-CERT advisory was published. So it appears that this was an ICS-CERT editorial issue.

An important point that Jeff makes in his comment, that was alluded to in Joel’s comment, is the fact that the original vulnerability discovery only concerned the MD controllers. Emerson work on the issue expanded the disclosure to their SD controllers as well. I think that it is always important for vendors to take that extra step to see if other products have the same or similar vulnerabilities.

More Info on Recent ICS-CERT Advisories

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

When is a Vulnerability not a Vulnerability?

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

Quality of Write Ups

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

Responsible ICS-CERT

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

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

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

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