Researcher Publishes Industrial Complex Hack 190
snydeq writes "Security researcher Kevin Finisterre has published code that could be used to take control of computers used to manage industrial machinery, potentially giving hackers a back door into utility companies, water plants, and even oil and gas refineries. The code exploits a flaw in supervisory control and data acquisition software from Citect. The vendor has released a patch and risk arises only for systems connected directly to the Internet without firewall protection. Finisterre, however, sees the issue as indicative of a 'culture clash' between IT and process control engineers, who are reluctant to bring computers off-line for patching due to the potential havoc wreaked by downtime. 'A lot of the people who run these systems feel that they're not bound by the same rules as traditional IT,' Finisterre said. 'Their industry is not very familiar with hacking and hackers in general.'"
Re:Why ... (Score:5, Informative)
Why would you have critical systems like that directly connected to the 'Net anyways?
To reduce costs. Its cheaper for an engineer to remote-in to check on something than have them physically drag their butt to work. Fewer people are able to monitor more 24/7 systems this way.
And its almost always cheaper to use an Internet connection than a dedicated leased line for this sort of thing.
Disconnected from reality (Score:5, Informative)
At the place I did the work for, the control systems were completely isolated from the internet. They sit on their own network and only talk to each other. They are all running Windows Server 2003 on HP Proliant ML370s with redundant everything (RAID drives, power supplies, UPSes, etc). The closest those things get to communicating with the outside world is when they download their data to a historian server on the other side of a DMZ link. It is a one way connection to the historian server. The historian is then referenced when people offsite need to know what is going on at the plant. The only way to connect to the historian is with VNC from one specific IP/MAC.
Enough of the security tangent. The point I was originally trying to make is that most industrial machinery doesn't need to be patched. It runs one or two software applications that do a specific thing. There is absolutely no reason to touch the box once it is up and running. Security in an industrial environment needs to be handled at the physical/network layer, not at the box. Why does the hardware running your valves need internet access? Why does a box running a CNC machine need internet access?
Re:Well (Score:3, Informative)
These kind of issues seem to [slashdot.org] come up [slashdot.org] here a [slashdot.org] fair bit [slashdot.org].
http://google.com/search?q=site%3Aslashdot.org+SCADA [google.com]
SCADA security is a mixed bag. (Score:5, Informative)
It's a mixed bag. Some (older GE Fanuc PLCs for example) have zero security features, and only have a telnet daemon wide open to the world. The obvious answer is to bitch at the vendor and mitigate it with ACLs or some such, but really you'd have to know something about what you're hacking at to force it to do anything more than lock up, which might be bad, but generally is more of an inconvenience to a worker on the floor since all mission critical environments should have people standing by in such a case with the ability to manually override.
To my knowledge there's only been one real targeted SCADA hack that caused damage, [computerworld.com] and he had inside information. Don't get me wrong, I'm all for increasing security in SCADA environments, but the biggest hurdle isn't technical; it's political. Most SCADA environments that I've seen have been set up by electricians that programmed the SCADA devices but know pretty much nothing about IT (FYI, there's a lot of Linksys gear out there). They're usually paid overtime to work on the SCADA network and they see IT personnel as a threat to their livelihood. Someone I know was threatened with a screwdriver for just trying to replace a router.
Reality check needed... (Score:2, Informative)
Re:Why ... (Score:2, Informative)
Seriously? If you can't afford to buy some sort of basic protection for internet connected equipment, you need to re-think your business model. If you can't afford the downtime to install a simple firewall, then you really won't be able to afford the downtime it will cause when somebody breaks in.
It's not as bad as it sounds. (Score:5, Informative)
I developed an HMI using Citect, and for my needs it was significantly better than the alternatives. Actually, it was pretty excellent. But you wouldn't use it to control dangerous machines: it runs on Windows. :-) Supervisory Control and Data Acquisition is high-level: the user-friendly end of process control. We used Citect to control the machines that control the machines.
You could poke a button on Citect that said, "open this valve," but all Citect did was message an industrial PLC that performed all the safety calculations and bounds checks and actuated the relay, then sent the result back for Citect to display. Actually, a better example would be to poke a button to start the next phase of a run. You wouldn't use SCADA to open or close an individual valve much more than you'd invoke a single C function from a CLI.
I would argue that in fact the traditional rules of IT do not all apply to these SCADA systems. They are quite often single-purpose PCs that have little or no connection outside the plant floor. If they worked on commissioning day, they'll probably still work today. They don't need a lot of management. Not that machines don't get taken down for maintenance, but you don't want a surprise incompatibility in your software update keeping the system down longer than anticipated. Wreaks havoc on the supply chain. Actually, Citect can clone control stations (legitimately, not just 0wn3d), so you could do a phased deployment of patches without losing any capability; I was speaking more generally.
It is true, though, that process engineers I've known don't think much about network security. They're concerned about guarding against a china syndrome, so the important stuff is off the net and often talks to SCADA via RS-232. A hacker might steal data or stop the run, but probably couldn't make things go boom.
Re:Why ... (Score:3, Informative)
Maybe, but I doubt it. The people who continuously monitor control systems are not engineers, they are operators. Engineers are usually "exempt" employees, so their overtime is free. I might also say that if your control engineers are stretched too thin by call-outs, the solution is not more engineers, it's different engineers. I used to work as THE process control engineer at a small chemical plant. Having to go into work at 3 am to fix a problem is very strong incentive to find the real cause of that problem and fix things so it doesn't happen again.
Anyhoo, probably the most common reason to hook a control system up to the internet is to make data accessible to people in other parts of the company.
Re:He doesn't get it ... (Score:3, Informative)
And I am an IT person with a CS degree that worked as a historian and i/o integrator, industrial software developer, and most recently have been working on a project to integrate equipment w/ layer 4 scheduling data.
Most of the places I have done work for I have seen at least a small number of HMIs that were running on Windows (InTouch, ProcessBook, RsView, etc). I agree that kiosks can be built running off of a read-only image, etc but that takes a great deal of effort, especially for a system that likely cannot be imaged for easy replacement. A better solution would be to install the antivirus and tell it which files need to be ignored. If this continues to cause problems for the system then it is likely you are running more than an HMI on it. Disconnect those serial rocket boards, install some nice serial to ethernet switches, and put your I/O on a server instead of a PC where anyone could walk by and mess with it. Just because you can connect live I/O to a PC does not make it a good idea.
If your HMI is overloading the PC when anti-virus is installed, your doing it wrong.
An even better solution would be to stop using PCs entirely. There are a lot of really good CE-based HMIs out there that are built specifically to run HMI software.
And rather than closing with a broad generalization as you have done, here is a more specific comment from my own experience:
It's that damned subset of engineers that insist only on hardware requirements and install equipment without any regard for how it needs to interact (or in many cases how it will communicate at all) with data systems and other infrastructure, regardless of the consequences. The good engineers take a step back and determine the true needs of the equipment and process, requiring vendors to provide them with solutions for the larger scope, not just something that can be slapped in and called working.