Radio Killed the Radio Stars: Security Analysis of RF Protocols for Industrial Applications
Published on: January 16, 2019
TL;DR: After having analyzed the several RF protocols for industrial applications, distributed by global vendors, we discovered that none of them had sufficient security features to prevent an attacker from hijacking the communication and manoeuvre the controlled connected machines.
In Summer 2016 the condo we live in went through some renovation work. We had construction workers here for the about half a year. This was around the time when I was getting into software-defined radio (SDR) technology, and had a spectrum analyzer open all the time on my computer. Just for fun. After a while I’ve noticed some peaks of energy around 434MHz. I didn’t pay attention, until when I saw one of the workers holding what looked like a rugged remote controller with a tiny antenna. I rushed back in my office and took a closer look at the spectrum: I could clearly see that the peaks were showing in perfect sync with the noise of the huge crane swinging over my roof.
I had a little chat with the worker and asked him: “Is there any safety mechanism? Like, if I push a button to make the load go down, and someone is under that load, what happens?” In the local dialect, he answered something that I could roughly translate as
"🤬 if you do that, you must have some serious problems.
This sounded like the perfect project idea to pitch to my colleagues! So I did. After some back and forth, brainstorming, and someone in the team having related ideas, we’ve decided to go after this, map the market, reverse engineer the protocols, look in depth into the embedded systems inside these remotes, and perform an all-around security analysis.
So here we are. After a long break in the middle, hard research work, and a challenging disclosure process, I’m very happy to share the results of what my colleagues in Trend Micro Research and I have produced.
Meanwhile, the renovation work is done and we’re enjoying a shiny new stone paver.
Sub-gigaherz radio-frequency (RF) protocols are widely adopted for both consumer and industrial applications. From simple garage-door openers to remote controllers that manoeuvre huge mining drillers or overhead cranes that can lift tons of loads. So, way beyond construction cranes. These RF protocols operate in the ISM bands (e.g., 433, 868, 915 MHz, depending on the region), have a range up to several hundreds meters, can easily go through obstacles, are very low priced, and are very flexible.
Industrial RF Remote Control Systems
These industrial remote-control systems usually comprise a receiver (RX) with a few relay switches (e.g., to power up the controlled motor or other electrical loads), and a transmitter (TX) that looks like a rugged remote controller with buttons. Both RX and TX have an embedded digital radio chip and a micro-controller that implements the actual application-level protocol (e.g., structure of messages, CRCs, pairing, addressing). Each transmitted message carries a distinct command that the RX actuates, usually by triggering the relay switches in a given, configurable way.
Despite the simplicity of these systems, there is no standardization in the application-level protocol, nor security best practices that go beyond the use of rolling-code to avoid replay attacks (in the best case).
After having analyzed the systems produced by several global vendors, in our research we discovered that none of the implementations had any robust security features (not even rolling codes) that would prevent an attacker from hijacking the communication and take control of the heavy industrial machines connected to the RX unit. After having responsibly disclosed our findings through Trend Micro’s ZDI (10 advisories and 3 ICS-CERT alerts, some of which resulted in security firmware updates), we’ve drawn a list of recommendations for end users, system integrators, and vendors, to ensure that current-generation systems get properly secured, and that next-generation systems will be secure by design.
This has been the hard part. Digging into custom protocols and figuring out all the bits that travel on the SPI bus (to make sure that we’re looking at the right data on the RX side) was challenging, yet a lot, lot of fun!