Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Security Businesses Hardware

Researchers Create An Undetectable Rootkit That Targets Industrial Equipment (bleepingcomputer.com) 59

An anonymous reader quotes Bleeping Computer: "Two researchers presenting at the Black Hat Europe security conference in London revealed a method of infecting industrial equipment with an undetectable rootkit component that can wreak havoc and disrupt the normal operations of critical infrastructure all over the world. The attack targets PLCs (Programmable Logic Controllers), devices that sit between normal computers that run industrial monitoring software and the actual industrial equipment, such as motors, valves, sensors, breakers, alarms, and others."

Researchers say they packed their attack as a loadable kernel module [PDF], which makes it both undetectable and reboot persistent. The attack goes after PLC pin configurations, meaning the PLC won't be able to tell which are the actual input and output pins, allowing the attacker full-control to make up bogus sensor data, send fake commands, or block legitimate ones.

The researchers acknowledge that the attack is extremely complicated, but the article argues it would still be of interest to a state-sponsored actor.
This discussion has been archived. No new comments can be posted.

Researchers Create An Undetectable Rootkit That Targets Industrial Equipment

Comments Filter:
  • At some point, anyone bent on malicious programming _wants_ to be detected -- when the payload does whatever malice intended. Before then, it wants to hide. Loadable kernel modules are a good way to hide, but not perfect. It might be detected by network activity (gotta love those lights) or power consumption (machine not sleeping). Both AFAIK still major detection mechanisms for all intrustions.

    But LKM are a known security risk, and can be turned off in Linux. Easy with known hardware. At one time Ope

    • by neilo_1701D ( 2765337 ) on Sunday November 06, 2016 @10:59AM (#53223193)

      But LKM are a known security risk, and can be turned off in Linux.

      True... but the purchaser of (say) a CNC grinder or a motion control system or a 50 port temperature sensor or whatever other exotic industrial equipment you can dream up is NOT a Linux user. A good CNC operator will do things that makes your head spin but not have the faintest idea about network security. All they care about is plugging in the power and the network cable and uploading designs from Autocad.

      At some point, anyone bent on malicious programming _wants_ to be detected -- when the payload does whatever malice intended. Before then, it wants to hide. Loadable kernel modules are a good way to hide, but not perfect. It might be detected by network activity (gotta love those lights) or power consumption (machine not sleeping). Both AFAIK still major detection mechanisms for all intrustions.

      Industrial equipment is expected to run differently to a computer. The guys on the shop floor don't give a rats about clean shutdowns etc; they turn the power off. Your average shopfloor person sees the flashing lights on a PLC and doesn't understand what they see (unless it's an error condition they have been trained for).

      You raise valid points... but consider where industrial equipment runs, and who runs it.

      • You raise valid points... but consider where industrial equipment runs, and who runs it.

        I've considered it. If you're a small shop then you're also quite unlikely to be the target of this. If you're a big shop where these machines are utterly critical then you already have a dedicated team looking at it and maintaining it, separate from the team operating it.

    • > At some point, anyone bent on malicious programming _wants_ to be detected -- when the payload does whatever malice intended.

      Not at all. Espionage is a clear example. Surely the target will notice when their ship gets blown up, but you don't want them to know it was due to espionage, much less computer, and certainly you don't want them to know WHICH computers you have compromised.

      With industrial control specifically, you may want to make the final device fail, perhaps have an ICBM explode at launch

  • by iggymanz ( 596061 ) on Sunday November 06, 2016 @10:54AM (#53223167)

    Some of us are old enough to remember PLC that worked fine by themselves, not needing to be hooked to any other "computer". Maybe we need to start thinking about making things simpler again, where it makes sense, for reasons of security, robustness and even longer life of the equipment.

    • by PPH ( 736903 )

      not needing to be hooked to any other "computer"

      So how then you you propose to have the engineering department located in Bangalore update the PLC firmware?

      • Someone physically goes on location and does it manually. If you update machine software you better verify that it actually changes what and how you want to change anyway, getting undesired results from software update is not exactly a rarity, especially if you don't have an actual production machine to test the software on first. Normally you hire a team of local service guys anyway, traveling half a world away to update PLC or swap some minor part in the machine gets rather pricey.
    • Lets be fair now. I worked with SCADA systems nearly 20 years ago - computer-interfaced PLCs are nothing new.

      • Exactly. What is more new is updating the PLC remotely, IP based networking to PLCs, more standardisation of PLC operating systems, more network connectivity between SCADA networks and the outside world, and far more activity by state actors in industrial automation. At the end of the day, a PLC is a computer hooked up to a network card, connected to another computer running SCADA most likely on windows. There is a lot of security and obscurity that makes compromising these things hard, but there is an awfu
    • One of my clients has a C200H still running a bandsaw machine. It was made in 1990. Not connected to anything and still going strong.

      Storing comments and variable names in the CPU is a really good innovation though...

    • by Cramer ( 69040 )

      Unless they're programmed by paper tape, they will, at some point, be connected to some other computer -- directly (serial, ethernet) or indirectly (floppy, usb stick)

      Sure, 30 years ago one wrote their ladder-logic program on paper and keyed it into the PLC through a tiny keypad (that's only rarely attached to anything.) It was a major pain in the ass.

  • The difficulty of messing with industrial equipment is not how to mess with the software, but in how to get access to it in the first place. These days most newer machines don't actually have a physical PLC(unless you count safety plc that only handles the safety), instead they run a soft plc on a PC, generally side by side with windows using VT-x. Once you have access to such a machine messing with it is really not hard at all.
  • by khz6955 ( 4502517 ) on Sunday November 06, 2016 @11:24AM (#53223285)
    'Majid Hashemi [linkedin.com] : Avanade, a Microsoft / Accenture joint venture'

    From billg:
    To: mhashemi:
    Cc: a.abbasi:
    Msg: "Please write a report on Linux PLC malware so as to distract from the curent Microsoft Windows phishing/malware/virus infestation on the Internet."


    Is there any other kind of rootkit except the undetectable kind. It's interesting that in that entire document they managed to mention Raspberry Pi 13 times, Linux 5 times and Microsoft Windows not at all.
    • How many PLCs do you think run windows? Let me give you a hint; it's a round number. A very round number.
      • Huge number of PLC-s run on a windows machine, TwinCAT ftw! Best way to develop a machine by a long shot. If an industrial machine has a PC its a safe bet it runs windows, so all of them run windows.
  • Pick any two (Score:5, Interesting)

    by jenningsthecat ( 1525947 ) on Sunday November 06, 2016 @11:25AM (#53223289)

    This reminds of the old engineering saying "good, fast, cheap - pick any two". Only in this case it's "complex, configurable, secure - pick any two". If you want security then you either forego complexity, (so the device can't do a lot, plus all the combinations and permutations of its behaviour can be understood and determined in advance, plus its attack surface is correspondingly smaller), or you forego configurability, (meaning functionality is set in wires or DIP switches or ROM, not by software that can be altered).

    Such complex and versatile systems, (such as the Internet), simply can't be protected adequately, unless they're disconnected from the outside world and therefore lose most of their advantages. What comprises solid protection today, probably won't tomorrow. We need to find ways of mitigating damage and recovering quickly; we can't rely on thwarting malicious hacking, because that's simply not possible in the long term. This applies equally to crappy consumer grade IoT gear and hardened SCADA systems. Yes, a good SCADA system is, (or should be), harder to compromise; but usually the payoff is commensurately bigger.

    • by DrXym ( 126579 )
      All PLC / SCADA networks should be closed networks. The biggest danger is some doofus in the factory connecting a PC or router to the same network and inadvertantly exposing it to the world. In most other cases, security can be managed adequately with some locked cabinets. Most PLCs already reside inside locked cabinets to stop workers from pulling wires out on purpose or by accident.
    • by twdorris ( 29395 )

      Only in this case it's "complex, configurable, secure - pick any two".

      Hmmm. Ok. I'll take secure and configurable. Thanks.

      Not sure your attempt to rework an "old engineering saying" was entirely successful.

      I suspect your later use of the word "versatile" would have been a better choice here. "versatile, configurable, secure - pick any two". Yeah, that seems to work.

      • Hmmm. Ok. I'll take secure and configurable. Thanks.

        Not sure your attempt to rework an "old engineering saying" was entirely successful.

        I suspect your later use of the word "versatile" would have been a better choice here. "versatile, configurable, secure - pick any two". Yeah, that seems to work.

        Good point - thanks. I wasn't entirely satisfied when I wrote the comment, but didn't take the time to figure out why. Your wording expresses my meaning better than mine did.

  • How does the "persistent over reboots" part work? I haven't read the whole paper, but a search for "reboot" or related terms returns nothing.
  • They've found a cheap PLC they can exploit. Buy a decent PLC and you have a fair shot against something like this.

    I was a PLC monkey (still am) when Stuxnet was new. Shortly afterward I watched one of my Clients, an automation manufacturer with a fairly decent market share migrate their critical products to signed firmware. Controllers, ethernet bridges, and industrial switches to start with, but it continues--there's signed firmware options for more and more of the available products.

    You buy the product

  • by DrXym ( 126579 ) on Sunday November 06, 2016 @01:36PM (#53223875)
    PLCs are designed to run on closed networks and normally have no protection around their firmware. They're expected to be commissioned and forgotten about. Some PLCs will even boot their firmware straight from an SD card slot which can be modified to make the PLC do anything. They are not secure in any way, shape or form.

    Adding security could be done of course, and perhaps there are things to be done that should be. But for the majority of deployments total security adds complexity to protect against a threat which is extremely unlikely to ever happen. If you want to protect your PLCs from being tampered with, there is a far simpler solution - buy a big secure cabinet and a big padlock. If you're super paranoid, fill any firmware update slots with epoxy.

  • As the article mentions, this would likely need a nation state sponsor.
    This attack is unfocused. The attacker probably has no idea what the individual IO points mean or do.
    The attack would be only to destroy.
    That's an Act of War.

    You're next move Dr. Strangelove?

    I write industrial control software. Most of my customers don't have their process control computers accessible, except as needed. As for IO points, at least with what I work on, each system is unique.
  • Of course this is detectable. If it is loaded into the PLC persistently, then you can find it via a JTAG read and compare. If not, you can detect it during load.

Basic is a high level languish. APL is a high level anguish.

Working...