ICS-CERT Updates Two Rockwell Alerts

This afternoon the DHS ICS-CERT updated two alerts that it issued for Rockwell PLC’s last week. The updated alerts (here and here) have the same, single-sentence addition made:

“This vulnerability was discovered by Aditya K. Sood and presented by him at DefCon 2015 in Las Vegas, Nevada, on August 8, 2015.”

This means that all six of the DefCon related alerts that ICS-CERT published last week come from the same talk. Strange that none of the other talks about ICS security matters merited an alert, advisory or update of a previously issued advisory.

NRC to Look at PLCs

Today the Nuclear Regulatory Commission (NRC) published a notice in the Federal Register (79 FR 7406) acknowledging that it had received a petition for rulemaking under 10 CFR 2.802(c) {NOTE: The notice mistakenly lists 10 USC 2.802(c)} that requests that the NRC “NRC require ‘new-design programmable logic computers’ to be installed in the control systems of nuclear power plants to block malware attacks on their industrial control systems of those facilities”.

The notice explains that since the petition was received in proper form that the NRC will officially consider it. The NRC is not requesting public comments on the petition or the topic at this time. A docket has been established on the Federal eRulemaking Portal (www.Regulations.gov; Docket # NRC-2013-0214) that will be used to make information about this petition available.

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.

Reader Email – ICS Safety Misconceptions

I got an interesting email from a reader of my post yesterday on Digital Bond’s SCADA Security Portal. I’m not sure what the reader’s background is, but I am assuming that it isn’t control system engineering. The misunderstandings that form the basis of the questions are so important that I thought that I would address them in a post instead of an email reply.

Here is what the Reader wrote:

“We read your blog on Digital Bond about the various legislative efforts to make ICS safe. We would like to ask your opinion about how can any ICS/SCADA be safe when the programmed memories of the controllers are corruptible, that is, endlessly rewriteable?

“Cannot the process control engineer pause the system for, say, 2 minutes to change to another preprogrammed no-write memory?”

There are three basic misconceptions here and I’ll address them in turn. They are:

• Legislation can make something safe;

• Re-writeable memories are corruptible; and

• Un-rewriteable controllers are possible.

Legislation

One of the great misconceptions of the modern liberal era is that government legislation or regulation can make anything safe. At the most legislation or regulation can mandate that something should (or should not) occur, that certainly does not make it happen. A perfect example of that can be found in the illicit drug trade; numerous laws and regulations at the local, State, Federal and international level make the transport of, for example, cocaine illegal. Has it stopped or even seriously slowed that trade? Not hardly.

Even in the safety realm, OSHA regulations have not stopped companies and facilities from allowing unsafe conditions to exist. OSHA, even including State and local inspection officials, does not have enough manpower to go around and ensure that everyone is following the rules. What the OSHA regulations have done to increase workplace safety (and they have certainly done that on a gross basis) is to provide a basic set of guidelines for safe practices and provide sanctions for violations of those guidelines when those violations result in worker injuries and deaths. Avoidance of those sanctions have made most companies follow most of those guidelines on a fairly consistent basis (lots of deliberate weasel wording there). And the worst violators are sanctioned out of business.

ICS security legislation at its best will not make control systems secure or safe. At most it can establish a program for determining minimum standards for security in the design and implementation of control systems and provide incentives for (or disincentives for not) applying those standards. They would help provide a level playing field for those companies that design, install or maintain a secure control system. That would raise the general level of security in the control system community, but it WOULD NOT SECURE CONTROL SYSTEMS. I don’t think that that is actually possible.

Corruptible Memories

Okay, I guess that I will have to concede that re-writeable memories are inherently ‘corruptible’. Whether or not that is a good thing or a bad thing depends on how those memories are deployed. In a “properly” designed system only the owner of the system (through their engineering staff of course) will have the ability to re-write the memory. In an adequately designed system the owner will know when the re-writeable memory is re-written and will be able to react in a timely manner when it is re-written by an unauthorized individual or re-written in an unacceptable manner (either accidentally or purposefully).

PLC’s Require Re-writeable Memories

The modern control system is predicated on the ability of the owner to buy a programmable [emphasis added] logic controller (PLC) and make it perform a specific function in his system (and perhaps change that function as his process changes). There is no way that PLC manufacturers can make a controller for each specific function in every process.

Okay, technically they could. They would be prohibitively expensive (thousands of times more expensive than they now are) and they wouldn’t work. That’s because no design engineer has successfully documented the requirements of more than a single controller system (and I would be surprised if even one single-controller system was successfully specified in advance) without there being a need for tweaking the controllers to perform properly in the real world. Controllers must be programmable at the installation where they are put into use and that requires re-writeable memories.

Even if a controller could be specified and produced for a single purpose application at a reasonable cost, no one would buy it because it would not allow for process improvements or process changes.

Process Control Systems Must be Modifiable

Modern manufacturing processes require control systems that can be modified to meet changing conditions. This means that systems engineers must be able to modify the actions of the various components of the systems. This can only be done with some sort of programmable logic controller.

Security for PLC’s has to be designed to limit communications to and from the PLC’s to routing through a secure network to a protected control system computer. The more levels of protection provided to the system the more likely it will be that an attacker will be unable change the programing of the PLC’s. That is how you protect the operating end of an industrial control system.