World's power grids infested with (more) SCADA bugs Areva Inc. - a Paris-based company that serves nuclear, wind, and fossil-fuel power companies - is warning customers to upgrade a key piece of energy management software following the discovery of security bugs that leaves it vulnerable to hijacking. The vulnerabilities affect multiple versions of Areva's e-terrahabitat …
"A spokesman at Areva's Maryland outpost ... said ... <SCADA systems> are not connected to the internet and therefore they're not vulnerable to viruses of any kind,"
He may be right that their systems shouldn't be easily accessible from the Internet.
If he then really truly said "therefore they're not vulnerable to viruses of any kind" then that makes him a pillock of the first order, worthy of immediate promotion to first line help desk telephone jockey. It should also hopefully disqualify the whole company from any further business where there is any nontrivial need for system integrity and/or safety.
Perhaps he's not heard of (as a recent example) Downadup [1], but Downadup's not the first and won't be the last virus which propagates without an Internet connection, in fact it happily propagates without any network connection at all if folks haven't taken the appropriate precautions wrt removable storage.
[1] http://www.theregister.co.uk/2009/01/22/disabling_windows_autorun/
SCADA is not vulnerable to viruses - It's not a windows box, it runs propiatory hardware and software, and as such is not succeptable to viruses that you refer to (previous poster).
The weakness is the systems that connect to SCADA which could be windows / linux / whatever that can interact with SCADA, not the SCADA system itself.
I assume the previous poster has no working experiance or knowledge of SCADA, is a first rate pillock, and is worthy of immediate promotion to first line help desk telephone jockey.
"SCADA is not vulnerable to viruses - It's not a windows box, it runs propiatory hardware and software, and as such is not succeptable to viruses that you refer to (previous poster)."
O'really? Says who?
Here's the launch announcement for e-terrahabitat 5.5 [1]: "Support for Microsoft’s Windows Server 2003 for 64-Bit Itanium-based systems, in addition to the 32-bit version already supported, reinforces AREVA T&D’s commitment to e-terraplatform security, stability and scalability. "
Windows for security, stability, and scalability? That'll work, won't it :(
"I assume the previous poster has no working experiance or knowledge of SCADA"
I think you made another wrong assumption... maybe you're muxed ip between SCADA, DCS, and PLCs? Anyway, nothing personal, but best just keep quiet if you don't really have a clue.
[1] http://www.areva-td.com/news/US_460_AREVA+T&D%27s+e-terraplatform+2.3+and+e-terrahabitat+5.5+launch+with+support+for+MICROSOFT+Windows+2003+for+64-Bit+Itanium-based+Systems.html
"How on earth is mission critical software STILL being written that is susceptible to buffer overflows?"
I would guess:
1) Old, old code, and old, old libraries, written by Uncle Fester a few decayears ago
2) People coming out of Uni having caught all the bad habits about how to write "efficient C code". They possibly might think they can do multithreading, too.
3) People a long time out of Uni never having been un-taught all the bad habits about how to write "efficient C code". They possibly might think they know how to program.
4) C code
And also:
Quality Assurance not implemented or degenerated to ticking off boxes. Possibly handled by reconverted beancounters.
Mine's the one with "I worked with Recycled Cobol Monster" on the back.
Maybe. If alongside the absence of ANY kind of external access (not just Internet), every computer in the system a) has every single USB port filled with epoxy resin, and b) has no other removable storage (CD, DVD, floppy, Zip drives etc) installed. In which case upgrades are impossible short of swapping out hard drives - which then introduces a virus risk.
There's no such thing as unhackable. Back in the early 80s, during my own somewhat nefarious teenage years, the hacker who introduced me to the scene told me that the Second Law of the hacker was that "What man can make, man can break." (The First Law, of course, being the now hackneyed "Information wants to be free" axiom.) I've since kept that in mind when building security into my applications: no matter how good I think I am, someone, somewhere, can and eventually will crack it.
Thus the most important thing to consider in developing a security solution, especially in mission-critical systems like SCADA, is not to hope you can completely prevent intrusion, because you can't, but how effectively and quickly you can mitigate damage WHEN an intrusion does occur. While this does seem to go against the "prevention better than cure" ideology, it does not do to discount the need for the cure by focusing every resource on prevention. Manual overrides, on-site triggerable emergency shutdowns, clean restore/reboots, proper personnel security procedures and redundant backup systems are all part of a properly thought-out security solution. Anything less is deluding yourself - and playing roulette with people's livelihoods. Or even lives.
Black Heli because it's the closest symbol of paranoia in the icon list... and paranoia in security is paramount!
GE Cimplicity on Windows.
It's not 100% obvious that the Cimplicity/Windows pair is behind the problem at Areva, but I don't see anything else mentioned either. Might have been nice if the article had a bit of "added value" filling in some of these gaps. Then again, that perhaps might have upset the legal eagles, and we wouldn't want that.
The C4 whitepaper is worth a look; it also mentions some other undesirable behaviours in addition to buffer overflows, such as nearly-transparent username/password-type transactions over the LAN, decodable with a sniffer and a tiny tiny bit of intelligence.
Other SCADA packages and OSes are available, and others are probably also just as vulnerable.
http://www.c4-security.com/SCADA%20Security%20-%20Attack%20Vectors.pdf
""Computers used at nuclear power plants are not connected to the internet and therefore they're not vulnerable to viruses of any kind," he said."
It is not the computers to worry about for they do not work well or if at all without Human Input/Organic Output. And is it Thoughts Shared which Create a Greater Beta Virtual Machine and IT Machine Environments for Human Discovery of Our Other Selves. That which we truly are and accept ourselves to truthfully be.
There is an Ongoing Escalating Problem whenever Knowledge and Information exceed Known Intelligence Parameters but Immediately Resolved with the Creative Intercourse of Discourse.
'"Computers used at nuclear power plants are not connected to the internet and therefore they're not vulnerable to viruses of any kind," he said'
Yea, because a bored nightshift worker wont plug in a usb stick and try running a game.
I've seen many closes systems with viruses roaming their internal network.
Your average virus is designed to turn your PC into a spam drone or just wipe your data. They wont try faking signals to the PLC which does all the proper controlling on the system.
Seriously. The systems with access to SCADA may not themselves have access to the internet. But to state that power plants live in some kind of internet-free zone is silly.
Blaster compromised US power distribution in 2003, not because it was a SCADA attack but because it took out systems at power plants as collateral damage. I suspect there would have been issues even if the SCADA controllers themselves remained entirely untouched by the attack, simply because IT staff at compromised sites were running like hell to fix the Windows boxes.
http://seclists.org/bugtraq/2003/Sep/0053.html
And blaster was really more of a prank than anything else; it used a publically posted PoC as its payload, looked for new hosts to infect, and crashed systems. Yes, it was a large pain to deal with, but it wasn't installing other code or formatting harddrives on restart or silently phoning home. It was incredibly noisy and easy to see. But it was also very fast!
Power generation infrastructure has been neglected for decades in the US and lots of Europe.
Does anyone here think that the facilities are staffed to afford the eyeballs to do monitoring of logs on SCADA systems?
There was a great Defcon talk on SCADA attacks last year and the presenter admitted "it's noisy as hell. But no one reads the logs, so it doesn't matter." He was considering working with fyodor (nmap) to add the SCADA attack to the nmap toolkit and to make it much quieter.
Once you're inside a network, if you know what you're doing, whether an internal host talks to the internet or not is not a problem. As long as they talk to switch ports, you can talk to them. If you can get the guy who answers phones to read your email and click on a link, or visit your website, the odds that you can get access to a windows box that talks to internal switches just went through the ceiling.
The real concern is not worms or script kiddies. It's people with folks on salary with training and practice doing attack/defense in teams. State actors and large organizations could undoubtedly do this; the real problem is in coming up with a defense against it in a heavily privatized and decentralized system.
We mostly dislike the geographic firewalls in China, Australia, Burma, etc.
We may ultimately find that what we need are business sector firewalls mandated by governments that can require all actors in a given sector to be running behind a common and commonly secured set of connections. Not just hardware platforms, but actually insist these folks drop their current addresses and buy leased lines to dedicated data centers with budget for ingress and egress monitoring and response.
My guess is we won't get to a state like that until someone seriously, ahem, degrades performance on SCADA infrastructure. The politics of doing it may be completely untenable even then.
There's a lot of interesting comments here, obviously some people have experience, clearly some people don't...
There's also a lot of niave thinking going on, "Viruses won't think to send control commands for a specific application" ... Hmmmm, perhaps the original writer won't think to do that but it's certainly possible that somebody might change an existing virus to complete these kind of task, in any case there are much easier ways to attack networks like this
Presuming that nobody can get into the plant and hook up to one of these networks is deadly, one of the best pen tests i've seen is someone dressed as a telecoms engineer (bt) who walks in, fiddles with core comms cabinets, even get's people to unlock them and then leaves "without trace".... Before you know it your highly secure network is connected to a WAP and accessible from outside the building, perhaps even in the case of a 3G router attached to your network the world... The security of an application rely's on much much more than the security of your code, although it is of course important. air gap is a complete cop out, my personal view is that air gap in our current climate counts for very little without signicant monitoring, auditing and other security controls.
It seems that it wouldn't be a very difficult attack for somebody who was determined enough, I guess we can only hope that they have some kind of seperate monitoring / overide system.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
