Saturday, November 18, 2017

Public ICS Disclosure – Week of 11-12-17

Today this is not about a new disclosure but about some new information on an ICS-CERT advisory that was published this week. SEC Consult published additional information on the Siemens SICAM vulnerabilities on the FullDisclosure web site.

The ICS-CERT advisory reported that publicly available exploits were available, but did not provide a link. This report from SEC Consult provides proof of concept code for exploiting the first two vulnerabilities and a link to a very old (2003) link to an earlier report on the code injection vulnerability. That link leads to a report by Luigi Auriemma, a name that hasn’t been seen on this blog in quite some time.

The Luigi report is about the GoAhead web server that was apparently used by Siemens in the affected versions of the SICAM devices. This is not noted in either the ICS-CERT advisory or the Siemens security advisory. Luigi describes GoAhead this way:

“Goahead (sic) webserver is an embedded OpenSource server that can be build (sic) on a lot of systems (CE, Ecos, GNU/Linux, Lynx, MacOS, NW, QNX4, VXWORKS, Win32 and others).
“It is supported by a lot of companies that use it for their projects and it is also used like ‘base’ for other webservers, furthermore it has been developed for be very tiny and to run on embedded systems.”

Apparently, Siemens used an unpatched version of the webserver (Luigi reported that the vulnerability he reported was fixed in December 2003) in the affected versions of the SICAM devices. Since Siemens (and almost all other ICS vendors) did not start to take control system security seriously until after 2010 (STUXNET), it is not surprising that a newer version of the webserver was not incorporated in these devices; in fact, it is quite possible that they were not informed of the vulnerability.

This is an old, but continuing problem, with third party software used in many of the control system devices used still today. If the original vendor does not have an active method for sharing vulnerability information with all of its customers, the using vendor may not become aware of the vulnerability until some third-party researcher discovers the problem.

More disturbing in this case is the fact that neither ICS-CERT nor Siemens mentioned that the vulnerabilities (apparently all three) in the SICAM devices were based upon vulnerabilities in a GoAhead web server. If it were not for this separate SEC Consult disclosure, the community would not realize that that there was a third-party vulnerability involved that may still exist in other non-Siemens devices.

Friday, November 17, 2017

S 2083 Introduced – Port Cybersecurity

Earlier this month Sen. Harris (D,CA) introduced S 2083, the Strengthening Cybersecurity Information Sharing and Coordination in Our Ports Act of 2017. This bill is essentially identical to the version of HR 3101 that was passed in the House last month.

While Harris is not a member of the Senate Commerce, Science, and Transportation Committee (the committee to which this bill was assigned for consideration), her co-sponsor, Sen Sullivan (R,AK) is. This means that there is a chance that the Committee could take up the bill.

It is unusual for companion legislation to be introduced this late in the process. It probably means that Harris does not think that there is a reasonable chance that the Senate will take up HR 3101, even though there was bipartisan support for that bill in the House. That is not unusual, the House passes a lot of bills that are never taken up by the Senate; the Senate is slower to pass legislation.

If this bill is marked up by the Commerce Committee there will be a better chance that it will be taken up by the whole Senate. Unless there are significant amendments made to the bill, there is a good chance that the House would accept the Senate version of the bill and not require it to go to conference.

It is unlikely that this bill will receive any consideration this year.

CSB’s Arkema Investigation Update

Earlier this week the Chemical Safety Board (CSB) held a news conference (note this link is to a copy of the email that I received about the press conference, the Sutherland statement is not currently available on the CSB web site) to provide an update on their investigation of the fires at the Arkema site in Crosby, TX after Hurricane Harvey (discussed in this blog here). As part of that news conference, CSB released a video showing the time-line of activities that took place during the incident.

The Time Line

CSB shared the following time-line graphic at that news conference


Sutherland concluded her statement by saying: “There is a valuable lesson that facilities in the Gulf and elsewhere should note:  Reassess continuity of operations plans and worst case (sic) scenario assumptions.  Plan and plan again. Don’t be lulled into a false sense of safety by thinking that ‘it can’t/ won’t happen here.’”

A key part of that planning process is the identification of the key assumptions made during that process. Here, for example, the assumption was that flood waters would not exceed 2-ft. I would be surprised if this assumption was made and documented in any formal fashion, but it was made when it was decided to elevate the backup generators by that much.

If the facility had documented the reasoning process that lead to that decision, a periodic review of the plan may have noted that the increased rainfall that storms have been producing in the north-western Gulf Coast in recent years might have called for a revision of that assumption.

All emergency response plans need to be formally reviewed a recurring basis. For example, along the Gulf and Atlantic Coast, chemical facilities should formally review their hurricane response plans every spring, well before the start of the season. That review should include:

• Lessons learned from previous seasons;
• Assumptions about storm action levels;
• Assumptions about worst-case scenarios;
• Shutdown decision points;
• Evacuation decision points;
• Coordination activities with local community responders;
• Facility protection plans; and
• Recovery plans.

Worst-case scenario planning, it must be remembered, should not start with an assumption about what is the worst thing that could happen to the facility. It should start with an analysis of what is the worst thing that can happen at a facility. At the Arkema facility this would have been the decomposition/fire/explosion of the material in one of the cold storage buildings. From that worst-case incident the planning process needs to identify possible routes to that incident and the mitigation measures necessary to prevent those causes.

Was the worst-case planning at the Arkema facility adequate? In hind sight, it is easy to come to the conclusion that it was not; easy, but not necessarily correct. Three feet of flood water had never been documented in that area, so it is hard to fault Arkema (or any of its neighbors) for planning for such flooding. Plans going forward will have to be revised for that eventuality, but it was not reasonable pre-Harvey.

The other thing about emergency planning that we see clearly from this event is that plans need to be modified on the fly as situation change. It is clear from the timeline presented by CSB, that Arkema continued to recognize that the situation was changing for the worst and that they adapted in a timely and proactive manner to those changes. This is one of the reasons that facility evacuation plans in the face of storms like these must consider leaving a team on site to respond to changing conditions.

Any stay behind team needs to include knowledgeable management and operations/maintenance personnel that have the authority and skills to react to changing conditions. They must be protected against the potential storm effects and provided with communications tools to be able to coordinate with local response agencies if required.

As I have noted before in discussing this event, the CSB investigation of the incident should focus on the planning process that was in place for this facility. The result of the investigation should include recommendations for emergency planning actions that chemical facilities should take to prevent damage (with off-site consequences) from predictable natural disasters like hurricanes, floods, tornados, and earthquakes (all in appropriate areas of the country).

Thursday, November 16, 2017

ICS-CERT Publishes Two Advisories

Today the DHS ISC-CERT published two control system security advisories for products from Siemens and Moxa.

Siemens Advisory

This advisory describes multiple vulnerabilities in Siemens SICAM RTU products. The vulnerabilities were reported by SEC Consult Vulnerability Lab. Siemens is recommending that the web server be disabled after system commissioning to mitigate the vulnerabilities in current versions.

The three vulnerabilities reported are:

• Missing authentication for critical function - CVE-2017-12737;
• Improper neutralization of input during web page generation - CVE-2017-12738; and
• Improper control of generation of code - CVE-2017-12739

ICS-CERT reports that a relatively low-skilled attacker could remotely exploit the vulnerability using a publicly available exploit to execute arbitrary code. The Siemens security advisory notes that network access to the affected devices is required.

Moxa Advisory

This advisory describes multiple vulnerabilities in the Moxa NPort serial network interface products. The vulnerabilities were reported by Florian Adamsky. Moxa has a new firmware version that mitigates the vulnerability. There is no indication that Adamsky has been provided an opportunity to verify the efficacy of the fix.

The three vulnerabilities reported are:

• Improper neutralization of special elements in output used by downstream component - CVE-2017-16719;
• Information exposure - CVE-2017-16715; and
• Uncontrolled resource consumption - CVE-2017-14028

ICS-CERT reports that a relatively low-skilled attacker could remotely exploit the vulnerability to allow for remote code execution on the device.

ICSD Publishes SSP Revision Decision Tool

Today the DHS Infrastructure Security Compliance Division (ISCD) published a new tool on the Chemical Facility Anti-Terrorism Standards (CFATS) Knowledge Center. The tool can be used by facilities to help decide if their recent CSAT 2.0 tiering letter will require edits of a currently approved site security plan.

The new tool, the “Decision Tree: Could Site Security Plan Edits be Required?”, is a flowchart with a series of binary response questions. The answers to each question either lead to another question or one of two ultimate answers:

“Edit may not be required”; or
“Recommended edit”

The alert reader will recognize that neither of those responses are definitive. With the exception of one decision tree, the reason for this is clear, the decision trees end with a question about the appropriateness of existing security measures for the new situation. Since it is not technically possible for the facility to definitively answer that question, the facility will be required to make their best, educated-guess in answering that question.

As in all things CFATS, if there are questions, contact your facility Chemical Security Inspector, Regional Compliance Manager, or the CFATS Hotline.

Wednesday, November 15, 2017

IED Precursor Chemical Study Published

Today the DHS Chemical Facility Anti-Terrorism Security (CFATS) web site was updated to include links to a pre-publication copy of the report of the National Academies report on possible modes of regulating improvised explosive device (IED) precursor chemicals. This study was commissioned by DHS in August 2016 as part of their efforts to craft effective regulations for the prevention of the use of ammonium nitrate in IEDs.

A quick review of the 191-page document would indicate that the study committee has taken a very nuanced look at the issue of controlling precursor chemicals to prevent their use in the construction and use of IEDs by terrorists. There is no quick fix proposed by the study. Instead they have produced six broad recommendations:

Federal, state, local, and private sector entities attempting to reduce the threat of IED attacks by restricting access to precursor chemicals should focus on both person-borne and vehicle-borne IEDs.

Federal, state, local, and private sector entities attempting to reduce the threats from person-borne and vehicle-borne IEDs should consider multi-chemical, rather than single-chemical, strategies.

Federal, state, local, and private-sector entities attempting to reduce the threats from person-borne and vehicle-borne IEDs should focus on retail-level transactions of precursor chemicals, especially e-commerce.

Federal, state, local, and private-sector entities should explore strategies for harmonizing oversight of the sale and use of commercially available kits that contain precursor chemicals that are specifically designed to be combined to produce homemade explosives.

US DHS should engage in a more comprehensive, detailed, and rigorous analysis of specific provisions for proposed mandatory and voluntary policy mechanisms to restrict access to precursor chemicals by malicious actors.

The federal government should provide additional support for voluntary measures, activities, and programs that can contribute to restricting access by malicious actorsto precursor chemicals used to manufacture IEDs.

I will be taking more detailed reviews of various portions of the study in future blog posts.

ICS-CERT Publishes 3 Advisories and Updates 2

Yesterday the DHS ICS-CERT published one medical system security advisory and two control system security advisories. Those advisories were for products from Philips, ABB and Siemens. They also updated two Siemens advisories.

Philips Advisory

This advisory describes an insufficiently protected credentials vulnerability in the Philips IntelliSpace Cardiovascular and Xcelera cardiac image and information management systems. This vulnerability were apparently self-reported. The Philips security page notes that the vulnerability was reported to Philips by a customer. Philips has produced a hot fix update to mitigate the vulnerability.

ICS-CERT reports that an uncharacterized attacker could remotely exploit this vulnerability to access sensitive information stored on the system, modify device configuration, and gain access to connected devices.

NOTE: The Philips security page also has a note about the KRACK vulnerability potential effect on Philips products. Research is ongoing at Philips.

ABB Advisory

This advisory describes multiple security features vulnerabilities in the ABB TropOS. These are the KRACK vulnerabilities in this product that I discussed earlier. ICS-CERT reports that ABB is still working on mitigation measures.

ICS-CERT reports that an uncharacterized attacker within radio range of the product could exploit these vulnerabilities to decrypt, replay, and forge some frames on a WPA2 encrypted network.

Siemens Advisory

This advisory describes multiple security features vulnerabilities in the Siemens SCALANCE, SIMATIC, RUGGEDCOM, and SINAMICS Products. These are the KRACK vulnerabilities. Siemens is continuing to work on updates.

ICS-CERT reports that an uncharacterized attacker within radio range of the product could exploit these vulnerabilities to decrypt, replay, and forge some frames on a WPA2 encrypted network.


This update provides new information for an advisory that was originally published on May 9th, 2017 and updated on June 15th, 2017, on June 20th, 2017, on July 6th, 2017, on July 25th, 2017 on August 17th, 2017 and most recently on October 10th. The update provides new affected version information and mitigation links for:

• SIMATIC NET PC-Software: All versions prior to V14 SP1


This update provides new information for an advisory that was originally published on May 9th, 2017 and updated on June 15, 2017,on July 25th, 2017, on August 17th, 2017, and most recently on October 10th. The update provides new affected version information and mitigation links for:

• Softnet PROFINET IO for PC-based Windows systems: All versions prior to V14 SP1
• SIMATIC ET 200AL: All versions prior to V1.0.2

KRACK Commentary

ICS-CERT publishes two vendor reports (one two-week old and the other almost a week old) of the KRACK vulnerability in wireless networks (and misses the publicly available information from a third vendor), and still does not see a problem common to all industrial and medical control systems that allow for wireless access, a problem severe enough to provide an alert on the vulnerabilities? SHAME on DHS for allowing this blindness to continue.
/* Use this with templates/template-twocol.html */