Verder naar navigatie Doorgaan naar hoofdinhoud Ga naar de voettekst

Technical Advisory – ExpressLRS vulnerabilities allow for hijack of control link

30 juni 2022

door Richard Appleby

Research Research Vulnerability Technical advisories Emerging Technologies 
 Vendor: ExpressLRS
 Vendor URL: https://expresslrs.org
 Versions affected: 1.x, 2.x
 Author: Richard Appleby
 Severity: Medium 7.5 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Summary

ExpressLRS is a high-performance open source radio control link. It aims to provide a low latency radio control link while also achieving maximum range. It runs on a wide variety of hardware in both 900 Mhz and 2.4 GHz frequencies. ExpressLRS is very popular in FPV drone racing and other remote control aircraft.

Using only a standard ExpressLRS compatible transmitter, it is possible to take control of any receiver after observing traffic from a corresponding transmitter.

ExpressLRS uses a ‘binding phrase’, built into the firmware at compile time to bind a transmitter to a receiver. ExpressLRS states that the binding phrase is not for security, it is anti-collision.

Due to weaknesses related to the binding phase, it is possible to extract part of the identifier shared between the receiver and transmitter. A combination of analysis and brute force can be utilised to determine the remaining portion of the identifier. Once the full identifier is discovered, it is then possible to use an attacker’s transmitter to control the craft containing the receiver with no knowledge of the binding phrase. This is possible entirely in software using standard ExpressLRS compatible hardware.

Impact

This attack could result in full control over the target craft. An aircraft already in the air would likely experience control issues causing a crash.

Details

The binding phrase is passed through the MD5 cryptographic hash algorithm to obtain a unique byte sequence. Of this sequence, the first 6 bytes are stored as a shared UID between the receiver and the transmitter. The last four bytes of the UID are used as a seed to generate a random frequency hopping spread spectrum (FHSS) sequence. Both the transmitter and receiver hop between frequencies in the FHSS sequence in sync.

A ‘sync’ packet is sent from the transmitter to the receiver to at the start of a connection and at regular intervals through the FHSS sequence. CRC checks, initialised using the last two bytes of the UID are used to ensure that packets has been received intact.

The following diagram indicates the relationship between these elements.

Three weaknesses were identified, which allow for the discovery of the four bytes of the required UID to take control of the link.

Two of these issues relate to the contents of the sync packet.

  1. The sync packet contains the final three bytes of the UID. These bytes are used to verify that the transmitter has the same binding phrase as the receiver, to avoid collision. Observation of a single sync packet therefor gives 75% of the bytes required to take over the link.
  2. The CRC initialiser uses the final two bytes of the UID sent with the sync packet, making it extremely easy to create a CRC check.

The combination of these two issues means that only one byte is unknown from the UID used to generate the FHSS sequence. To find the last byte, all possible byte values were used to create 256 different possible FHSS sequences. The third weakness occurs in the FHSS sequence generation.

  1. Due to weaknesses in the random number generator, the second 128 values of the final byte of the 4 byte seed produce the same FHSS sequence as the first 128.

By choosing a frequency from the FHSS sequence, and observing the timings relative to a received sync packet, it is possible to determine which entries in the brute forced 128 FHSS sequences correlate with the final byte of the UID.

Once the final UID byte is discovered, the UID can be set in the transmitter and it will connect with the receiver.

It is acknowledged that the FHSS sequence can also be discovered by observing packets over the air without brute forcing the sequences, but that this can be more time consuming and error prone.

Recommendations

The security of the ExpressLRS can be improved with the following changes.

  1. Do not send the UID over the control link. The data used to generate the FHSS sequence should not be sent over the air.
  2. Improve the random number generator. This could involve using a more secure algorithm, or adjusting the existing algorithm to work around repeated sequences.

Disclosure Timeline

  • December 1, 2021: Initial contact with ExpressLRS Github repository owner
  • February 3, 2022: Technical advisory draft sent to repository owner
  • February 8, 2022: Github pull request for patch submitted to repository: https://github.com/ExpressLRS/ExpressLRS/pull/1411
  • February 9/10, 2022: Discussions regarding size of pull request and effectiveness between ExpressLRS developer and NCC Group
  • March 4, 2022: Github pull request submitted to ExpressLRS which addressed size issues
  • March 5, 2022: Pull request rejected by ExpressLRS maintainer; differing opinions between NCC and developers
  • June 30 2022: Advisory published
Richard Appleby

Richard Appleby