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?
he has a very American-sounding name.
... where do you think most americans came from?
...
... besides mexico
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."
Citect is not the only SCADA software company out there. They have a large market share, yes, but there are many other companies that author software for this market. This 'buffer overflow' affects only Citect software and none of the other company's offerings are affected. Yes there are some fools out there who will connect their systems directly to the `tubes, but there probably aren't as many as you would think. There are probably some vulnerabilities in other vendor software as well. But you know what, take a deep breath, take a break, and watch the blinking lights.
Sig this!
'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.
Someone I know was threatened with a screwdriver for just trying to replace a router.
What's the big deal? Drink the screwdriver and then replace the router.
Plain Fear mongering at work, nothing more. I have worked in Power Plants for 30 years now, from analog to digital, and he is so full of fear mongering and "what ifs" worse than a Long Island housewife. First, there being no money or "secrets" in hacking a power plant, why bother? If this was such a problem, then why don't we see it happening? Also, there is a huge cost on manpower, material, resources and lost revenue to take a powerplant down on someones fantasy security exploit, and those resources are much better spent on repair, and upgrades for efficiency and emissions. I use these systems daily, and they (unlike most computer systems available) work 24/7/365 going years without problems, quietly doing the job designed for, dumping data for engineers to study and just humming along nicely. Every now and then another fear monger comes along with new fantasy's of death and destruction if we don't drop everything and buy his/her service or patch of whatever snake oil he has for sale. Being engineers (practical, operating, not desk bound) we simply learn to ignore and move on, fixing what is broken and leaving what works alone. Our operating record speaks volumes for our work.
The national budget must be balanced. The public debt must be reduced; the arrogance of the authorities must be moderate
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.
"Cheaper" should not have more weight than "secure".
This betrays almost unthinkable naivete. Cheaper always has weight. It's a question of overall system cost, and people tend to ignore non-obvious risk. Welcome to the human condition.
Ever go to any of those sites that tell you where your dollar bill has been? They have a place where you can put your bill's serial number, and see if anybody else has done the same. It's kinda fun!
But did you notice that there is NO SECURITY WHATSOEVER behind authenticating your possession of the dollar bill? That's OK, because the cost of compromise is unspeakably small - perhaps somebody will be annoyed... The cheapest solution, which is merely asking somebody to type something in, is plenty enough.
There's a formula at work here, something like this:
$CostOfCompromise*$LikelyhoodOfCompromise <> $CostofSecurity*$ReductionOfLikelyhood.
As long as the left side is "heavier" than the right side, you're doing the right thing. If you institute major security in an area where the cost of compromise is miniscule, you're wasting your money. Go for hookers and blow instead - at least you enjoy it!
If you don't invest significantly in security where the cost of compromise is high, or at least, the likelyhood of compromise is high, then you sure don't deserve your hookers and blow!
So, the right answer is proper risk assessment. Spend your money in areas where it'll do you some good. And be a cheap bastard if it really doesn't matter much!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Actually in my opinion the SCADA PCs although vulnerable in many cases are not the best
way to attack these systems. It is much easier to just start firing junk into the registers
of the PLCS controlled or monitored by the SCADA systems. In many cases the controllers are just
hanging balls to the wind on the network. Anyone that has messed with them at the protocol level
knows that most of the protocols in use have little or no security functionality.
Got Code?
From the article: "The system is composed by software installed on standard computer equipment running on commercial-of-the-shelf Microsoft Windows operating systems."
And that's the problem. It's not running on QNX, or VxWorks, or LynxOS, or MonteVista, or even Windows XP Embedded. With those systems, the system is usually built to have just the components needed to do the job, not with every gimmick Microsoft puts in their desktop OS.
And, of course, it's yet another buffer overflow, part of the defective-by-design semantics C and C++ use for arrays. (And yes, I know what I'm talking about.)
Then I assume that you are not familiar with RBAC systems like SELinux built in the kernel. In a "dangerous" environment where 1 minute of downtime is equal to 100k$'s, lockdown is the only way to go. Running as root or equivalent should never be allowed, period.
We can lock even root down to console-only access and have the user-servers loaded up from netboot and nsf mounted drives from the user-server. Roles based upon who the user is will grant access to what they need to do, and nothing more. All actions will be logged, and all critical decisions will be logged to a recording server. Why wouldn't we want to have users use dumb terminals? 2 commands can kill their session and lock them out.
Viruses will not exist, as we can literally prevent the user from executing anything, even in their home environment. Root, with other than console access, is yet another user.