Slashdot Mirror
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."
So you're saying closed source, only-validate-functionality, stale code has security holes?
I want to delete my account but Slashdot doesn't allow it.
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.
Sig Battery depleted. Reverting to safe mode.
Cool, sort of like having access to an industrial 3d printer. Tho picking up your finished products might be tough.
---- Booth was a patriot ----
lot of the stuff comes from a dos / win 3 / 9X mine set likely loaded with hacks and out stuff to keep them going so to get real security they may need to be rebuild from the ground up.
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.
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.
[Fuck Beta]
o0t!
We just got a great deal on some barely used USB sticks from Iran. Only plugged into their centrifuge controllers once.
Have gnu, will travel.
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).
Next we'll find out its not a good idea to have a POTS connection to the US War Operations Plan Response system
A lot of newer DCS gear is starting to have process firewalls being build in to the hardware at the controller layer. Also a change I've seen of late is that a lot of vendors software no longer runs ABSOLUTELY EVERYTHING at a privileged level as has been done in the past!!!
This should reduce the attacks on the PLC devices themselves, however the protection of the SCADA/DCS Servers (usually Windows Based) relies on GOOD system administration and knowledge about possible attack vectors..
Anything that straddles a corporate and process network NEEDS to be hardened, however more often than not this is the weak point (Process historians and other servers that provide end-user data are the biggest risk)
I've seen windows 2000 machines that are on both networks running 2000 SP1 and no later security patches THIS YEAR (Not a practice recommended by the vendor either, this was a customer who 'knew better').... lets also mention that it also had a VERY easy to guess Admin password!
Tis a scary world.
Most vendors have best practices for keeping nasties off the process networks, it's usually the customers who compromise to make their own life easier. Usually decisions made by the onsite IT people who, lets be honest, have NO idea about how/what a process system does. I work across many large sites and in general the IT people do not understand what is required and tend to be the ones who punch the massive holes in the firewalls to get things to work.
The vendors (I work for one) are now catching up by hardening things better at the hardware and software levels, but it's the legacy stuff that scares the bejeezus out of me!!!
Burma?
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
Choose your allies carefully, it is highly unlikely you will be held accountable for the actions of your enemies