Italian Hacker Publishes 0day SCADA Hacks 106
mask.of.sanity writes "An Italian security researcher, Luigi Auriemma, has disclosed a laundry list of unpatched vulnerabilities and detailed proof-of-concept exploits that allow hackers to completely compromise major industrial control systems. The attacks work against six SCADA systems, including one manufactured by U.S. giant Rockwell Automation. The researcher published step-by-step exploits that allowed attackers to execute full remote compromises and denial of service attacks. Auriemma appeared unrepentant for the disclosures in a post on his website."
You cant blame him (Score:1, Offtopic)
Re: (Score:2, Insightful)
Like the US economy?
Re: (Score:2)
The italian justice system?
Re: (Score:1)
Italian government?
Re: (Score:3)
Silvio, is it you?
Re: (Score:1)
Yeah, the Italian economy is circling the loo.
However, if someone were to be injured or killed because of this fellows actions, I think his reasoning is going to ring a bit hollow.
Re:You cant blame him (Score:5, Insightful)
That it's 'in the open' just means that there is an urgency to correct these problems... problem being; that urgency existed prior to public disclosure.
Better to have this information publicly disclosed and subject to scrutiny than the previous system... which involved, apparently, obfuscating or ignoring vulnerabilities or gross incompetence of those responsible for detecting such vulnerabilities.
Re: (Score:2)
Yeah, the Italian economy is circling the loo.
Pecunia non olet! [wikipedia.org]
Re: (Score:1)
Italian economy isn't crappy, at least not much more than US economy in these days.
However, we've got a things or two which are actually very crappy: ... ... ... ...
1) Prime Minister
2) Government
3) Legal System
4) Infrastructures
5) Taxes
99)...
Re: (Score:2)
99)... ... ... ...
I take it a bitch isn't one of those problems though?
Re: (Score:1)
Yeah, the stupid idiot who almost had the US completely out of debt. What a fag.*
*That's fag in the pejorative sense, not the cigarette sense.
Re: (Score:2)
Hillary Clinton took a position in the Italian government?
Isolated networks are A Good Thing (Score:4, Insightful)
Isolated networks are your friend.
It won't stop insider attacks or naive-person-inserts-poisoned-USB-attacks but it's a good first step.
As for naive employees: Train your people well.
Re:Isolated networks are A Good Thing (Score:4, Informative)
Re: (Score:2)
Re: (Score:2)
Just use earplugs.
Re: (Score:2)
Nah. In most data centres, dismembering a server with a roofing hammer would barely be heard. In some data centres, it would probably be routine procedure.
Re: (Score:3)
No really. I mean, you can smash their equipment, but that's hardly a big deal.
Controlling valves, system, dropping rods, shutting off dam, and so on are the big risks.
Re: (Score:3)
Re:Isolated networks are A Good Thing (Score:4, Informative)
The Stuxnet worm proved that even isolated networks are vulnerable. Besides there is tons of valuable data and metrics on those networks that needs to make its way to plant managers who may or may not be onsite. That data also makes it way into reports that show plant efficiency and keep track of problems that pop up. Its difficult to isolate that data from the rest of the world.
We need to face facts that many automation protocols are severely dated and insecure. Has anyone ever heard of Modbus? Its an industrial communications protocol that was developed by Modicon in the late 70's and is STILL used today. Its 100% insecure and can be used to write to registers and "coils" on many PLC's/PAC's. Originally it ran over rs232/422/485 networks but today it has a modern TCP version called ModbusTCP. And that has no authentication built in. As long as you can talk to that PLC you can write to any of its registers. Other protocols are also wide open such as the massively popular Profibus/ProfiNET, and etherNet/IP (IP stands for industrial protocol).
There are dozens of automation controller manufactures out there. Many using these insecure protocols with no replacements in sight. Plus add to that that many end devices that communicate with these controllers are pretty simple in design, pressure gauges, temperature sensors, valve islands motion controllers, etc. are simple in design and implementing a security layer between them is not easy. Modbus is simply a send command to read a register or coil and a simple response. The only other setup is usually setting an 8 bit device address that is accomplished via a set of rotary or dip switches.
Until someone that is big in the industry (Schneider/Modicon, Allen Bradley, Siemens or Rockwell) comes out with a secure protocol that is simple, reliable and open to anyone to implement, there wont be any change. The only security is to isolate networks and pray no one infects computers inside the control network.
Re: (Score:2)
I would like to point out that there ARE some efforts to secure the non-deterministic SCADA side of things. Secure authentication is available for the DNP (IEEE-1815) protocol. At the present they must be pre-shared symmetric keys and there is no way to change those keys over the protocol; though that feature has been written and is undergoing review. The secure authentication
Re: (Score:2)
I should have pointed out the real-time nature of these protocols as well. And its a good point that security will increase response time. That is unacceptable.
But again, getting plant floor data from the control systems to reporting/database software is something that everyone wants to access from anywhere in the world. As long as internet facing computers are hooked to control/SCADA systems gathering such data for reporting means there is a bridge to the control network.
I am working on an automation syste
Re: (Score:1)
Re: (Score:2)
I spent 15 years in industrial power, working with the exact communications and control networks you complain about. I know what you're talking about and sympathize to a large extent.
Your boss' request, however, does not compromize security. There is nothing insecure about providing read-only access to the network. A secure device sitting on the industrial network could export/expose the system status through a variety of means, none of which would accept requests to alter the system state. At a very extrem
Re: (Score:2)
Control net facing machine receives updates, forwards them over rs232 to an internet facing machine. Cut the Tx on the public net machine so it cannot in any way signal back to the secured machine even if it is compromised.
Re: (Score:2)
The Stuxnet worm proved that even isolated networks are vulnerable.
To be fair, it only demonstrated that a single piece of software could exploit multiple attack vectors. As to what networks were infected and how isolated they were, that's mostly speculation.
Re: (Score:1)
I think the government are asshats, but one logical reason for remote control of SCADA (i.e. if the government deliberately had the exploits - conceivable) would be in the hypothetical scenario that China or some other 'adversary' were to take control of a nuclear plant and use it to power deployed weapons and craft, or try to make it a nuclear disaster site to weaken morale or wreck infrastructure and capability etc. OR, maybe the government just didn't know, OR maybe they planned to use said exploits them
Why not isolate the networks? (Score:3)
Re: (Score:2)
Crack the router with the VLANS and you have both networks. If its something someones life depends on, physically isolate the networks.
Re: (Score:2)
And now you're running 15 plants country wide and head office wants all the data on your shiny new SCADA system centrally available (for no other reason than they like to pretend they know what they're doing), so you're forced to run a VLAN. The problems here are mostly social, not technical.
Data diodes. (Score:1)
They want the data? Display it on a screen and point a webcam at it. Data diode.
Complexity can be added as needed (eg an intermediate system that stores all the data and can run queries on it -- but still can't send anything back to the SCADA system), but there needs to be the equivalent of an air gap across which information only flows one way.
Re: (Score:2)
Separate systems have been how all the SCADA system I have seen are set up.
Re: (Score:3)
Re: (Score:2)
I've been in hundreds of plants all over the world, in a wide variety of industries, and I would estimate maybe 25% have had an air gap. Maybe half had a bridge PC or a router.
This includes a lot of old facilities, that were controlled with pre-ethernet PLCs. In most of those place the PLC network had some separate segments (running Modbus or Devicenet of something), but there was usually an ethernet PLC somewhere plugged into the same network as everything else.
Re: (Score:3)
Of course that was because of SOX. The design of most SCADA networks is so bad just about any normal computer security beraks them.. Especially when multiple vendors are involved. SOX auditors made everybody kick SCADA off the business network... Which has the side effect in most shops of keeping it off the Internet as well.. Or limited to point-to-point networking (dial up)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
using real modems.
Site 1 calls in and logs on.
main site drops the connection and uses the credentials to call back to site 1 on the Stored phone number.
Hell I had a us robotics modem from 1989 that did this it's called ringback security and is highly effective. it kept a lot of fellow hacker friends out of my stuff. I even dared them to crack it.
Today a dial up system is stupid. Private T1 line connection from point to point is the cheap answer ($79.00 a month today not crossing state
Re: (Score:2)
Re: (Score:2)
My USR modem would hang up for 30 seconds (It's a setting) and this would clear the line even if the other side did not hang up.
I did live in a broken exchange though that did not clear the line if both sides did not hang up. but that was years ago. Telephone spec calls to clear the line if the ON hook is pressed for 5 seconds or more.
Incorrectly configured modems that hang up and instantly dial back can be spoofed this way.
Re: (Score:2)
You're assuming the person doesn't know how to fool the switching equipment into staying connected.
There's a lot of old phreaking tricks that aren't so common now, but with computerized switching equipment, anything's possible.
Re: (Score:1)
Alas, those old phreaking tricks won't work anymore in places that have moved away from the legacy in-band signaling and control hardware. Which is pretty much all of the civilized world since the early '90's for the PSTN. One could I suppose get lucky with a local PBX - but the attack still requires obtaining access to the PBX controller / software, not just access to modem's phone line.
Re: (Score:2)
Re: (Score:2)
More often than not I have found the justification for connecting the control and office networks to be the "DA" part of SCADA. Management wants control side data in reports and it is much more cost effective and timely to automate that than to have someone physically enter it on another network.
Most of the SCADA outfits sell software to do exactly that, the "data historian" type applications. Invensys sells modules to deliver data directly from control networks to both their office side products (Avantis,
Re: (Score:2)
Re: (Score:2)
As someone said above, making an unidirectional UDP connection is quite trivial.
Re: (Score:1)
Re: (Score:2)
*Most* larger plants run by *Most* larger companies are actually quite capable of such a thing. What you are suggesting isn't uncommon at all. Pretty much every plant I have worked at bar one had either isolated networks (a horrendous pain in the arse), or a VLAN arrangement with routers and firewalls, the most common end point being a one way trip out of the control system onto some other network in a DMZ style arrangement (a very workable solution).
The problem ultimately is cost. The critical installation
Its not that hard! (Score:5, Insightful)
Most SCADA's are still bound to COM. Easiest way to get DCOM working; disable *ALL* security. When you're commissioning a site, and the hardware is being finicky, the last thing you want to do is spend 9 hours debugging some obscure DCOM glitch specific to server 2003 service pack 1 (the only system some of this stuff runs on), so it isn't hard to see why most people have zero security.
Bring on the days of OPC UA, which makes security possible without having a hernia!
Re: (Score:2)
You can run OPC-UA over DCOM so you don'y have to throw away your legacy code. You can then evolve your system later
But I too will be so glad when I don't have to run a system over DCOM
Re: (Score:2)
Practically speaking, I honestly don't see much of the industry moving off windows. Sure it is technically better, but try persuading management.
UA, however will give you added security on windows, which is at least a start.
Re: (Score:2)
I can vouch for the happier developers part... But lets be practical here, name a UA toolkit for Linux? Oh, and because most of industry is still on legacy OPC, it must support publishing via DCOM. You can't alienate 90% of your clients because you are an early adopter. I would be very seriously interested in seeing such a toolkit.
Re: (Score:2)
I will have a a look, but my company is not a member of the OPC foundation, so the source code option is out for us. Hopefully in the future we can move to this, but the clients right now demand a windows solution.
Re: (Score:2)
unified automation [unified-automation.com]
Re: (Score:2)
The company I work for is doing exactly that. Our new OPC server will support both. It is hoped that the monstrosity that is DCOM will eventually go the way of the dinosaur. We chose an OPC toolkit specifically because they had UA support (and possibly in the future WPF).
Re:Its not that hard! (Score:4, Interesting)
2003 SP1? HA! I've seen stuff running on Win98, because the electric engineers in charge are out of their league when it comes to computers, and win98 "just works"
I took some PLC introduction course in 2006 or 2007 and the guy was bitching about linux, because linux doesn't have support. And he liked linux because it's stable, but manufacturers only support Windows, and the only way to be SURE that your software is going to work AND last for many years, is to use a not-so-new computer. I'm glad that guy only does small things like cooling control and wood drying facilities.
But at least he got one thing right: All the control LOGIC has to be in the PLCs. The SCADA is for a nice GUI and logging ONLY. You should add enough buttons, switches and lights to make the system fully usable even if all the SCADA computers are down. And that doesn't mean "manual override", which is something else you should have too.
I doubt there are applications where a SCADA system should be making decisions.
Re: (Score:3)
Actually, support at rockwell, will specify your windows version and service pack. Otherwise the software does not run. It isn't always a matter of incompetence on the engineer's side, but sometimes the vendor shoves stuff down your throat. And its all well and good to only work with vendors with decent support and security, but practically if you are a SI, your clients often specify what hardware and software you use. And the most secure systems sometimes lack functionality. We tend to select the latest s
Re: (Score:2)
2003 SP1? HA! I've seen stuff running on Win98, because the electric engineers in charge are out of their league when it comes to computers, and win98 "just works"
You have a horrendously over simplified view of the industry or happen to have seen some few isolated cases. No the reason so much stuff runs on Windows 98 is not because it just works and the engineer doesn't know how to use a computer. Quite the opposite. In many cases trying to keep old computers running is harder than switching to the new ones, but the cost is non-trivial.
We have emergency shutdown systems who's major interface run on Windows 98. Not because a new computer is too hard or a windows licen
Re: (Score:2)
Luxury. Some process-control systems are still running Windows 3.x
Re: (Score:1)
Re: (Score:1)
exactly. i have to agree by 100%. i work winthin the branch. its just like you said. but most likely you DONT HAVE TO hack into something...factory default passwords in controllers and embedded systems are (at least in building IT) more common then (even weak) custom logins. if you make it to reach a controllers (web) interface, chance is good you just access it by default password.
DUH.... (Score:3)
If your SCADA system is on an unprotected and ISOLATED network then you deserve the hack.
Kick managers in the nuts that ask for a remote connection to the SCADA system or it's PC's running the pretty UI for the plant operators. there is NO reason to allow any access except from the keyboard and mouse. anyone WORKING on the systems, IE the programmers and engineers should be using sanitized laptops that are ONLY USED for that purpose.
I was doing this in 1996 when I was doing SCADA systems using the craptastic WonderWare and AB systems.
Re: (Score:1)
He he. OK, I will *sighs*
It's not 1996 any more (Score:2)
Kick managers in the nuts that ask for a remote connection to the SCADA system or it's PC's running the pretty UI for the plant operators.
Turds run downhill--that middle-manager probably has directives from his boss...or perhaps the government or regulatory body...to obtain data from the SCADA system and so in turn has requested access so he can provide that data.
I don't get much call for remote access to the HMI (operator interface) itself in my projects--but it is my primary purpose in these jobs to provide remote access to these systems for access to alarming/annunciating as well as process historian data. On-call operations personnel "ne
Re: (Score:2)
* NEVER put real-time (PLC's/PAC's/controllers) and supervisory (HMI, historian data logging, etc) on the same network!
This here is really one of the keys. Network segregation is your friend. The network design is as important as the logic in these systems. The "airgap and be done with it" crowd do not seem to understand this!
Re: (Score:2)
If your SCADA system is on an unprotected and ISOLATED network then you deserve the hack.
Kick managers in the nuts that ask for a remote connection to the SCADA system or it's PC's running the pretty UI for the plant operators. there is NO reason to allow any access except from the keyboard and mouse. anyone WORKING on the systems, IE the programmers and engineers should be using sanitized laptops that are ONLY USED for that purpose.
I was doing this in 1996 when I was doing SCADA systems using the craptastic WonderWare and AB systems.
We have a WonderWare based system on our plant. I can understand why you're so bitter and twisted :-)
But on the topic of managers, they aren't the problem. In engineering everything is possible and you can only question the implementation. It's really trivial to design a system that allows complete remote view / remote access without compromising the core integrity of your control system. It really comes down to competence, and like mindedness. If management tells you to do it on the cheap and your compromi
Common Thread (Score:1, Interesting)
Windows is the COmmon thread to all the threats. STUX was a windows exploit. When can folks get it through their head that Windows belongs on the bosses desk running excell and project and NOT on the factory floor running production.
Luigi Auriemma is my hereo (Score:3)
It would not surprise me if he ends up finding more vulnerabilities than the rest of the world combined and he does it exclusivly for fun/challenge.
"Responsible" disclosure does tend to mitigate problems in the real world much like a virus scanner installed on a random desktop.
However neither approach provides the proper incentives to the market to address the root cause of the design/process deficiency which allowed the defect to occur. Responsible disclosure actually artifically lowers the cost the industry has to pay for a security failure only while it is found by someone who is deemed to be "responsible". This makes all software less safe in the long run.
Programming suite != PLC (Score:1)
Then again, if your PLC network routes publicly, you deserve to be aggravated.
Re: (Score:1)
I sure hope my retro encabulator is safe (Score:2)
If someone got access to the modial interaction of magneto reluctance and capacitive duractance, we could all be in a world of hurt.
2011 and we still have the same idiot programming (Score:3)
I checked over a few of his bug reports, and was bemused to see the same old rubbish
"mplayer" - calloc() called with a 32-bit integer multiply
"id Tech 4 engine" - memcpy(_,_, size - 6) , where 'size' is the size of a received packet and can be 5 bytes
"Unreal server" - crash the server by sending an unexpected packet (the code does an assert() instead of just dropping the packet or whatever)
"winamp" - craft a video with large dimensions, winamp does signed 16bit multiply of video height*width
I guess the mplayer one can be explained by free software people not having proper programming training, but iD etc. , you would think that they would hire programmers who think about the possible contents of the variables each time they write an arithmetic operation, especially when it's known that the value of the variable is read from a file or socket and could be anything.
It really is not difficult to check that size >= 6 (and then that size - 6 buffer_size) before writing "size - 6" in a memcpy.
I never understood assert() either, just seems like a recipe for disaster in production; it's not difficult to test conditions and invoke actual error handling and recovery
Re: (Score:2)
assert() is very useful if used properly. It is supposed to be a debug support tool, crashing the program the moment something happens that cannot possibly be right, e.g. a function being called with an array with the wrong number of elements. This way, when the program crashes, you have immediately an idea of what went wrong, and must no
unrepentant (Score:2)
Of course he is.
We've had the "responsible disclosure" discussion, and although some of you may disagree, I'm not the only one who thinks it was a bust. Looke a lot like lazy companies wanted ahead notice, without living up to their share of the "responsible" part, namely actually fixing the bugs in a timely manner.
And then there was legal and other actions against people who told the manufacturers ahead of time that they were going to disclose a vulnerability at this conference or that publication.
If you c
Re: (Score:2)
Oh yes, I forgot:
If you think that exploits don't exist until someone discloses the vulnerability, you live in lalaland. More often than not, when a 0day is published, a whole lot of bad guys already knew and actively exploited it for quite a while. In fact, if you read carefully, you'll notice that suspicious activity is sometimes what caused the investigation that lead to the discovery of the vulnerability.
simple solution to SCADA "hacks" (Score:1)
What viruses like STUXNET do is reprogram the hardware (CPLDs) to do what they want. In a recent article about BIOS viruses (and antivirus) people were saying how dumb it is to give an OS the ability to reprogram the BIOS without any physical safeguard. In mission critical systems absolutely no hardware should be reprogrammable without a physical safeguard like a switch. Of course to make sure the idiots dont leave it switched to programmable (we all know they would be because a switch is "such a pain"),