My professional background is network and Internet security, I quickly discovered the huge risk of an hostile takeover of UAV midair.
My experiment is based on 3DRobotics telemetry radios. but works with many more radios, based on the same, open, solution.
Please note that this is not a security risk of Ardupilot project, ArduCopter, ArduPlane is *not* to blame. You may get an idea that some changes should not be allowed while armed, but that’s not a proper solution. Having all the options we have, after all, GCS is a device to be trusted, and the primary control during a auto mission.
Radios lack proper security, mostly due to limited processing power for proper encryption. We are left with an simple attempt to secure the data, which is very easily worked around.
The open nature of the project, makes it impossible to truly protect the transmitted data. The radios do not have space & processing power to use public&private certificate based verification of data, also we would need a simple and a method of letting users selv-sign/generate such certificates for as many radios they needed in a network.
The current attempt to secure the transmission is based on radios dropping packets branded with different NetID- and the frequency hopping pattern to be seeded by the NetID.
So knowing or guessing one UAV’s (or companies) NetID, (provided it’s even changed from the default one) , enables anyone to send packets that are perfectly valid on the network.
To verify the theory, I needed an experiment:
I created a specialy crafted firmware for the stock telemetry radio, it proved to be a trivial task, Let’s call the module for BlackSheep, it have the following features:
- Automatic sniffing of nearby NetID (as we know, the user-set NetID is also used to seed the frequency hopping)
- When it finds valid packet with NetID, it learns active frequencies, and changes it’s frequency hopping to the pattern of that particular NetID – locking in on it. – whole process takes ~1second.
- By connecting BlackSheep to any GCS, we have instantly a valid connection to a nearby operating UAV.
Hijacking the drone in real life.
We can assume a low-tech drone hijacker would do it by running a GCS and just do it manually. An intermediate hacker would use scripts with MavProxy, or clicking around in GCS software – but the optimal solution, is a predefined set of commands used by a modified GCS for easy map interaction.:
This is what an takeover looks like;
- pointlessly evil hijacker could just disarm the drone midair or send MAV_CMD_DO_FLIGHTTERMINATION – but that’s not the goal here.
- send, and repeat a few times: SR?_* = 0 – disables all telemetry output from AP , make the radio go silent. This will also reduce amount of packet collisions if we have 3 radios operating. (UAV is the one occupying most of the radio time) – now the victim GCS operator does not get any more updates.
- Then we set all control FLIGHTMODE_? to AUTO or Guided (by preference), and disable FS_Throttle and FS_GCS , CH6 and other programmable options are disabled. The pilot with RC can’t do anything anymore.
- Enabling SR?_EXT_STAT – gives the hijacker RAW GPS data, altitude, speed – this data is usually not visible on a GCS, so the victim can’t see it – but hijacker knows where the UAV is.
- Uploading a mission, or Guided mode instructions sends the UAV to wherever hijacker wants – victim have no valid input, and cannot see it in GCS, all he gets is Mavlink heartbeat.
- Finally, for the extra evil touch hijacker can inject Mavlink MAVLINK_MSG_ID_GLOBAL_POSITION_INT packets (as if autopilot was sending it) with proportionally incorrect data, so we could get the victims GCS display and log the real movement, with actual speed, but in different direction, misguiding as to where the UAV went.
I skipped a few trivial steps, like setting higher cruise-speed, and few platform dependent commands – but the short summary should be frightening enough.
What can be done to prevent such hijacking ?
- Fly without telemetry radio, reducing mission control and control redundancy, not good.
- Use cellular network to get TCP or UDP control, limited coverage.
- Use wifi, very poor range.
- Satellite modem, expensive, very low data rate, often ~2400bps
- Continue to develop open solutions with hardware limitations that limits us to very simple security solutions, like the one in use today – very easy to circumvent.
- Use customized, specialized, closed solution that offers good security, it is not proper certificate based encryption, but rather an odd, but very effective scrambling. Effective mostly because the firmware is locked down, and not easy to analyze.
Final words:
Telemetry radios , 433/900Mhz are great, most aviation authority approved approved flights , professional or hobby, are within VLOS, where these radios perform great.
The fact the source i open, is not a drawback, but a strength. It allows people like me to detect security vulnerabilities, like many other can do, and documents them, or protect against them, so others cannot silently abuse them, without users understanding what’s going on.