ICS-CERT Updates Petya Alert (#3)

Today the DHS ICS-CERT published their third update of the Petya Variant Alert that was originally published on June 30^th, 2017, and then updated on July 3^rd and again on July 5^th. Today’s update provides links to additional vendor information sites:

• Beckman-Coulter (an addendum to their WannaCry info);

• Phillips (a discussion on their security webpage); and

• Smiths-Medical

Interestingly, both Phillips and Smiths-Medical provide links to Microsoft® sites. The Phillips links to the new Microsoft Petya article which contains another link to the manual method for turning off SMBv1 if applying the MS17-010 update is not an option. Smiths-Medical links back to the WannaCry article.

ICS-CERT Updates Petya Alert (#2)

Today the DHS ICS-CERT published the second update to their Peta Variant Alert. That alert was originally published on June 29^th and first updated on July 3^rd.  This update adds new links to malware information from US-CERT and two new suppliers.

The US-CERT links include:

• Alert (TA17-181A) Petya Ransomware

• Malware Initial Findings Report (MIFR) - 10130295.pdf

• MIFR-10130295_stix.xml

• TA-17-181B_IOCs.csv

The two new vendor links were for Johnson & Johnson, and Schneider.

The only really new information here is the data on indicators of compromise from US-CERT.

ICS-CERT Publishes WannaCry Update (#9)

Today the DHS ICS-CERT published their first WannaCry update in almost two weeks. The last update was published on May 31^st for the alert that was originally published on May 15^th, 2017. The update includes a link to new vendor information and a link to the update in the STYX format, a machine readable format for sharing cyber threat information.

The new vendor information comes from Johnson & Johnson. The Update provides a link to a new ‘Security Advisories’ page which contains links to two product advisories; Certus®140 System, and Carto®3 System. No really new information is available in either document.

ICS-CERT kept the original Johnson & Johnson link in the Update. Unfortunately, that link now has nothing to do with WannaCry. All mention was removed leaving it just a generic cybersecurity disclosure reporting page. That link probably should have been removed from the Update.

ICS-CERT did miss reporting on Siemens WannaCry updates for a number of their products, including (thanks to the Siemens ProductCERT for their tweets):

• Ultrasound products, published June 1st;

• Mammography products, published June 1^st;

• Multimodality Workplace products, published June 1^st;

• Siemens Healthineer products, published June 1^st; and

• Advanced Therapy products, published June 9^th.

These were just mainly product update reporting.

BTW: I half expected to see an ICS-CERT alert on CrashOverride today since US-CERT came out with their alert today. I’m still reading the Dragos paper but it sounds interesting. More to come, I’m sure.

Sigh – ICS-CERT Updates WannaCry Alert Again (#8)

Today the DHS ICS-CERT published another update to their WannaCry Alert that was originally published on May 15^th. There is no new information specifically from ICS-CERT, but links are provided to information from four new vendors:

• Beckman Coulter (multiple products);

• Samsung (generic);

• Toshiba (generic); and

• Toshiba Medical Systems (generic).

Beckman takes a very detailed approach, but one that is significantly different than the one Siemens has used. They start off by providing a single web page that is the source of information about each of their product lines. Then they classify each product into specific and limited categories:

• Not a Microsoft OS – no problem;

• Microsoft patch has already been deployed by Beckman;

• Neither patch nor WannaCry is applicable to the version of Windows® used;

• Products where hardware firewall is recommended;

• Products where detailed specific recommendations are provided; and

• Oops, we don’t know yet; wait for more information.

Each time Beckman identifies a product as a firewall candidate, they include a link to an interesting article about firewall protections against WannaCry by the NH-ISAC. The Q&A at the end of that brief article is particularly well done. I am surprised that ICS-CERT has not included that link in this Alert.

ICS-CERT Updates WannaCry Again (#7)

Today the DHS ICS-CERT published yet another update (#7) to their WannaCry Alert that was originally published on May 15^th. While the previous updates just generally added links to vendor reports on affected products this one provides new information about the expansion of the number of malware that exploit the same Windows® SMB vulnerability used by WannaCry. It also continues to add new links to new and updated vendor information

More Malware

This update provides a very brief discussion about three additional malware examples that use the same Windows vulnerability. Those malware are:

• UIWIX ransomware;

• Adylkuzz Trojan; and

• EternalRocks worm

New Vendor Links

The update provides links to a new vendor information product from Johnson Controls. Additionally, links are provided to updated information products from Siemens (Computed Tomography Products, Magnetic Resonance Products, and Biograph mMR). No really new information in any of these documents.

ICS-CERT Updates WannaCry Again (#6)

Yesterday the DHS ICS-CERT provided their 6^th update to their WannaCry Alert that was originally published on May 15^th and last updated on May 22^nd. They added links to vendor advisories from:

• Spacelabs Healthcare; and

• Dräger

Both of these vendor advisories make an important note of one of those problems that have not generally been mentioned in the WannaCry debate; control system compatibility with operating system updates. Both vendors specifically state that they have verified the operation of the their Windows® based products with the March MS update that dealt with the SMB vulnerability that underlies the WannaCry attack.

I did a more lengthy post on this issue back in January of 2012 and it is something that all ICS owners should be aware of. Automatic updating of the OS on the machine upon which the industrial control system resides is not necessarily a good thing. Add to that the cases where the ICS is so intertwined with the MS-OS that the vendor has to issue their own patch (see the Spacelabs discussion about their XTR 96280) to implement the MS fix. This results in an additional delay between the identification of the problem and the time that the device owner has any chance of fixing it.

Just one more problem with implementing security on industrial (and medical, and ….) control systems.

ICS-CERT Updates WannaCry Alert Again (#5)

For the fifth consecutive business day ICS-CERT has updated its WannaCry Alert that was originally published on May 15^th, 2017. Today’s update includes:

• Updates of two previously issued Siemens Security Advisories (Imaging and Diagnostics Products; and (Laboratory Diagnostics Products);

• Adds a new Siemens Security Advisory (Ultrasound Products); and

• A link to a Honeywell Security Update.

I have not mentioned it to date because I have been expecting ICS-CERT or US-CERT to mention this in their alerts (they have not done so as of yet), but Siemens has been reporting since their first advisory publication that there are actually six vulnerabilities involved in the WannaCry malware. Those are:

• CVE-2017-0143 - Windows SMB Remote Code Execution Vulnerability (Input Validation);

• CVE-2017-0144 - Windows SMB Remote Code Execution Vulnerability (Input Validation);

• CVE-2017-0145 - Windows SMB Remote Code Execution Vulnerability (Input Validation);

• CVE-2017-0146 - Windows SMB Remote Code Execution Vulnerability (Input Validation);

• CVE-2017-0147 - Windows SMB Information Disclosure Vulnerability (Information Leak / Disclosure); and

• CVE-2017-0148 - Windows SMB Remote Code Execution Vulnerability (Input Validation)

I’m not sure that this really provides much in the way of actionable information. Both the Mitre CVD and NIST CVE listings for these CVE are dated from before the WannaCry outbreak. The Microsoft TechCenter reports for these CVE are also dated; still reporting that there have been no exploits of the vulnerabilities.

ICS-CERT Updates WannaCry Alert Again (#4)

For the fourth day in a row the DHS ICS-CERT updated their alert for the WannaCry ransomware. It was originally published on Monday and the latest update was yesterday. Today’s update adds links to WannaCry notifications from the following vendors:

• Siemens (Radiation Oncology Products; Biograph mMR; Point-of-Care Products; and  Advanced Therapy Products);

• Tridium; and

• Emmerson DeltaV

The update also provides a link to a general WannaCry support document from Siemens Healthineers. This document and a further linked Siemens’ blog post provides a good technical discussion of the WannaCry problem and solutions; including links to Microsoft updates for ‘unsupported’ (outdated?) Windows operating systems still in use by Siemens Healthineer (and too many other industrial control) products.

ICS-CERT Updates WannaCry Alert, Updates 2 Advisories and Publishes 2

Yesterday the DHS ICS-CERT published another update of their WannaCry ransomware alert, updates for two advisories, and published new advisories for products from Schneider Electric and Miele Professional. They also published a notice about the date of the Fall 2017 ICSJWG meeting in Pittsburg, PA on September 12-14, 2017.

WannaCry Update

This update provides new information on the alert published on May 15^th and updated on May 16^th and again on May 17^th. Unfortunately, I missed yesterday’s update so I will list both sets of changes at one time. The new information includes WannaCry advisories from the following vendors:

• Siemens (Multi-Modality Workplace (MMWP) products; Magnetic Resonance Products; Laboratory Diagnostics products; Computed Tomography products; Radiography, Mobile X-ray and Mammography products; Molecular Diagnostics products; and Molecular Imaging products) (NOTE: the language is nearly identical on all 8 Siemens advisories);

• General Electric;

• Phillips (general security web page, scroll down to WannaCry article);

• Smiths Medical;

• Johnson & Johnson (general security web page, scroll down to WannaCry article); and

• Medtronic

GE Proficy Update

This update provides new information on the advisory originally published on January 17^th, 2017 and updated on January 24^th. The update provides links to updates for the following products:

• GE has released new versions of the Historian software, Version 6.0 SIM 9 (Standard and Enterprise);

• GE has released a new version of the Historian software, Version 5.5 SIM 37;

• GE has released a new version of the CIMPLICITY software, Version 8.2 SIM 49; and

• GE has released a new version of the CIMPLICITY software, Version 9.0 SIM 22

NOTE: The contact information for receiving CIMPLICITY v9.5 and Historian v7.0 have inexplicably been removed from this update. GE still recommends updating to these versions.

GE Multilin Update

This update provides new information on the advisory originally published on April 27^th, 2017. The update adds two new affected product lines to the advisory:

• Universal Relay, firmware Version 6.0 and prior versions, and

• URplus (D90, C90, B95), all versions.

Update information is provided for the Universal Relay products. GE expects to release the URplus firmware updates in July. The 369 Motor Protection Relay firmware update is still expected to be released next month.

Schneider Advisory

This advisory describes an incorrect default permissions vulnerability in the Schneider Wonderware InduSoft Web Studio. The vulnerability was reported by Karn Ganeshen. Schneider has released a new service pack to address the vulnerability. There is no indication that Ganeshen has been provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that a relatively low skilled attacker with authorized access could exploit this vulnerability to escalate his or her privileges. The Schneider Security Notification expands that to state:

“The directory and files are added to system's PATH. Therefore, they can be manipulated by non-administrator users to write malicious files/DLLs and escalate privileges once these are executed.”

Miele Advisory

This advisory describes a path traversal vulnerability in the in the Miele Professional PG 8528, a large capacity cleaner and disinfector used in hospitals and laboratory settings. This advisory provides updated information on the ICS-CERT alert on this vulnerability reported on March 30^th, 2017. ICS-CERT still does not provide a link to the public disclosure by Jens Regel. Miele has provided software updates to mitigate the vulnerability. There is no indication that Regel has been provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that a relatively unskilled attacker could remotely use the publicly available exploits to read or modify sensitive data or files, execute unauthorized code or commands, and possibly cause a system crash.

ICS-CERT Updates an Advisory and an Alert

Yesterday the DHS ICS-CERT updated two control system security notices; one an alert for the BrickerBot vulnerability and the other affecting products from Belden Hirschmann.

BrickerBot Update

This update provides new information on the alert that was originally published on April 12^th, 2017. The update more specifically acknowledges the Radware contribution to the state of current knowledge about BrickerBot. It also provides:

• A slightly more detailed and updated description of the operation of both BrickerBot.1 and BrickerBot.2; and

• A new mitigation measure; updating Ubiquiti device firmware.

Belden Hirschmann Update

This update provides new information on the advisory that was originally published on January 26^th, 2017. The update expands the scope of the advisory; adding three new vulnerabilities that were apparently fixed with the originally reported new software version. The newly reported vulnerabilities are:

• Server-side request forgery - CVE-2017-6036;

• Cross-site request forgery - CVE-2017-6038; and

• Information exposure - CVE-2017-6040

Belden did not change their original Security Bulletin. Instead, they issued an additional Security Bulletin to describe the ‘new’ request forgery vulnerabilities. Belden actually describes the cross-site request forgery as a subset of the server-side request forgery, rather than specifically listing it as a separate vulnerability. Belden never does specifically acknowledge the ‘information exposure’ vulnerability reported by ICS-CERT.

Interestingly, the only change that ICS-CERT makes to their ‘impact’ statement designed to reflect the additional vulnerabilities is to change the words ‘of this vulnerability’ to ‘of these vulnerabilities’. It does not acknowledge the Belden report that the ‘new’ vulnerabilities may allow an attacker to “trick administrators into changing the configuration of the device”.

ICS-CERT Updated MEMS Accelerometer Alert

Today the DHS ICS-CERT updated their control system security alert for physical vulnerabilities in a wide variety of MEMS accelerometers. The original alert was published on March 14^th, 2017.

Today’s update provides a link to another manufacturer’s (Analog Devices) alert about the problem with a slightly different look at the vulnerability.

Interestingly, ICS-CERT still does not provide acknowledgement of researchers who discovered the vulnerability nor does it provide a link to their academic paper that describes the vulnerability. Nor does it mention the cute vulnerability name that has been attached to the problem by the researchers; ‘Walnut’. I guess that ICS-CERT is the tough nut to crack.

ICS-CERT Updates Moxa Alert Again

This afternoon the DHS ICS-CERT published a new update to their Moxa alert (originally issued on April 8^th and then updated on April 20^th). The new update adds an acknowledgement of the original disclosure and more details about the ports involved in the vulnerabilities.

The Changes

The Alert now reports that Reid Wightman of Digital Bonds Labs was the original reporter of the five vulnerabilities upon which this alert was based. It also now acknowledges that Reid did coordinate with Moxa (but not, shame for shame, with ICS-CERT).

A paragraph has also been added to the mitigation section of the report that lists the ports that Moxa recommends should be either blocked or have access restrictions applied. The list of ports was in the original alert, but was removed in the first update. The port information in this update is more complete in that it distinguishes between the ports that are not needed by the device and the ports that may be used in normal operation. The same information was available in the DBLabs report that was responsible for the initiation of this alert.

Intellectual Property

I am glad to see that ICS-CERT is finally giving Reid credit for discovering these vulnerabilities. ICS-CERT has had an on-again, off-again policy of disclosing the researchers responsible for alerts. I understand that ICS-CERT would prefer that they (or some other CERT) would be used as a disclosure intermediary. Their thought is that their official office can apply more pressure to vendors to take vulnerability reports more seriously. While that may be true (more on that later) that should have nothing to do with giving credit where credit is due. Not giving credit smacks of theft of intellectual property.

Vulnerability Coordination

Now as to the larger question of the role of ICS-CERT as a coordinator of vulnerability disclosures, let’s take a look at that role. First off, I have seen nothing in legislation or regulation that provides ICS-CERT with any specific authority to act as such a coordinator. That probably is not really necessary as long as researchers and vendors mutually recognize ICS-CERT as an independent arbiter of disagreements about the legitimacy of vulnerability claims, on the one hand, and the legitimacy of vendor mitigations on the other hand.

It is becoming increasingly obvious that there are elements within the research community that no longer have much respect for ICS-CERT as a dispassionate intermediary. I have read a number of social media comments over the last year or so from a number of different researchers that expressed their concerns about the apparent willingness of ICS-CERT to side with the vendors when there is a disagreement on vulnerabilities.

Appearance of Favoring Vendors

In my very limited interactions with ICS-CERT, I have never had any problems. But then again, I am a security gadfly not a researcher. But that really does not make any difference. As I told young NCO’s in numerous leadership classes; it doesn’t make a damn bit of difference if you are or are not prejudiced. If those that report to you think you are prejudiced, then they are going to respond to you as if you were prejudiced.

At the very least ICS-CERT has a problem with the appearance that they favor vendors when there is a dispute between researchers and vendors. That appearance is going to help drive away researchers, particularly those without enough of an industry reputation to have their disclosures stand on their own merit. Those researchers are going to take less desirable modes of disclosure, public zero-day disclosures or, even worse, sell disclosures to the highest bidder.

This is particularly disturbing as the ICS security world is expanding by leaps and bounds. The number of researchers in this space is continuing to expand as new researchers (and established researchers from other fields) continue to see ICS research as an expanding field. Even more important the number of vendors affected by ICS vulnerabilities is also increasing as more industries (medical, automotive, aircraft, and security controls) begin to realize that their control systems have important security vulnerabilities that are no longer masked by obscurity.

Need for Coordination

The other question that this specific set of vulnerabilities raises is whether or not a disclosure coordinator is really needed. A legitimate case can be made that new researchers in the field, without a well established reputation, probably do need to have an independent agency act as a go between particularly when the security issues being raised are novel or difficult to understand.

That was certainly not the case here. Reid Wightman is not, by anyone’s measure, an ICS neophyte. He has a well-established personal reputation built across a number of organizations. That plus his current association with Digital Bond Labs should provide as much weight to the vulnerability disclosure as could ICS-CERT. He should be able to approach any ICS vendor in the world and have his report of vulnerabilities taken seriously and promptly acted upon. I question the commitment to security of any vendor that fails to respond promptly to a researcher of Reid’s stature and knowledge.

To take over a year to correct serious security vulnerabilities (and we are hoping that they will be completed in August as promised) is inexcusable. Particularly when the devices in question exist in a critical communications nexus in so many critical installations. Even if there is a legitimate reason for it taking a year to correct all of the problems (and I find that difficult to believe) most of these issues could certainly have been corrected well before now.

The Siemens model of disclosing a vulnerability even before all of the affected devices have patches/updates available is one that deserves close study by the industry. This is particularly true when there are legitimate methods of reducing the risk of vulnerability exploits that the owner can take while waiting for an update to become available.

A Good Step Forward

In closing, I want to make a clear statement that I think ICS-CERT took a valuable and correct step today with their making these changes to the Moxa Alert. Reid deserves credit for the vulnerability discovery and for his efforts to properly disclose those vulnerabilities to Moxa. System owners deserve to have the information on mitigation measures that are now available in the Alert. I continue to believe that ICS-CERT has an important role to play in coordinating vulnerability disclosures. The changes made today will help to ensure that they look like they are playing the role of a disinterested intermediary that both sides can respect and trust.

ICS-CERT Updates (Changes) Moxa Alert

Yesterday afternoon the DHS ICS-CERT updated the Moxa Alert that was originally released on April 8^th. ICS-CERT reports changes in three areas of the Alert, the summary section, the list of affected equipment and the mitigation section. As was true with the original release, there is some controversy associated with this revision of the alert.

Changes in Summary

First the update removes a general description of the uses of the affected equipment from the Summary. Then it removes the statement that: “The researcher released the report after initially coordinating with the vendor.” Finally, it provides updated information from Moxa confirming all five of the vulnerabilities reported by Digital Bond LABS instead of the just 3 of 5 confirmed in the original Alert. The Alert still does not list DBLABS as the source of the public report of the vulnerabilities.

The removal of the initial coordination statement appears to be a political move by ICS-CERT to minimize the issue that Moxa still does not plan on issuing a fix to the problems until ‘late August 2016’. The revised language makes it look like Moxa was blindsided by the April 5^th report and are diligently working on a firmware update. They may be working on an update now, but the DBLABS report provides a timeline showing that Moxa was notified of the vulnerabilities on July 24^th, 2015.

Changes in Products Affected List

The revised Alert reformats and expands the list of affected Moxa NPort devices affected by the five vulnerabilities. It also indicates that Moxa acknowledges the defect in the new list of affected devices. The DBLABS report suggested that more devices than they originally reported were probably affected by the vulnerabilities, acknowledging that the ones listed in the report were the only ones that they had tested.

Interestingly, some of the devices tested by DBLABS do not appear on the revised list of affected devices. These include Moxa NPort 6150/6250/6450/6610/6650, firmware release 1.13. Also interesting to note is that DBLABS was careful to list the firmware versions of the devices they tested and there are no version numbers on the revised list in this update. This indicates that the problem is nearly universal across the NPort product line.

Changes in Mitigation

The third section of changes to the Alert actually over laps mitigation section heading and includes the last two paragraphs from the summary section. Changes were made in those two paragraphs as well. First the new version eliminates the list of affected port numbers provided by DBLABS. Second it removes the description of the uses of the affected NPort devices. That description had stated that:

“The Moxa NPort 6110 device is a Modbus/TCP to serial communication gateway that integrates Ethernet and serial Modbus devices. The Moxa NPort 5100 series and 6000 series devices are serial to Ethernet converters that can be used to connect serial devices to an Ethernet network.”

The changes in the mitigation section of the Alert deal mainly with the fact that Moxa now acknowledges all five of the reported vulnerabilities and reports that the expected August update will mitigate all five. Moxa continues to report that it will not be updating the firmware for the NPort 6110 since that was discontinued in 2008.

Finally, ICS-CERT removed the statement that: “Password protecting the configuration file for the NPort 5100 and 6000 series devices has been reported by the vendor to prevent the upload of unauthorized binary files to the device.” It has been replaced with the more generic and even less helpful (but more truthful): “Set up access control to affected devices to prevent any unauthorized access.”

The Controversy

While it appears that this update was a political response to satisfy the sensibilities of Moxa, or maybe minimize the concerns of the owners of the NPort devices, it did nothing to sooth the outrage of the investigators who had attempted to ‘properly’ coordinate their disclosure of these very serious vulnerabilities with the vendor.

Last night there was an interesting exchange of TWEETS® between Reid Wightman (@ReverseICS) the author of the original DLABS report and Dale Peterson (@digitalbond) the owner of Digital Bond. Now admittedly, Dale and Reid are very vocal (and persuasive) complainers about insecure by design ICS devices (which might legitimately include the noted overwrite firmware vulnerability), but insecure passwords, buffer overflow, cross-site scripting and cross-site request forgery vulnerabilities are just plain, old-fashioned, sloppy programming problems. And taking over a year to correct that crappy programming is just unforgiveable.

I am more than a little concerned that the ICS-CERT alert continues to ignore two very important points made in the DBLAB report. First the fact that Moxa serial converter devices were targets in the December cyberattacks on the Ukraine grid and that they were bricked by over-writing the firmware. Second that DBLABS has shared at least one report of a live exploit of an NPort device with Moxa.

Finally, the mitigation measures mentioned in the Alert are totally inadequate to provide any sort of protection of these devices in the field. And that is totally inexcusable since the DLABS report provides detailed mitigation measures based upon the vulnerable ports (again those port designations were removed from the alert). If the list of the vulnerable ports had not been removed from the Alert, ICS-CERT might have been forgiven for not quoting the DLAB mitigation suggestions, but they did and I’m not.

I have been a champion in this blog of the vulnerability coordination activities of ICS-CERT, even suggesting that they be made responsible for coordination activities for NHTSA, the FAA, and the FDA. With blatant industry pandering like this alert update, I think that I am going to have to re-think that position.

ICS-CERT Updates KACO Alert

Two days ago ICS-CERT published a minor update to their alert from August, 2015 for a hard-coded password vulnerability in KACO HMI products. The revised version added a single sentence to the summary portion of the Alert:

“According to this report, the password is easily found in the client code.”

I have no idea why ICS-CERT thought that this was important enough to add to the alert seven months after it was originally published. I suppose that it could be because KAKO has not been responsive enough in addressing this vulnerability.

Readers of this blog might be more than a little surprised that it has taken me two days to report on this update. The reason for that is simple, I just received an email this morning from ICS-CERT advising me of the recent update; this notification is a service that anyone can sign up for and I have previously mentioned it. A couple of months ago ICS-CERT changed their policy of listing updates to their alerts and advisories on their landing page. They had been making Twitter® notifications of these revisions, but did not do so in this case.

There are a couple of other oddities about how they handled this update. Normally ICS-CERT annotates changed versions of alerts and advisories by sequentially adding a letter to the end of the advisory number; for example, a first update would be labeled ICS-ALERT-16-074-XXA. They did not do that in this case. Another thing that they normally do is to highlight the changed areas in the body of the alert or advisory. Again, they did not do so in this case.

Now, none of these irregularities has a real impact on the information presented and in this case the change to the document is so minor that perhaps they thought that all of these additional details were not needed.

Just for the record here is the personal web site of the researcher, Aditya K Sood, who reported this vulnerability and a link to video of his presentation where he publicly disclosed this (and at least 3 other) HMI zero-days.

In any case there are muckrakers and nitpickers like me to keep the public informed, so now you know about this minor change and the oddities that go with it. I’ll leave it to the reader to figure out what this all means.

ICS-CERT Updates Two Rockwell Alerts

This afternoon the DHS ICS-CERT updated two alerts that it issued for Rockwell PLC’s last week. The updated alerts (here and here) have the same, single-sentence addition made:

“This vulnerability was discovered by Aditya K. Sood and presented by him at DefCon 2015 in Las Vegas, Nevada, on August 8, 2015.”

This means that all six of the DefCon related alerts that ICS-CERT published last week come from the same talk. Strange that none of the other talks about ICS security matters merited an alert, advisory or update of a previously issued advisory.

ICS-CERT Updates Havex Alert

Last night the DHS ICS-CERT published an updated version of their alert for the Havex Trojan. The update provides a more complete description of the actions of the Havex Remote Access Trojan (RAT), though still not as detailed as the original F-Secure blog post. It does, however, report for the first time a separate operational issue with the Havex RAT:

“It is important to note that ICS-CERT testing has determined that the Havex payload has caused multiple common OPC platforms to intermittently crash. This could cause a denial of service effect on applications reliant on OPC communications.”

This would not be expected to be a deliberate design element of the Trojan, but it could serve as an indicator of a potential Havex attack for organizations that do not have operational system logging capabilities.

ICS-CERT Still Restricting Information

ICS-CERT is still restricting information about the known ‘watering hole’ sites to the US-CERT secure portal. I agree with Dale Peterson’s Tweet that this probably slows the community response to this threat vector as only a very limited number of control systems organizations currently have access to this information source. ICS-CERT continues to provide information on how to request access the US-CERT secure portal:

“ICS-CERT encourages US asset owners and operators to join the control systems compartment of the US-CERT secure portal. To request access to the secure portal send your name, email address, and company affiliation to ics-cert@hq.dhs.gov.”

This is a very low threshold to pass to gain access to this information. While we can (and should) debate whether or not ICS-CERT should be restricting access to information that the source of the Havex attack already knows (and the F-Secure blog post identifies clearly enough for the attacker to know which compromised sites have been identified), any organization that uses an OPC server in their control system architecture should apply for access to this information.

Mitigation Measures

The update also significantly expands the mitigation measures that organizations can use to limit the activity of the Havex Trojan. There is not anything new here, but this appears to be a pretty good list of actions to take to secure control systems in general. ICS-CERT does not provide any specific indicators of compromise in this alert, but they do provide a link to the F-Secure blog post on this RAT from Monday that does contain some of those indicators.

Presumably more up-to-date indicators are available through the US-CERT secure portal. This is another reason for potential targets to request access to the US Cert Secure Portal.

Information Sharing

ICS-CERT continues to request that organizations that know or suspect that they have been compromised by Havex contact ICS-CERT. Any new information that may be provided by users will make the ICS-CERT investigation of this malware more complete.

This would be a very good point in time to have federal legislation in place that would provide safeguards for organizations that wish to share this type of information with ICS-CERT. At a minimum such information sharing activities should be protected to limit liability concerns and restrict what detailed data the government can share with other organizations, both governmental and private sector.

Lacking such specific cybersecurity information sharing protections, anyone submitting detailed information to ICS-CERT should attempt to avail themselves of the protections provided by Protected Critical Infrastructure Information (PCII) program. At an absolute minimum any information submitted to ICS-CERT should specifically include the following PCII Express Statement:

“This information is voluntarily submitted to the Federal Government in expectation of protection from disclosure as provided by the provisions of the Critical Infrastructure Information Act of 2002.”

A better method would be to include the ‘Express and Certification Template’ found in Appendix 5 of the PCII Procedures Manual.

ICS-CERT Updates Sign Alert and Publishes new OpenSSL Advisory

Today the DHS ICS-CERT published an update to yesterday’s alert about an automated road sign system and an advisory for a new vulnerability in OpenSSL. Neither system is what comes to most people’s minds when the term ‘industrial control system’ is mentioned. The first extends the definition because apparently ICS-CERT doesn’t already have enough on its plate and the second reminds us that secure communications is a key component of any secure cyber-system.

Daktronics Alert Update

Today’s update brings new information about the scope of the vulnerability and an expansion of the interim mitigation measures suggested by Daktronics and the Federal Highway Administration, the organization that notified ICS-CERT of this particular vulnerability.

According to Daktronics the ‘hard coded credential’ is actual a default password that can (and obviously should be) changed when the system is installed. I can understand why the FHA gets the two vulnerabilities confused, after all (SARCASM WARNING) they are a well-known font of control system security knowledge.

Then Update also includes three ‘device specific’ mitigation measures to add to the standard ICS-CERT generic security measures. The new mitigation suggestions are:

• Displays should not be on publicly accessible IP addresses. Placing a display on a private network or VPN helps mitigate the lack of security,

• Disable the telnet, webpage, and web LCD interfaces when not needed, and

• Change the default password to a strong password as soon as possible on all installed devices.

Nothing really new there; I hope that that is because ICS-CERT is not spending valuable resources on this particular vulnerability.

OpenSSL Advisory

Remember how upset the control system security community was with the initial ICS-CERT about the HeartBleed vulnerability because there was so little actual control system information available in the initial advisory. Well the folks at ICS-CERT did not learn the lesson, today’s advisory about the multiple vulnerabilities recently corrected by OpenSSL contains even less information. They don’t even list the vulnerabilities involved.

According to the OpenSSL Security Advisory the vulnerabilities include:

• SSL/TLS MITM vulnerability (CVE-2014-0224)[This was the only vulnerability mentioned in the KB-CERT Advisory that I tweeted about this morning];

• DTLS recursion flaw (CVE-2014-0221);

• DTLS invalid fragment vulnerability (CVE-2014-0195);

• SSL_MODE_RELEASE_BUFFERS NULL point dereference (CVE-2014-0198);

• SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298); and

• Anonymous ECDH denial of service (CVE-2014-3470)

In many ways we are in the same place we were when the HeartBleed alert was first published, we don’t know what systems use the vulnerable OpenSSL versions. ICS-CERT does point users at their HeartBleed affected list with the following comment:

“NCCIC/ICS-CERT has produced an OpenSSL affected/unaffected products list that specifies which vendors, products, and product versions are affected by the OpenSSL HeartBleed vulnerability. This document also contains a list of vendors, products, and product versions that evaluated their products and have asserted that their products are not affected by the OpenSSL HeartBleed vulnerability. Owners and operators of control systems might use this list to determine whether their equipment may also contain a version of OpenSSL that is affected by these newly reported vulnerabilities. This document will be updated as needed.”

This is helpful for some versions of OpenSSL, but version 0.9.8 were not affected by HeartBleed, but will be affected by some of the vulnerabilities listed above. So some of the vendors listed as clean for HeartBleed may actually have problems with some of these vulnerabilities.

Of course, this is the type of information that we would expect from ICS-CERT. Based upon the HeartBleed experience we can expect to see this type information in version D or E of this advisory. But we are kept up to date on Automated Road Sign vulnerabilities.