RVD#3316: No authentication in MAVLink protocol

[vmayoral]

id: 3316
title: 'RVD#3316: No authentication in MAVLink protocol'
type: vulnerability
description:  The Micro Air Vehicle Link (MAVLink) protocol presents no authentication
  mechanism on its version 1.0 (nor authorization) whichs leads to a variety of attacks
  including identity spoofing, unauthorized access, PITM attacks and more.
  According to literature, version 2.0 optionally allows for package signing which
  mitigates this flaw. Another source mentions that MAVLink 2.0  only provides a simple 
  authentication system based on HMAC. This implies that the flying system overall 
  should add the same symmetric key into all devices of network. If not the case, this may
  cause a security issue, that if one of the devices and its symmetric key are compromised, 
  the whole authentication system is not reliable.
cwe: CWE-306
cve: CVE-2020-10282
keywords:
- MAVLink
- v1.0
- v2.0
- PX4
- Ardupilot
system: "MAVLink: v1.0"
vendor: "PX4"
severity:
  rvss-score: 9.6
  rvss-vector: RVSS:1.0/AV:AN/AC:L/PR:N/UI:N/S:U/Y:T/C:H/I:H/A:H/H:U
  severity-description: critical
  cvss-score: 9.8
  cvss-vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
links:
- https://arxiv.org/abs/1906.10641
- https://arxiv.org/abs/1905.00265
- https://ieeexplore.ieee.org/document/8425627
- https://www.researchgate.net/publication/335973981_Assessing_and_Exploiting_Security_Vulnerabilities_of_Unmanned_Aerial_Vehicles
- https://link.springer.com/chapter/10.1007/978-981-13-8406-6_66
- https://www.esat.kuleuven.be/cosic/publications/article-2667.pdf
- https://www.usenix.org/conference/usenixsecurity19/presentation/kim
- https://docs.google.com/document/d/1ETle6qQRcaNWAmpG2wz0oOpFKSF_bcTmYMQvtTGI8ns/edit
- https://docs.google.com/document/d/1upZ_KnEgK3Hk1j0DfSHl9AdKFMoSqkAQVeK8LsngvEU/edit
- https://docs.google.com/document/d/1XtbD0ORNkhZ8eKrsbSIZNLyg9sFRXMXbsR2mp37KbIg/edit
- https://github.com/PX4/Firmware/issues/13538#issuecomment-574281772
- https://github.com/rligocki/Diploma_thesis_px4
flaw:
  phase: unknown
  specificity: subject-specific
  architectural-location: platform code
  application: Flying vehicles and/or others using MAVLink protocol.
  subsystem: communication
  package: N/A
  languages: C, C++
  date-detected: 
  detected-by: 
  detected-by-method: testing
  date-reported: '2020-06-30'
  reported-by: "Victor Mayoral Vilches (Alias Robotics)"
  reported-by-relationship: security researcher
  issue: https://github.com/aliasrobotics/RVD/issues/3316
  reproducibility: always
  trace: N/A
  reproduction: N/A
  reproduction-image: N/A
exploitation:
  description: Not available
  exploitation-image: Not available
  exploitation-vector: Not available
  exploitation-recipe: ''
mitigation:
  description: MAVLink 2.0 includes signing capabilities which mitigate this issue. Signatures seem to be optional for backwards compatibility and https://arxiv.org/abs/1906.10641 confirms this matter. Proper mitigation should enforce signatures.
  pull-request: N/A
  date-mitigation: null

[vmayoral]

Been reviewing the release notes of PX4 and from the outlook, versions prior than v1.7.0 (stable) don't seem to fully support all the features including with the signing capabilities. A similar research should be done with Ardupilot and other autopilots that make use of this protocol.

NOTE: for the sake of time, no actual code review was done to confirm the presence and/or implementation of MAVLink 2.0 in v1.7.0 of PX4 so take the information above only as preliminary

For reference: https://github.com/PX4/Firmware/releases?after=v1.7.4beta

[vmayoral]

Further extended ticket with:

MAVLink protocol provides a very good way to transport a huge amount of data with very low overhead but provides only very basic security features. In current state MAVLink only provides a simple authentication system based on HMAC. This means that drone manager must add the same symmetric key into all devices of net- work. This creates a security issue, that if one of the devices and its symmetric key are compromised, the whole authentication system is not reliable. Then messages might be suppositious and there is no way to find it out.

From PX4/PX4-Autopilot#13538 (comment)

[glerapic]

This has the potential to harm humans if a bad operator takes control of the device and it goes kamikaze. Please consider changing the Hazard value from H:U to H:H

[vmayoral]

Mmmm I'm a bit hesitant about that. This vuln itself affects the robot components and would need to be chained with other flaws to affect humans, don't you think so? That's why i left it as unknown.

[glerapic]

Fair enough.

LGTM!

[vmayoral]

Fine then, filed for a CVE ID CVEProject/cvelist#4246

[khancyr]

Hello,

I don't understand the point of this ticket... It is clearly stated that mavlink 1.0 protocol doesn't provide any system of authentification....
So this vulnerability isn't one...

About mavlink2.0 with signing, if somebody got the signing key, yes you got an issue but that like for all systems when you lose a key.

About ArduPilot, we use mavlink2.0 by default since some time. So we aren't vulnerable to this.

[vmayoral]

Hi @khancyr,

I don't understand the point of this ticket... It is clearly stated that mavlink 1.0 protocol doesn't provide any system of authentification....

That's right. MAVLink 1.0 does not implement authentication or authorization but while that design decision is respectable (and likely appropriate for that time), it still includes with it a security flaw which is what's described in this ticket and what's captured with a CVE ID.

The lack of authentication is thereby a vulnerability on MAVLink's version 1.0.

About mavlink2.0 with signing, if somebody got the signing key, yes you got an issue but that like for all systems when you lose a key.

About ArduPilot, we use mavlink2.0 by default since some time. So we aren't vulnerable to this.

Last time I checked the source code of PX4 and ArduPilot (a couple of months ago) noticed that for backwards compatibility (and to support several GCSs), the autopilot allows to negotiate communications with both MAVLink 1.0 and 2.0 endpoints. Depending on how intialization and handshake process is established, it's somewhat trivial to get the autopilot to exchange messages using the insecure and unauthenticated version 1.0. This is somewhat covered at https://mavlink.io/en/guide/mavlink_version.html#negotiating_versions.

I cooked a simple exploit PoC for PX4 which validated this. Never got the time or resources to test it also in ArduPilot but I'm happy to review it if anyone can support us in the process with some resources.

Frankly, I scrolled quickly through the ArduPilot code so I might have missed something but happy to double check it if you can provide pointers where there's evidence that ArduPilot implements only a subset of MAVLink, and thereby discards this characteristic (negotiation of the version). That certainly would be a proper mitigation, though it'll break backwards compatibility.

Let me now if you something to add in here but for the time being, I'm keeping this open based on this rationale for ArduPilot.