Yes, you can remotely hack factory, building site cranes. Wait, what? Did you know that the manufacturing and construction industries use radio-frequency remote controllers to operate cranes, drilling rigs, and other heavy machinery? Doesn't matter: they're alarmingly vulnerable to being hacked, according to Trend Micro. Available attack vectors for mischief-makers include the ability to inject …
The radio control handsets are (relatively) secure and "offline"
When they have a port into the remote control handset and you use that to "remote control" the "remote control" from some PC on a wireless network .....
Brain rotting disease known as Realtime Embedditis.
Try explaining Postel's principle to an embedded controller engineer. At best he will listen and chuckle. Usually he will just ignore you and continue to write code which has absolutely no input validation and will fall over the first time something wrong happens. It will, however, be faster by 20 clock cycles and smaller by 10 bytes. That is essential, because if it is not the lamb will break the seventh seal and the world will end.
Ditto for DIY encryption. Nearly all uses I have seen were the result of "this will be faster and smaller than this very complicated reference implementation of a standard encryption scheme".
Certain manufacturers use IR on their controllers for the simple reason that if the operator doesn't have line of sight to the machine it should stop dead and do nothing.
Not impossible to muck about with, but a damn sight harder than broadcast RF in much the same way as the Navy still use signal lamps (as Mr Corfield found on his recent exploits up north) - Point-to-Point/tight-beam, difficult to intercept and easy to encrypt. More people should be using it. Or embedding decent security in their products!
It's hard to make some of these things fail "safe"
A lot of equipment gets damaged/causes risk if stopped suddenly so having a system slam on the emergency brakes because a controller loses line-of-site for a second while the operator scratches their nose - might not be the safest option.
But you also don't want to use 2-factor authentication and enter a 16 digit password for an emergency stop.
A lot of equipment gets damaged/causes risk if stopped suddenly so having a system slam on the emergency brakes because a controller loses line-of-site for a second while the operator scratches their nose - might not be the safest option.
True, but it doesn't need to "slam on the emergency brakes".
It's entirely possible to design for a graceful halt and fall back to a pause/standby position. It's probably a good idea for this sort of thing not to be trundling around without operator eyes-on.
Exactly. And, in the environments where it DOES matter, such security is implemented... usually at cost.
A F-35 or F-15 or Gripen, or any modern fighter with sensor fusion for that matter, MUST adhere to HEAVY encryption, if they don't want to deliberately expose all of their assets to a snooping enemy.
Quote
Though you would hope that the controller itself would prevent some of the dangers as part of its functional safety management.
-
Speaking from the industrial robot side of things, its not that easy to program a safe working envelope into something like that.
I might put a vice or a fixture up measuring 400mm by 300mm by 200 mm tall, I'd then have to go into the machine setup and program the correct parameters up, then the next part is a different size, or placed on the machine 50 mm from where it was before....... scale that up to a building site and the crane would need to know where the brick pallets have been stacked, then hope that whoever delivers the next batch of bricks lands the pallet in the same spot.. because the machines dont know and dont care theres 1/2 a ton of material in the way......
And humans are very squishy
>Though you would hope that the controller itself would prevent some of the dangers as part of its functional safety management.
How would the controller know that moving the load N instead of E would put it through the window of the bosses car?
The cranes have load sensors and load/angle/extent limits but they don't generally have a map of allowed traverse space - in the way an industrial robot would. Imagine a building site where you had to redefine the safety envelope everytime a delivery arrived or a new wall was built
---
How would the controller know that moving the load N instead of E would put it through the window of the bosses car?
---
How about N vs S? Your comment pushed me over the "should I bother to post?" edge, as the article had tickled an old memory about a not-exactly-security issue with a traveling crane. I probably read it on comp.risks, which means "before 2001" when I went cold-turkey.
Anyway, some repair of said crane had resulted in the phases being connected incorrectly. It powered up OK, stopped. Then the repair guy commanded a small movement one direction, but due to the reversed phases, the result was in a small movement the other direction, which the control loop "corrected", leading quickly to full power the opposite of the correct direction. The stop blocks at the (actual, not anticipated) end of the track were not able to halt the mass of the crane traveling at full speed, and it crashed through the wall and landed on a vehicle parked outside. There was speculation at the time whether that vehicle was owned by the electrician who had done the erroneous wiring. Poetic, but unconfirmed.
'Though you would hope that the controller itself would prevent some of the dangers as part of its functional safety management.'
They do, though you wouldn't know that if you just accept the so called report at face value. I do wonder what purpose 'reports' such as this hope to achieve other than FUD.
It would be interesting to know what the report author is offering by way of mitigation, what are they charging or how are they 'monetising' the results of their 'analysis'. To my knowledge they are not in the business of producing the equipment so are not pushing a particular product. Perhaps they are just somehow cashing in on the ignorance of people without the technical knowledge to make a rational risk assessment of this particular 'vulnerability' ( if I could reduce the font to sufficiently emphasise my assessment, you would barely make it out!).
By far, the biggest risk with equipment such as this is 'operator error' and it always will be.
Sadly, operator assessment and training funds may be disproportionately redirected to resolve this non issue. The cynic in me thinks the motivation is just the search for the next Millennium Bug and the business opportunities it created.
Christ, I watched five full minutes of the ConExpo 2017 show before I realised doing my job is less boring. I mean, I can appreciate the expertise of the people operating the machines, but I've had more exciting experiences examining the contents of my own navel.
Christ, I watched five full minutes of the ConExpo 2017 show before I realised doing my job is less boring
Yeah, to be fair that wasn't their best.
The 2012 Intermat show was quite entertaining - they had a troupe of parkour types and proceeded to break more or less every rule of the HSE handbook for working with machinery, working at height, with the runners climbing across the machines whilst operating. Not that the video does justice to watching it from the front - it's a bit chopped up.
They can only drive around in circles so many times before you've seen every angle of the machines.
All this "stuff" was bid to be built "on the cheap" with inadequate security criteria, then awarded to the lowest bidder. It's clear to see that the engineering and construction companies have been remiss in exploiting new technology in a responsible way and, probably clinging to a mantra of all government regulation being bad regulation, failed to exercise due care themselves - demonstrating once again, that leaving regulation of highly technical matters to market forces alone is folly for all.
No mining/off-shore stuff built to insanely high standards and costs a fortune.
But the standards were created decades agoand are for physical ruggedness, waterproofing, electrical safety, explosion proof, EMC emissions, reliability - not for being hacked by North Korean Cyber Ninjas.
It doesn't really matter where the driver is, if the guy handling the coupling doesn't have direct control over the motion (in terms of safety). 1/2 mile or 12 feet is enough to make squishy things get squished.
Remote control of cranes, etc has been a great boost to safety because it puts the operator at the point where the dangerous bit is. If the security of said systems isn't up to snuff and there's a safety risk due to compromise then it's time for HSE involvement - and you KNOW that things will get fixed fast if there's a sniff of regulations forcing the units to be sidelined until they are.
The companies that make these aren't thinking about security - they would not have seen any reason to encrypt/sign packets in their protocol. They would only care about interference to the extent that it could result in a 'misheard' command. If they address DoS at all, they would make the protocol have to keep repeating movement (go right for 1m, go right for 1m, go right for 1m) rather than have a "go right" command that keeps going right until a "stop" command is issued.
The good news is that the control units would be a tiny fraction of the cost of the whole crane, so it should be relatively easy to retrofit a much more secure controller. The question is: who is going to pay for it?
Is this view based on direct knowledge or as it reads, just supposition?
I have direct knowledge of one current manufacturers approach, which in a nutshell, is highly proprietary protocol with a specific frequency / ID code combination individually configured between Transmitter and Receiver, low power so that effective range is no more than a few tens of meters ( close proximity line of sight) and default action is DO NOTHING unless a specific valid command is received in every decoded packet.
This appears to address your points, is already widely installed and has been for a couple of decades.
This is the norm for all industrial crane control handsets. Some of the encryption might be a bit naive IF you were close enough to sniff the packets - which would generally mean on site.
The problem detailed in the report is that some of these remote handsets had external ports (for testing/updates etc) and people were connecting these to networked PCs to allow more remote control or easier updates - these extra links weren't secured.
Conventionally, assessment of risk is
Likelihood X Potential Harm equals Risk
Potential Harm doesn't change only the likelihood can be changed in risk reduction.
Yes, the scenario you describe could result in the crane moving. But what is the likelihood of a miscreant being in the right place with the right gear and the motivation to do it? By most measures there are far more probable risks to spend time and effort resolving than this, such as someone breaking in and stealing a transmitter. I would argue that has a higher likelihood therefore you put your resources here rather than to an extremely low probability event. I would put your scenario at the same probability as a 'welded' control contactor or relay and they are at a level of acceptable risk.
At some point you have to set acceptable risk or you would never do anything.
I'm confused about the article's distinction between overhead cranes used inside warehouses and factories, such as the one pictured in the article, which are operated by remote, and the "building site" (e.g. mobile or tower) cranes mentioned in the headline, which usually contain human operators.
Site cranes are moving to putting the operator on the ground too.
The reason being that it should be much safer if they don't have to make that climb several times a day.
Aside from that, they've always been remote controlled by a guy with a walkie talkie because you can't see what the load is doing from the cab.
I was quite surprised to find that many kinds of building equipment use identically keyed locks on their starters so the builders don't have to carry around multiple keys. After that, this little revelation is not surprising at all.
Cranes used for materials handling have other safety systems besides software. They have to, because having a crane suddenly drop stuff isn't a desired outcome. So entertaining as it may be to speculate, speculation should take into effect the mechanical controls and also the (usually) ladder logic controls built into limit the cranes being used unsafely or becoming unsafe as a consequence of mechanical, electrical or electronic failure.
I'm not daft enough to say "never", but do bear in mind that safety controls are overlapping and it takes a cascade of failure rather than a single event. Yes, I know cascades happen but the guiding principle is ALARP, not "never fail under any circumstances".
This isn't hysteria at all. Say you, a construction company, wished to gain a better market share. Given that your methods would be as near optimal as makes no difference, your only options are to shave margins, cost-cut or perhaps inflict some reputational damage on your competitors. However, casual website defacement will only go so far, so how's about messing about with their heavy plant remotely?
The thing is, you do not actually have to do very much to a remote-operated crane to make operating it dangerous to the point of site Health & Safety shutting everything down pending investigations. Listening to the chatter from operator to crane then replaying segments back at the crane would do, if the systems are as insecure as this article suggests.
Brief replays would make the crane overshoot targets and bang into things, behaviour that seriously upsets people where heavy weights are concerned. Five minutes messing with a crane remotely and site H & S shuts everything down to investigate. The attacker waits a day or two, then repeats at random intervals. With a parabolic antenna they don't even need to be very close to the target; half a kilometre or so would do.
All of these shennanigans push the project over time. Builders who overrun don't get repeat business.
'Listening to the chatter from operator to crane then replaying segments back at the crane would do'
So an operator is driving the crane in (it's reasonable to assume) a normal, safe and orderly manner.
These safe and orderly command sequences are recorded.
Then you make 'brief replays of sections' of his previously safe and orderly operation which would suddenly make the crane overshoot and bang into things? Quite possibly without a suspended load at this time because his task was finished.
Nah, not convinced by your flight of fantasy because it fails even a cursory level of scrutiny.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
