Thursday, March 22, 2007

New SCADA vulns

Researchers recently announced vulnerabilities in SCADA OPC systems. SCADA refers to the computerized control over things from dams to oil refineries to rail roads to nuclear power plants. As I discussed in a presentation last year, SCADA is completely open to attack, especially OPC.

OPC is a standard for Microsoft Windows that makes it easy to write GUI applications for SCADA. They translate between Windows primitives such as MS-RPC/DCOM to backend protocols that actually do the monitoring and controlling of switches, valves, pressure gauges, thermometers, and so forth. These backend protocols are often based upon standards that pre-date Windows. They are horribly insecure because few people in the SCADA industry know what a "buffer-overflow" is.

Unfortunately, OPC is completely open to attack. The code is horribly insecure. It took me 5 minutes to find a remotely exploitable bug when I downloaded sample implementations from the OPC Foundation a couple years ago. The real problem is not vulnerabilities but authentication. OPC installations are normally run without needing a username or password, which means a hacker can control them without having to mess around with things like buffer overflows. Moreover, if proper authentication and encryption are enabled, then you can't actually remotely exploit them without first logging on. This is the case with the recent announcement from neutralbit: it's only exploitable if the user has login privileges.

Unfortunately, many SCADA organizations are not going to take neutralbit's work seriously for this reason. They know that since their systems are already wide open to attack, that patching them against this bug won't stop a hacker. That would be wrong. First, there is the possibility of worm exploiting these bugs. Second, at some point the SCADA industry is going to have to catch up with the rest of the world with regards to securing their products. Neutralbit has done an excellent job of explaining to you potential problems with OPC, but they've also explained them to hackers and cyber-terrorists. Any kid who wants to prove he's a vulnerability hunter now knows he can go onto eBay, get some cheap OPC products, find vulnerabilities in them, and announce them to the world. There is a good chance that many more OPC vulnerabilities will be announced and/or exploited in the next couple years.

Of course, it doesn't mean you should take down your SCADA network to patch your OPC systems immediately, but it does mean you need to be looking into the problem. For example, you should never buy a SCADA product without first asking the vendor for an independent vulnerability assessment from a third party (e.g. Errata Sec, Matasano, ISS/IBM, Neohapsis, neutralbit, etc.). Chances are good that if they can't give you an independent vulnerability assessment for their products, that they will have the easily discovered vulnerabilities like those that neutralbit is announcing.


Raven said...

Have you reported this "exploit" in the OPC Foundation sample implementations to the OPC Foundation? If not why not?

Robert David Graham said...

No. ISS had a policy of not bothering vendors for low priority bugs. You'll notice that none of the X-Force advisories required authentication to exploit -- it's not that we didn't find any, it's because we put them down on the priority list. In addition, nobody was interested in it. All our SCADA customers told us that they didn't care, since their OPC system were otherwise wide open anyway.

Julian L. Rrushi said...

Hash: SHA1


I have a comment on the fact that it took you 5 minutes to identify a remotely exploitable vulnerability in OPC, since it could implicitly be thought of as a security metric regarding the exposure of critical infrastructures to cyber attack.

Being a SCADA security researcher myself, I have had the chance to study in depth the research work carried out in US/Canada and regarding vulnerability analysis of SCADA protocols and their embedded real-time operating systems. As a resarcher I deem this work to be highly innovative and intelligent. Therefore, while it may be true that SCADA software as released by the respective vendors may be subject to various vulnerabilities, before being deployed such a software is carefully analyzed by world-class vulnerability analysis frameworks. Examples include the DEADBOLT vulnerability analysis framework by MIT, the INL control system plant assessment, or the Achilles SCADA Assurance Platform. It isn't likely, I believe, that a vulnerability that may be found in an implementation of an industrial protocol in a 5 minutes time frame, or a vulnerability that may be identified even by kids, could exist in real world deployments of SCADA software tested by the aforementioned frameworks.

As a conclusion I can say that to the best of my knowledge US critical infrastructures are highly resilient to cyber attack. Their communication protocols and operating systems are looked after by extremely skilled people who possess the most advanced attack and defense intelligence.

Julian L. Rrushi

Version: GnuPG v1.4.2.2 (GNU/Linux)


Dale said...

Come on Robert. You know better than that.

There is a difference between an attacker being able to launch, browse, read and write data to an OPC server due to DCOM authentication settings and being able to gain remote control of the Windows PC.

Since many OPC servers sit on a DMZ between corporate and the control center, owning the PC would allow an attacker to potentially attack the control center from the corporate network via a system on the DMZ.

When you found this you should have reported it to the OPC Foundation, and I would argue CERT/CC or US-CERT. It is not too late, and the OPC Foundation is typically responsive to bugs in their sample code.

Dale Peterson
Digital Bond

Robert David Graham said...

I agree with Dale Peterson's comments. I didn't mean to minimize the cool work by neutralbit guys: hard proof of the fact that vulnerabilities are widespread in OPC has been needed for a long time.

However, the comments by Julian L. Rrushi are nonsense. It reflects an industry deluding itself. The DEADBOLT and Achilles things he described, but they aren't addressing what hackers do to attack systems. Authentication is still weak in deployed systems, and the software is still full of the types of vulnerabilities that are well-known in the hacking community. I say this because I have done binary and source reviews of such systems, and have had no problems finding holes.

For example, if Mr. Rrushi were correct, "vulnerability scans" from products like Nessus would be common on SCADA networks. However, such scans are rare -- because they crash equipement -- because they are full of holes that kids can find in 5-minutes.

Julian L. Rrushi said...

Hash: SHA1

Hi Robert,

I didn't mean to say that SCADA systems are not vulnerable. What I meant is that with regard to the level of exposure to cyber attack there be may a considerable difference between referring to SCADA code as released by vendors and referring to SCADA code as deployed in critical infrastructure.

To my opinion the difference is due to the fact that before being deployed SCADA code is subject to vulnerability analysis.

Question: What is the level of exposure to cybert attack of SCADA code before and after being analyzed by Errata Security ? I'm confident that after being analyzed by Errata Security SCADA code will be more secure. And it is the post analysis code that is deployed. All here.

Anyway, congratulations on your interesting blog. Hope to see more on Steganography some day.

Best regards,
Julian L. Rrushi
Version: GnuPG v1.4.2.2 (GNU/Linux)