Slashdot Mirror
Researcher Publishes Industrial Complex Hack
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.'"
If you hook up a device to the internet without any firewall protection, you deserve what you get.
The vendor has released a patch and risk arises only for systems connected directly to the Internet without firewall protection.
Why would you have critical systems like that directly connected to the 'Net anyways?
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
...a standard cell phone will let you pretty much instantly hack and control anything in the country except for the utilities. For those, you need to go to 2 different locations that control all the utilities in the country.
That movie had the "Mac guy" so I totally trust it.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
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?
And who are you? Seriously. Why is your opinion of what is "critical" worth anything in this discussion?
And the cost of hiring those people vs the cost of cleaning up after an attack? Skipping security is ALWAYS cheaper. As long as you never consider the cost of an attack.
#1. ATM's. No. They were not originally connected to the Internet.
#2. Driving license. So what? That would catch up to you after the traffic tickets were entered into their system.
#3. Corporate VPN's. We're talking critical systems here.
Wrong. There is access to them without having them connected to the Internet. Just as it was back in 1990.
All of your reasons come down to "cheaper".
"Cheaper" should not have more weight than "secure".
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, 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.
"Powers. I have them."
'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.'"
He's attempting to lay blame for these infrastructural issues at the feet of the engineering staff. What he doesn't understand is that engineering systems have very different operational requirements from running a server farm or a few thousand desktops. Engineers avoid IT like the plague, because IT people will come down on engineering systems like a ton of bricks, enforcing arbitrary company-wide standards regardless of the damage they do. For example, if you have a timing-sensitive real time process running on a PC, it may not be wise to put the Symantec Antivirus pig on that particular box. Yet I've seen that happen, usually without the person in charge of that equipment even being notified. Afterwards, everybody wonders what happened with something goes seriously wrong with a production process. IT's attitude in such cases is usually "we followed company policies. Not our fault." The hell it wasn't.
The reality is that IT misguided or ignorant departments are frequently a far bigger danger to process control and real-time data acquisition systems than any number of Chinese crackers. That's because they rarely make the slightest effort to accommodate the needs of the technical staff, and have often gone to extreme lengths to have upper management approve utterly Draconian policies that MUST be applied to ALL computers.
Engineers are often justifiably leery of having IT involvement in any of their projects. The consequence of that, of course, is that now you have people with no specific security training implementing remote communications. Of course, a lot of these problems could be ameliorated with some simple requirements such as "all off-site communications MUST be secured with a VPN" or something similar.
Ultimately, what it comes down to is communications being handled by conscientious, well-trained individuals that are open-minded and willing to accommodate the special needs of engineering systems. I can't tell you how rarely I've seen that happen.
The higher the technology, the sharper that two-edged sword.
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.