More Secure Portal Rumors

This has been an interesting weekend for rumors about ICS-CERT releases on the US-CERT Secure Portal. First I have heard from multiple sources that there may be two or more control system advisories from ICS-CERT currently listed on the Secure Portal. With this you get the normal reminder that critical infrastructure owners and legitimate security researchers may request access to the Secure Portal; see instructions on the bottom of the ICS-CERT landing page.

I have had a single source tell me that the Unitronics advisory I described earlier this week was, in fact, originally released to the Secure Portal on October 1^st as I surmised, but that an updated version was released on that portal on November 3^rd as described in the publicly released version of the advisory. That reasonably explains the discrepancy that I noted in that earlier post.

Finally I am hearing a disturbing rumor (admittedly from a different single source) that there is a control system vulnerability that has been released to a government-only limited distribution section of the Secure Portal. I can certainly see a need for a really limited initial disclosure of an advisory if it was dealing with military hardware for instance. What is disturbing to me is that there is reportedly (again single source without verifiable details) not going to be a public disclosure of the vulnerability. Again, if this would only affect military hardware, that is perfectly legitimate. I just don’t have enough details to make the call.

Another Secure Portal ICS Advisory – 10-05-15

There are rumors that another industrial control system advisory has been released to the US-CERT Secure Portal by the DHS ICS-CERT. Typically these advisories are for high-risk vulnerabilities for control systems used in critical infrastructure. They are released in limited distribution to allow critical infrastructure owners to take appropriate mitigation measures before the vulnerabilities are made public.

Again, I do not have access to the Secure Portal (if I did I would not be able to write posts like this), so I am not able to confirm the veracity of these rumors. Control system owners and ICS security vendors can get access by contacting ICS-CERT (see the bottom of their web page for instructions) and determine if any of the control system applications that they are using have active advisories listed on the Secure Portal.

ICS PHISHING Alert from ICS-CERT

I am hearing rumors that ICS-CERT has published an alert on the US CERT Secure Portal about an on-going phishing campaign directed against various organizations in the chemical and energy sectors. I understand that the alert is supposed to provide specific information about indicators that may be used to detect these attacks. I would urge all organizations in these two sectors (and really everyone else in critical infrastructure) to locate this alert on the Secure Portal.

As usual I have to remind folks that I don’t have access to the Secure Portal (and if I did I wouldn’t be able to post warnings of this sort) so you will have to go there yourself to see if the rumors that I am hearing are true. I also urge every high-risk chemical facility to sign up for access to the Secure Portal so that they have routine access to alerts and advisories that are issued in that venue.

NOTE: The following information comes from the ICS-CERT landing page:

“ICS-CERT encourages U.S. asset owners and operators to join the Control Systems compartment of the US-CERT secure portal. Send your name, e-mail address, and company affiliation to ics-cert@hq.dhs.gov.”

I do not expect that this alert will make it to the public ICS-CERT web site. The type of indicators that I would expect to see on an alert of this sort are time sensitive. They would be released on the Secure Portal because DHS would not want to compromise an on-going investigation of reported attacks.

ICS-CERT Publishes Eaton’s Cooper Advisory

This morning the DHS ICS-CERT published a new advisory for a predictable TCP sequence vulnerability in Eaton’s Cooper Power Systems controls and relays. The vulnerability was initially reported by Dr. Raheem Beyah, David Formby, and San Shin Jung of Georgia Tech. Eaton’s Cooper has produced a patch to mitigate the vulnerability and ICS-CERT reports that the researchers have validated the efficacy of the patch.

ICS-CERT reports that a skilled attacker could remotely exploit this vulnerability to execute a  man-in-the-middle attack.

The Eaton’s Cooper advisory notes that by “ensuring that controls are not accessible from external networks and that appropriate physical security measures are provided at network access points, any risks associated with this vulnerability are greatly minimized”. They also note that the “vulnerability could allow for the potential of spoofing attacks and session hijacking”.

ICS-CERT reports that they had released this advisory to the US-CERT Secure Portal on January 6^th. The company advisory was not issued until July 6^th after the patches had been made available. The fact that the advisory was issued on the Secure Portal so early in the coordination process indicates how serious this vulnerability can be. And this reinforces the need for system owners to regularly check the Secure Portal for information on critical vulnerabilities.

BTW: The Schneider update is still not listed on the ICS-CERT landing page. I wonder what is going on. The updated advisory is available; it is just not listed.

Another ICS-CERT Advisory to Secure Portal

I am again hearing rumors that ICS-CERT has issued a new control system advisory on the US-CERT Secure Portal. I cannot confirm the rumors because I do not have (actually I have declined) access to the Secure Portal.

As always I would recommend that control system owners regularly access to the Secure Portal to see if there are any new advisories posted for their systems. That is, after all, the purpose of this type semi-public release of control system advisories; let the system owners look at the advisory, make the risk-based decision about applying the identified mitigations, and if appropriate,  applying those steps all before the  vulnerabilities are made public.

Out-of-Date Systems

I am told that there is an interesting side bar involved with this particular vulnerability. It seems that the advisory is for a product that is reaching the end of its commercial life and will soon be removed from the market in the foreseeable future (and that frequently means ‘from support’ not too much further down the line). With the high cost of control system components, these devices frequently remain in service for much longer than their sales life. The problem here would be that once the manufacturer stops supporting a device, any subsequently identified vulnerabilities rarely, if ever get patched. This is becoming a serious issue in the current control system environment.

Just today I had an interesting conversation with a gentleman that has been selling medical monitoring devices for a large number of years and is still active in the field. He was complaining to me about some of the new devices coming into the market place were developed to operate on the Windows 7 OS and had problems interfacing with the computers that his customers were using running Windows XP. And he was particularly proud of the fact that he was using Windows XP Professional.

I suppose at this point in time we really have to consider that every XP based computer is compromised, or at least would be if an attacker was interested in the device. This would mean that any device running on an XP system is at least readily compromisable. But, like my friend, many people are really happy running their XP systems until they die (I mean the machines, of course).

More on Yokogawa Advisory

Overnight I have been hearing some interesting information about the Yokogawa Advisory issued by ICS-CERT late yesterday afternoon. It seems as if at least a couple of folks had received emails from ICS-CERT notifying them that an advisory about Yokogawa vulnerabilities had been released to the US-CERT restricted portal.

This would normally have been a standard action to be taken with vulnerabilities in a device/application that is widely used in critical infrastructure or in cases where the vulnerabilities were severe enough that exploitation of the vulnerabilities could reasonably be expected to put facilities at risk. It would certainly seem as if both those conditions were relevant in this case.

The whole point of releasing advisories to the secure portal is to allow critical infrastructure a window of opportunity to take action to protect themselves against exploitation of a control system vulnerability before disclosure is made to the public. People working in critical infrastructure get information about such vulnerabilities pushed to them if they are registered with US-CERT (quite obviously I am not so certified, nor do I, quite correctly, have access to the secure portal; I don’t have an appropriate need-to-know).

In a true coordinated disclosure, I would assume that ICS-CERT would reach an understanding with the vulnerability discoverer about public disclosure of the vulnerability while the corresponding advisory was being closely held within the Secure Portal. There is no indication that Rapid7 disclosed this vulnerability to ICS-CERT. Their disclosure policy (which I noted last night) clearly indicates that they coordinate their disclosure with the Carnegie Mellon CERT (CERT/CC).

I would have like to have thought (and certainly did before last night) that with vulnerabilities as potentially serious as this one, that ICS-CERT would have initiated conversations with the vulnerability disclosure to arrange for a reasonable period of at least limited disclosure to allow the release of the vulnerability in the Secure Portal for some reasonable amount of time. With an organization like Rapid7, that might include allowing them to privately notify their paying clients, but not making general public notification of the vulnerability until ICS-CERT published their public advisory.

For whatever reason, that does not appear to have been done in this case; or at least not effectively. With ICS-CERT apparently releasing this to the secure portal at about the same time that Rapid7 was publishing public notice (with Metasploit modules) indicates that there was some serious miscommunication between the two organizations.

Since yesterday afternoon’s advisory release from ICS-CERT did not include the standard Secure Portal disclosure statement it doesn’t seem that they are willing to publicly discuss this issue for whatever reason. I suspect that it is a political (small ‘p’) issue with ICS-CERT trying to maintain reasonably good relations with the security research community, particularly those that coordinate their disclosures with vendors and/or CERTs. I understand that kind of effort since ICS-CERT has little enough that they can give in the way of incentives to that community to responsibly disclose these vulnerabilities.

This particular situation, however, is quite serious. The disclosure of the Metasploit modules at the same time as the public disclosure of the vulnerability always gives an edge to the potential attackers. Given the fact that that Yokogawa systems are used in critical infrastructure this potentially puts the public at risk. If miscommunication was responsible for that risk, then we need to know about what steps are being taken to prevent such incidents from happening in the future.

At the very least the DHS OIG needs to take a look at this particular incident. Congressional committee’s looking at cybersecurity issues also need to look at this situation and determine what their legislative responsibilities are to help prevent such occurrences from being repeated.

Let’s hope that the owners of these Yokogawa systems, particularly those in critical infrastructure, are able to get these vulnerabilities mitigated before someone aggressively exploits them. I sure don’t like relying in hope.