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.'"
Well (Score:4, Insightful)
If you hook up a device to the internet without any firewall protection, you deserve what you get.
Why ... (Score:5, Insightful)
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?
Re:Well (Score:5, Insightful)
what do you get? internet herpes?
a firewall will protect your computer from many exploit attacks, but that's not a reason to rely solely on a firewall for protection.
running a system with a bunch of unpatched security vulnerabilities and simply relying on a firewall to protect you is just as foolish as connecting to the internet without a firewall. after all, what happens if the firewall fails, is bypassed, or has a security vulnerability of its own?
Re:Why ... (Score:5, Insightful)
a) What is critical to you may not be critical to me
b) Keeping them offline might make sense for security, but it makes servicing them more difficult, and so more people need to be hired, and so it is more expensive (which is bad, apparently)
c) Sometimes, critical systems need to be online, and widespread. For example, if banking wasn't networked, then ATMs wouldn't work. If you had your license suspended, it would take hours to get that information to all the other cops, and you could keep driving without penalty. Also, work-from-home wouldn't 'work', and corporate VPNs would be pointless.
Critical systems *should* be connected to the 'net, so we can have access to them. But, they should also be better protected, and backed up offline.
Comment removed (Score:2, Insightful)
Re:Well (Score:5, Insightful)
If you hook up a device to the internet without any firewall protection, you deserve what you get.
We should be glad that people release these 'bugs' openly - I'm sure that this information would have made Mr. Finisterre a lot of money, if he approached the right (wrong?) person. Imagine what would happen with no firewall AND no public notification?
Re:Why ... (Score:5, Insightful)
Re:Why ... (Score:4, Insightful)
It will only take one incident to loose any cost savings by an order of magnitude.
Seriously, you can't get into any of your machines for an hour, how much does that cost? the machines start doing the wrong thing?
By the numbers. (Score:4, Insightful)
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".
Re:Why ... (Score:3, Insightful)
Re:Why ... (Score:2, Insightful)
The nuclear station that went down due to slammer wasn't because they did not have firewalls.
Typically, it's the authorized users who're the biggest problems.
Better security isn't always better! (Score:3, Insightful)
"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!
Re:Disconnected from reality (Score:3, Insightful)
If the system is not connecting directly to the internet, why open yourself up to problems.
The original author said that they are using Windows Server 2003. I have seen many places where windows 3.1 and windows 95 are still in use.
Haven't had a patch in well, I don't know how long.
My point is, I wouldn't want to put a patch on anything that was already working.
Unless management is willing to pay for all of this redundancy and the IT people to handle all of this patch work.
Oh, yeah. How are we going to test the computers before we bring them back online? Use a redundant power/chemical plant.
So in some of these complex systems it takes a week to six weeks to bring them back online to capacity.
I have actually seen simple batch reactors which would take six weeks to bring back online, after a failure. Although it wasn't any OS that caused the glitch (it was actually a chip failure), I sure wouldn't want an OS patched to fix a problem that doesn't exist.
SCADA SCHMADA (Score:3, Insightful)
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.
The problem: Microsoft Windows (Score:3, Insightful)
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.)