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."
what's the worse that could happen? (Score:2)
no seriously, think about it.
Good news, everybody! (Score:3, Interesting)
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.
Re: (Score:1)
A silver lining, until it kills someone.
Re:Good news, everybody! (Score:5, Insightful)
As a matter of fact, I do know how severe the problem is - I work in this industry. Hence my comment about how PLCs should never be connected to the public internet. (It is a terrifying fact that internet scans have shown that, in fact, many PLCs *are* connected to the Internet. SCADA interface servers, too. My only hope is that those PLCs aren't controlling anything very sensitive. If I close my eyes and think happy thoughts, I can convince myself that they might just be telemetry data collectors with no field control capability...).
Anyway, I am personally disgusted by the attitudes of the PLC manufacturers to the security situation. Many of them seem to regard this as just an opportunity to sell upgrades to new hardware - which isn't even going to be on the market for months!
Let's look at what's actually changed as a result of adding these modules to Metasploit:
1) The PLCs are just as shitfully insecure as they were before
2) Exploitation of that crap security no longer requires the specialized knowledge and skillsets that it previously might have. It is now officially low-hanging fruit that any idiot can pluck. Script kiddies - and even most computer professionals - don't even know what ladder logic is. Now, they can erase the logic in a PLC - and still not even know what it is!
Maybe, _maybe_, a few highly publicised "incidents" enabled by point 2 will cause the manufacturers to make some progress on point 1. If that's the only way to improve the state of industrial communications security, I would call that an even more bleak and cynical "silver lining" than my original sarcastic comment.
In any case, you don't need Metasploit modules to know if a PLC with IP communications is insecure. Here is a simple process for detecting insecure IP PLCs on any network, based on Project Basecamp's presentation:
1) Is it a PLC, using hardware & firmware that is currently available on the market, with an IP based network interface?
2) Then it's insecure.
None of the vendors passed their tests.
Air-gapping the network, or at least ensuring that there are strong chokepoints isolating the control network from anything else, helps quite a bit. That won't stop the most motivated actors (Stuxnet proves that) but at least it will keep the script kiddies and automated exploiters out.
To be perfectly clear, I think Project Basecamp is doing the world a huge service in identifying the security problems with PLCs. I think that creating Metasploit modules is going one step further than what's helpful, though. The world needs to know about exploitable holes in SCADA & control security, but it doesn't need easy ways to exploit them. Why do a vandal's work for them?
Re: (Score:2, Funny)
There is a small ray of hope. With any luck, "Project Basecamp" will suffer some setbacks from "Project Campfire" - the project aimed at showing the vulnerability of most people's living arrangements to catching fire and burning down. Many of the goals seem the same, as well as the mindset of the teams. Perhaps they should merge.
Re: (Score:3, Insightful)
I'm sure you know this...and are aware of the vulnerability disclosure wars. The responsible disclosure debates.
Rainforestpuppy was one of the earliest authors of a responsible disclosure policy. Since then, many places have adopted their own policy --but the real caveat is unlike RFP's... theirs favor...them. Never the consumer.
Every vendor RDP gives the vendor all the time in the world to 'assess' a threat, label it 'high impact but low probability' because it's "complicated" to exploit, and give them
Re: (Score:2)
Hi Sapphire Wyvern -
I'm the research lead of the Project Basecamp team, so hi.
I did hem and haw about releasing exploit tools for the vulnerabilities, but the truth is that Digital Bond tried informing the vendors years and years ago about these vulnerabilities. Starting in 2001, DB simply told people about the problems. In 2006 DB started releasing Nessus checks to demonstrate that PLCs were vulnerable without releasing the exact 'how' to exploit them. Neither path worked...we heard from more lawyers th
Re:Good news, everybody! (Score:5, Insightful)
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.
It's a network issue, not a PLC problem. (Score:2)
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.
Re: (Score:2)
Re: (Score:1)
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.
I got this covered! (Score:2)
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.
571 without fixing a know secrity hole (Score:1)