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.

[Anonymous Coward]

Then there is Allen-Bradley with their Micro-VAX blade plugin to network and perform serious device control... The fact is, is that a lot of these devices ARE intended to be networked these days, but they are still built with a 70's and 80's non-networked mindset. My opinion, having written a LOT of software for integrating PLC's into complex manufacturing control systems for companies and organizations ranging from General Motors to Honeywell to Motorola to Rockwell to the US Navy, is that the best approach is to keep the controllers separate from the network systems, and use embedded PC's with I/O capabilities (PC-104 devices are very nice these days, running Linux or QNX) to trigger the PLC's when an external event warrants it, such as changing the recipe or route for some product.

Re:These things were too successful.

[guruevi]

On the other hand even if they were separated from the internet, they were intended to have some sorts of communication between a base (such as an office) and a remote station. I purchased a set of 33.6k programmable modems (Telindus Aster 5) once that were set up to dial in automatically into a specific location with passwords etc. pre-programmed. How easy do you think it would've been for anyone else to dial-in to those systems if they knew any of the details?

The matter of fact is that until the last 5 years none of these system makers thought about any security even though the techs in the field knew how their systems were going to be set up at the customer. I've worked with Siemens several times (both with their PLC side and their medical instruments side) and every single time I had to provide the additional security on my (or my clients) network even though it was never planned for, requested by them or even had come up in the negotiations when these things were purchased.

And to give you a reason why I think they should plan for it: Windows XP SP1 is what they not only use on their own systems but also set as a requirement for developers to use with their SDK's (together with some custom packages and Visual Studio 6).

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.

[deniable]

I used to work with PLCs driving mining equipment. We knew ten years ago that these things weren't secure and shouldn't be accessible. Thankfully, we just built the machines and plugged them into their network. Their security guys are probably on medication by now. They got over-ruled when middle management types 'needed' to have the office and plant networks hooked together for easy overview or stats reporting or whatever the excuse of the week was. (Giving them what they asked for in a secure fashion wasn't the point, they wanted the access.)

Re:These things were too successful.

[mysidia]

Worse it's easy to claim a product is secure when it is not

A product is not "secure" or "insecure"

A deployment where a product is used is secure or insecure.

A deployment of a product can be highly secure in its expected deployment scenario, but the deployment horribly insecure if you plug it into an outside network which contains unmanaged devices.

There may be flaws in a TCP stack (For example), that could be exploited if an unmanaged device were allowed to produce arbitrary communications, but the deployment can be secure when all devices are managed, and there is no operator console command to generate the invalid packet, without physical access to plug a laptop into the cordoned off network.

Re:These things were too successful.

[DarkOx]

Right security is about people. I agree not every single device needs to be hardened like a fort. I think this is actually a trap many security folks, especially geeks fall into. Its wrong because it ends up frustrating everyone else, and they start not cooperating, circumventing security controls and opening wide holes than existed in the first place.

The most important thing is that everyone understands what things are. If its well known that say some industrial control app is thin on input validation, does simple clear text unauthenticated communications with other devices, and has a configuration interface with a password dialog easily bypassed by rigging up a specific query string, all that might be okay. There might even be very solid reasons for it. It keeps the code base small, easily understood, might offer performance advantages on limited hardware, etc. Hardware hardened for industrial applications is often limited and expensive. You might ask why even bother with the login screen if its so easy to defeat, well its a lock for honest people, it might help oh This is Isle 3A bay 15, I am supposed to be making this change on 3B-15, oops sort of mistakes.

Clearly such devices are designed for use on closed networks, as long as everyone understands that there is no reason to make things harder for people. Its when usb sticks and laptops start getting plugged in, or someone connects it to a larger network you see problems. Manufactures need to be upfront about these things being designed for a specific ecosystem. "Yes it password protected, but its human interface feature not a security control..."

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!!

Completely Irresponible

[Anonymous Coward]

This series of zero-day public disclosures is an abhorrent act that violates most any professional or ethical code out there.

As these vulnerabilities impact devices which are known to be networked, as well as being in control of critical infrastructure, these "researchers" have at their disposal US-CERT/ICS-CERT, as well as direct contacts with the vendors in question.

They chose to turn this into a marketing stunt to sell tickets to their conference and to attempt to sell consulting services to the control systems industry. Luckily, I see this, and I will NEVER recommend that Rapid7, Dale Peterson, Digital Bond, Dillon Beresford, Jacob Kitchel, Tenable Network Security, or Ruben Santamarta be allowed near ANY critical systems.

These individuals have shown their true colors. The vendors WANT to play along, they WANT to increase security. Instead, these fools did a complete end-run around them and just dropped EXPLOIT CODE into the hands of everyone in the world. These "researchers" clearly do not care about the users of these systems, just the $$ they can milk out of the newly instilled fear.

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.

Awww!

[PPH]

We just got a great deal on some barely used USB sticks from Iran. Only plugged into their centrifuge controllers once.

Yes, keep it "offline"

[dinodriver]

I agree. I work for a water utility and making any changes to our system requires us to physically report to the locked, alarmed office and access (through password login) a scada computer terminal, or to report to the facility in question and log in there. I often wish I could at least access current complete "read only" system data on my phone or computer so that when I'm paged by the system and it reports that a fault has occurred (example could be as simple as "pump #1 failed to start") I could see how crucial it is for me to respond or if it's something that could wait till morning. But we so far have avoided the slippery slope of remote access and so I have to respond physically and access the situation. (and to avoid responding to less than crucial problems, we just set the system to only call out on serious issues and just log the others for review during business hours).

SCADA are not PLC's

[gnalre]

Ok, firstly SCADA and PLC's are two different things. SCADA is the HMI control system and PLC's are the parts that actually talk to the physical devices. While sometimes they are in the same box usually they are totally different devices. Secondly PLC's can be anything from windows PC's to low level simple processors. However they have one overriding concern and that is real time control of the plant hardware. This is why PLC's are hard to secure. Often they have not the power to run encryption algorithms required for security.

But they should not need to. Almost all of them are bespoke running closed simple OS, using proprietary languages. More importantly they should all isolated both behind physical security and network within a DMZ. That's not to say security cannot be improved, however these are not your PC's connected to the internet.

SCADA machines are more problematic Generally they are standard PC's running windows(Often quite an old version of windows). The very generic nature of the hardware and OS is its biggest weakness. As are their users. One of the problems we have encountered is viruses being stuck on PC's via USB sticks brought in from outside. We have even found games installed by bored users. So why not put antivirus software on them you may ask? Well the problem there is finding AV software which does not affect the operation of the SCADA software. Secondly is maintaining updates. To do that is either a manual process(not really feasible) or connect them to a central server or internet. This introduces an attack vector of its own.

STUXNET is always highlighted when these conversations come up, but this is misleading. If reports are to be be believed this was perpetrated by national agencies with all the resources that implies. No system is totally secure in that situation, the best you can hope for is to detect and delay. However most systems will never come under such a coordinated attack. Saying that it has concentrated the PLC industries mind on security, so thats not a bad thing, but we are no where near the Armageddon scenario that such articles seem to hint at