An electronic device used to control machinery in water plants and other industrial facilities contains serious weaknesses that allow attackers to take it over remotely, the US agency that safeguards the nation's critical infrastructure has warned. Some models of the Modicon Quantum PLC used in industrial control systems …
I'm no expert in these thingies, but while the multiple hardcoded account/password thing is at best mind boggling, i really don't get it why it's critical.
One would assume that while the devices are connected over a network, that network would be internal and isolated from "bad real world" as much as possible.
Thus, to gain access to a means to exploit these vulnerabilities, you'd have to go INSIDE the place. And if that happened, you already failed. The time it takes to tap the network, scan for devices, take control, and reprogram them is probably as much as it takes to blow the place sky high using conventional means.
Begs the question then, how many facilities went around and made the supposedly isolated (and operation critical) network a part of the general network to "make it easier". Or are they just worried because they now have to go about checking device integrity because it's not something noticeable as opposed to a explosive charge?
My 0.0002c on the former because being lazy and thinking about security after the failure is the norm not the exception.
Idiots ignoring basic design rules
The problem with these systems is the idiots that connect them to the internet . Used as designed (NO INTERNET CONNECTION) PLCs with built in passwords are not a problem. (Earlier PLCs did not even have accounts and passwords as they were designed to be used only on well secured networks with no idiot users.)
If a connection has to be made (to satisfy some hare brained management decision) then it should be by a single - well hardened - Linux system to mitigate as far as possible the ill effects.
Begs the question then, how many facilities went around and made the supposedly isolated (and operation critical) network a part of the general network to "make it easier"
I suspect that it is actually cost driven. Don't underestimate how penny pinching companies can be. Quite a lot of large industrial accidents can be traced back, one way or another, to a lack of willingness to spend a small amount of money to avert what was thought to be an unlikely disaster.
In my view companies are pretty bad at taking improbable though severe risks seriously. Look at TEPCO, owners of the plant at Fukushima. They chose to continue to operate their ancient old reactors against all advice, just for the sake of a few Yen profit. Look where that got them.
I'm not saying that companies using the Internet to connect industrial control networks together between sites should stop doing that. They could easily and cheaply make such networks much more robust by hiding them behind VPNs. That way any hacker would have to break through a VPN first before they can start attacking vulnerable SCADA systems. And if they were really paranoid they could rent private lines off their telecomms company. Both of those approaches are way cheaper than dealing with an oil refinery explosion...
I suspect that actually, quite a lot of companies already do that sort of thing one way or another. But there are bound to be some that haven't even begun to consider what sort of risk hacking represents to their systems.
You've basically hit the nail on the head there. Working with the stuff (not the effected PLCs in this instance but we do have S7 PLC controllers) its far too easy with the new kit to just connect it up to a network that is open to the tubes.
Its "easy" and they bill it that way from the manufacturer. Build your SCADA network over commodity network hubs/switches using regular ethernet connected to bog standard x86 windows computers.
As you said mission critical networks should and need to be isolated, all the way down to the floppy drives, CD drives and USB ports. BUT that takes time, effort and someone who knows what they are doing.
Most of these SCADA and PLC systems are not managed from the plant floor, but through a remote management tool which needs to get out through the WAN. That is how they are exposed to the rest of the world and hackers.
NEVER. Assume. Anything!
that is a violation of Rule #1 on any list.
it is axiomatic that anything significant in controls must NOT be accessible from outside, must NOT be operating on anybody's commodity hardware or OS, that there are no documented back doors, there should be no undocumted back doors for security, and the equipment should not be assembled where Sneaky Petes run wild in the streets.
so far, SCADA seems to violate half the rules, and typical implementations (hey, boss, why can't I troubleshoot a process problem in our nitroglycerin plant from my iPhone at the roadhouse?) violate all the rest.
these things, and I include the "smart grid" boobytrap for society here, should be on systems similar to 1980s car electronics, in that they are specialty devices manufacturer-specific, no hardware docs, no external access, oddball access protocols, and designed as real-time VSMs instead of apps on a commercial OS.
PLCs should be on a private network. If there is a need to reach them from a remote place then use a VPN.
In general it is also a bad idea to just hook up PLCs to the corporate WAN. Industrial networks should be private from the rest of the corp network. No bneed for the bean counters to be able to cock up the PLCs.
Many internet connected devices (eg. debuggers) have absolutely no security at all and it is pretty much routine to treat them the same way (allowing people to, say, debug a development board from the other side of the planet).
Bloody good reason for backdoors
There is a very good reason for backdoors. They allow service staff to be able to access the devices either remotely or when on site.
Many a time the backdoor has allowed service personel to recover a system where someone changed passwords and forgot them or died or was fired and won't play ball.
Just secure it all with a VPN.
“I really don't know if the [device] is a release valve, an input valve, or a lightbulb.”
Unless, once in, you access the SharePoint server with PDF diagrams of the system.
I've said it before, and i'll say it again...
Why the HELL are these connected up to a web-facing network? Sounds like something even a secondary-school student would catch as a security risk.
Fine, keep it on an intranet, with maybe a VPN login if you really need it, but this? It just smacks of slap-dash development.
Then how would the folks in the control room post their tebowing pics to facebook?
why on earth, would you connect your scada control system to any public network or even administrative network, are we just stupid stupid stupid......people being really f*ckin* stupid. This is turning into the Millennium Bug, just unplug the PLC from the f*ck*** network and get people visit the control room rather than trying to run the plant from f*ck*** office 1000 miles away. If you feel you really need remote control its called a ethernet KVM! ILO or DRAC or IPMI.....Look no hands.
visit the control room?
... how are they going to do that when control admin has been outsourced to India/wherever?
Or, what would Stallman do.
Buy proprietary security at your peril. A GNU SCADA would have a zillion warning prompts in courier before it connected too any network, and it wouldn't have no predictable passwords BECAUSE NOTHING EVER SHOULD.
What would Stallman do?
He wouldn't call it Open Source for a start, and he'd probably demand you make everything you associate it with free as well.
Shhh. It's OK
1) No one will ever find about them.
2) Their staff will *never* tell anyone about them.
I don't want to worry anybody but:
“I really don't know if the [device] is a release valve, an input valve, or a lightbulb.” Or presumably a Large Hadron Collider..?
Or presumably a Large Hadron Collider..?
...and there are 53 more in this segment alone!
So they have finally found these default passwords.
And what idiot put the plc & scada near a wan connection .
These devices like any system are prone to physical access issues
from someone with knowledge .
Layered security model required ,which includes physical security application & monitoring .
So what happened to SOX & COBIT for critical infrastructure in the US ?.
GNU SCADA offerings not great
Recently had a trawl to eval open source SCADA offerings and had to conclude that the commercial offerings win hands down. Sorry, Mr Penguin!
(Now this gives me an idea for my next open source project: An open source SCADA with no hard-coded password backdoors, SSL encryption all the way, authentication via public-private key pairs. Should be done by Christmas...)
A lot of them only support one driver, MODBUS.
I've asked about it at my workplace, where we currently use a combination of CitectSCADA and MacroView (the latter at least runs on Linux). We use these because of the wide array of drivers out there, most proprietary. I have written a driver to interface a particular model of meter to MacroView, which could possibly be ported to other systems, but right now there's no economic incentive to do so.
Then there's the visualisation features — although IMHO a lot of what I've seen done in Citect could possibly be achieved today using AJAX and SVG in a modern web browser. Then again, perhaps I've only seen the tip of the iceberg so far.
"but right now there's no economic incentive to do so."
Ain't that the truth. The funny thing is the folks who plugged these things in probably felt the same way to paying the few extra bucks to secure the thing. The difference of course being that a lack of an extra driver won't potentially expose the entire system to a single point of failure. I guess the suits aren't that good at weighing cost into their risk / benefit analysis.
More likely this is a hit piece written for a competitor or to inspire more federal control. Really do we need the federal government to take over every aspect of the economy?
There is more free enterprise in Europe that the good old USA.
It gets better. A lot of these systems use radios for connectivity to remote sites.
Die Hard 4.0
Wasn't this sort of thing pretty much central to the plot?
Bruce should have time to save us before that asteroid arrives.
windriver debug port?
Is this actually the debug port for Wind River Systems embedded VxWorks OS (or maybe something compatible with the Wind River debug port)?
If it is, it doesn't say a great deal for the credibility of the "analysts" who have been (mis)reporting this so far.
Hey El Reg, why don't you phone your Intel press contacts and check (Wind River are owned by Intel these days).
This is news to who?
Apart from the Daily Fail I thought everyone knew about this - well, everyone who matters anyway. The reason nothing bad has happened is because it's boring ... and there are so many better and juicier targets to play with ...
Skip to the next IP address please ... there's nothing here to see...
- Google straps on Jetpac: An app to find hipsters, women in foreign cities
- Updated Microsoft Azure goes TITSUP (Total Inability To Support Usual Performance)
- The Return of BSOD: Does ANYONE trust Microsoft patches?
- Munich considers dumping Linux for ... GULP ... Windows!
- Review Apple takes blade to 13-inch MacBook Pro with Retina display