Hack Allows Drone Takeover Via ‘ExpressLRS’ Protocol

A radio control system for drones is vulnerable to remote takeover, thanks to a weakness in the mechanism that binds transmitter and receiver.

The popular protocol for radio controlled (RC) aircraft called ExpressLRS can be hacked in only a few steps, according to a bulletin published last week.

ExpressLRS is an open-source long range radio link for RC applications, such as first-person view (FPV) drones. “Designed to be the best FPV Racing link,” wrote its authors on Github. According to the report the hack utilizes “a highly optimized over-the-air packet structure, giving simultaneous range and latency advantages.”

The vulnerability in the protocol is tied to the fact some of the information sent over via over-the-air packets is link data that a third-party can use to hijack the connection between drone operator and drone.

Infosec Insiders Newsletter

Anyone with the ability to monitor traffic between an ExpressLRS transmitter and receiver can hijack the communication, which “could result in full control over the target craft. An aircraft already in the air would likely experience control issues causing a crash.”

Weakness in Drone Protocol 

The ExpressLRS protocol utilizes what is called a “binding phrase,” a kind of identifier that ensures the correct transmitter is talking to the correct receiver. The phrase is encrypted using MD5 – a hashing algorithm that’s been considered broken (PDF) for nearly a decade. As noted in the bulletin, “the binding phrase is not for security, it is anti-collision,” and security weaknesses associated with the phrase could allow an attacker to “extract part of the identifier shared between the receiver and transmitter.”

The core of the problem is tied to the “sync packets” – data communicated between transmitter and receiver at regular intervals to ensure they are synced up. These packets leak much of the binding phrase’s unique identifier (UID) – specifically, “75% of the bytes required to take over the link.”

That leaves only 25% – only one byte of data – left open. At this point, the report author explained, the remaining bit of the UID can be brute forced, or gathered “by observing packets over the air without brute forcing the sequences, but that this can be more time consuming and error prone.”

If an attacker has the UID in hand, they can connect with the receiver – the target aircraft – and take at least partial control over it.

The author of the bulletin recommended the following actions be taken, to patch over the vulnerabilities in ExpressLRS. Do not send the UID over the control link. The data used to generate the FHSS sequence should not be sent over the air. Improve the random number generator. This could involve using a more secure algorithm, or adjusting the existing algorithm to work around repeated sequences.

Register Now for this LIVE EVENT on MONDAY JULY 11: Join Threatpost and Intel Security’s Tom Garrison in a live conversation about innovation enabling stakeholders to stay ahead of a dynamic threat landscape and what Intel Security learned from their latest study in partnership with Ponemon Institue. Event attendees are encouraged to preview the report and ask questions during the live discussion. Learn more and register here.

 

Suggested articles

Discussion

  • Darren Allatt on

    Funny thing is, you have a small window of time of 8 minute or less in most cases to do your attack; and where is ELRS being used? At drone races, parks and abandoned buildings. So not really a “risk” in anyway.
  • Nathan Schneider on

    You do realize this is the same vulnerability for literally any other packet based RC link available right? Further, part of ELRS is that those sync packets tell the RX what “rhythm” the TX is on and when to expect packets and telemetry data. You’re never going to sync to the same rhythm as the real transmitter so the best you can do is DDoS the drone out of the sky, which has been a thing for years now. Say you do sync the RC packets. Well the telemetry data is also on its own “rhythm”, separate from the RC packets. You’ll never match both, and you’ll never be able to what the telemetry rhythm is. In either case since you’re disrupting the link it’ll just failsafe and drop out of the sky. And these toys are so fragile they’re not surviving a mid maneuver failsafe. Another point, 90% of ExpressLRS users fly within 1km. If you really wanted to take over someone’s drone that close, seems like an awful lot of work when you could just go physically confront them… Also funny using a DJI drone as the thumbnail, as if thats relevant. I suggest you learn more about RC links and actual cybersecurity before you go posting clickbait next time.
  • Stephen on

    As the author of the protocol noted - this binding phrase is not designed for security, it is designed to prevent collisions. Most RC radio systems use this mechanism of a shared hash but they are hiding their implementation in closed source - and security through obscurity is not security at all.
  • James on

    This is complete garbage. There are no drone control links that are not susceptible to a hostile takeover. The binding phrase was never meant to be "secure" or a secret. RC links are not supposed to be secure protocols.
  • Greg on

    Well. Manipulation by the Far is the best way for a press to say on the surface... Is it not? Throw the technicall terms in, make yourself sound like you know what you are talking about, confus people and then SPECULATE THE S... out of the subject. Oh i miss the time when it was about the fact not a made up, empty assumptions and manipulation to get more clicks.... This is the world you are building for chindren....
  • R S QUICK on

    Maybe try reading the actual GitHub pull request (and rebuttal). Richard Appleby (aka redfiveau? and "the author of the 'bulletin'") suggested additions to the code that were deemed irrelevant (as they have been by almost every RC control link available to "non-military" users) by the ELRS developers; with good reason. The suggestion that this is "unique" to ELRS is based on ignorance; not "threat intelligence." Quoting an ELRS dev: Appleby's suggested "changes do nothing to address [his "security"] complaints though, other that obscuring the UID... [Anyone] can take control against your [suggested changes to the ELRS] code without ever knowing the UID or using any special hardware using simple replay on the sync packet and the same brute force CRC seed discovery (which can be performed on the device in milliseconds). [Your suggested change] therefore fails to raise the barrier of entry at all-- it solely makes the code more complicated with absolutely zero increased difficulty. There is zero benefit and zero done to address security with this. Therefore it doesn't matter how much code space it occupies compared to master, unless it occupies less code space, there's no reason to even consider this at all." Now you can go back and write the exact same article for DJI, Spektrum, FreeSky, Crossfire, Tracer, etc...... Otherwise, this is just an attack article on something that you (and Appleby) apparently know nothing about.
  • Seriously on

    Oh noes! My unencrypted communication is unencrypted. Whoever read that bulletin and completely failed to do any related research (Nate Nelson) on how radio communication works should really find a new field. Investigative reporting is definitely not your forte.
  • CapitalG6 on

    I think someone nearby my apartment complex “Sky-Jacked” my POS 4DRC V12 a few days ago on it’s maiden voyage. I thought it was totally weird and more than user error to all of a sudden start flying straight up and out of sight.?To loose control connection with my drone while I was literally within a few feet of it.

Leave A Comment

 

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.