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.

PHMSA Publishes Pipeline Safety Regulation Update Final Rule

Today the DOT’s Pipeline and Hazardous Material Safety Administration published a final rule in the Federal Register (80 FR 12762-12781) updating various portions of the Pipeline Safety Regulations. The NPRM for this rulemaking was published in November 2011.

These amendments address several subject matter areas for both gas and hazardous material pipelines including:

● The performance of post-construction inspections;

● Leak surveys of Type B onshore gas gathering lines;

● Qualifying plastic pipe joiners;

● Regulation of ethanol;

● Transportation of pipe;

● Filing of offshore pipeline condition reports; and

● Calculation of pressure reductions for hazardous liquid pipeline anomalies.

Based upon public comments submitted in response to the notice of proposed rulemaking (NPRM) PHMSA made the following changes to the proposed rulemaking:

● Responsibility to Conduct Construction Inspections, expanded to include both gas and hazardous material pipelines and revised to more clearly identify the types of individuals who should be excluded from the required inspections {§192.305 and §195.204};

● Qualifying Plastic Pipe Joiners, to provide greater scheduling flexibility and require requalification of a joiner if any production joint is found unacceptable {§192.285(c)};

● Calculating Pressure Reductions for Hazardous Liquid Pipeline Integrity Anomalies, PHMSA is is adopting LPAC’s suggested language as it best clarifies that an operator must calculate remaining strength or reduce operating pressure until a repair can be completed {§ 195.452(h)(4)(i)};

● Alternative MAOP Notifications, PHMSA is changing the advance notification requirement from 180 days to 60 days {§ 192.620(c)(1)};

● Welders vs. Welding Operators, PHMSA is now citing Appendix A as being applicable to welding and welding operators {§192.225, §192.227, §192.229, §195.214, and §195.222};

● Odorization of Gas Transmission Lateral Lines, PHMSA is re-evaluating the proposal and may consider it in a future rulemaking.

PHMSA included a number of editorial type changes in the NPRM and all of them are included in the final rule. Additionally, the following editorial changes have also been included, but were not discussed in the NPRM:

● Hazardous Liquid Construction Notifications, PHMSA makes it clear that they do not want to be notified of hazardous liquid pipeline facility construction with a cost of less than ten million dollars, so § 195.64(c)(1)(iii) is being deleted.

● Electronic Submission of reports {§191.25, §192.805, §192.949, §195.56, §195.452, and §195.505}

The effective date for this rule is October 1, 2015 and immediate compliance is authorized.

Bills Introduced – 03-10-15

The Senate was in town yesterday and there was a proforma session in the House (most everyone was home working in their districts) so there were only 32 bills introduced yesterday. There was only one that would be of specific interest to readers of this blog:

S 697 A bill to amend the Toxic Substances Control Act to reauthorize and modernize that Act, and for other purposes. Sen. Udall, Tom [D-NM]

This bill was introduced with much fanfare in the Senate Environment and Public Works Committee yesterday. It is being touted as a bipartisan (8 Democrat and 9 Republican cosponsors) update to the TSCA program. Just remember that a similar bipartisan bill (S 1009) was introduced last session and it died in the same committee. This will almost certainly be a controversial bill with people sniping at it from all sides.

ICS-CERT Publishes 5 Advisories

This morning DHS ICS-CERT published five advisories for industrial control system vulnerabilities. The affected systems come from GE, Elipse, SCADA Engine, ABB, and CIMON.

GE Advisory

This advisory describes a predictable TCP sequence vulnerability in GE Digital Energy’s Hydran M2 device. The vulnerability was reported by Raheem Beyah, David Formby, and San Shin Jung of Georgia Tech. GE has eliminated this vulnerability in versions of the product produced after October 2014. There is no indication that the researchers have verified that the vulnerability has been removed from newer versions of the device. This vulnerability was originally reported on the US-CERT Secure Portal on February 10^th.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit this vulnerability to send counterfeit packets as if they came from the device.

Since the vulnerable devices cannot be fixed they either have to be replaced or protected by other measures which would isolate them from the attack.

Elipse Advisory

This advisory describes a process control vulnerability in the Elipse E3 application; the vulnerability is actually located in a third-party (Telerik) DLL. The vulnerability was reported by Ivan Sanchez from Nullcode Team. Elipse has produced a new version which mitigates the vulnerability. ICS-CERT reports that Sanchez has verified the efficacy of the fix.

ICS-CERT reports that the vulnerability could not be remotely exploitable but goes on to explain that a social engineering attack could cause an authorized operator to load a compromised DLL.

ICS-CERT reports that Telerik has notified its other affected customer of the problem with its DLLs and has provided them with updated version that do not include the vulnerability. Hopefully those other un-named vendors will notify their customers of the vulnerability.

SCADA Engine Advisory

This advisory describes three vulnerabilities in the SCADA Engine BACnet OPC Server. These vulnerabilities were reported by Josep Pi Rodriguez. SCADA Engine has produced a new software version that mitigates the vulnerabilities. ICS-CERT reports that Rodriquez has verified the efficacy of the fix.

The three vulnerabilities are:

● Heap-based buffer overflow - CVE-2015-0979;

● Input validation - CVE-2015-0980; and

● Authentication - CVE-2015-0981

ICS-CERT reports that a relatively low skilled attacker could remotely exploit these vulnerabilities to execute arbitrary code or modify the OPC Server database.

ABB Advisory

This advisory reports on the CodeWright HART DTM vulnerability in ABB products. The base information provided in this advisory is the same as that found in the latest version of the CodeWright advisory. ICS-CERT reports that ABB has begun to integrate the new CodeWright library but ABB reports that they have updated versions for the affected products which include the corrected CodeWright libraries.

CIMON Advisory

This advisory describes a DLL hijacking vulnerability in the CIMON CmnView.exe application. The vulnerability was reported by Ivan Sanchez of Wise. CIMON has produced a patch that mitigates the vulnerability but there is no indication that Sanchez has verified the efficacy of the patch.

ICS-CERT reports that the vulnerability is remotely exploitable via a social engineering attack. No exploit is publicly available for this specific system but there are publicly available exploits for this ‘attack vector’.

Fix Verification

Some people have asked me why I make a big deal out of announcing whether or not the researcher who discovered a vulnerability has verified the efficacy of the fix. After all, I am asked, isn’t it in the best interest of the vendor for the fix to work? Today a report from the Zero Day Initiative showed why it may be important for an outsider to verify fixes.

One of the key vulnerabilities exploited by Stuxnet was the now infamous Microsoft MS10-046 vulnerability. This vulnerability allowed systems to automatically run DLL files from USB devices without the operator initiating the action or even knowing that it took place. Microsoft patched that vulnerability four years ago. Earlier this year Michael Heerklotz reported that the patch did not work.

If Microsoft can convince themselves that a flawed patch mitigates a vulnerability then anyone can. A researcher that discovers a vulnerability looks at it in a different light than does a software engineer that is fixing it under a deadline. Two ways of looking at the problem may not actually be enough, but it is certainly better than just one way.

I’ll continue to be the gadfly that reports whether or not ICS-CERT is reporting that an outsider has verified the efficacy of the mitigation measure being reported.

How to Disrupt Drones - Background

There is an interesting article over at WTOP.com about work supposedly being carried out by the Secret Service in their attempts to prevent a re-occurrence of the recent ‘drone incursion’ at the White House. I’m very surprised that they are doing their testing in Washington, DC, but that may just be because there are more air space controls in place there than most anywhere else in the country. But, all of that aside, the discussion of disrupting drone activities is an important one for all critical infrastructure security, one that I have pretty much ignored until now.

This will be the first of a short series of articles about the use of drones as weapons against critical infrastructure and what can be done to reduce the risk of their successful employment as a weapon.

What is a Drone

Thanks to the War on Terror just about anyone in the world that hears the word ‘drone’ first thinks of war birds like the Predator equipped with Hellfire missiles, taking out al Qaeda leadership or killing innocent civilians depending on your point of view. This is for all intents and reasonable purposes a war plane. While some commentators (and a couple of popular TV shows) have warned about terrorists gaining control of such weapons, defending a facility against such attacks is a job for the US Air Force not the local chemical facility security manager. So I will ignore such sophisticated weapons until such time as North Korea or Iran starts selling them at Wal-Mart prices to various terrorist organizations.

No what is of legitimate concern to security managers at critical infrastructure locations is the much more common and less sophisticated remotely piloted vehicles that the FAA is calling sUAV (small unmanned aerial vehicle). Weighing less than 55 lbs this class of vehicles encompasses everything from the small toy helicopters you buy in the mall (the FAA calls these micro UAV if they weigh less than 4.4 lbs) to hobiest type vehicles like the quad copter that crashed at the White House, to sophisticated surveillance aircraft being introduced into service around the country.

The limited payload size of these aircraft means that they will be unlikely to be used against hardened targets like nuclear reactors. They would, however, be able to carry a small explosive or incendiary device, which means that they could be capable of initiating an attack on a chemical facility.

More likely, however, is that the surveillance capability of these types of vehicles could by terrorists to gain detailed knowledge of the layout and security measures at a targeted facility in preparation for an attack, or even for command and control activities during an infiltration.

A much more likely use of these vehicles will be surveillance activities by non-violent activist groups (think GreenPeace) wanting to document perceived or alleged environmental or ethical violations at chemical facilities. Similarly, I expect that we will see an increasing number of news organizations using these sUAV for acquiring videos for the evening news.

Drone Capabilities

Because of the wide variety of potential vehicles it is going to be difficult to describe a specific set of characteristics for this class of aircraft. In order to remain in the sUAV classification the FAA does intend to limit the maximum speed to 100 mph and require that an operator be in constant control of the device.

Fixed wing versions of these drones are going to have some limitations on their maneuverability just because they require air flow over/under their wings to maintain lift; they won’t be able to hover for instance. Their low weight, however, will mean that they will be able to fly relatively slowly without stalling. Low speed also means pretty good maneuverability.

Rotary winged versions will probably not reach the 100 mph speed, but they will be very maneuverable and will be able to hover and reverse. Spinning the aircraft body in place will also be a rather unique capability.

Motive power will be electric for the smaller aircraft and internal combustion engines will be common on the larger versions. The electric versions will be relatively quiet; the IC’s not so much.

All of these sUAV will require real-time electronic communications with their controller/pilot. This means a WiFi, cell phone or radio link.

Weaponization

To date I haven’t seen any specific discussion of weapons actually being deployed on any of these small aerial vehicles, but it is just a matter of time. Because of the size of the platform, however, there will be some limitations.

You can just about forget these vehicles being used as gun platforms. It wouldn’t be too hard to mount a small barrel and firing device, but any cartridge of significant caliber will provide so much recoil that the flight controls will be seriously disrupted. This will be less true of the larger, fixed-wing aircraft, but the engineering required to design and build a system with any significant size (caliber) and accuracy will be extensive. I know some gun-nuts that would be interested in the challenge, but I don’t see anything happening in this arena soon.

Rockets would be much better suited to this type of platform. The problem would still be size/weight restrictions. The aiming and firing mechanism is going to be a design challenge. The small size of the warhead for any but those mounted on the largest platforms in the class will limit the strike utility of these weapons.

The most effective way to weaponize these vehicles would be with explosives. Bombing will certainly be tried, but I suspect that the accuracy will be WWI level; certainly nothing like the precision weapons delivery we’ve come to expect of sophisticated aerial platforms. Much more effective will be the flying bomb where the explosive payload never leaves the aircraft. A couple of pounds of plastic explosive will be well within the capability of all but the smallest micro UAV. This is the type of weaponization that would be the cheapest and easiest to engineer; I expect that it will be the first to be employed in the wild.

There is also the possibility that these aircraft could be employed in an electronic warfare mode. Many large chemical manufacturing facilities use wireless communications techniques in their control system deployments. Using a drone as a platform to intercept, jam or mimic these communications could provide a unique attack capability. This mode of attack would require a great deal of sophistication and multiple areas of expertise to implement. In the near term this is a low probability attack method.

There are other less sophisticated ways to employ sUAV as weapons. The easiest, of course, is to employ the aircraft as a direct kinetic weapon, just fly it into the target. This was a well publicized method used by a very limited number of Japanese pilots in WWII. The higher the speed capability the more effective this will be as an attack method.

There are other attack techniques that could be used in specialized situations. I’ll give just couple of examples that come to mind. Attach a long copper wire to the drone and fly it into an electric sub-station; exciting things will happen. Or fly a drone through a flare at a refinery; great balls of fire.

HR 1073 Introduced – EMP

As I mentioned earlier Rep. Franks (R,AZ) introduced HR 1073, the Critical Infrastructure Protection Act. This bill would require DHS to consider electromagnetic pulse events (natural and man-made) in federal planning scenarios.

As I mentioned in my earlier post this bill is closely patterned after HR 3410 which was introduced and passed in the House last session. Now that I have had a chance to actually read HR 1073 it is clear that it is the same bill with two inconsequential additions;

Section 3 was added to specifically state that this bill cannot be “be construed to grant any regulatory authority”;

Section 4 was added to specifically state that this bill provides no authorization for new spending and that it may only “be carried out only by using funds appropriated under the authority of other laws”.

The added wording was superfluous as there is no mention of regulations or spending authority in the bill. As with the previous bill this will require DHS to undertake new work without providing any new money or manpower. That being said I don’t see any significant opposition to this bill in either house.

If it is brought up it will be considered under suspension of the rules in the House and under unanimous consent procedures in the Senate, so there will be not real debate and no amendments offered. If it gets to the floor in either case it will be passed with a substantially bipartisan vote.

ICS-CERT Publishes 5 Siemens Advisory and an Update

Yesterday the DHS ICS-CERT published five new advisories for various Siemens control system products and updated their supplement to the NTP advisory. All six documents were based upon reports that Siemens issued yesterday.

NTP Supplement Update

This update reflects new information that Siemens released on the NTP Vulnerability reported in its RuggedCom ROX based devices;  a new version of ROX 2 has been released that mitigates the vulnerability in those devices. Additionally Siemens reported that this vulnerability also affects their SINUMERIK controllers; an upgrade is available to mitigate the vulnerability in this product.

SPCanywhere Application Advisory

This advisory describes multiple vulnerabilities reported in the SPCanywhere mobile application. The vulnerabilities were originally reported by Karsten Sohr, Bernhard Berger, and Kai Hillmann from the TZI-Bremen, Kim Schlyter, Seyton Bradford, and Richard Warren from FortConsult, and Stefan Schuhmann. Siemens has produced a new mobile application (SPC Connect) that mitigates these vulnerabilities. There is no indication that the researchers have been given a chance to verify the efficacy of the fix in the new application.

The vulnerabilities include:

● Missing encryption of sensitive data - CVE-2015-1595 and CVE-2015-1596;

● Improper cross-boundary removal of sensitive data - CVE-2015-1597

● Storing passwords in recoverable format - CVE-2015-1598

● Authentication bypass using alternate path - CVE-2015-1599

ICS-CERT reports that some of these vulnerabilities could be remotely exploited by a relatively low skilled attacker while others might require more skill and/or local access. Siemens reports that the last two vulnerabilities require physical access while the other only requires a “privileged network position to be able to control network traffic”.

As far as I can tell this is the first time that ICS-CERT has issued an advisory for a mobile application. As more of these applications come into use for remote access to industrial control systems I expect that we will be seeing more of these advisories.

S7-300 Advisory

This advisory describes a DOS vulnerability in the Siemens SIMATIC S7-300 CPUs. The vulnerability was reported by Johannes Klick, Christian Pfahl, Martin Gebert, and Lucas Jacob from Freie Universität Berlin’s work team SCADACS. Siemens reports a mitigation technique to resolve this vulnerability. There is no indication that the researchers have verified the efficacy of this fix.

ICS-CERT reports that the vulnerability is remotely exploitable, but that an exploit would be difficult to craft. Siemens reports that, in addition to standard network protections, read/write protections should be applied to the system to mitigate the vulnerability. There is no mention by either ICS-CERT or Siemens of any intention to provide a more effective fix.

An interesting TWEET from Michael Toecker focuses on the mention of the role of Profibus in this vulnerability; he asks: “Who else uses the same Profibus stack?” Control systems use lots of different applications. When an application vulnerability affects one system the question is always going to be if the same vulnerability affects other systems. Researchers/hackers routinely use this type information to look for vulnerabilities in other systems.

SPC Controller Advisory

This advisory describes a DOS vulnerability in Siemens SPC Controllers (a hybrid physical intrusion detection and access control system). The vulnerability was reported by Davide Peruzzi of GoSecure!. Siemens has produced a firmware update that mitigates the vulnerability but there is no indication that Davide has been given an opportunity to verify the efficacy of the fix.

ICS-CERT reports that a relatively low skilled attacker could remotely exploit this vulnerability to effect a denial of service attack. Siemens reports that network access is required and that the web interface must be enabled.

SIMATIC Advisory

This advisory describes a search path vulnerability in various SIMATIC products. The vulnerability was reported by Ivan Sanchez from WiseSecurity Team. Siemens has produced updates for most of the affected products, but there is no indication that Ivan has been afforded the opportunity to verify the efficacy of the fixes. Additional mitigation steps have been provided pending updates of the other products.

ICS-CERT reports that a moderately skilled attacker could exploit this vulnerability. They claim that the vulnerability is not remotely exploitable, but mention that arbitrary code from files on network shares could be executed based upon a social engineering attack; a classic remote exploit technique.

GHOST Advisory

This advisory describes the Siemens systems affected by the GHOST vulnerability in the glibc library. Siemens is apparently self-reporting this vulnerability. Siemens has produced an update for one of the two systems affected. Additionally they report that a third system may be vulnerable depending on the installation configuration used; the default configuration is not affected.

ICS-CERT reports that a relatively low skilled attacker with local network access could exploit this vulnerability to effect a denial of service attack. ICS-CERT notes that there is no known Siemens specific exploit available for this vulnerability, but that there are publicly available exploits for other systems.