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.
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.
Re: (Score:2)
Undetectable = does nothing (Score:2)
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
Re:Undetectable = does nothing (Score:5, Insightful)
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.
Re: (Score:2)
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.
May only want second order effects detected (Score:2)
> 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
hey, you got your computer in my PLC (Score:5, Insightful)
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.
Re:hey, you got your computer in my PLC (Score:4, Informative)
wrong-headed thinking by you. I'm talking unnecessary use of tech that gets us nothing in return. You are obviously someone who has never seen a machine that could have lasted decades was destroyed because a CPU module with 5-7 lifespan failed.
Re: (Score:2)
oh do tell with specific examples of manufacturer of PLC and vendor of gear it destroyed. I'd be particularly delighted if in the tool and die realm because ....reasons.
Re: (Score:2)
I'm talking unnecessary use of tech that gets us nothing in return.
The major source for this exploit is going to be remote update of PLC firmware/logic. By remote, I don't mean "internet" but simply physically remote. This does give you something from a plant operation point of view as it is simply one more task that's automated, and potentially a very expensive task due to the dollars per hour for the task in question. So the tech does get you something, at the increased cost of additional "risk". These risks should be mitigable (security into the network, security of th
Re: (Score:2)
I'm talking unnecessary use of tech that gets us nothing in return.
Do elaborate. What part of attaching a computer to a PLC has provided nothing in return? What part of the PLC magically breaks when the CPU in the computer dies?
I'm honestly curious because when I work with these things on a daily basis I often hear from people talking about some useless computers somewhere and yet they aren't able to fix their PLC problem which is why they call me. First place I go is the computer whose existence they question. Likewise over the years of supporting ancient shit I've yet to
Re: (Score:2)
So you've never, for example, seen a stamping press line destroy their robotic feeding arms? I'm interested what you'd make out of robot arms crushed to cardboard thickness. The shit I'm talking about happens, happens because of unnecessary use of embedded controllers when PCL did the job just fine for decades
Re: (Score:2)
Oh I've seen it. I also saw it many years ago with PLCs. And I also saw it before. What you're describing is hardware failure without interlocks protecting the equipment. That is poor design and coding and nothing to do with advances in controllers.
I'm also interested in what you think a PLC is and does, if not en "embedded computer". The modern way these systems hook up has necessitated a dramatic increase in processing power and system complexity. This has not been "unnecessary" and has not given "nothing
Re: (Score:2)
sure, a PLC is a type of computer by some definitions. I'm amused you think the situation could be "interlocked" though, ram of press weighing more than a locomotive with robotic arm *supposed* to be in die area as thing is coming down, narrowly missing the arm in proper operation. You're going to have the arm zoom away while holding blank? or dump the blank in wrong place? you'd make a bigger mess than the arm getting crushed.
Re: (Score:2)
You're describing one kind of interlock, one that is supposed to sit in the path of the energy. This would absolutely not work on large hydraulic machines, or machines which move with incredible force. However interlocks aren't all about stopping the moving, they are about removing energy.
One example of your die is to interlock the hydraulic fluid and have hydraulics lock the device in place. I've done the same thing with really large slide valves. They move with such force that a jammed valve can result in
Re: (Score:3)
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?
Re: (Score:1)
Re: (Score:2)
Lets be fair now. I worked with SCADA systems nearly 20 years ago - computer-interfaced PLCs are nothing new.
Re: (Score:2)
Re: (Score:1)
Because that stopped stuxnet dead in it's tracks. Driver signing only makes the task of getting them loaded slightly more complicated. (i.e. obtain someone's signing key)
Re: (Score:2)
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...
Re: (Score:1)
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.
not the hard part (Score:1)
Re: (Score:3)
Nonsense. I long ago developed non-detectible malware, but I can't prove it because you can't detect it.
Undetectable rootkit targets PLCs (Score:5, Interesting)
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.
Re: (Score:2)
Re: (Score:1)
Pick any two (Score:5, Interesting)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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.
Reboot persistence? (Score:2)
Real PLCs support signed firmware (Score:2)
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
This shouldn't be surprising (Score:4, Interesting)
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.
Act of war (Score:2)
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.
Bullshit (Score:2)
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.