Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Security IT

Project Basecamp Adds Stuxnet-Like Attacks To Metasploit 17

Trailrunner7 writes "Project Basecamp, a volunteer effort to expose security holes in industrial control system software, unveiled new modules on Thursday to exploit holes in common programmable logic controllers (PLCs). The new exploits, which are being submitted to the Metasploit open platform, include one that carries out a Stuxnet-type attack on PLCs made by the firm Schneider Electric, according to information provided to Threatpost by Digital Bond, a private consulting firm that has sponsored the effort. It was the third major release from researchers working for Project Basecamp and included three new modules for the Metasploit platform that can exploit vulnerable PLCs used in critical infrastructure deployments. The exploits rely on a mix of software vulnerabilities and insecure 'features' of common PLCs, which serve a variety of purposes in industries as varied as power generation, water treatment, manufacturing and others."
This discussion has been archived. No new comments can be posted.

Project Basecamp Adds Stuxnet-Like Attacks To Metasploit

Comments Filter:
  • no seriously, think about it.

  • by sapphire wyvern ( 1153271 ) on Sunday April 08, 2012 @09:00AM (#39612137)

    Oh good. What the world really needs is for script kiddies to be able to knock industrial equipment offline without even learning anything about the equipment they're attacking.

    Well, maybe some incompetent fools who put PLCs on a publically-accessible network will learn a valuable lesson. I guess every cloud has a silver lining.

    • by nurb432 ( 527695 )

      A silver lining, until it kills someone.

    • by PlusFiveTroll ( 754249 ) on Sunday April 08, 2012 @09:48AM (#39612331) Homepage

      If I've pissed up enough to get equipment on the net that can be hacked, I prefer a script kiddie owning it rather then a 'hacker' with knowledge and patience. The script kid will tend to be impatient or plain dumb, such as flooding the machine with traffic or knocking it offline, in which a problem will be noticed pretty quickly. The patient hacker... you may never know he was in your machine until he's compromised the entire network. He'll hide or patch the original hack so others can't use it and it doesn't show up in a pen test done on the network.

      A script kiddie's like a flu, yea it can be deadly but you're running a fever and coughing so people see what's going wrong. A dedicated hacker is like HIV, by the time you notice it you likely have full blown AIDS and have spread it to all the partners around you.

  • With managers demanding global plant performance data in real time, it is vital to build security into the interface networks. The PLC's are just dumb relay-replacements in most cases. The challenge is in the SCADA/Distributed Controls architecture and getting IT guys who know nothing about automation to understand the limitations.

    • This is partially true. While the network should be separate, it only takes one computer with a USB cell modem connection to infect the PLC. Hell, it doesn't even need to be a live connection. A contractor with an infected laptop can infect the whole network when he plus in to diagnose the PLC. Bam, the PLC is modified for a future fail.
      • Perhaps I should have titled my post "It's a computer problem, etc.". Again, in your scenarios, it's a computer with a USB wireless device, or a contractor's laptop, not the PLC. Wireless PLC networking, when used at all, should be limted to discreet and analog I/O functions which under most hardware protocols are MAC address specific and pretty hard to spoof.

  • Our Schneider system is so ancient that we couldn't figure out how to connect a computer to it to even do maintenance let alone 0wn the system. Something about Modbus Plus and the laptop we were using not having an 8bit ISA slot.

  • We are going to need laws to punish manufacturers that just do not care about their security holes. While I am fully against making software writers responsible for bugs (nobody can program without introducing bugs), I think something should be done about vendor selling software well known for being insecure.

This is the theory that Jack built. This is the flaw that lay in the theory that Jack built. This is the palpable verbal haze that hid the flaw that lay in...

Working...