Slashdot Mirror
Italian Hacker Publishes 0day SCADA Hacks
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. If I were Italian I would be trying to find things that are crappier than the Italian economy too.
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.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
I used to work at a foundry that had a Rockwell SCADA system. It operated on a completely physically separate network from the normal, internet-facing corporate network. If somebody needed access to both the SCADA system and their email, they had two computers on their desk. For something not as critical as say, a utility, I think this was a bit of overkill (at least they could have used VLANs), but why is this not a semi-common practice? Why do these controls need to be on a network with a route to the internet?
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
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!
I have determined that my sig is indeterminate.
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.
Do not look at laser with remaining good eye.
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.
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.
By the look of the Rockwell exploit, it only impacts the PC-based programming suite, rslogix. The worst of it would seem to be that you could aggravate a programmer trying to setup a system and NOT remotely take over and reconfigure a PLC system.
Then again, if your PLC network routes publicly, you deserve to be aggravated.
"Perennially barely legal"
The Rockwell exploit is for the programming software, RSLogix5000, which is the equivalent to an IDE. Very unlikely open and running on a computer that is mission critical. This is only for changes and initial commissioning of the system, not a SCADA system.
he (who doesn't appear sinister) does this rather than some asshat secret group to turn a 9/11 style drill into a compromise of security.
Bravo!!!
Rockwell better make sure my retro encabulator is secure from those hackers!
If someone got access to the modial interaction of magneto reluctance and capacitive duractance, we could all be in a world of hurt.
jp
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.
I knew this guy years ago for his published exploits for different Quake3-based servers. I was amazed at the level of detail and wide spectrum of exploits/tools for those games. It was really helpful and allowed server admins to patch the vulnerabilities.
Now it seems his real job is in the industry. Good to know, the industry will be safer with him around, as everything else.
Mr. Auriemma has been discovering security vulnerabilities and publishing them on the major security website like Secunia etc...
he has been doing a great job and we have been patching promptly after his discoveries.
This is just one of them, just b/c it's gov stuff, he doesn't need bashing!
I work in an industrial environment, doing PLC/SCADA automation systems. The company appears to have blocked access to this website, so here's hoping we don't use any of those systems ;-)
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
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 can think of a better way to make sure people don't tell you in advance about what they found wrong with your crap, I'd like to hear it. :-)
Sorry, but while I would give most Free Software and small/hobby projects the benefit of the doubt and be kind to them, anything manufactured by a large company needs immediate full disclosure. Pain is the only way these MBAssholes learn. If you try to be "responsible" with them, they'll consider it an opportunity to fuck you over and still do nothing about the quality of their stuff.
Assorted stuff I do sometimes: Lemuria.org
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 "need" to have SMS notification on critical alarms/events. Regulatory bodies need reports for everything from custody transfer to environmental contamination data. It is IMPOSSIBLE to keep a SCADA system truly isolated from all public networks anymore. To be legally compliant much less competitive requires data from SCADA systems to be available off-site. Even with 100% physical separation you'd be shuffling USB drives around which would be just as vulnerable, or using other physical media (DVD-R's etc) but that is not an acceptable solution due to volumes of data and the requirements for timely data (up to near real time in some cases)
Ideally, it would be GREAT if we could play in our own little sandbox but technology moves on and outsude forces beyond our control demand we leverage that technology to boost production, increase efficiency, make the workplace safer and reduce environmental damage-those demands cannot be meant without connectivity in any way at all. So instead of fighting it we MUST address security PROPERLY--not just including perimiter security. That includes not just patching SCADA software but implementing proper system architectures as well as enforcing policies and procedures. Some stuff I rarely see done but should always be done these days include:
* enforce complete ban on shared logins--no more of this "user operator password Operator1" crap.
* In windows platform systems make it a policy to elimiate "workgroups" and implement proper domains with group-policy enforced security
* disable all removable media access for all but a very few
* NEVER put real-time (PLC's/PAC's/controllers) and supervisory (HMI, historian data logging, etc) on the same network!
* make security audits and software patches or upgrades part of the maintenance/turnaround schedule with all other equipment--and insist to vendors (with threat of rip and replace) that support for current OSes and sane security policies are a requirement for your business.
Using Windows in ana automation system might be flawed, security might not be built into real-time netowrks, and SCADA software may be full of bugs, but the most immediate threat is how far behind the times automation systems are in implementing security measures compared to business/general IT.
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 not dig as long into the code. This is different from exceptions or other error handling because the latter can legitimately happen in operation, while assertions indicate conditions that cannot happen if the program is not buggy.
If you are correct about the Unreal server, it seems clear they used an assert() where an exception was due, since the program is not broken only because it is fed bad data.
Victims of 9/11: <3000. Traffic in the US: >30,000/y
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"), it would only boot to an internal keyboard menu system that would prompt you on how/if you want to reprogram the system when switched to program mode. To be clear, I'm talking about switch that would actually change the circuit and not just be an indicator for the firmware.
Why is it so hard for people to realize that these systems need to be well protected?
Anons need not reply. Questions end with a question mark.
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.
Clearly, you have never seen the craptastic bug ridden code that Carmack creates.
Take Doom1&2 sources: At first, he is elegant and modular and clean. Then, in the effort of getting shit done he will becomes sloppy and hackish.
When faced with a deadline and a performance issue he invents REJECT table -- an O( n^ ) complexity system which does not scale well at all X sectors creates X*X REJECT entries, this feature, bolted on basically in Beta...
It stands to reason that if even the lead programmer makes mistakes, his subordinates will do so as well.
We're all human, even if you choose to worship some.
More on SCADA vulnerabilities here:
http://www.controlsystemworks.com/blogengine/post/Post-Stuxnet-industrial-automation-systems.aspx