Public ICS Vulnerability Disclosure – Week of 04-02-17

This week there were three public control system security vulnerability disclosures; two published on the Full Disclosure web site and one on SecurityWeek.com. The affected devices include data loggers, network connection devices and PLCs.

PLCs

On Wednesday Eduard Kovacs published an article about twin vulnerabilities in the Schneider Electric Modicon programmable logic controllers (PLCs) that were reported by Simon Heming, Maik Brüggemann, Hendrik Schwartke, Ralf Spenneberg of OpenSource Security. The reported vulnerabilities were:

• Hardcoded encryption key; and

• Password sent in clear text

Schneider received notification of the vulnerabilities back in December, but some snafu occurred and no action was taken. OpenSource published the vulnerabilities on their web site (here and here) on Tuesday.

NOTE: I tweeted about this vulnerability on Wednesday.

Data Logger

On Thursday Karn Ganeshen announced multiple vulnerabilities in data loggers, meter monitors and electric meters from SenNet. The reported vulnerabilities are:

• No access control on the remote shell;

• Shell services running with excessive privileges;

• OS command injection (with POC); and

• Insecure transport

Ganeshen reported that the vendor has fixed the vulnerabilities and ICS-CERT will be issuing an advisory.

Network Connection Devices

On Thursday Karn Ganeshen announced SNMP vulnerabilities in network communication equipment from Cambium. The reported vulnerabilities are:

• SNMP community strings privileges are not enforced correctly;

• Device configuration backups – access control issues; and

Ganeshen also reports that the Cambium devices are also subject to the following design flaws that magnify the above vulnerabilities:

• It is possible to access full device configuration using SNMP. Device configuration includes usernames, passwords, SSIDs, keys, certificates, syslog config, and other network & wifi specific details.

• It is possible to trigger configuration backups, which can then be retrieved using SNMP.

• It is possible to wipe out and / or make changes to the device configuration remotely.

Ganeshen reports that ICS-CERT was notified on September 12^th, 2016 and on April 5^th Cambium announced that the vulnerabilities would be fixed in 2^nd Quarter 2017.

ICS-CERT Updates Two (Three?) Schneider Advisories

Yesterday afternoon the DHS ICS-CERT updated two earlier advisories for Schneider systems and referenced a third in both of those updates. The earlier advisories addressed:

• Schneider Electric Quantum Ethernet Module Hard-Coded Credentials - ICSA-12-018-01;

• Schneider Electric PLCS Multiple Vulnerabilities – ICSA-13-077-01A; and

• Schneider Electric Multiple Vulnerabilitiesa – ICS-ALERT-13-016-01A.

Ethernet Module Firmware Updates

In addition to the earlier mitigations developed by Schneider, the revised advisory reports that two new firmware updates are now available for 140NOE77101 and 140NOE77111. The updated advisory does not mention if the original researcher, Rubén Santamarta, has been provided an opportunity to verify the efficacy of the updates.

There are still un-mitigated vulnerabilities on this advisory.

PLC Updates

The updated advisory notes that Schneider has developed a patch for HTTP and FTP services that allows the HTTP to be disabled on certain modules. The link for these patches is a generic link that takes one to the Schneider site with no immediately apparent method to find the patches. Schneider still hasn’t produced a patch for the vulnerabilities in the Modicon M340 or Premium PLCs.

Once again there is no indication in the updated advisory that the researcher, Arthur Gervais, has had a chance to verify the efficacy of the patches.

Reader Comment – More on PLC’s

An interesting comment was posted on yesterday’s blog about ICS misconceptions. It seems that I missed one of the underlying points about another way to go about securing control systems at their points of action; the PLC. The Anonymous readers suggest that instead of allowing for reprogramming of PLC’s via the hard wired connection (which is a potential source of attack through the networked control computer) that the reprograming could be done by physically changing the memory card for the PLC like one does with the memory card on a digital camera.

While this novel suggestion would certainly avoid the in situ reprograming of the PLC that was seen in the Stuxnet attack (for instance) it has some limitations on its applicability in large scale control systems like those found in chemical plants. It also ignores the fact that the programing of the PLC memory chip still takes place using the same workstation that would allow the Stuxnet type attack in the first place.

Large Number of PLCs

A large scale chemical manufacturing facility can have thousands of PLC’s in operation. The relatively small specialty chemical manufacturer that I last worked at had one reaction vessel (the one I spent the most of my time working with) with over 100 controllers on it alone. While most of these operated valves (a fairly simple operation) a great deal of time was spent over the years on tweaking the specific interlock rules and valve operation timing (including how fast the valve opened and closed) instructions. And that was with processes that were still largely operator controlled. As we moved to increased process automation the programing got even more complicated and time consuming.

For the vast majority of PLC’s in use in a modern manufacturing facility I don’t think that the physical changing of program memory cards is practical. While the act of switching a memory card is fairly simple when one looks at the number of PLC’s involved in a fairly simple process adjustment the number of card changes involved almost ensures that a wrong card will be put in an inappropriate slot.

Physical Security Issues

There is also a physical security issue that must be addressed, a fact frequently overlooked in discussions of cyber security. If programing changes are now going to be physically implemented at the PLC we now have to provide protections that will prohibit the unauthorized change of cards as a means of cyber-attack. The current centralized programming operation only requires physical security measures for the control computer and its associated hardware. And physical security measures are frequently more expensive than cyber-security measures.

Programming Vulnerability Remains

Finally, the programming still has to be done at the facility level, even if that means hiring an outside consultant to handle that job. This leaves the programing control workstation as the point of attack on the PLC’s. It would avoid the problems associated with the wireless network capabilities that vendors are adding to their PLC’s (and are apparently being sucked up by system owners), but the computer that allowed the networked attack on the PLC in the Stuxnet attack is still the point of vulnerability.

Safety Systems

Having noted all of these shortcomings in this proposed solution, there is certainly one area where a control system owner might want to consider this methodology; safety control systems. These stand-alone systems are tweaked infrequently at worst and are relatively simple systems. Their strong points are reliability and inaccessibility. It would seem that only allowing programing changes via firmware substitution would be ideally suited to these types of systems.

Since these systems backstop security systems by not allowing for catastrophic failure of the process, separating them from the potential for a Stuxnet type attack would seem to be a smart idea. Their limited use and infrequent need for updates would also seem to be ideally suited for the design of a single use programing work station that would only be able to program these devices and have no ability to connect to the internet or corporate networks. Device signing could be used to ensure that only trusted drives and memory cards could be used on the system.

Safety system designers may well want to consider this methodology to increase the reliability and security of those systems.