Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Security IT

Researchers Find Slew of Flaws In SCADA Hardware, Software 110

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."
This discussion has been archived. No new comments can be posted.

Researchers Find Slew of Flaws In SCADA Hardware, Software

Comments Filter:
  • by Gothmolly ( 148874 ) on Saturday January 21, 2012 @09:17PM (#38777773)

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

  • by icebike ( 68054 ) * on Saturday January 21, 2012 @09:22PM (#38777801)

    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 [ge-energy.com] 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.

  • by Anonymous Coward on Saturday January 21, 2012 @09:48PM (#38777947)

    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.

  • by gman003 ( 1693318 ) on Saturday January 21, 2012 @09:51PM (#38777959)

    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?"

  • One more quote (Score:4, Insightful)

    by TubeSteak ( 669689 ) on Saturday January 21, 2012 @10:36PM (#38778191) Journal

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

    "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.

  • by FooAtWFU ( 699187 ) on Saturday January 21, 2012 @11:10PM (#38778339) Homepage
    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.

  • Comment removed (Score:5, Insightful)

    by account_deleted ( 4530225 ) on Sunday January 22, 2012 @02:06AM (#38778933)
    Comment removed based on user account deletion
  • by teridon ( 139550 ) on Sunday January 22, 2012 @07:17AM (#38779889) Homepage

    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.

  • by JWW ( 79176 ) on Sunday January 22, 2012 @10:03AM (#38780557)

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

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...