Consumer drones freely accessing the airspace are fundamentally changing aviation and posing new safety and security challenges. For this reason, in recent years, Civil Aviation Authorities (CAAs) worldwide started pushing for the adoption of Remote Identification (Remote ID or RID). The rules and protocols that mandate consumer Unmanned Aircrafts (UA) to periodically broadcast their telemetry information (latitude, longitude, operator’s position, velocity, identifiers and many others) enabling third party entities such as law enforcement and critical infrastructure protection systems to identify and locate drones and their operators.
The DroneScout ds230 appliance, manufactured by BlueMark Innovations, is a (direct/broadcast) Remote ID receiver capable of receiving and interpreting telemetry messages periodically broadcast by drones. In particular, the DroneScout is based on the Open Drone ID (ODID) open-source framework which makes it compatible with both the DIN EN 4709-002 standard (EU) and the ASTM F3411-22a-RID-B standard (USA). The device is equipped with two independent Wi-Fi (802.11) interfaces and one Bluetooth interface and supports all transmission protocols (Bluetooth legacy, Bluetooth Long Range, WiFi NaN and WiFi Beacon) and all frequency bands (2.4, 5.2 and 5.8 GHz) currently required by the different Remote ID standards.
In this blog post, we disclose three vulnerabilities (critical, high and medium risk) which affect the DroneScout ds230 device. Two of these vulnerabilities could allow an attacker to spoof Remote ID information forcing the DroneScout ds230 to drop Remote ID information transmitted by legitimately communicating drones. The consequence of this is the attacker being able to inject fake locations associated with the legitimate drones detected by the DroneScout. The third vulnerability discovered demonstrates the capability to install malicious firmware updates on the DroneScout appliance. The crafted update could contain arbitrary files which, in turn, could lead the attacker to gain administrative privileges on the underlying Linux operating system.
The manufacturer BlueMark Innovations has, upon discovery, solved the vulnerabilities in firmware version 20230605-1350. Users of the ds230 are urged to upgrade the device to the latest firmware.
DroneScout ds230: Background Information
Before going into the details of the vulnerabilities, a bit of background information about the DroneScout ds230 is required. The DroneScout ds230 is not a device intended for the final user, it is instead designed for system integrators that want to integrate the functionalities provided by the DroneScout into their own products. Also, the DroneScout is not a stand-alone device and requires an MQTT broker (typically provided by the system integrator) for collecting the Remote ID information detected by the ds230 appliance. Finally, beyond the wireless interfaces introduced earlier, the DroneScout is equipped with an ethernet interface which allows asset owners to connect it to their own networks and that is used by the device to communicate with the MQTT broker. From a high-level point of view the DroneScout works as follows:
- It uses its internal wireless interfaces to continuously scan both Wi-Fi and Bluetooth channels. From the wireless point of view the DroneScout is a completely passive device. It never transmits anything over wireless and the wireless interfaces are configured in monitor mode.
- When a frame (Wi-Fi or Bluetooth) containing Remote ID information is detected, it parses the content of the Open Drone ID message and associates the parsed Remote ID information to the source MAC address of the drone sending the Remote ID message.
- Collected Remote ID information is periodically transmitted over the ethernet interface to the third-party managed MQTT broker (the system integrator). The content of the MQTT messages is JSON formatted.
Vulnerability Analysis: BlueMark Innovations DroneScout ds230
While analyzing the DroneScout ds230 from BlueMark Innovations, we found three distinct vulnerabilities, as listed below:
Critical Risk
- CVE-2023-31191: Information Loss or Omission (CWE-221)
- Base Score: 9.3
- CVSS 3.1 Vector: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:H
High risk
- CVE-2023-31190: Improper Authentication (CWE-287)
- Base Score: 8.1
- CVSS 3.1 Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Medium risk:
- CVE-2023-29156: Information Loss or Omission (CWE-221)
- Base Score: 4.7
- CVSS 3.1 Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:L L
Inject Fake Drones Trajectories with CVE-2023-31191
The most impactful vulnerability is CVE-2023-31191. With this vulnerability the DroneScout can be forced to drop Remote ID telemetry information broadcast by real drones and instead generate and transmit JSON encoded MQTT messages containing fake Remote ID information injected by the attacker. Consequently, the system integrator running the MQTT broker will have no access to the legitimate drones’ Remote ID telemetry information.
Now, let’s see how this is possible.
DroneScout logic is handled by the firmware main executable dronescout.arm64. When a new drone (let’s call it D) with source MAC address Md is detected by the DroneScout (i.e., D transmits ODID messages containing Remote ID information and these messages are captured by the DroneScout), dronescout.arm64 creates an in-memory global linked list entry indexed by Md which, among other things, contains:
- Md->channel: the Wi-Fi channel C where the ODID messages transmitted by D have been captured on.
- Md->RSSI: the Wi-Fi frame reception RSSI.
DroneScout’s firmware version 20230104-1650 introduced an algorithm that, as stated by the release notes: “implement[s] an algorithm to suppress WLAN transponder signals on neighboring channels in case the RSSI is very strong. (If for instance a transponder is detected on channel 6 at -45 dBm, it will also be detected at channel 4, 5 7 and 8. The algorithm will suppress those detections on adjacent channels.)”
The algorithm is implemented in function wlan_pcap_handler (0x408a80) and a decompiled snippet is shown in Figure 1.
In short, when a new Wi-Fi frame containing an ODID message is received from MAC address Md on channel C1 with RSSI R, this algorithm implements the following logic:
- If C1 is an adjacent channel (i.e., ((Md->channel – C1) + 3) < 7) and the reception RSSI R is greater than the last RSSI registered for Md (i.e., (R – Md->RSSI) > 6), then Md->channel is set to C1, Md->RSSI is set to R and the new ODID message is accepted and used to fill the Remote ID information in the global entry corresponding to Md.
- Otherwise, the new ODID message is accepted only if C1 is the same as C (i.e., Md->channel). In other words, the new Wi-Fi frames are accepted only if received on the same channel that was previously registered for Md.
The description above is a simplified version of the algorithm which handles other details like the timestamps of the ODID messages received from Md and the case of a first ODID message received from a specific drone D. However, these details have been omitted to avoid too much distraction as they do not impact the vulnerability discussed here.
An attacker can exploit the algorithm described above with the following procedure:
- Create an ODID message with spoofed source MAC address Md and containing crafted Remote ID data.
- Inject the ODID message with the spoofed source MAC address on an adjacent channel Ca (e.g., if the drone D is transmitting on channel 6, the attacker can transmit on channel 8).
- Transmit the Wi-Fi frames with high enough power such that they are received by the DroneScout with an RSSI Ra that satisfies the condition discussed above (i.e., ((Ra – Md->RSSI) > 6)). This can be achieved by using a transmitter amplifier or a high gain/directional antenna.
If the conditions above are satisfied, when the DroneScout receives the ODID message spoofed by the attacker it will set Md->channel to Ca and Md->RSSI to Ra and from this moment forward it will start dropping the ODID messages received from drone D on channel C.
Figure 2 shows the potential impact of the described attack. In the example, the attacker is injecting spoofed ODID messages on an adjacent channel to make a drone D appear like it is going in a certain direction (west in the example).
This happens although the drone D is actually in a different location. This is shown in Figure 3 that reports the position of the drone D as it appears once the attacker stops injecting spoofed ODID messages.
An attacker can obtain the same kind of result also with CVE-2023-29156. However, in that case the vulnerability is more complex and less reliable to exploit, therefore the lower risk base score.
NOTE: the information and the screenshots refer to DroneScout’s firmware 20230329-1042. However, the discussed vulnerability applies to all the previous firmware releases, starting from version 20230104-1650. Also, the base address used for firmware analysis is 0x400000.
Malicious Firmware Update with CVE-2023-31190
With CVE-2023-31190 an attacker that has the ability to execute a Man-in-the-Middle attack (e.g., DNS poisoning, ARP poisoning, control of a node on the route to the endpoint, etc.) could prompt the DroneScout ds230 to install a crafted malicious firmware update containing arbitrary files (e.g., executable and configuration), and gain administrative (root) privileges on the underlying Linux operating system.
This is possible because of a vulnerability in the updated procedure used by the DroneScout appliance. The user can manually update the DroneScout to the latest firmware by executing the update script /root/update.sh. The script downloads the firmware from https://download.bluemark.io/dronescout/firmware/stable/ds230.tar.bz2 as shown in Figure 4.
As shown in Figure 4, the firmware is downloaded using curl with option “–insecure”. As stated in curl documentation the “–insecure” option “allows curl to proceed and operate even for server connections otherwise considered insecure … WARNING: this makes the transfer insecure”. In other words, this means that when the “–insecure” option is used, curl ignores the TLS certificate provided by bluemark.io HTTPS server. An attacker able to redirect connections directed to “bluemark.io” towards a host under his control (e.g., Man-in-the-Middle) can configure a static HTTPS file server with a self-signed TLS certificate and trick the update.sh script into downloading a maliciously crafted firmware update file (ds230.tar.bz2).
In our PoC, we created a crafted ds230.tar.bz2 update archive for firmware version 20230329-1042. In this crafted archive the file “media/root-ro/root/version.txt” (which will be installed in “/root/version.txt”) has been modified to include the string “20230329-1042-pwned”. Then we created the corresponding ds230.tar.bz2.md5sum file that is used by the update script to verify the integrity of file ds230.tar.bz2: md5sum ds230.tar.bz2 > ds230.tar.bz2.md5sum
We configured the local DNS server to return the address of a server under attacker’s control when the name “download.bluemark.io” is resolved. Then, on the attacker’s server we created the directory structure shown in Figure 5.
Next, we executed ssfs which is an HTTPS static file server with self-signed TLS certificates. Finally, we executed the update script /root/update.sh on the DroneScout appliance. DroneScout connected to the server controlled by the simulated attacker and proceeded to install the crafted firmware. This can be seen by dumping the file /root/version.txt on the DroneScout at the end of the update process, as shown in Figure 6.
We recommend that asset owners and systems integrators quickly apply the updated firmware (version 20230605-1350) released by BlueMark Innovations on June, 5, 2023 (or more recent firmware releases when available).
Summary
The DroneScout ds230 from BlueMark Innovation is one of the first commercially available appliances supporting the most recent broadcast Remote ID standards. We had the opportunity to analyze the DroneScout ds230 and, in this article, we have disclosed three vulnerabilities that affected the Remote ID receiver. Two of these are rated critical and high risk and could impact the reliability of the data provided by the DroneScout appliance and the security of the asset owners’ networks. We urge owners of the BlueMark DroneScout ds230 and system integrators using the device to apply the available firmware upgrade to prevent adversaries from exploiting the presented vulnerabilities.
Remote ID policies and standards which require drones to periodically broadcast their telemetry information will play an essential role in the future of aviation. This is true both in terms of airspace security and safety as they allow entities such as low enforcement and critical infrastructure authorities to be aware of the drones surrounding a certain area. If vulnerabilities are not addressed, the potential to spoof legitimate telemetry data across a growing number of commercial drones presents a potentially dangerous risk to the integrity of Remote ID policies and broadcasted telemetry information.
