Public ICS Disclosures – Week of 12-14-19

This week we have five vendor disclosures for products from WAGO, ABB, 3S, BD and Symantech. There is also an updated advisory from 3S.

WAGO Advisory

CERT-VDE published an advisory describing 9 vulnerabilities in the WAGO Series PFC100 and Series PFC200 devices. The vulnerabilities were reported (CVE links to individual reports) by Kelly Leuschner of Cisco Talos. WAGO has a specific workaround and firmware updates to mitigate the vulnerabilities. There is no indication that Leuschner has been provided an opportunity to verify the efficacy of the fix.

The nine reported vulnerabilities are:

• Information exposure through sent data - CVE-2019-5073;

• Buffer access with incorrect length value (2) - CVE-2019-5074 and CVE-2019-5075;

• Missing authentication for critical function (3) - CVE-2019-5077, CVE-2019-5078 and CVE-2019-5080; and

• Classic buffer overflow (3) - CVE-2019-5079, CVE-2019-5081 and CVE-2019-5082

NOTE1: The following Talos reports include exploit code: CVE-2019-5073; CVE-2019-5074; CVE-2019-5075; CVE-2019-5079; CVE-2019-5081; CVE-2019-5082

NOTE2: Talos reports that some of these vulnerabilities are in third-party components from 3S.

ABB Advisory

ABB published an advisory that describes four vulnerabilities in their PB610 Panel Builder 600. The vulnerabilities were reported by NSFOCUS. ABB has a new version that mitigates the vulnerabilities. There is no indication that NSFOCUS was provided an opportunity to verify the efficacy of the fix.

The four reported vulnerabilities are:

• PB610 HMIStudio crashes after launching an empty *.JPR application file;

• PB610 HMISimulator does not check content-length of the HTTP request;

• PB610 HMIStudio accepts malicious DLL file in an application; and

• PB610 HMISimulator provides interface with access to arbitrary files

3S Advisory

3S published an advisory [.PDF download link] describing a null pointer dereference vulnerability in their CODESYS V2 runtime systems. The vulnerability was reported by Chen Jie from NSFOCUS. 3S has new versions that mitigate the vulnerability. There is no indication that Chen has been provided an opportunity to verify the efficacy of the fix.

3S Update

3S published an update [.PDF download link] of an advisory that was originally published on November 20^th, 2019. The new data includes updated exploit information.

BD Advisory

BD has published an advisory describing the impact of the Internet Explorer® Scripting Engine Memory Corruption Vulnerability in their products. The vulnerability is self-reported. BD is working to test and validate the Microsoft patch for BD products that use the affected third-party components.

Symantec Advisory

Symantec has published an advisory describing an improper authentication vulnerability in their Industrial Control System Protection product. The vulnerability was reported by Tyler Holland at Horne Cyber Solutions. Symantec has an update that mitigates the vulnerability. There is no indication that Holland has been provided an opportunity to verify the efficacy of the fix.

Industrial Industry Manufacturers Clarified

Okay, I have an semi-official (here is what we meant, but please don’t quote me) clarification of what Symantec was trying to say when they came up with the phrase ‘Industrial Industry Manufacturers’ it means “industrial control system manufacturers and any other organizations who provide solutions to industrial facilities”. In other words anyone that makes the software or hardware used to control industrial processes; with hardware being used in the manufacturing plant terminology (not limited to control system terminology) to include pumps, valves, motors, frequency converters, pipes, etc.

Good; This I can understand. From a process chemist’s point of view that covers a whole bunch of stuff that I hadn’t worried much about from a security perspective before. But it certainly makes a lot of sense if you think about how you might go about destroying a manufacturing facility. You could just randomly operate relays and that would almost certainly screw up production and/or quality but might not shut down a facility. To shut down a facility you need to be able to destroy equipment (catastrophically if possible). To do that remotely you need to understand the design criteria and the various failure modes of that equipment. That’s all information that the equipment manufacturer will probably have on hand on some networked computer somewhere.

When I worked with the Intel (tactical level only) folks for a brief period in the Army they had a very interesting counter-intelligence term; EEFI – Essential Elements of Friendly Information. It was used to describe the information that the Commander did not want his enemy to know about his forces. So from an industrial security perspective (protecting the facility not just the cyber systems) it looks like whoever wrote Duqu was targeting our (the collective good guys) EEFI.

That’s even scarier than just Stuxnet…

BTW: That really seems to make the latest ICS-CERT update extremely confusing. Perhaps they should have said Duqu was not just [emphasis added] targeting ICS vendors.

Symantec Updates Stuxnet Dossier

Yesterday Symantec published version 1.4 of their “W32 Stuxnet Dossier”. A blog entry explains that there were essentially two new items included in the updated version (and Symantec intends to continue updating their report as they continue to come up with new data on the attack). First they were able to time track the infection and track it back to five specific initial attack vectors. Second they confirmed much of the work that Ralph Langner has reported on the 417 attack code (without reaching any conclusions about the specific target because the code was ‘disabled’).

Tracking the Infection

Certainly the most valuable part of this new information is the information Symantec was able to provide on how the worm was physically spread from the initial attack vectors. They are in a unique position to conduct this portion of the research because they possess 3,280 distinct copies of the virus from the wild representing 3 separate variants of the worm. This combined with the fact that Stuxnet records system data (including time stamp and IP address) every time that it infects a new host and Symantec can provide a good picture of how the attack proceeded.

Symantec has been able to show that there were five separate organizations that were used as initial attack vectors, what Symantec misleadingly calls targets. All five of these initial vector organizations, Symantec reports, have a presence in Iran. Apparently an infected USB drive was introduced into these organizations as a way of pointing the worm at its intended target without risking the actual presence of the author’s agents in Iran.

In its discussion of the spread of the worm the Dossier authors make a point of noting that the worm had a designed-in self-limiter, after infecting three separate computers the infection from that particular device shut down. Looking at the cluster diagrams on page 9 of the Dossier it does not seem as if any single attack-vector organization was infected more than twice by the initial device on each attack wave.

While this may simply be a data anomaly due to the small sample size, it seems unlikely with ten separate infections. It seems more likely that the agents carrying the infected USB drive were under instructions to limit their infection to just two computers to reduce the likelihood of their being detected.

The other interesting thing from these diagrams is that it does not appear that there is any cross linking between the infection trees. We can clearly see from the diagrams that within an infected zone there are a number of places where a single computer is linked to multiple sources, as we would expect from an increasingly networked world. It is not clear whether Symantec just failed to note cross infections from the initial attack vectors, or if these infections were actually isolated from each other.

The Reason for the Tracking Data

While Symantec is to be commended for putting this data together, it seems obvious that the virus designers put this tracking tool into the worm for a reason. If they were able to collect this data from infected computers (which they certainly were until the identified command and control link was shut down) they were able to paint a very complete picture of how their attack spread. This would certainly be valuable information to design subsequent attacks.

With that in mind I would like to suggest that clearly identified C&C computer that was shut down relatively soon after Stuxnet was identified was not the only method by which the originators planned to get information back from Stuxnet infected computers. If I were designing this system I would have seeded the operational area with a network of communications nodes.

Given the information sharing design of the Stuxnet worm, each time an infected computer talked with another computer on its network it would drop an updated copy of its infection history into the new computer. If a separate virus were designed to set up a very specific bot network, one designed to ‘listen for’ a new set of Stuxnet infection histories and report that history back to a separate command and control computer, the Stuxnet authors could keep receiving updated information on the progress of the spread of the virus. It would also allow them to map the optimal path to link to any particular infected computer.

In the infection on a targeted computer (or attached PLC’s) were not completely cleared, then a subsequent Stuxnet-like virus would be more easily targeted at those systems. Such an attack could be very directed without the collateral exposure that led to the discovery of Stuxnet. And with the spread of Stuxnet far and wide across the world, the attack would not necessarily have to be limited to Iranian nuclear facilities or even against just targets in Iran.

This bot network would be very hard to detect since it would be operationally limited to a very small set of instructions. Unless one knew exactly what to look for this network could exist for years before it was discovered. In fact, if the designers were particularly devious, they would set up at least a couple of separate bot networks to allow for one or more to be detected and remediated without loosing contact with their tools.

Identifying Stuxnet Source

With the source tracking data that Symantec has, it would seem to be a relatively simple investigation to determine who carried the infected USB drive into the attack vectors. Symantec obviously does not list the real identity of these initial targets, but they must certainly have that data. An intelligence or law enforcement organization should be able to take that data, conduct the appropriate investigation and determine who was likely to have carried the USB drive. Will this happen? I doubt it.

Symantec Stuxnet Update

Yesterday, Symantec published the 1.2 version of their Stuxnet Dossier. According to a blog on their site, they have still not been able to identify the actual target for Stuxnet, but they have done some additional work on the “high level the behavior of the PLC code” and have updated their Stuxnet document to include that information.

The updated information is a bit over my head (I was an ICS user not programmer), but it would certainly be of interest to control systems engineers and security experts.

The blogger, Eric Chen, notes that they would have provided some more information on the remaining zero-day vulnerability, but Microsoft has still not provided a patch/update to resolve that vulnerability (a “Task Scheduler privilege escalation vulnerability”) so Symantec will hold off until some future revision of the Dossier to explain that issue.

Stuxnet Dossier from Symantec

Thanks to the folks at SCADESEC List for pointing me at today’s Symantec Blog about their release of the W32 Stuxnet Dossier. Symantec has compiled a 49 page document that lists what they know or have been able to learn about the Stuxnet … thing (virus, Trojan, worm, malware; none of these really fits. We may need a new term.). It is a pretty document (good production values) but it is more importantly an important learning tool for anyone concerned with protecting (or unfortunately attacking) industrial control systems.

Perhaps the scariest part of the document comes just before the Introduction:

“While the bulk of the analysis is complete, Stuxnet is an incredibly large and complex threat. The authors expect to make revisions to this document shortly after release as new information is uncovered or may be publicly disclosed.”

Part of this is driven by the need to get this together for delivery at the Virus Bulletin 2010 conference. Part of this is apparently still being driven by the complexity of Stuxnet, and I assume the very real possibility that the unknown design team may have new variants on the way.

At a glance, much of this document is over my head technically. If you are a control system engineer at a high-risk chemical facility (or a power plant, or a food processor, or…..) you probably need to download and read this document; soon. I’ll wade through the technical stuff, I recommend that the rest of the chemical security community does the same.

Stuxnet Transmission

Just a quick note about another Stuxnet transmission technique discovered over at Symantec. Their latest Stuxnet blog describes how infected project files can transmit the malware between computers and even provides a way to re-infect a cleaned computer by running a back-up version of a project file. It certainly seems like the Stuxnet design team wanted to make sure that their toy had staying power. So now Stuxnet can be propagated via:

● USB Stick
● Print Spooler
● Network via P2P
● Project Files

The only thing missing is an email transmission mode via the address book list and the Vulcan Mind Meld. But, research is still on going.

BTW: Symantec has collected all of their Stuxnet blogs at one convenient URL: http://www.symantec.com/connect/stuxnet