Slashdot Mirror

← Back to Stories (view on slashdot.org)

Project Basecamp Adds Stuxnet-Like Attacks To Metasploit

Posted by timothy on from the for-good-measure dept.

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

17 comments

  1. what's the worse that could happen? by Gravis+Zero · · Score: 2

    no seriously, think about it.

    --
    Anons need not reply. Questions end with a question mark.
  2. Good news, everybody! by sapphire+wyvern · · Score: 2, 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.

    1. Re:Good news, everybody! by nurb432 · · Score: 0

      A silver lining, until it kills someone.

      --
      ---- Booth was a patriot ----
    2. Re:Good news, everybody! by PlusFiveTroll · · Score: 4, 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.

    3. Re:Good news, everybody! by sapphire+wyvern · · 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?

    4. Re:Good news, everybody! by cold+fjord · · Score: 1, 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.

      --
      much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
    5. Re:Good news, everybody! by Anonymous Coward · · 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 months or years to sit on it.

      In the meantime, much like a post further down--intelligence agencies and your proverbial "good" hackers are milking them to death. And you virtually never hear about it because the companies don't want to look. Because that industry isn't required to notify. Because if they do, they aren't particularly required to tell the truth when they spin it.

      Producing this as a tool, or "weaponizing" it forces the hand of the software vendor and their customers. Over a decade ago I listened to an advisor to the president tell a room with a thousand people that these hacks would never happen because they were too complicated. He *knew* at the time of attacks that happened, but his analysis was that because they were all insider jobs, it was a social threat and not a technical one. He was utterly wrong even back then, but those outsider-hacks almost never made the light of day--only two or three even made for archetypical stories (and one of those was even in the 80's)

      I just want to point out--it isn't as simple as your claim of doing the vandal's work for them. Yes, they've just made it easier for everyone to hit your network, and the networks I once worked on.

      Tough shit. Your community fluoridation centers are protected by barred windows or no windows, steel doors and two locks. They are protected by processes, checklists, multiple trained individuals according to your state or local standards.

      This software is routinely not even protected by a password. And there's really two possible reasons why:

      1) You lied to management and advised them this was not a risk because you thought you were an expert. You were an incompetent, dishonest, or unethical engineer. I'm going to assume this didn't happen in your case.

      2) Management did a cost-analysis on advise to secure the system and concluded that such security was not salable, or would not produce a return from their customers.

      In the process, all of the SCADA vendors and installers have negligently and with malfeasance exposed their communities to potentially lethal risk. Regardless of the industry.

      Now--to a certain extent, that happens every single day with carefully controlled probabilities. The chance of every safety failing, and failing open is for nearly all reasonable purposes... 0. Process engineers are good at handling this.

      Until you hook up a computer to the internet and actively expose it to every malicious party in the world.

      Now, often times the computer can be overridden by other local systems that will not permit a potentially hazardous condition. They may require local lockouts, overrides, disconnecting things to stage certain tests... But in the glorious modern era -- all of this is networked by master controllers.

      You can say it was unethical to produce these softwares. But the responsibility of accepting the risks of these is yours alone. Even if they did not exist when you engineered the system -- you should have anticipated the threat. After all, people have been warned about it for nearly 20 years now.

      But enjoy those 20 years of shareholder value, cost savings etc. Because the first corp to publicly fall to this is probably going to get consumed by the invisible-hand and have their resources divested even faster than congress can have them indicted.

    6. Re:Good news, everybody! by Anonymous Coward · · Score: 0

      If you noticed because the script kiddie's dumbness caused raw sewage to enter the rivers, or some gas plant to go bang, you're not really going to care that it was a script kiddie vs some patient dude hanging out doing nothing. Something bad happened.

    7. Re:Good news, everybody! by Anonymous Coward · · Score: 0

      Either way. The operators that are standing next to it can be killed when the aforemention scriptkiddie moves the heads together and they explode, throwing shrapnel everywhere. Of course the kiddie never sees this result and doesnt know about the new widows and orphans he just created.

    8. Re:Good news, everybody! by giminy · · Score: 1

      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 than engineers. Now that we're releasing exploit tools and causing bad days for the vendors and (unfortunately) end users, vendors are starting to come around and listen.

      It stinks, but that's what has been required. Some vendors are taking the issues seriously, others are not. The ones that aren't are going to see a lot more pressure from us, I think...

      Reid

      --
      The Right Reverend K. Reid Wightman,
  3. It's a network issue, not a PLC problem. by some+old+guy · · 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.

    --
    Scruting the inscrutable for over 50 years.
    1. Re:It's a network issue, not a PLC problem. by IDreamInCode · · Score: 2

      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.

    2. Re:It's a network issue, not a PLC problem. by some+old+guy · · 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.

      --
      Scruting the inscrutable for over 50 years.
    3. Re:It's a network issue, not a PLC problem. by Anonymous Coward · · Score: 0

      Also - If the guy plugs his computer in to work on a PLC, the virus can only affect the PLC while his computer is connected to the control network. If the guy is a tech - I can promise you that he will know immediately that his PLC is not functioning and dump the original program back in. The security problem is easily remedied by isolating the control network and keeping all PC's off of it. Then make sure to control your remote access through a VPN endpoint and life is good.

      If you've got an engineer worth his salt, he won't put any PC traffic on his control network - EVER - The last thing you want is someones youtube addiction bringing down your network. Besides, there as so many easier ways to bring down a manufacturing plant on an ethernet control network... just take any patch cable and plug both ends into the same switch - presto, instant packet storm and non-functioning plant. If you use your head when designing the PLC control network, there is no need for a password protected PLC.

  4. I got this covered! by thegarbz · · Score: 1

    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.

  5. 571 without fixing a know secrity hole by manu0601 · · Score: 1

    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.