ICS-CERT Publishes 5 Advisories by the Numbers

Five separate advisories were published by the DHS ICS-CERT folks today and there are a lot of other interesting numbers involved. First there are two new sets of vulnerabilities from coordinated disclosures and three sets following up alerts for uncoordinated disclosures. Next there are two advisories from Luigi and one from Basecamp. Then there are two Siemens advisories for different devices by different researchers. Finally we have a real first; a vulnerability reported in a cybersecurity device.

Siemens

Siemens has two new devices now listed on the ICS-CERT list of vulnerable control systems applications; Scalance S and Scalance X. The similarities in names is apparently due to both being communications devices; Scalance X is an ‘Industrial Ethernet Switch’ and Scalance S is a security module that includes a ‘Stateful Inspection Firewall’. Vulnerabilities in either could open an otherwise secure network to attack.

The two vulnerabilities reported in Scalance S were disclosed to Siemens by Adam Hahn and Manimaran Govindarasu. The vulnerabilities are a brute-force authentication vulnerability and a stack-based overflow vulnerability. Both are remotely exploitable by a moderately skilled attacker and could result in a DOS or possibly arbitrary code execution. Siemens has a firmware update and a security advisory to ‘resolve’ these vulnerabilities. Interestingly ICS-CERT does not say that the researchers have verified the resolution of these vulnerabilities.

There is just a single buffer overflow vulnerability reported in the Scalance X by Jürgen Bilberger from Daimler TSS GmbH directly to Siemens.  This is a remotely exploitable vulnerability that could be exploited by a moderately skilled attacker. A successful exploit could result in a DOS or execution of arbitrary code. Siemens has a firmware update for this vulnerability that, again, the advisory says ‘addresses the vulnerability’ without saying that the researcher has verified that claim.

I’m not sure how ICS-CERT was notified about these vulnerabilities since both advisories clearly state that the disclosures were directly to Siemens. I would probably assume that the notification was made by Siemens and that would certainly be a positive move from a company that a large number of people associate with their insecure-by-design PLCs.

Luigi Uncoordinated Disclosures

Two of today’s advisories were follow-ups to alerts due to uncoordinated disclosures last year by Luigi. One of the advisories references the earlier alert, but the other does not. What’s really unusual about that is that another advisory for the same product, the MICROSYS Promotic HMI, where ICS-CERT did not reference the original Luigi related alert. To the best of my knowledge these are the only two instances where an earlier alert was not referenced in the advisory; strange coincidence that they both are about the same product reported by the same researcher.

The Promotic vulnerability is for a ‘use after free’ condition that would allow an attacker to corrupt data or possibly execute arbitrary code. Remote execution is not possible as the exploit requires a local user to run a vulnerable project file. MICROSYS notes that the latest version of Promotic does not contain this vulnerability so users can just download the latest version to correct the problem.

The second advisory is for the Certec webMI2ADS HMI application, or maybe it is the atvise webMI that they referenced in the original alert. There has been more than a little confusion in naming protocols in systems upon which Luigi has reported. This is probably due to the fact that Luigi is operating out of Italy and names do change in different countries.

The Certec advisory addresses four separate vulnerabilities;

• Directory traversal;

• Null pointer;

• Termination of software; and

• Resources consumption

These vulnerabilities are remotely executable that a relatively low skilled attacker could exploit to cause a DOS or perhaps access ‘sensitive data’. Registered users can download a new version of the application that does not contain these vulnerabilities. The Advisory reports that Luigi has confirmed that the update ‘resolves these vulnerabilities’.

Basecamp

The Basecamp related advisory concerns the vulnerabilities identified in the Koyo ECOM1000 Ethernet Module. Reid Whitman was responsible for the original disclosure as part of the Basecamp presentations at the S4 Conference in January. There were five vulnerabilities identified in this product;

• Buffer overflow;

• Weak password requirements;

• Web server cross-site scripting;

• Web server requires no authentication; and

• Uncontrolled resource consumption.

All of the vulnerabilities are remotely exploitable allowing a moderately skilled attacker to exploit these vulnerabilities. Koyo has a produced a patch that addresses each of these vulnerabilities with varying degrees of effectiveness. The web server, for example, is now disabled by default but the module can reconfigured by the user to enable the web server and apparently re-opening the vulnerability.

ICS-CERT Updates Three S4 Alerts

With the folks at Digital Bond releasing more of their Basecamp SCADA tools today, the DHS ICS-CERT was forced to update their alerts for three of the systems that were addressed in the Basecamp exercise. Those alerts directly affect the Koyo ECOM100 Ethernet Module, the Schneider Electric Modicon Quantum PLC, and the Rockwell Automation ControlLogix PLC.

When I first read the updates (a paragraph added to each existing alert) I was impressed by the fact that ICS-CERT acknowledged that the Rockwell vulnerabilities also applied to other PLC’s besides those manufactured by Rockwell. That Alert states:

“As this exploit does not specifically target a system and is aimed at a protocol employed by many PLC vendors, this release could impact many additional vendors.”

Unfortunately when I went back and read the announcement on Digital Bond I was more impressed about the whopping understatement that was provided by that ICS-CERT remark. Reid Wightman explains the extent of the term ‘many PLC vendors’ this way:

“About 300 vendors belong to the organization responsible for the EtherNet/IP CIP specification, so the list of affected devices is going to be…large. This vulnerability should include some systems by Schneider Electric, WAGO, Omron, Opto 22, Phoenix Contact, and ABB, just as examples.”

NOTE: The ‘300 vendors’ link takes you to the directory of ODVA members. I’m not sure how many of these vendors actually produce PLC’s. The links on that page do not take you to vendor web sites, just a pop-up of the street address of the vendor.

Of course, complicating this further is that many manufacturing systems come as complete packages with PLC’s pre-installed. In many cases the owner has no idea which vendor supplied the PLC in the system.

We all knew that that Project Basecamp was blowing the lid off of industry’s ability to ignore the PLC security issue. Even so the scope of the problem is becoming even more mind blowing as more information comes out of the project.

Another interesting question comes to mind. How is ICS-CERT going to deal with the multiple vendor issue for the Rockwell alert? Are they just going to coordinate with Rockwell to resolve the vulnerability? Rockwell is undoubtedly big, but are they big enough to pull the entire ODVA membership into accepting a change to the communications protocol to secure access to the PLCs? Or is ICS-CERT going to cajole the ODVA directly or is it going to try to deal with each of the vendors involved?

What is certain is that it is going to be quite a while before we have a resolution to these three alerts.

Reader Comment: Basecamp Communications Devices

It took me a while, but I finally got a chance to ‘moderate’ a response to this weekend’s blog post on the Basecamp disclosure process from Dale Peterson; one of the drawbacks to traveling cross country by car is that you can’t do much work on the internet. Dale explains the reasoning for including the Koyo ECOM100 and notes that the Schweitzer alert was for a wireless communications device, the SEL 2032 Communications Processor.

As Dale points out, vulnerabilities in the communications nodes between the PLCs and the control system are essentially major vulnerabilities for the control system and the PLC; they can allow protected access to both. As such they were clearly fair game for analysis.

The only point that I was trying to make about the ECOM100 being a ‘ringer’ (and the same point should have been made about the Schweitzer device) is that the PLC vendors had clear public notice about what was going to happen with the research into their devices. Since they should have known about the disclosed vulnerabilities (especially the ones that were specifically designed into the systems), they have no cause to complain about the ‘uncoordinated disclosures’. They are the ones that put their customers at risk not Project Basecamp.

Unless the Project Basecamp team provided direct notification to Koyo and Schweitzer about their products being included in the evaluation, the same blanket dismissal of concerns does not apply. On the other hand, the process industry really does need to understand that these types of devices (and I assume that the same types of vulnerabilities will show up in many if not most of these types of devices currently in use) may provide a broad avenue of attack on control systems. This clearly needs to be recognized and addressed.

So with the caveat that the following does not apply if they received advanced notification of inclusion in the Project Basecamp investigation, I think that both Koyo and Schweitzer were poorly treated by an uncoordinated disclosure of their vulnerabilities. More importantly their customers may have been unduly put at risk by not allowing these two manufacturers a chance to correct the system defects before the vulnerabilities were made public.

Twenty lashes with an al dente noodle for each of the uncoordinated disclosures for these two manufacturers (again with an immediate pardon if they received advanced notification of inclusion in the process) to Dale Peterson for his unsportsmanlike conduct. On the other hand, I think that it is time to look at all of the devices and systems that we employ to control critical processes, so a small quiet kudo to Dale as a salve to his wounds for his efforts (and of course the hard work of the entire Project Basecamp team and supporters) to bring formal attention to this problem.

ICS-CERT Publishes Five S4 Based Alerts Plus Two Other Alerts

On Friday the DHS ICS-CERT published 7 separate alerts, five of which referenced vulnerabilities that were publicly discussed at Digital Bond’s SCADA Security Scientific Symposium (S4) in Miami, FL. These alerts, combined with a similar alert published on Thursday, may mark just the tip of the iceberg as Dale Peterson noted on the DigitalBond.com blog that 30 students at a HMI hacking class before the actual symposium “were quickly finding 0days using ActiveX and File Format Fuzzing”.

Oh yes, the two other alerts. They were based upon uncoordinated disclosures by the Digital Security Research Group (DSecRG) for systems produced by WellinTech and WAGO.

S4 Alerts

The five S4 alerts issued Friday included a general alert for disclosures made during the Project Basecamp portion of S4. The alert notes that the reported vulnerabilities in multiple vendor products included “buffer overflows, backdoors, weak authentication and encryption, and other vulnerabilities that could allow an attacker to take control of the device and interfere or halt the process it controls” (page 1). The four other S4 related alerts dealt with specific vulnerabilities in systems from four separate vendors; those vendors were:

• Rockwell Automation

• Schneider Electric

• Koyo (Note: not a PLC vendor, but an Ethernet vendor that provides communications between PLCs and the actual control system)

• Schweitzer

Project Basecamp was a detailed search for and reporting of vulnerabilities in various PLC’s used by industrial control systems. Dale has become increasingly vocal over the last six months or so about his dissatisfaction at cybersecurity community’s disregard of the consequences of the insecure design of programmable logic controllers (PLC). In both his blog and in any other venue that would listen (or even pretend to listen) he has made it clear that everyone in the control system vendor and researcher community has known for at least 10 years that the basic PLC design has inherent cyber-security flaws that make them vulnerable to attack. These vulnerabilities were made painfully clear in the design of the Stuxnet virus.

Because the Stuxnet worm exploited vulnerabilities in the Siemens PLC, many of the Siemens security flaws have been publicly documented, while the rest of the industry breathed a sigh of relief that their systems weren’t being used by the Iran’s nuclear program. The whole point of Project Basecamp was to formally tell the world that Siemens was not alone in their ‘insecure by design’ problems.

That the world, at least the security professional side, has taken notice cannot be doubted. There has been significant discussions in a number of forums (on LinkedIn.com and on the SCADASec list for instance) and in the cyber related press. Unfortunately, most of that discussion has been about the public disclosure of the vulnerabilities (along with some Metasploit® modules published to aid in the exploit of those vulnerabilities) rather than on the potential effects of the vulnerabilities on real world control systems. Hopefully, the fait accompli provided by Dale and the Basecamp team will eventually allow for a more detailed discussion of the vulnerabilities and how to protect control systems from attack using those vulnerabilities.

ICS-CERT does make a valuable contribution (with a forgivable sideways slap at Project Basecamp) to that inevitable discussion in the general Basecamp alert. They note (page 2):

“This public release increases the potential for cyber attack on these devices, particularly if the devices are connected to the Internet. ICS-CERT reminds users that the use of readily available and generally free search tools (such as SHODAN and ERIPP) significantly reduces time and resources required to identify Internet facing control systems. In turn, hackers can use these tools combined with the exploit modules to identify and attack vulnerable control systems. Conversely, owners and operators can also use these same tools [emphasis added] to audit their assets for unsecured Internet facing devices.”

But, less anyone forget, the Iranian PLCs that were the Stuxnet target were not connected to the Internet, nor were their control systems. Many of the vulnerabilities reported by the Project Basecamp team will allow an attacker to exploit the vulnerabilities without having to target an internet connected PLC; it will require a higher skill level and more system knowledge. There are loads of attackers with the appropriate skills and system knowledge can be easily obtained via social engineering attacks. Internet-isolated control systems (if there are really such things in existence) are not safe from attacks based upon these vulnerabilities.

WellinTech Alert

The WellinTech alert provides initial information on a reported password encryption vulnerability in the KingSCADA product that could allow an attacker to read and use a user password, thus gaining user level access to a control system. Exploiting this vulnerability requires access to the SCADA server.

WAGO Alert

The WAGO alert concerns multiple vulnerabilities in the I/O System 750. The vulnerabilities include:

• Remote firmware download;

• Remote data leakage; and

• Remote access.

Interestingly a DSecRG press release notes that the WAGO disclosure of the 750 series controller vulnerabilities was made in support of Project Basecamp. Additionally the DSecRG web site notes two other control system vulnerabilities released by DSecRG on the same day. One deals with a default password vulnerability on Tecomat PLCs (more Project Basecamp fallout?) and an ActiveX vulnerability on an OPC system. I expect that we’ll see ICS-Alerts on these on Monday.