Researcher Finds Nearly Two Dozen SCADA Bugs In a Few Hours
Trailrunner7 writes "It is open season on SCADA software right now. Last week, researchers at ReVuln, an Italian security firm, released a video showing off a number of zero-day vulnerabilities in SCADA applications from manufacturers such as Siemens, GE and Schneider Electric. And now a researcher at Exodus Intelligence says he has discovered more than 20 flaws in SCADA packages from some of the same vendors and other manufacturers, all after just a few hours' work."
Eh?
When the light turns on, the roaches scurry. SCADA has been ignored by infosec up till now. Many of these systems are old, or are new systems not designed any different then they were in the 80's or 90's. It's not hard to find low hanging fruit when you're the first person picking it. Give 'the system' a few years and it won't be any different then Linux and Windows bug hunting now.... once you convince everyone to upgrade, that is.
This is why SCADA needs to be built out separately from your data network.
is another's exploit.
Anyone who's used some of these SCAD products already knows they're buggy as hell. I'm not the least bit surprised there are security errors.
The industry uses what they use because that's what they use. Their standards are built on their expectactions which are built on their experience. Long ago, computers were machines you didn't turn off. They were reliable and steady. People wrote software which adhered to that mindset. But then the PC industry came and every hobbyist became a programmer. That's when all hell broke loose. But that was fine because these were small system and you just reboot and keep on with whatever you were doing. You were just one person. What did it matter? But the next thing you know "enterprise applications" are being built on a platform intended for single users... bringing with it a whole crapload of lax and shoddy standards.
Now you know how we got where we are today.
How do we get out? Linux is built under the same old school priciples of reliability and stability so it tends to be able to run a lot longer than WinTel. But even that's showing signs of relaxing. And Apple? It had a reputation for not having problems... that was until people started to use it.
So how do we get out? Obvious answer is to go back to what worked. But that's EXPENSIVE. No more "off the shelf solutions" with implied (though EULA denied) guarantees. No more OSes built from single-user, patched and hacked systems. AS/400 for mature systems and service standards come to mind. IT got cheaper with PCs and WinTel. But they also became 10,000 times more risky. People who spend money are constantly lied to by various parties and don't listen to their own IT people about what they should do.
It's time to go back. It's time to go back.
Everyone knows about the holes, including the manufacturers. They're designed to operate on controlled, private networks. Every time someone gets hacked, they should go after the implementors, not the vendors as they should factor security onto their site designs. I'm not excusing the manufacturers, just people need to know this is engineering and not infosec - people buy black boxes which do stuff and that's all that matters to them.
In a few hours??!!! it's a SCANDAL!!
it explains the bugs they have right there. tomhudson also goes by Barbara, not Barbie, and webmistressrachel around here.
I tracked the video down to ReVuln - SCADA 0-day vulnerabilities
Now can someone tell me what I saw? All I can see is video of some commands being typed into a command window in a older version of Windows, and lots of graphics (and funky music) saying exploit this and exploit that. How do I know that what they are claiming is what is shown on that video?
Note that I am not doubting that SCADA systems are not secure, the've been my bread and butter for a long long time. I just want cold hard facts., not a presentation that looks like it is a sales pitch aimed at scaring SCADA manufacturers.
I am Slashdot. Are you Slashdot as well?
SCADA was supposed to be an industrial control system, where nobody thought "hey... let's suddenly connect this incredibly important system that could literally kill people if it were compromised..... to the internet".
So it shouldn't be surprising the thing is full of vulnerabilities. It wasn't designed to be a secure system from smart and incredibly skilled people trying to attack it. It was designed to be secure through physical security and lack of access in the first place. The problem is that everyone expects data all the time now, even reporting from their industrial processes. So some higher up demands it, and the IT department is forced to connect these systems to the net... opening up a huge amount of problems.
Duh.
AccountKiller
So, if I'm a random security researcher, how do I get my hands on these SCADA systems to test them? They certainly aren't open source, and I'm guessing they aren't cheap. I doubt you can just type a credit card number into GE's web site and download one. How do they get one to look at?
If the Big Bosses want to know the status of their machines and run reports on that status 24/7, fine.
Just have the equipment log to a write-only device that is in turn read by equipment the Big Bosses can access.
There's still the very serious risk of highly sensitive data leaking out and being used against the company or its SCADA devices in a USB- or social-engineering-based attack, but at least the equipment that can kill people will not be directly write-able from the Internet.
It's not SCADA, but back in the day I knew a corporate Unix sysadmin who had the console on a hardcopy teletype long after teletypes were out of fashion. He had it print a heartbeat every 15 minutes and the time at regular intervals. When the teletype was silent for too long or if the time was too old when he walked into the room, he knew the machine crashed and about when it crashed. This also told him when the computer lost power and when it came back up if there was a power failure.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
I DO work with those suckers, and let me tell you, they start spitting bugs at you just after the installer ends!
Some of those systems are based on a technology called OPC. That's OLE for Process Control. Over the network it runs on DCOM. Of course unencrypted and usually without authentication because it's already hard enough to get it running somehow.
Of course those are Windows-only solutions. And of course, those systems are often so complex and badly made that updates are next to impossible.
There is currently no knowledge about security in those companies. They simply don't understand it. I've been in companies which had that problem, and believe me, it's very frustrating and fruitless to talk to such people. Their strategy simply seems to come up with the most breathtaking "arguments" to keep you silent. Common "arguments" are, "Windows 9x is secure as nobody writes malware for it anymore", or "NetBEUI is secure because it's not routable".
What we need is a cultural change in SCADA implementations, but that's not easy to do.
How do system updates or license updates work then? .net frameworks. And the software often has 1990s style licensing systems running which might need regular license keys to stay up to date. This was apparently the most common infection vector for Stuxnet.
Keep in mind those systems often are Windows systems running huge amounts of software on them like SQL-servers or
Todays SCADA systems are less and less designed to allow for that. Another obvious point would be that those systems need to boot from read-only memory. Sounds trivial yes, but just try that with Windows.
OK, unfortunately the video is not really informative.
Remote execution means that the attacker was able to tell the other system to run commands. One common method (stack overflow) works like this:
(In C) you have a local variable, for example to hold a string. Imagine it's 10 characters long, and you want to write 20 characters into it. It's obvious that you overwrite something. Since local variables are on the stack, you overwrite parts of it. The stack also stores the return address of the function call. If you overwrite this, you can make the function "jump back" to wherever you want... even to the string you just gave it. So instead of the function returning to the main program, it executes the machine code you gave it in your string.
The standard article on this is:
http://phrack.org/issues.html?issue=49&id=14#article
Sometimes particularly badly designed systems will even just take a command and execute it, but that is rare.
Heap Spraying is to get strings into the memory, for example to be executed by the stack overflow method. It's useful since on some systems the simple method doesn't work.
Arbitrary File Download means that the attacker was somehow able to tell the victim to arbitrarily download a file. This can be used to overwrite files (e.g. the screensaver, or configuration files) or to make life easier for the attacker.
Session hijacking means that you can take over a session, for example of a logged in user. So you are able to impersonate the logged in user.
Home Pregnancy Test http://goo.gl/DJx0v Home pregnancy test, If you think you are pregnant, you may want to test yourself at home with a home pregnancy test. Home pregnancy tests have been most women's first choice to confirm their suspicion they might be pregnant.
There does seem to be a concerted effort here to derail the thread, a prime example being the above and similar comments.
Microsoft Windows SQL virus takes down SPDS safety system in Nuclear power plant
Blaster worm linked to severity of blackout
Engineers Befuddled by Blackout
AccountKiller
I found half a dozen in the GE product this year, in a few hours also. The same bugs were present in an old version and the new release, so I'd suggest their SDLC is flawed and they are in no hurry to fix security problems.
Shoddy.
16 years ago I worked on/developed industrial control systems and the fact this industry hasn't moved anywhere on the security front is not surprising. At the time development was still 1970s-80s style, save the punch cards. Most of the software developers had never learned structured programming and would still argue against it a solid decade after their mainstream ilk gave up the fight. Their code style was pure 70s at best and pure chaos at worst when written by the EEs. The newest code was all written in a language that I thought was already in the dustbin of history 5 years before I got there. Network security was completely foreign to everyone there.
The equipment was extraordinarily-buggy on top of our highly-questionable software. I remember numerous long nights isolating and writing workarounds for bugs or code that defended them from the user. These black boxes were all selected by either EEs for electrical characteristics, MEs for physical mounting/environmental characteristics, or some combination of the two. Their prices were high and therefore they gained a strange aura among non-programmers for being infallable objects with exceptional engineering.
The funny thing is the last time I heard from a contact there my software was still in use cooking up parts and the company was still selling injectors using the same crappy DOS-based interfaces we had back then. Mind-boggling. Today I can hardly fathom software that remains unchanged for even a couple years due to the pace of change on the internet.