ICS-CERT Publishes One Advisory and Updates Another

Today the DHS ICS-CERT published a new control system security advisory for a product from CA Technologies. Earlier this week I missed the fact that they also updated a previously published (and much updated) advisory for multiple products from Siemens.

CA Technologies Advisory

This advisory describes a directory traversal vulnerability in the CA Technologies Unified Infrastructure Management application. The vulnerability was reported by Andrea Micalizzi (rgod), working with Zero Day Initiative. CA Technologies has produced an update to mitigate the vulnerability. There is no indication that Andrea has been provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that a relatively unskilled attacker could remotely exploit the vulnerability to create or overwrite critical files that are used to execute code, such as programs or libraries.

The CA Technologies Security Notice (not referenced in the ICS-CERT Advisory) includes two additional vulnerabilities:

• Insecure handling of session id’s - CVE-2016-9164; and

• Path traversal information disclosure - CVE-2016-9165

Latest Siemens Update

This update provides updated affected version information for SIMATIC S7 products. It also provides links for new updates for various SIMATIC S7 products. The latest update of the Siemens Security Notification also notes that Siemens corrected fix information for PCS 7 V8.0 and V8.1.

OMB Approves TSA Surface Transportation Security Training NPRM

Yesterday the OMB’s Office of Information and Regulatory Affairs (OIRA) announced that it had approved a notice of proposed rulemaking (NPRM) from the DHS Transportation Security Administration (TSA) regarding transportation security training requirements for surface transportation organizations. The rulemaking was submitted to the OMB back in July.

This rulemaking was required by Congress in 2007 in the Implementing Recommendations of the 9/11 Commission Act of 2007 (PL 110-53). Security training requirements for surface transportation organizations were specifically required by:

Section 1408 (6 USC 1137), Public transportation security training program;

Section 1517 (6 USC 1167), Railroad security training program;

Section 1534 (6 USC 1184), Over-the-road bus security training program;

Congress required that each of these training program rules to be established within six months of the adoption of the bill (August 3, 2007). Each of these training program requirements include the same program elements including the requirement to submit those training programs to DHS for approval.

There have recently been some significant delays in many rulemakings between the time of OIRA approval and publication in the Federal Register. This probably entails an internal requirement for additional justification of publishing rulemakings this late in the Obama administration. Since this has no chance of moving to a final rule until well after the Trump administration inauguration this rulemaking may escape that midnight rule review delay.

ICS-CERT Publishes 3 Advisories and Latest Monitor

Yesterday the DHS ICS-CERT published three control system security advisories for products from OSIsoft, Siemens and Phoenix Contact. Earlier this week they also published the September – October 2016 Monitor.

ICS-CERT Monitor

The latest issue of the ICS-CERT Monitor reports on activities of the DHS ICS-CERT for September and October of 2016. No real valuable information in this issue of the Monitor with ICS-CERT returning to the glossy corporate quarterly report format for this issue. The main articles include:

• ICS-CERT Vulnerability Coordination;

• Cybersecurity Crawl, Walk, Run;

• DHS Moving US-CERT Portal to HSIN, Rebranding as NCCIC Portal;

• ICSJWG Fall 2016 Meeting Recap;

• ICS-CERT Hosts Regional Training in Lisbon, Portugal;

• ICS-CERT Releases Defense-in-Depth and Annual Vulnerability Coordination Reports; and

• What is a CSET Assessment?

OSIsoft Advisory

The advisory describes an incomplete model of endpoint features vulnerability in the OSIsoft PI System software. This is apparently a self-reported vulnerability. OSIsoft has produced a new version that mitigates the vulnerability.

ICS-CERT reports that a relatively unskilled attacker with local access could effect a DOS attack to cause a shutdown of the PI Data Archive or connected applications. The OSIsoft Security Update, on the other hand reports that an exploit of the session management issue could “result in remote shutdown of the PI Data Archive or connected applications”.

Siemens Advisory

The advisory describes a privilege escalation vulnerability that affects several of industrial products from Siemens (18 products listed in advisory). The vulnerability was reported by WATERSURE and KIANDRA IT. Siemens has produced updates for six of the products and temporary fixes for the remaining products pending the production of new updates.

ICS-CERT reports that it would be difficult to effect a working exploit of the vulnerability and would require local authenticated access to the product. Interestingly the Siemens Security Advisory notes that:

“If the affected products are installed under their default path (“C:\Program Files\*” or the localized equivalent) and the default file system access permissions for drive C:\ were not modified, the security vulnerability is not exploitable.”

Phoenix Contact Advisory

The advisory describes multiple authentication vulnerabilities in the Phoenix Contact ILC (inline controller) PLCs. The vulnerabilities were reported by Matthias Niedermaier and Michael Kapfer of HSASec Hochschule Augsburg. Phoenix Contact has produced an update and recommended security practices to mitigate the vulnerability. There is no indication that the researchers have been provided an opportunity to verify the efficacy of the fix.

The vulnerabilities include:

• Cleartext storage of sensitive information - CVE-2016-8366;

• Authentication bypass issues - CVE-2016-8371; and

• Access to critical private variable via public method - CVE-2016-8380.

ICS-CERT reports that a relatively unskilled attacker could remotely exploit the vulnerability to access human-machine interface (HMI) pages and to modify programmable logic controller (PLC) variables. ICS-CERT explains that the new version only corrects the plaintext password storage issue.

Oops, Missed Second Schneider Advisory

Last night I missed the second Schneider control system security advisory published yesterday by ICS-CERT. It describes two vulnerabilities in their IONXXXX series power meters and it is a follow up to an earlier alert. The vulnerabilities were reported by Karn Ganeshen. Schneider has provided instructions to mitigate these vulnerabilities. There is no indication that Ganeshen has been provided an opportunity to verify the efficacy of the fix.

The two vulnerabilities identified in the advisory (the second was not identified in the original alert) are:

• Cross-site request forgery - CVE-2016-5809; and

• Improper access control - CVE-2016-5815

The ICS-CERT advisory does not address the three separate default password issues for the HTTP, Telnet and front panel access to the device though it was mentioned in passing in the earlier alert. These are specifically addressed in the Schneider Security Notification referenced in the advisory. That notification only addresses the default password issue (urging owners to change their device passwords from default values to prevent unauthorized access), but not either vulnerability addressed in this advisory.

ICS-CERT reports that a relatively unskilled attacker could remotely exploit the two covered vulnerabilities to make configuration changes on the device.

BTW: While ICS-CERT notes that there are no “known public exploits specifically target these vulnerabilities” (Karn’s disclosure did not provide a POC) it does not mention that Karn provided a partial list of organizations that are using the affected power meters.

ICS-CERT Publishes Two Advisories

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

Schneider Advisory

This advisory describes twin uncontrolled resource consumption vulnerabilities in the Schneider Electric Magelis human-machine interface (HMI) products. The vulnerabilities were reported in a coordinated disclosure by Eran Goldstein, in collaboration with Check Point Software Technologies and CRITIFENCE and publicly reported earlier this week. Schneider plans on having a new release available next spring, but is providing work arounds listed in this advisory.

While ICS-CERT calls both vulnerabilities ‘uncontrolled resource consumption vulnerabilities. CRITIFENCE uses more descriptive names:

• Improper implementation of HTTP get request – CVI-2016-8367; and

• Improper implementation of HTTP chunked Transfer-Encoding request - CVI-2016-8374.

ICS-CERT reports that a relatively unskilled attacker could remotely exploit these vulnerabilities to cause a denial of service for the affected devices. The Schneider security notification notes that the vulnerabilities can only be exploited when the Web Gate Server is activated; the function is disabled by default.

BTW: These are the Schneider vulnerabilities that I retweeted about earlier this week.

Moxa Advisory

This advisory describes two vulnerabilities in the Moxa OnCell Security Software. The vulnerabilities were reported by Maxim Rupp (who at this point should be listed as a member of the Moxa cybersecurity team; just saying). Moxa has produced a new version (for two of the ten affected systems) that mitigates the vulnerability. There is no indication that Rupp was provided an opportunity to verify the efficacy of the fix.

The vulnerabilities include:

• Improper authentication - CVE-2016-8362; and

• Permissions, privileges and access control - CVE-2016-8363

ICS-CERT reports that a relatively unskilled attacker could remotely exploit these vulnerabilities to download files or execute arbitrary command by web console.

Anhydrous Ammonia and Roadways

I ran across an interesting editorial about a recent anhydrous ammonia pipeline leak. The focus of the editorial was on the problem of aging pipelines, but it briefly addressed an issue that I have touched upon on several occasions; the problem of anhydrous ammonia leaks near major roadways.

The Incidents

The most recent incident was on October 18^th near Tekamah, NE (see news reports here, here, here and here). There was a major leak on an above ground portion of an 8” diameter pipeline carrying liquefied anhydrous ammonia. The resulting vapor cloud crossed US 75. A motorist drove through the cloud and died. The accident is being investigated by the National Transportation Safety Board (NTSB).

The other incident that I have reported on was in August of 2009 in South Carolina where there was a hose rupture during a tankwagon unloading incident. Again, the resulting vapor cloud crossed a major highway (US 321). A mother of two drove into the cloud and died.

In both cases the facility owners properly notified authorities of the incidents, but the response was not quick enough (or perhaps not well planned enough) to have stopped the victims from driving into the cloud.

PHMSA and Leak Detection

Back in 2010 while reporting on an advanced notice of proposed rulemaking (ANPRM) from the DOT’s Pipeline and Hazardous Material Safety Administration on hazardous liquid pipelines I did a special post of the comments that I submitted on that rulemaking. In those comments I noted that pipelines carrying poisonous inhalation hazard (PIH) chemicals (like anhydrous ammonia) pose a special hazard in the case of leaks. I suggested that:

“Any time that a PIH pipeline traverses an area near major thorough fare the PHMSA regulations should provide treatment similar to the HCA provisions even if the roadway is in an otherwise rural area. Once again, any above ground portions of the PIH pipeline in these areas will have an even larger potential affect.”

I also noted that:

“Once again, I would like to suggest that any place where a PIH pipeline is above ground externally based leak detection sensors are the only technology that would provide adequate warnings of the relatively small leaks of PIH materials that could affect unprotected civilians.”

In its notice of proposed rulemaking (NPRM) on the hazardous material pipeline revisions PHMSA responded to my comments (and similar comments by others) about HCA provisions for pipeline segments near roadways by saying:

“PHMSA is not proposing to designate major road and railway crossings as HCAs, but will consider whether the pipeline IM requirements should be applied to these areas when completing the study that Congress mandated under section 5 of the Pipeline Safety Act of 2011. PHMSA notes that the pipelines at such crossings would be afforded additional protections under the other proposals made in this proceeding, including the requirements for the performance of periodic internal inspections and the use of leak detection systems.”

On the external leak detection issues, PHMSA responded:

“PHMSA commissioned Kiefner and Associates, Inc., to perform a study on leak detection systems used by hazardous liquid operators. That study, titled “Leak Detection Study,” [4] was completed on December 10, 2012, and was submitted to Congress on December 27, 2012. PHMSA is considering, in a different rulemaking activity, whether to adopt additional or more stringent requirements for sensitive areas in response to this study.”

It should be noted that in the recent incident, it appears that the pipeline operator did have flow-based leak detection active on the affected pipeline section. One news report stated that: “the company’s remote sensing system detected a pressure drop on the portion of the pipeline that runs through Burt County. A pressure drop means a release may have occurred, he said.” Automated valves were then closed and authorities notified, just not soon enough to stop the one victim from driving into the ammonia cloud.

Emergency Notification

In both of these incidents the facility owner made all of the appropriate notification when the leak was discovered and there is no indication that the emergency response was not prompt. Still, in both cases an innocent third-party, with no connection to the facility, died as a consequence of the leak. In both cases they drove into a vapor cloud that looked no different than innocent bank of fog. Once in the cloud the auto’s motor stopped (for lack of oxygen) and the people died either from ammonia exposure or lack of oxygen.

While it is easy to say that better something would have prevented the leak (and the NTSB investigation will tell us that), it is even easier to say that if the person driving the car had been warned not to drive into the cloud, they would not have been killed. We have to expand our definition of emergency notification.

For local residents, notifications can be made by a reverse 911 notification system. In the most recent incident that would have saved the victim; he was a local who apparently was in search of the source of the ‘pungent odor’ of ammonia that he had smelled. If he had been notified by a reverse 911 system, he may never have left the house, and almost certainly would not have driven into the cloud if the message had been properly crafted.

For out of area personnel traversing highways near such incidents, the reverse 911 system is much more problematic. More advanced systems use phone location for notifications not sign-up addresses. But, then again, safety people are trying very hard to stop people from answering phone calls while driving. Something else is needed.

I proposed in an earlier blog post that signs could be posted on major roadways near fixed facilities and pipelines that handle PIH chemicals. These would be digital signs that would flash a warning not to proceed when a local PIH chemical detector detected a chemical cloud near the roadway. When not warning of a PIH leak, the signs could display other safety messages.

Moving Forward

The editorial that peaked my interest in this incident concludes by saying:

“Nebraska’s congressional delegation needs to work together to ensure the agency [PHMSA] is giving Nebraska proper attention, particularly in the case of anhydrous ammonia, to avoid a repeat of the tragedy caused by the leak in Burt County.”

The Nebraska congressional delegation does have some influence. Rep. Fortenberry (R,NE) is on the House Appropriations Committee (but not the Transportation Subcommittee). Sen. Fischer (R,NE) is an influential member of the Senate Commerce, Science and Transportation Committee and Chair of the Surface Transportation and Merchant Marine Infrastructure, Safety and Security Subcommittee (at least until December 31^st).

The most immediate thing that will influence any legislative or regulatory action on the pipeline safety issues involved in this incident will be the outcome of the NTSB investigation. The preliminary investigation by NTSB has not yet resulted in the incident being added to the list of current investigations. This means that there may not be a formal NTSB investigations. If, the NTSB does not take up this investigation then the effects of this accident on future legislative or regulatory actions will be very limited.

ICS-CERT Publishes 3 Advisories and Malware Trends Paper

Today the DHS ICS-CERT published three new control system security advisories and an in-house paper on malware trends. The three new advisories are for control system products from Schneider and IBHsoftec. One of the Schneider advisories addresses a vulnerability I discussed on Saturday. Neither of the Schneider advisories listed here are the ones referenced in a TWEET® from Critifence that I retweeted this morning.

Schneider Unity Pro Advisory

This advisory describes an insufficient control flow management vulnerability in the Schneider Electric Unity PRO Software product. The vulnerability was reported by Avihay Kain and Mille Gandelsman of Indegy. Schneider produced a new version of the software that mitigates the vulnerability. There is no indication that the Indegy researchers have been provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that while this vulnerability could be exploited remotely, since a two-stage social engineering attack would be required to exploit the vulnerability, developing a working exploit would be difficult. The Schneider Security Notification implies that direct loading of the corrupted file by the attacker could be possible “when the application program loaded in the simulator is not password protected”.

IHBsoftec Advisory

This advisory describes a buffer overflow vulnerability in the IBHsoftec S7-SoftPLC. The vulnerability was reported by Ariele Caltabiano (kimiya) through ZDI. IHBsoftec has produced a new version to mitigate the vulnerability. There is no indication that kimiya has been provided an opportunity to verify the efficacy of the fix.

ICS-CERT reports that relatively unskilled attacker could remotely exploit the vulnerability to “be able to affect integrity, confidentiality, and availability of the target device”.

Schneider ConneXium Advisory

This advisory describes a buffer overflow vulnerability in the Schneider Electric ConneXium firewall product. The vulnerability was reported by Nir Giller. According to ICS-CERT,Schneider is developing a firmware update, but the Schneider Security Notification (not listed in the ICS-CERT advisory) indicates that an update is currently available through “your local Schneider Electric representative”.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit the vulnerability to execute code during the SNMP (Simple Network Management Protocol) login authentication process.

The Schneider document also provides workaround information for the vulnerability.

Malware Trends

This white paper was produced by the ICS-CERT Advanced Analytic Laboratory (AAL). It is a 24-page review of the current state of malware. Once again ICS-CERT has produced a nice review document suitable for updating non-technical management on cybersecurity issues. It covers the following topics:

• Attacker tactic changes;

• Malware evolution;

• Persistence methods;

• Infection vectors;

• Defensive tactics; and

• Platform challenges

Unfortunately, like most recent ICS-CERT technical documents, it is very light on data specific to the control system (ICS) security community. It is not until page 17 where we see the first specific ICS discussion in a subsection of the platform challenges discussion. Even that discussion is very brief and very light on the details. For example, half of the discussion about Black Energy consists of the following paragraph:

“BlackEnergy is an interesting case of malware that has undergone a dramatic change in its design and target depending on the groups that use it. Initially, BlackEnergy was a DDoS bot primarily used by the Russian hacker underground to take down sites. Support for plugins was added in the next major revision (BlackEnergy2), changing the exclusively DDoS box into a powerful multi-tool. Years later, researchers discovered that threat actors utilized zero-day exploits and spear phishing, combined with BlackEnergy 2 and specially-tailored plugins, to target and compromise ICS networks.”

This is a good overview document that I would have been proud to have authored. The technical skills and experience of the AAL deserve a much better showcase.