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."
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.
Like the US economy?
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.
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.
help me fix this "Terrible" karma, please!
99)... ... ... ...
I take it a bitch isn't one of those problems though?
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.
Silvio, is it you?
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.
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