Researchers Find Slew of Flaws In SCADA Hardware, Software

Trailrunner7 writes "At the S4 security conference this week, 'Project Basecamp,' a volunteer-led security audit of leading programmable logic controllers (PLCs), performed by a team of top researchers found that decrepit hardware, buggy software and pitiful or nonexistent security features make thousands of PLCs vulnerable to trivial attacks by external hackers that could cause PLC devices to crash or run malicious code. 'We were looking for a Firesheep moment in PLC security,' Peterson told the audience of ICS security experts. They got one. 'It's a blood bath mostly,' said Wightman of Digital Bond. 'Many of these devices lack basic security features.' While the results of analysis of the various PLCs varied, the researchers found significant security issues with every system they tested, with some PLCs too brittle and insecure to even tolerate security scans and probing."

Comments

unreviewed code is buggy?

[Gothmolly]

So you're saying closed source, only-validate-functionality, stale code has security holes?

Re:unreviewed code is buggy?

[hairyfeet]

Are you forgetting the 6 year old Debian bug? the KDELook bug that lasted for over a year before caught? the hacked Quake 3 that lasted in the repos for a year and a half? The "many eyes makes bugs shallow" is a fallacy because it (incorrectly ) assumes that you have enough eyes that have the required skillset and that those eyes are doing NOTHING but searching said code, literally millions and millions of lines in just your average distro, for bugs. Then of course they have to be scanning ALL updates, patches, changes, for any possible vectors. Do the math friend and you'll find you'll have to clone about a million top level programmers just to keep up! I'd frankly be amazed that there is even 10% of the code in your average distro being checked by eyes other than the ones that actually wrote the thing. Just look at how much cruft and dead code the LO guys are finding in the OO.o codebase and that is one of THE most popular programs in the entire FOSS ecosystem!

In the end there is good and bad code in EVERY format from BSD and GPL to proprietary, it all comes down to the skills of the programmers and how seriously security is stressed in that company. There is nothing "magical" about FOSS that instantly makes it immune to bugs, nor does it give coders the power to instantly write non buggy code. Hell I could paste this post with links to Linux hacks, starting with kernel.org on down, but what's the point? Sadly perception bubbles and flag waving have replaced serious debates here which is why the numbers have been plummeting for nearly 2 years now. i hate to agree with him but old Mikey 500 accounts is right "Slashdot = Stagnated". I mean look at your own post that got a +5 for a simple variation of the classic "Use Linux!" troll. Its like the old Mel Brooks joke "all go to hell except cave 76!" and treating companies and licenses like ballclubs to root for.

Kinda sad that supposedly well educated geeks have ended up no better than those we laugh about cheering for reality TV stars, only we replace the Kardashians and Survivor for Google, Apple, MSFT, and the GPL.

These things were too successful.

[icebike]

Most of these PLCs were simply too successful for their own good. Many of these designs were created in the 70s with no real intent of ever having then live in an on-line environment, but rather to be isolated in machinery as simple as pumps, motors, and simple stand along controllers for a variety of machines.

The problem lies not with the PLCs but the questionable decision to wire these things into the network.

Some of these things are extremely simple controllers. Others, like the mentioned D20 ME are micro computers onto themselves. These devices are built from a long line of simple process controllers, which grew to their current state from simply hanging more and more interfaces, better processors, and a mountain of legacy software, onto what started life as a very simple device.

None of them were ever intended to be put directly on the wild and wooly net, even when the did contain Ethernet ports, modems, and radios. Everyone assumed these were on their own in-plant network and that no one would hook them up to even their general purpose lan, let alone to computers accessible to the internet.

Anything less successful would have been replaced by a total redesign and rewrite from the ground up.

Re:These things were too successful.

[Anonymous Coward]

I program, install and commission PLCs in high security facilities, including prisons. We mostly use them for door control, interlocking and some low-level interfacing to other systems for which we don't have a high-level interface.

I do not believe that the responsibility for security should rest with a relatively cheap, simple bundle of IO and a processor programed in ladder logic. The security should be in preventing access to the SCADA/security network to which these controllers are attached. These things aren't servers, it's hard to imagine a reason for having them anywhere near the WWW. In our high security sites we usually have an air gap enforced by a physical barrier (two layers of four metre high razor tape fence) which is regularly broken by people disregarding policy and carrying in USB memory sticks. This is a potential attack vector, assuming whomever wrote the attack program had intimite knowledge of how the PLCs were programed. Most network security barriers are overcome in time as new vulnerabilities are discovered. Given the commission-and-hands-off nature of PLCs, rolling out updates to patch theoretical vulnerabilities is going to be a VERY hard sell, considering any change to the PLC usually requires re-commissioning every field device attached to it.

Re:These things were too successful.

[gman003]

Agreed. My father actually works for a major company that makes these (among other things - he works in a different department, but uses the things in his line of work). I told him earlier about a story from here about a major flaw in a city's usage of it. His *first* *response* was something along the lines of "what moron decided to plug that thing into a network in the first place?".

The systems were designed and are still designed to be fully isolated from intruders. The authentication is mostly there as an afterthought, to keep the site janitor or a secretary from logging in and seeing what happens when they push the big shiny buttons. The city in question most likely hadn't even changed the password from stock, as it was still three characters long.

Remote login shouldn't ever be permitted, because it shouldn't ever be necessary. A trained operator is always on-site, in many cases because a trained operator is legally required to be on-site 365 days a year.

Yeah, a lot of the blame should fall on the people making these - they should have wisened up to security requirements ten years ago. But part of the blame goes to the people who said "sure, let's plug this into the Internet! What could *possibly* go wrong?"

Re:These things were too successful.

[FooAtWFU]

While it is indeed laughable and sad that these unprepared devices were attached to the Internet, it is also worth highlighting that being detached from the Internet is not itself a pancaea. Stuxnet was able to damage Iranian uranium centrifuges without those centrifuges ever being attached to the Internet.

But yes, detaching them further is a very good plan.

Re:These things were too successful.

[teridon]

The security should be [...] an air gap enforced by a physical barrier [...] [but this is] regularly broken by people disregarding policy and carrying in USB memory sticks.

You admit the fatal flaw, but still think physical security is enough? Even when it appears that all it takes to defeat your "security" is one retarded, or corrupt, security guard?

You might as well cover your ears and scream "LA LA LA I CAN'T HEAR YOU". Obviously these PLCs need to be connected to a network of some kind to be useful. But even when that network is physically secure, those PLCs and their associated IT systems need to be secure against known attacks.

Re:These things were too successful.

[JWW]

Quick question. So you're saying that they need to secure the system from the guards so that they can't use it to open the cell doors? Wouldn't it be assumed that the guards already have the implicit capability to open the cell doors?

I love how security discussions almost always evolve into someone arguing that some particular actor in the system needs to be prevented from doing something that is actually part of their job!!

One more quote

[TubeSteak]

The wired.com article has this choice quote
http://www.wired.com/threatlevel/2012/01/scada-exploits/

"I didn't want a vendor to jump out in front of the announcement with a PR campaign to convince customers that it wasn't an issue they should be concerned with," Wightman said.

I can't imagine the type of two faced dickery it would take to spin weaponized exploits as something not to be concerned with.