HR 5733 Introduced – ICS Cybersecurity

Last week Rep Bacon (R,NE) introduced HR 5733, the DHS Industrial Control Systems Capabilities Enhancement Act of 2018 (Note: the link is to a Committee draft of the bill not the official GPO version). The bill would amend 6 USC 148 to provide specific requirements for the National Cybersecurity and Communications Integration Center (NCCIC) to address industrial control system security issues.

Section 148 Amendments

The bill would make two specific amendments to §148. First it would add to the list of principles outlined in paragraph (3)(1) the following language: “activities of the Center address the security of both information technology and operational technology, including industrial control systems;”.

Second the bill would add a new paragraph (f) that would require the NCCIC to “maintain capabilities to identify and address threats and vulnerabilities to products and technologies intended for use in the automated control of critical infrastructure processes.” This would specifically include requirements to:

• Lead, in coordination with relevant sector specific agencies, Federal Government efforts to identify and mitigate cybersecurity threats to industrial control systems, including supervisory control and data acquisition systems;

• Maintain cross-sector incident response capabilities to respond to industrial control system cybersecurity incidents;

• Provide cybersecurity technical assistance to industry end-users, product manufacturers, and other industrial control system stakeholders to identify and mitigate vulnerabilities; and

• Conduct such other efforts and assistance as the Secretary determines appropriate.

Moving Forward

Bacon and both of his cosponsors {Rep. McCaul (R,TX) and Rep. Ratcliff (R,TX)} are members of the House Homeland Security Committee to which this bill was assigned. The bill is currently scheduled to be marked-up by that Committee on Wednesday. While there are no Democratic sponsors for the bill, I expect that it will receive bipartisan support in the Committee and on the floor of the House. It would likely be considered under the suspension of the rules provisions in the House (limited debate, no floor amendments).

Commentary

While I certainly applaud the addition of control system language to this bill, the lack of a definition and changes to other definitions in §148 is likely to cause problems down the road. I would like to offer this definition for addition to §148(a):

Industrial Control System - The term ‘control system’ means a discrete set of information resources, sensors, communications interfaces and physical devices organized to monitor, control and/or report on physical processes including but not limited to; manufacturing, transportation, access control, and facility environmental controls;

Additionally, the following existing definitions need revision:

Cybersecurity Risk - The term ‘cybersecurity risk’ means:

(A) threats to and vulnerabilities of information, information systems, or control systems and any related consequences caused by or resulting from unauthorized access, use, disclosure, degradation, disruption, modification, or destruction of such information, information systems, or control systems, including such related consequences caused by an act of terrorism; and

(B) does not include any action that solely involves a violation of a consumer term of service or a consumer licensing agreement;

Incident - The term ‘incident’ means an occurrence that actually, or imminently jeopardizes, without lawful authority:

(A) the integrity, confidentiality, or availability of information on an information system,

(B) the timely availability of accurate process information, the predictable control of the designed process or the confidentiality of process information, or

(C) an information system or a control system;

I am disappointed that there was no specific mention of cyber emergency response teams, either US-CERT or ICS-CERT. This bill would have been a good place to add mention of them in §148(d)(1)(C). With the addition of industrial control systems to the areas of NCCIC oversight the mention of ICS-CERT would certainly be appropriate, and that mention could not be made without also including US-CERT.

Finally, I am astounded that this bill did not modify the ‘functions’ of the NCCIC, as outlined in §148(c). If the definitions I suggested above were made, at least part of that problem would be corrected because of the frequent references to ‘cybersecurity risk’ and ‘incidents’. Even so the language of §147(c)(7) would still need to add mention of industrial control systems to ensure that the NCCIC appropriately addresses the cybersecurity issues associated with control systems.

ICS-CERT Publishes Jul-Aug 2016 Monitor

Yesterday the DHS ICS-CERT published the latest version of their ICS-CERT Monitor. Lots of DHS ‘corporate’ type news in this issue, but nothing about any industrial control system incidents.

The opening article, which usually describes a recent incident, provides an overview of what types of services ICS-CERT provides when responding to a control system security incident. I had really been hoping to see some more details about the Navis WebAccess problem that resulted in an alert, an incident response alert and an advisory back in August. This was apparently a very limited in application (very small number of systems) incident, but it was an SQL injection attack on a maritime control system in the wild.

Other corporate news included:

• Presidential Policy Directive on Cyber Incident Coordination;

• US-CERT Portal moving to HSIN, changing name in Fall 2016;

• CSET 8.0;

• ICSJWG Fall 2016 Meeting preview;

• NCCIC team wins 1st Place at FIRST Conference in Seoul; and

• ICS-CERT Training pursuing status as accredited provider of Continuing Education Units;

For those readers that really pay attention to ICS-CERT operations, this issue does provide some interesting information. But, if you were hoping to learn something about industrial control system security issues, this is probably a waste of time.

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 Publishes 3 Advisories

This afternoon the DHS ICS-CERT published three control system security advisories. Two of them were for products from IniNet Solutions and the third was from 3S.

CODESYS Advisory

This advisory describes another null pointer exception vulnerability in a CODESYS product, this time the Gateway Server. The vulnerability was reported by Ashish Kamble of Qualys, Inc. 3S has produced a new version that mitigates the vulnerability and Kamble has validated the efficacy of the fix.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerability to crash the server.

This is the same type vulnerability that was reported last week by ICS-CERT in the CODESYS Runtime Tool Kit.

IniNet Solutions SCADA Web Server Advisory

This advisory describes three vulnerabilities in the IniNet Solutions GmbH’s SCADA Web Server. The vulnerabilities were reported by Kirill Nesterov and Aleksandr Timorin of Positive Technologies. IniNet Solutions has produced a new version that mitigates these vulnerabilities, but there is no indication that the researchers were provided an opportunity to verify the efficacy of the fix.

The three vulnerabilities are:

• Stack-based buffer overflow, CVE-2015-1001;

• Improper handling of URL encoding, CVE-2015-1002; and

• Path traversal; CVE-2015-1003

ICS-CERT reports that a relatively low skilled attacker could remotely exploit these vulnerabilities to manipulate and delete files, execute arbitrary code, and initiate a denial of service condition.

ICS-CERT also reports that the affected web server is known to be used in a variety of Beckhoff Embedded PCs. Beckhoff is apparently not accepting any responsibility for the vulnerable application.

IniNet Solution embeddedWebServer Advisory

This advisory describes a password cleartext storage vulnerability in the IniNet Solution eWebServer. The vulnerability was reported by Aleksandr Timorin of Positive Technologies. IniNet Solutions has produced a new version that mitigates the vulnerability, but there is no indication that Timorin was provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that a relatively low skilled attacker with local access could exploit this vulnerability to obtain logon information.

ICS-CERT also reports that the affected web server is known to be used in a variety of Baumüller PCs and Beckhoff Embedded PCs. Baumüller does not plan on updating their affected PCs because they are being retired in December. Beckhoff is apparently not accepting any responsibility for the vulnerable application.

ICS-CERT Publishes one Advisory and Two Alerts

This afternoon the DHS ICS-CERT published an OIsoft advisory for 56 vulnerabilities in one product and alerts on two different Rockwell products. ICS-CERT did not name researchers on Rockwell alerts so we cannot tell if these are DefCon related. The OIsoft vulnerabilities are all self-reported.

OSIsoft Advisory

This advisory almost describes the most serious of 56 vulnerabilities in the OSIsoft PI System software. The categories are listed for the top 25 vulnerabilities based upon risk; they are:

∙ CWE-20: Improper Input Validation (6 issues),

∙ CWE-250: Execution with Unnecessary Privileges (3 issues),

∙ CWE-200: Information Exposure (1 issue),

∙ CWE-476: NULL Pointer Dereference / Denial of Service (13 issues), and

∙ CWE-384: Session Management (2 issues).

OSIsoft has produced a new version of Data Archive that mitigates these vulnerabilities.

Rockwell Alert 1

This alert describes a cross-site scripting vulnerability in Rockwell Automation’s 1769-L18ER/A LOGIX5318ER web interface. A proof-of-concept exploit has been publicly released. ICS-CERT is coordinating with Rockwell.

Rockwell Alert 2

This alert describes a remote file inclusion vulnerability in Rockwell Automation’s 1766-L32BWAA/1766-L32BXBA web interfaces. A proof-of-concept exploit has been publicly released. ICS-CERT is coordinating with Rockwell.

Commentary

How long has OSIsoft known about some of these vulnerabilities. Probably a relatively long time. Luckily for them (we hope) no researcher found these vulnerabilities first. Just think of how many BH/DC presentations were missed because no one was looking.

Rhetorical question to think about: Was OSIsoft marketing behind the notification of ICS-CERT about these vulnerabilities? Great way to get folks to upgrade but might warn off new customers. I guess it could go either way.

Yesterday’s alerts clearly identified researcher who notified ICS-CERT days before public release. Today’s alert without apparent ICS-CERT notification did not get attribution. Is that the way ICS-CERT plans on handling this touchy issue in the future? If so, researchers take note. Drop ICS-CERT a line just before you go public.

ICS-CERT Publishes Four DefCon 2015 Related Alerts

This afternoon the DHS ICS-CERT published alerts for four control system product vulnerabilities that were publicly disclosed during DefCon 2015 by Aditya K. Sood on August 8^th. Proof-of-concept exploit code was presented at the conference.

Three of the four vulnerabilities were disclosed to ICS-CERT shortly before their release in Las Vegas, but they have not yet been able to complete the coordination/verification process with the vendors.

Moxa Alert

This alert describes three password related vulnerabilities in the Moxa ioLogik E2210 Ethernet Micro RTU controller. Two of these vulnerabilities are reportedly remotely exploitable.

Prisma Alert

This alert describes a cross-site request forgery vulnerability and an insufficiently protected password vulnerability in Prisma web products. Both of these vulnerabilities are reportedly remotely exploitable.

Schneider Alert

This alert describes three types of vulnerabilities in Schneider Electric’s Modicon M340 PLC Station P34 CPU modules. Those vulnerabilities include:

∙ Hard-coded credentials (remotely exploitable);

∙ Local file inclusion; and

∙ Remote file inclusion (remotely exploitable).

Some of these vulnerabilities were already in the coordination/mitigation process while others had not been disclosed to either ICS-CERT or Schneider.

Kako Alert

This alert describes a hard-coded password vulnerability in KAKO HMI products. This vulnerability is remotely exploitable.

ICS-CERT Publishes Schneider Advisory

This afternoon the DHS ICS-CERT published a new advisory for a memory corruption vulnerability in the Schneider Electric IMT25 DTM component. The vulnerability was originally reported by Alexander Bolshev, Gleb Cherbov, and Svetlana Cherkasova of Digital Security. Schneider has produced a patch that mitigates the vulnerability and ICS-CERT reports that the researchers have validated the efficacy of the fix.

ICS-CERT reports that it would be moderately difficult to craft an exploit for this vulnerability and notes that access to an adjacent network is required to exploit this vulnerability. The vulnerability is remotely exploitable.

The Schneider Security Notification for this vulnerability explains that the vulnerability “includes a potential buffer overflow that possibly could lead to memory corruption and cause Denial of Service or permit remote code execution”.

ICS-CERT Publishes Two Advisories

This afternoon the DHS ICS-CERT published two advisories for vulnerabilities in industrial control systems from Schneider Electric and Wind River.

Schneider Advisory

This advisory describes a fixed search path vulnerability (Schneider calls it a binary planting vulnerability) in the Wonderware System Platform. The vulnerability was reported by Ivan Sanchez of WiseSecurity Team. Schneider has produced a patch to mitigate the vulnerability and according to ICS-CERT Sanchez has verified the efficacy of the fix.

ICS-CERT reports that this vulnerability would require a social engineering attack to get an authorized user to load a specially configured DLL file. A successful exploit would allow execution of arbitrary code.

Wind River Advisory

This advisory describes a TCP predictability vulnerability in the VxWorks operating system. The vulnerability was reported by Raheem Beyah, David Formby, and San Shin Jung of Georgia Tech. Wind River has produced patches for the vulnerability, but there is no indication that the Georgia Tech team has been given the opportunity to verify the efficacy of the fix.

ICS-CERT reports that VxWorks is used in a number of ICS devices from a number of vendors. The VxWorks web site notes that the operating system is used in drones, medical devices and consumer IOT devices in addition to the ICS devices. ICS-CERT has contacted a number of vendors about the vulnerability. To date only Schneider Electric has produced a firmware patch to fix the VxWare vulnerability in some of their SAGE RTUs. Additional updates to the advisory will be issued when additional vendor information becomes available.

ICS-CERT reports that a moderately skilled attacker could remotely exploit this vulnerability to spoof or disrupt TCP connections to the affected devices. The Schneider advisory [.PDF Download] for the Sage RTUs notes that a successful exploit could allow a man-in-the-middle attack.

DLL Hijacking Vulnerability

I hear that ICS-CERT has published a DLL hijacking advisory for an industrial control system on the US-CERT Secure Server. Since I don’t have access to that site I can’t confirm that, and if I did I wouldn’t be able to talk about it anyway. If they have, they will get around to publishing it on the ICS-CERT site in the near future.

In any case, if you are the owner operator of an industrial control system at a critical infrastructure facility, you should already have requested access to the Secure Server so that you would be up to date on these types of vulnerabilities.

If you are not a critical infrastructure facility, you might try contacting US-CERT to see if you can get access, I understand that they have liberalized their rules about who they will give access. They are certainly willing to talk to security researchers and system integrators.

ICS-CERT Publishes Schneider Advisory

Today the DHS ICS-CERT published an advisory for a buffer overflow vulnerability in the Schenider Pelco DS-NVs software package (video management software). The vulnerability was reported by Ariele Caltabiano (kimiya) and Andrea Micalizzi (rgod) via the HP Zero Day Initiative. Schneider has produced a patch which mitigates the vulnerability but there is no indication that the researchers have been given the opportunity to verify the efficacy of the fix.

ICS-CERT reports that a relatively unskilled attacker could remotely exploit this vulnerability to execute arbitrary code.

Neither this advisory nor the Schneider notification identify the vulnerable DLL involved in this vulnerability so it is not possible to tell if the vulnerability would be unique to this application or if it might be found in multiple Schneider products.

ICS-CERT Updates Advisory and Publishes Monitor

This afternoon the DHS ICS-CERT updated their advisory (published yesterday) for the Elipse EC advisory and published the latest Monitor that describes ICS-CERT response activities during the last five months (September 2014 thru February 2015).

Elipse Update

This update provides a link to a Carnegie Mellon CERT (CERT-CC) vulnerability note  on the base vulnerability found in the Telerik Analytics Monitor Library. That advisory provides more details about how the vulnerability functions.

It looks like CERT-CC note will be updated as other vendors are identified as having vulnerable systems based upon the same Telerik DLLs (csunsapi.dll, swift.dll, nfhwcrhk.dll, and surewarehook.dll); probably listed after they are fixed. It will be interesting to see if ICS-CERT will provide new advisories for each vendor’s fixes of the problem or if it will just depend on CERT-CC updating their note.

ICS-CERT Monitor

The latest Monitor provides some additional information about the fairly extensive ICS-CERT response activity that we have been hearing a lot of second hand information about over the last year or so. This Monitor provides a summary of response data for FY 2014 (which ended on September 30^th). As we should have been able to guess from news reports the largest category of affected industries was the Energy Sector.

We still don’t have any real description of the kinds of affects seen as a result of the attack and we don’t know how many of the attacks were successful. There is a list of the generic attack vectors; not much new here. The second largest was network scanning/probing at 22% and third was Spear Phishing attacks at 17% (you can’t tell this relative size from the poor graphics). What is kind of scary though is that ICS-CERT could not find the source of the attack in 38% of the cases. I hope (and believe) this is a reflection of poor forensics and abysmal system logs and not ICS-CERT’s capability to analyze control system attacks.

There is also a brief section here about the ICS-CERT outreach activity to industry. It mentions the two-hour Secret level briefing that was given 15 times across the country in December. I would have liked to have been able to see one of these (unlikely as my Secret clearance expired decades ago and forget about ‘need to know’), but I really doubt the efficacy of the briefings. I would expect that these were given to C-Level managers who could not then take them back to their ICS folks because of the lack of security clearances at the operational level. And forget about notes or handouts since very few organizations outside of the Defense Industrial Base have facilities cleared to store Secret documents.

There is a brief discussion about the ICS-CERT Cybersecurity Evaluation Tool (CSET). It does mention that version 6.2 was released in January. Unfortunately there is nothing about that on the ICS-CERT CSET web site or the CSET Fact Sheet (for some reason both are only accessible via the ICS-CERT page via the ‘Assessments’ link, the direct links do not work); neither mentions version numbers at all. There is, however, a series of YouTube® video tutorials about version 6.2, but they are not mentioned on the ICS-CERT site. The Monitor staff did promise to have more information about v 6.2 in the next issue.

Lots of other interesting stuff, but nothing worth discussing here. Read it for yourself; it’s free.

ISC-CERT Updates DTP and HART-DTM Information

Today the DHS ICS-CERT published two new HART-DTM related advisories, updated the CodeWrights HART-DTM advisory, updated the NTP Advisory and published their promised NTP supplement. It was a busy information afternoon for ICS-CERT.

NTP Information

The third update to the ICS-CERT advisory on the NTP vulnerabilities was simply a change to add a link to the promised supplement addressing vendor specific information about how those vulnerabilities are implemented in specific products. That Supplement currently lists affected products (and mitigation measures) from/for the following vendors:

● Arbiter Systems;

● Innomoninate;

● Meinberg;

● Siemens; and

● Wind River System;

The Supplement does not currently list reportedly unaffected products. Updates to this Supplement are expected.

HART-DTM Information

The third update to the CodeWrights HART-DTM advisory provides some new information about affected systems, including adding Honeywell to the list of potentially affected vendors. Interestingly GE-MAKTec was not included on the list even though ICS-CERT published an advisory about their HART-DTM vulnerabilities today. The Update has also provided links to ICS-CERT advisories for Emerson, Honeywell, Magnetrol, and Pepperl+Fuchs.

There is some additional clarification about the potential impact of successful exploits of this vulnerability. ICS-CERT notes that it only affects the Field Device Tool (FDT) Frame Application. Since that application is only used for configuration changes, ICS-CERT reports that a successful exploit “does not result in loss of information, control, or view by the control system of the HART devices on the 4-20 mA HART Loop”.

ICS-CERT continues to emphasize how difficult it would be to craft an exploit for this vulnerability. Interestingly, they have removed the comments about compromised physical access to the 4 mA to 20 mA current loop. They emphasize that an exploit is possible from “any adjacent network that receives or passes packets from the HART Device DTM”.

The new advisories for Pepperel+Fuchs products and products from GE and MAKTec (GE provides the DTM software for the MAKTec Bullet Adapter DTM according to a GE Advisory) provide basically the same information as the current CodeWrights advisory.

Consistency of Information Sharing

It seems odd that ICS-CERT is issuing individual advisories for vendors affected by the HART-DTM vulnerability but issues a supplement for the advisory that lists those affected by the DTP vulnerability. In most ways it really does not make a difference which process ICS-CERT uses and they are under no mandate or obligation to maintain any sort of consistency in their methodology.

Having said that the multiple advisory process being used with the HART-DTM vulnerability does present a problem. The two advisories issued today share the same language as that found in the current version of the CodeWrights advisory. The Emerson and Magnetrol advisories share the language with the previous version of the CodeWrights advisory. This means that ICS-CERT really should have offered updates of those two advisories today as well. And when the next change takes place, they will have to update all five advisories (plus any others issued in the interim). Using the DTP advisory/supplement model, only one advisory needs to be updated when information on the base vulnerability changes.

ICS-CERT Publishes Two New Advisories

This afternoon the DHS ICS-CERT published two new advisories reporting multiple vulnerabilities in systems from Schneider Electric and Siemens.

Schneider Advisory

This advisory reports on two vulnerabilities reported in in Schneider Electric’s ETG3000 FactoryCast HMI Gateway by Narendra Shinde of Qualys Security. Schneider has produced a firmware update that mitigates the vulnerabilities. There is no indication in the advisory that Shinde was allowed to validate the efficacy of the update.

The two reported vulnerabilities were:

● Unauthenticated access - CVE-2014-9197; and

● FTP hardcoded credentials - CVE-2014-9198

ICS-CERT reports that a relatively low skilled attacker could remotely exploit these vulnerabilities to access to the HMI Gateway. ISC-CERT also reports that Shinde reported that default credentials also allow access to configuration files, but this is not counted as a ‘vulnerability’.

The advisory also reports that the firmware update does not actually change the FTP credentials; it merely disables the FTP. The Schneider ‘readme’ document accompanying the firmware updated download explains what functions are lost when the FTP is disabled. Schneider also notes that upon an ETG reboot the FTP is automatically re-enabled.

Siemens Advisory

This advisory reports twin denial of service vulnerabilities in the SCALANCE X-300/X408 switch family. The vulnerabilities were reported by Déjà vu Security. Siemens has produced a firmware update that mitigates the vulnerabilities but there is no indication that Déjà vu Security has had the opportunity to verify the efficacy of the fix.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit these vulnerabilities to execute a denial of service attack. Siemens reports that both vulnerabilities require network access and one of the vulnerabilities requires the attacker be able to sign in to the FTP server.

Missed Siemens Advisory

Readers who follow me on TWITTER® (@pjcoyle) know that yesterday when Siemens reported their SCALANCE vulnerability they also reported on their NTP vulnerability in their RuggedCom devices. This is the set of vulnerabilities reported by ICS-CERT back in December. Siemens reports that their ROX based devices may be affected by those vulnerabilities.

They report that they are working on updates for the affected products. Their current advisory does provide some interim mitigation measures that system owners can take while waiting for the updates to be made available.

I suspect that the reason that ICS-CERT did not report this particular Siemens vulnerability is that the original NTP Advisory ‘addressed the problem’. Unfortunately it looks like Siemens (and perhaps other vendors) may have to take additional actions to protect their systems beyond that recommended in the NTP Advisory.

Control System Security Program Promotion

It seems like the DHS Control System Security Program (CSSP) has decided that it needs to inform the public that it is hard at work designing ways to protect increasingly vulnerable industrial control systems. Their initial efforts, opening up the INL portion of their operation to the news media, seems be particularly effective. Two mainstream print organizations (LA Times, Washington Post) a broadcast news organization (CBS News) and an industry magazine (PC World) have all had significant on-line print stories about ICS security out in the last week. CNN has a video on-line about the same subject.

I didn’t see anything really new or outrageously wrong in any of these reports. In fact they seem to be pretty balanced stories for the general public about a topic that professionals have become increasingly vocal about over the last couple of years. There are some over-simplifications and some vulnerabilities may seem a little too easy to exploit, but for general public consumption these are pretty good information.

Hopefully this is a signal that DHS intends to pay a little more attention this year to industrial control system security issues during Cyber Security Awareness Month. Certainly the public needs to know how to protect their computers and personal information, but they also need to be made aware of the larger potential threats that may affect them and the communities in which they live.

ICS-CERT Issues Three SCADA Advisories

On Friday afternoon the DHS Industrial Control System Cyber Emergency Response Team published three advisories on their web site. One was a follow-up to one of the earlier Luigi alerts while the other two were about new vulnerabilities in systems reported by security researchers in ‘properly’ coordinated disclosures. The three advisories deal with the following systems:

• Rockwell RSLogix

• InduSoft ISSymbol

• ICONICS GENESIS32

Rockwell RSLogix

This Advisory updates an earlier alert issued for the vulnerabilities reported by Luigi. Rockwell has developed patches for these denial of service vulnerabilities in two versions their Factory Talk Services Platform (CPR9 SR3 and SR4). Patches are under development for earlier versions of Factory Talk and for RSLogix. ICS-CERT will update this Advisory when those patches become available. [CVE-2011-3489; Base Score 5.0]

InduSoft ISSymbol

Dmitriy Pletnev of Secunia Research reported ActiveX control buffer overflow vulnerabilities in the InduSoft ISSymbol product and developed proof-of-concept exploit code for those vulnerabilities. The vulnerabilities allow a low skilled attacker to conduct DOS attacks while a more skilled attacker could execute arbitrary code. InduSoft has published an upgrade for the affected systems as well as a new service pack. [CVE-2011-0342; Base Score 10.0]

ICONICS GENESIS32

Independent researchers Billy Rios and Terry McCorkle have identified eight separate memory corruption vulnerabilities in components of the GENESIS32 HMI/SCADA product. A low skill level attacker could cause a system crash while a more skilled attacker could execute arbitrary code. This vulnerability would require a social engineering attack causing a user to open specially crafted files. ICONICS has produced patches to mitigate these vulnerabilities.

Cyber Security Awareness Webinar

There is an interesting posting over on ControlGlobal.com about an industrial control system cyber security webinar that will be held later this month. The webinar is being sponsored by the Automation Federation and is being run by ISA. The presenter will be Matt Luallen, a co-founder of Encari an information security consulting company. The webinar starts at 11:00 am EST on November 19th. Registration ends on November 18th. There appears to be some confusion about who may attend. The ISA web site shows two pricings for the web cast, $195 for ISA members and $225 for non-members. Unfortunately the link to the registration page takes you through an ISA sign-on page that requires having a member or customer number and password. There is a link to ‘create an account’ with ISA, but it seems to request too much information for my personal security tastes. I haven’t seen any ISA presentations, but they are a ‘respected’ organization in the industrial automation field. This should be a good, informative presentation, and the price appears to be reasonable for corporate education purposes. Still if I were setting this up for ‘my’ high-risk chemical facility, I would sign on to the webinar from a facility conference room and have the entire security management team sit through the presentation. If any reader does participate, I would appreciate hearing some feedback. I would like to share such evaluations, for this and any other chemical security related seminar, with my readers.

Control System Security Metrics

A key component in any attempt to ‘improve’ a system is the ability to measure change in system characteristics. It is only thru such measurements before and after a system change that an objective analysis of improvement can be made. The DHS Control Systems Security Program (CSSP) recently published their latest version of their suggested metrics for measuring changes in relative security of industrial control systems (ICS), the Primer Control Systems Cyber Security Framework and Technical Metrics (Primer). Dimensions of Cyber Security The CSSP Primer describes a ‘framework’ for making decisions about ICS security. It identifies seven control systems cyber security dimensions that “capture many of the system attributes, which correlate with a control system’s risk exposure” (pg 1). The CSSP uses the term ‘dimension’ because they describe “an important aspect of the control system’s cyber security posture at a given point in time” (pg 2). Those seven dimensions are:

“Security group knowledge “Attack group knowledge “Access “Vulnerabilities “Damage potential “Detection “Recovery”

Detailed definitions of the terms can be found in the Primer (pg 2), but most of the dimensions are relatively easy to decipher just from their titles. The two ‘group knowledge’ dimensions are a little less clear than the others. The ‘Security group knowledge’ looks at looks at how easy it is for changes to be made to the ICS without the knowledge of those responsible for the security (the ‘Security Group’) of the ICS; supposing that such surreptitious changes could be used to gain control of the system. The ‘Attack group knowledge’ dimension looks at how easy it would be for an attacker to gain information about details of the system that would allow for a deliberate, knowledgeable attack on the system. ICS Security Metrics The security ‘dimensions’ help to define the framework for ICS security measures, but they do not provide any direct measures that will allow a facility to track the ‘performance’ of their security systems. The Primer notes that there are a number of different metrics that have been developed by people in the industry and provide the following list of references (pg 24) as examples:

“E. Chew, A. Clay, J. Hash, N. Bartol, and A. Brown, Guide for Developing Performance Metrics for Information Security, NIST Special Publication 800-80, May 2006.

“R. Ross, S. Katzke, A. Johnson, M. Swanson, and G. Rogers, “System Questionnaire with NIST SP 800-53: Recommended Security Controls for Federal Information Systems,” Technical Report, NIST, References and Associated Security Control Mappings, Gaithersburg, Maryland, March 2006.

“M. Swanson, N. Bartol, J. Sabato, J. Hash, and L. Graffo, Security Metrics Guide for Information Technology Systems, NIST Special Publication 800-55, National Institute of Standards and Technology (NIST), Gaithersburg, Maryland, July 2003.

“M. McQueen, W. Boyer, S. McBride, M. Farrar, and Z. Tudor, "Measurable Control System Security through Ideal Driven Technical Metrics", S4: SCADA Security Scientific Symposium, January 23, 2008”

The Primer authors note that to be effective there should be at least one metric for each of the ICS security dimensions listed in the Primer. They recommend (pg 5) that the following 10 metrics (and associated dimension) should be used to track changes in the security posture of ICS:

“Rogue Change Days (Security Group Knowledge); “Security Evaluation Deficiency Count (Security Group Knowledge); “Data Transmission Exposure (Attack Group Knowledge); “Reachability Count (Access); “Attack Path Depth (Access); “Known Vulnerability Days (Vulnerabilities); “Password Crack Time (Vulnerabilities); “Worst Case Loss (Damage Potential); “Detection Mechanism Deficiency Count (Detection); and “Restoration Time” (Recovery).

According to the authors, each of the metrics listed above is an answer to one basic security question: “What can be objectively measured on the system that is a reasonable representation of how nearly the system approaches the ideal of its associated control systems cyber security dimension?” The Primer provides a detailed technical discussion of each metric including a range of possible values and an ‘ideal’ value. While ‘ideal’ value may not be achievable, the measurable values do provide a tool for tracking progress or assessing the efficacy of security measures. Case Studies The Primer does provide two examples of how the security dimensions and metrics were used in actual practice in two different case studies. The first such study will be of primary interest to the chemical security community since it took place at a chemical facility with a DCS ICS. Unfortunately the details associated with the case studies are minimal and there is little discussion of how the metrics were applied. There is more detail for the second case study which looks at the more politically sensitive case of an electric power distribution SCADA system. Standards for Metrics What is missing from the discussion of the metrics is the definition of an ‘acceptable’ value for the metric signifying that the security measures are ‘adequate’. There is a brief mention of ‘target’ values in the two case studies. The authors describe the suggested target value as “the value that could be obtained by changing the system configuration to improve cyber security while retaining required functionality” (pg 20), but provide no information on how the value was set and use different values in the two different case studies. While not stated in the Primer, the reason for the lack of definition of acceptable values is at least partially based on the fact that such a decision is at its most basic a management evaluation of the risk and the cost of security. Where legal standards are set (and that has not yet been done for ICS) for acceptable values then achieving those standards becomes a matter of compliance not security. Recommendation The CSSP should be commended for developing this document. It is a valuable addition to the cyber security debate. It is, however, probably not an adequate amount of information to develop and implement a metric based ICS security monitoring program. It assumes a relatively high level of knowledge about industrial control systems and computer networks. If CSSP provides some training sessions (on-line and on-site) to support this framework, it will be much more accessible. Having said that, facilities that use an industrial control system need to get a copy of this document and review it in detail. High-risk chemical facilities in particular should pay special attention to these metrics in developing their cyber security programs.

Common Control System Vulnerabilities

Last month the Department of Homeland Security (DHS) National Cyber Security Division’s Control Systems Security Program (CSSP) released a report on the results of 15 control systems assessments that the CSSP has conducted since 2004. With only 15 assessments this is hardly a comprehensive look at industrial control systems (ICS) cyber vulnerabilities, but it does provide a window into the typical problems found in control system applications. These assessments were not done on live installations of control systems. The assessments were done using techniques such as “reviewing the production system network diagrams and firewall rules, and performing a hands-on assessment of a duplicate nonproduction installation of the system” (pg 1). “This controlled environment allows realistic assessments of systems and components without the adverse consequences resulting from potential system failures.” One of the scary aspects of this report is found on page 5 in the “Impact on ICS Security” section of the report:

“Although not all findings have been addressed, most systems have been modified to improve security based on assessment reports. After-action validation of mitigations to identified security flaws are performed by the CSSP assessment team to help ensure the security assessments are successful in increasing critical infrastructure security. Some of the vendors have been forthright in sharing the results with their customers, and some have felt that any disclosure of vulnerabilities could lead to exposure of their customers to potential cyber attacks.”

I’m not sure what disturbs me more the ‘not all findings have been addressed’ or the ‘some of the vendors have been forthright in sharing’ comments. The combination of the two should be enough to convince people in the chemical security community that there is a significant problem with the security of industrial control systems that are such an integral part of so many high-risk chemical facilities. Types of Vulnerabilities The report loosely groups assessed vulnerabilities into “nine general security problems that sum up the main weaknesses that ICS products and installations are prone to have due to legacy code, lack of security training and requirements, and ICS operational requirements” (pg 9). The top three (by % of assessment findings) problem areas are (pg 7): poor network protocol implementations (26%), information disclosure (21%), weak authentication (18%). The common vulnerabilities found in the network protocol implementation category include (pg 8, Table 1):

“Lack of input validation: Buffer overflow in ICS service “Lack of input validation: Lack of bounds checking in ICS Service “ICS protocol uses weak authentication “ICS protocol uses weak integrity checks “ICS product relies on standard IT protocol that uses weak encryption”

The common vulnerabilities found in the information disclosure category include (pg 8, Table 1):

“Unencrypted proprietary ICS protocol communication “Unencrypted nonproprietary ICS protocol communication “Unencrypted services common in IT systems “Open network shares on ICS hosts “Weak protection of user credentials “Information leak through unsecure service configuration”

The common vulnerabilities found in the weak authentication category include (pg 8, Table):

“ICS uses standard IT protocol that uses weak encryption “Use of standard IT protocol with clear-text authentication “Client-side enforcement of server-side security “Improper security configuration “No password required “Weak passwords “Weak password requirements”

Control System Security Debate This document is a valuable addition to the cyber security debate. Industrial control systems are used in a wide variety of settings, but they are of special interest to the chemical security community. ICS are a key component of most chemical manufacturing systems and even purely distributional facilities frequently use these systems to control loading and unloading operations. Security vulnerabilities in the ICS must be seen as potential avenues for attacks on high-risk chemical facilities using those systems. The current Site Security Plan implementation does address the issue of cyber security, including security issues associated with ICS. It does not include the same level of ICS assessment described in this assessment. This is certainly reasonable given the high level of complexity of the existing SSP, the limitations imposed by the authorizing legislation, and the level of expertise required to do these assessments. But, sooner or later, detailed assessments of security of cyber control systems will need to be done at the high-risk chemical facilities covered by CFATS.