Hacking Construction Cranes

Construction cranes are vulnerable to hacking:

In our research and vulnerability discoveries, we found that weaknesses in the controllers can be (easily) taken advantage of to move full-sized machines such as cranes used in construction sites and factories. In the different attack classes that we’ve outlined, we were able to perform the attacks quickly and even switch on the controlled machine despite an operator’s having issued an emergency stop (e-stop).

The core of the problem lies in how, instead of depending on wireless, standard technologies, these industrial remote controllers rely on proprietary RF protocols, which are decades old and are primarily focused on safety at the expense of security. It wasn’t until the arrival of Industry 4.0, as well as the continuing adoption of the industrial internet of things (IIoT), that industries began to acknowledge the pressing need for security.

News article. Report.

Tags: hacking, Internet of Things, reports, vulnerabilities

Posted on January 22, 2019 at 5:59 AM • 19 Comments

Comments

wiredog • January 22, 2019 6:35 AM

“primarily focused on safety at the expense of security.”
Yes, well, when a safety failure can kill people it damn well better be the primary focus. Now since a security failure can lead to a safety failure, security needs to be considered in that light.

My first job out of college, a few decades ago, was in industrial automation. For our gear the e-stop circuit actually dropped power to the machine. To override the e-stop you had to insert a key into a switch and the software then limited what the machine could do. Or, rather, many software operations were locked out if the override was enabled. Security was ensured by not networking the machine. Remote diagnosis required someone at the shop to go out an physically plug the network cable in. No RF was used because we didn’t trust it to be as reliable as a wired connection.

Will North • January 22, 2019 6:37 AM

I referenced your new book (accurately, I hope) in a comment piece on this hack for our B2B crane magazine. It’s a topic I aim to return to.

Modern cranes have wireless and wired connections between sensors (like cameras and anemometers, wind speed measuring devices), and on to the net for telematics and remote diagnostics. There might be other vulnerabilities there.

Dave • January 22, 2019 7:14 AM

It wasn’t until the arrival of Industry 4.0

Ah, and this is the problem, they’re still running Industry 4.0, when the recommended baseline version is at least Industry 5.7, and preferably Industry 5.9 or newer, with hotfixes PL3731 and PL4023 applied.

Petre Peter • January 22, 2019 7:55 AM

This MITM would be useless if the protocols were encrypted.

TimH • January 22, 2019 8:51 AM

Echoing wiredog, if a manual (at or by the equipment, by the equipment operator or plant supervisor) estop can be overriden by anything remote… then it’s not an estop in terms of health and safety.

Putting it another way, emergency controls to disable an equipment for safety can be ORed, but restarts must be ANDed. So everyone has to agree before a restart.

Clive Robinson • January 22, 2019 8:59 AM

It’s easy with hindsight to say,

these industrial remote controllers rely on proprietary RF protocols, which are decades old and are primarily focused on safety at the expense of security.

But forget a few things, such as why the Internet protocols were likewise so insecure back at the same time…

The world was 8bit or less in the microprocessor world thirty to fourty years ago. Frequently runing at 1MHz or so clock frequencies with maybe 4-8K of ROM and as little as 256bytes of RAM and 2400/75baud audio modems.

I designed one of the first 16bit Intrinsically Safe telemetry systems and there were all sorts of additional constraints that had to be added to the design, which further reduced what you had available back then.

Few realise that remote control units for cranes, trains and other equipment realy should be designed to be Intrinsically Safe (ExI). Put simply anywhere where there is a “no smoking” or flamable vapour / explosive dust warning should never ever have non intrinsically safe equipment in use (unless it’s ExD but then we are talking cast iron cases in the 25kg and up range, which is not exactly practical for a remote user).

Just trying to design a “Safe” system back last century was difficult enough due to the lack of resources. For instance most kit back then used hand written assembler which had been squeezed harder than an orange in a breakfast juicer.

Not only were block encryption primatives not feasable (DES-ECB) due to the large amount of ROM required, none of todays standard encryption primatives and modes had been put together more than DES-CBC. Some security was tried with Self Sychronizing Stream Ciphers, but they usually needed a big chunk of RAM for Sarray storage, thus were not at all secure.

But even if the ROM and RAM was available, there was another issue to consider, the CPU was not up to handeling encryption let alone hashes in anything less than a second or so, this was way to much latency for any mechanical device to be safe with.

Not many people have experience with Hard Real Time Systems but you want latency sub 50mS, thus with the very limited communications bandwidth even 2400baud serial data rates were such that only 10 char control strings were possible, adding checksums or Forward Error Correction (FEC) which was considered essential set this back to little more than three char commands of which one or two were variables ment things were very very limited in what could be done within the resource limmitations of the time.

It was not as though engineers had not thought about security, they had and it realy was not practical at all back then to do it

Sok Puppette • January 22, 2019 9:22 AM

It was not as though engineers had not thought about security, they had and it realy was not practical at all back then to do it

Here’s a practical security measure: use a damned wire.

MikeA • January 22, 2019 10:05 AM

Not exactly “industrial”, but I remember how computer mag-tape drives had a physical switch actuated by the “write ring” to control power to the write-amps. Later 8-inch floppies likewise fairly directly controlled the write power based on a notch in the jacket. Then 5.25-inch floppies inverted the sense of the notch, so it was “writable by default or if the little gummed ‘protect’ tab fell off”, and instead of controlling write power, the “write protect” was on at least some systems just another signal to “suggest” that the software might not want to write on this disk.

But more on e-stop. Cable cars (as seen in San Francisco, although no longer really part of the transit system as they were as late as the 1960s), have (had?) an interesting emergency brake. Actuating it via a lever at the operator’s position drives a steel wedge into the slot in the steel covering (split rail?) of the cable trench. De-actuating it involves a cutting torch and replacement of a section of trench cover. Try getting around that via WiFi.

Bob Paddock • January 22, 2019 11:40 AM

NIST invites comments on Draft NISTIR 8196, Security Analysis of First Responder Mobile and Wearable Devices, which reviews the current and potential use cases of these mobile and wearable devices by ﬁrst responders and analyzes them from a cybersecurity perspective. The goals of this analysis are to assist jurisdictions with selecting secure devices by identifying security objectives, and to enable industry to design and produce more secure public safety devices.

A public comment period for this document was open until January 7, 2019.
Publication Details:
https://csrc.nist.gov/publications/detail/nistir/8196/draft

CSRC Update:
https://csrc.nist.gov/news/2018/nist-releases-draft-nistir-8196-for-comment

Bob Paddock • January 22, 2019 12:01 PM

@Clive Robinson

“… The world was 8bit or less in the microprocessor world thirty to fourty years ago. Frequently running at 1MHz or so clock frequencies … Intrinsically Safe …”

The part you did not mention, easy to overlook, that most people fail to get is the limited amount of power available in an Intrinsically Safe system.

Currents and voltages are restricted by gas ignition curves. The Paper Pushers dictate how much current your widget can take, at a voltage usually well under ten volts (UL913/MSHA). This gives restrictions that Desktop PC people pushing mega-power encryption don’t have to deal with and never consider.

Let’s say we are designing a defibrillator, obviously battery powered, and need to run for at least ten years. We want to be able to query its status once a day and perhaps modify its settings once a year at an annual Checkup. Our clock frequency is restricted to 96 MHz in a burst mode during the query, with a normal clock frequency well below 100 kHz at most. Total system Flash is limited to 256K and RAM is limited to 32K. The RF portion of the device is LoRA based so could be queried and controlled for say 1km.

What encryption can we run on the device within those constraints, that would keep out bad actors long enough that their actions would have to be noticable (knowing that absolute security is impossible within these constraints)?

This encryption must also be good enough to satisfy those demanding encryption without understanding the constraints.

Can we get there with any encryption methods we have today?

johnR • January 22, 2019 12:44 PM

@Sok Puppette: “Here’s a practical security measure: use a damned wire.”

Wires are kind of difficult on a tall crane where the operator has to be on the ground or close to the work.

Weather • January 22, 2019 12:53 PM

Bob
Some Pic micros have hardware Aes and Sha, they wouldn’t be a drop in replacement, but new design can implemented them.

Sok Puppette • January 22, 2019 12:57 PM

What encryption can we run on the *device* within those constraints, that would keep out bad actors long enough that their actions would have to be noticable (knowing that absolute security is impossible within these constraints)?

You don’t necessarily have to encrypt anything; you need to authenticate things. And you don’t say how long your 96MHz bursts are or what kind of processor you have.

You’re throwing out arbitrary flash and RAM limits like they’re handed down from God. The power budget may be fixed (and may even limit the RAM). The silicon budget is NOT fixed. Your unwillingness to pay another buck for more chip area isn’t persuasive.

In fact, even if you have to add dedicated hardware to keep the crypto energy costs down, then tough. It’s not like your human-safety-critical, intrinsically safe defibrillator for obscure industrial environments costs anything south of $10,000 anyhow.

Shared-secret authentication on a message can easily be achieved with maybe 2 or 3 SHA hashes and a couple of thousand instructions around them (probably with only one hash a lot of the time actually). The Bitcoin miners are apparently getting about a billion hashes for about 1/8 of a joule of energy these days. Assuming you are 1/100 as energy efficient as they are, and that you’re being profligate and doing 4 hashes per message, the crypto will to authenticate a message (or to prepare one for authentication by a recipient) will cost you about 0.5 x 10^-8 joules, or 5.5 x 10^-8 mWh.

Shared secrets are a pain to use, though, and tend to force you to have less security in the surrounding protocol. You asked to “satisfy those demanding encryption”, so you’d really want public key. According to this, on 2011 X86 hardware, an ECDSA operation would have cost you about 30 mJ (or roughly 8 x 10^-3 mWh). On more efficient hardware I suspect it would be under one mJ. But say it’s 30. You have to do it twice to authenticate messages in both directions (although you might be able to avoid that). So it’s really 60 mJ or 1.6 x 10^-2 mWh per query.

You’re doing that once a day for 10 years. Round up to say you’re doing it 4000 times, so the lifetime energy cost of this CADILLAC VERSION, under UNFAVORABLE ASSUMPTIONS, is 67 mWh. If you really have to do it the cheap way with shared secrets, then it’s 4.4 x 10^-4 MWh. Lifetime.

Actually your biggest problem here is that something could run down your battery by sending you a bunch of bogus queries, which you have to authenticate. You’d have to rate limit them or have the device initiate the process or something.

OR you could just not put the damned thing on a wireless network.

Sok Puppette • January 22, 2019 1:07 PM

Wires are kind of difficult on a tall crane where the operator has to be on the ground or close to the work.

Are you saying your average large crane does NOT already have a wiring harness that goes all the way from the ground to the tippy top? That would really surprise me.

Whatever part of the crane you’re communicating with is already getting its power from somewhere. I can’t see wanting to change the two AA batteries for the anemometer 3/4 of the way along the upper boom very often. And if what you’re communicating with is the part that’s moving the crane around, it’s probably pretty low down on the crane anyway, and has to be connected (by wires) to some big motors.

Tatütata • January 22, 2019 1:43 PM

This is at least the second post on the subject. I can’t see anything special or original in the resource which is linked to today.

We found that controllers that use RF are susceptible to command spoofing, where an attacker within range can capture radio traffic, selectively modify the packets, and automatically craft arbitrary commands.

Wow! What an insight! I wonder where these people have been sleeping all that time.

Next: a paper on the dangers of the lack of authentication in TV remote controls. Someone could change from the street through the window the channel you’re watching to something embarrassing, or turn on your set in the middle of the night.

Tony H. • January 22, 2019 4:19 PM

Dropping power upon detecting an emergency or safety issue is not always the right thing to do. Obvious when you think of a car or airplane, but I’m sure also for a crane in many cases.

A few months ago I was watching from my office window while large pieces of glass were being installed for a skylight. I brought binoculars in to watch. Crane with a swappable end unit with suction cups that picks up the pane and swings it from ground level storage up to a third storey rooftop frame, and drops it right in at the right angle. Fractional inch accuracy – cool! The suction cups are run by a vacuum pump unit right on the end effector, which has a wired remote that seems to control both the vacuum and the fine positioning.

Some neat pictures at http://www.explore1.ca (No spam, I have nothing to do with them – it’s the company that was doing the work I was watching.)

Dropping power on the pump because of a crane problem would presumably lead to an eventual and probably hard to predict release of the glass. Sure – battery backup, not run off the same power supply as the crane, etc. etc. But still…

johnR • January 22, 2019 4:25 PM

@ Sok Puppette: “Are you saying your average large crane does NOT already have a wiring harness that goes all the way from the ground to the tippy top?”

No. I’m saying that a crane operator may have to stand in a place where a wire link between a handheld control unit and the rest of the crane is impractical, in order to see what’s happening. Obviously the crane itself has wiring.

Clive Robinson • January 23, 2019 5:13 AM

@ johnR, Sok Puppette,

Obviously the crane itself has wiring.

Not as much as you might think. Large cranes are usually designed turn either at the bottom or the top.

It’s also nice to get continuous turning for various reasons, which means “slip rings” or their equivalent… Which are not exactly the most reliable of things, so you don’t want them in signal lines if you can avoid it.

FS Engineer • January 23, 2019 9:24 AM

It wasn’t until the arrival of Industry 4.0, as well as the continuing adoption of the industrial internet of things (IIoT), that industries began to acknowledge the pressing need for security.

There’s your problem right there – you exposed the controller for your 100-ton crane to the internet in the first place. The internet is inherently hostile. This is like leaving a loaded gun on the kitchen table in a daycare, and saying “it’s OK, the safety’s on.”

We need to stop defaulting to connecting everything, even when we think we’ve got the latest security patches on. If your C-suite wants real-time metrics on the device level, they can still have that with a gateway reporting device that can only request metrics from the devices inside the work cell, without any command and control abilities. That way, even if the reporting device gets taken over, it can’t make your hardware go terminator.

Hacking Construction Cranes

Comments

Leave a comment Cancel reply