Wednesday, November 22, 2017

ICS-CERT Publishes Another Vendor KRACK Advisory

Yesterday the DHS ICS-CERT published a control system security advisory for WLAN enabled products from Phoenix Contact. This is for the  Key Reinstallation Attack – (KRACK) set of vulnerabilities. ICS-CERT credits the original KRACK researcher, Mathy Vanhoef of imec-DistriNet, for reporting the vulnerability, but this instance was self-reported by Phoenix Contact.

This advisory only reports three of the ten reported KRACK CVE. It is not clear if the vendor has evaluated the other potential KRACK instances and found them missing (not implemented) on their devices, or just thought that these were the most serious implementation issues in their devices.

The Phoenix Contact advisory at CERT@VDE provides much more detailed information about the extent of the vulnerability. They report:

“PHOENIX CONTACT embedded devices running in AP mode are not affected by these vulnerabilities. If devices are used in client or repeater mode, an attacker could in theory decrypt any packet sent by the client. Devices of the FL WLAN 110x, 210x, and 510x product families are only affected to a very limited extent. With these devices, only data packets sent within three seconds after key renewal could possibly be decrypted by a successful attacker. In general, if TCP SYN packets are decrypted, this can be used to hijack TCP connections and inject malicious traffic into unencrypted protocols. However, to perform the attack, the attacker must be significantly closer to the WLAN client than the access point. In industrial or indoor applications, the attacker would have to be inside the plant. A successful external attack therefore seems to be very difficult. Furthermore, the WPA2 password cannot be compromised using a KRACK attack. It is not possible for the attacker to gain full access to the network. However, note that if WPA-TKIP is used instead of AES-CCMP, the impact of this vulnerability is much more severe, because an attacker can then not only decrypt packets, but also forge and inject packets directly into the WLAN.”


TIRADE ALERT – Another vendor provides information on KRACK and ICS-CERT has still failed to publish an alert about the vulnerability, or even just a link to the original paper. I have been complaining about this inaction on the part of ICS-CERT where ever I talk about ICS security issues. I had an interesting conversation with Anton Shipulin, of Kaspersky Labs, over on LinkedIn about the issue and he noted that this could be the result of the recent NCCIC reorganization that ‘moved’ ICS-CERT into NCCIC. I still have not seen anything from DHS about the move, but if the reorganization changed the information sharing responsibilities of ICS-CERT to the control system security community, then DHS needs to reverse that change as quickly as possible. Perhaps Congress needs to look into this.

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



Commentary


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.
 
/* Use this with templates/template-twocol.html */