Mitigating protocol-specific attacks
David Melendez, R&D Software Engineer, Madrid, Spain
I. INTRODUCTION
Drones are taking an important role in nowadays Internet of Things, agricultural, multimedia, and even delivery industry. Historically, aircraft models have been controlled via radio, using typically AM or FM modulations with dedicated and expensive hardware. With commercial grade drones, come widespread communication methods, that allow lower costs. One of the most used is the WiFi standard.
The drone user, acts as a pilot from his phone, tablet or computer, and via a WiFi adapter, an application sends the user commands to the drone.
The main problem here, is that with the implementation of a widespread technology, comes widespread security problems.
Many commercial drones come with no security at all, but event if they have one, it is still lacking on many aspects,
making the control vulnerable to some protocol specific attacks. Not to mention the classical Radio Jamming. Even police grade drones has been hacked because their poor WiFi security [1].
At the same time, drones can be a critical vector to perform DoS and penetration attacks to critical infrastructures due to their mobility and small size. They are able to carry equipment as payload, designed for attack enterprise and home Wireless Networks and perform a wide battery of attacks once connected. Even if they aren’t able to connect to the victim’s network, they can cause damage like DoS attacks. Hardware like multiple WiFi adapters and Software Defined Radios, are an attractive choice for this purpose due to their small size and low cost.
II. STANDARD SECURITY
Security on WiFi drones, has to be, at least, as good as any other network that follows the nowadays protection standards.
Choosing a decent key and cypher protocol, is essential to avoid key hacking. A WPA/PSK would be enough in most
cases, but this method is still vulnerable to Deauthentication/dissassociation attack as the same as any other WiFi network.
However, this choice can cause an unintended delay effect between pilot orders and drone, because limited computing power on the drone side. For this reason, design has to take this into account in order to avoid a poor user experience.
III. STEALING DRONES
There is already some application that are able to steal a WiFi drone and can be mounted onboard on an embedded
system. One of these projects is named “SkyJack” [2] and sends a deauthentication 802.11 packet to take out pilot control and log into the drone HTTP session, stealing effectively the drone itself and takes the entire control of the system. This is a proof of concept of something that can be repeated all over WiFi-operated drones. It’s grade of success can vary from making an effective “Denial of Service Attack” (sending repeatedly those packets) to taking the entire control of the system.
Deauthentication attack is effective even if a key is configured because those packets are not encrypted with
the key, and anybody can send them.
IV. 802.11W PROTOCOL
This standard is intended to avoid Deauthentication attack problems, but is not widespread enough to support all devices, not well implemented, and any Management Frame that is sent before key establishment is infeasible to be protected.
V. ATTACKING DRONES USING SIGNATURES
While drone industry grows, a wide set of commercial projects claim to be a solution to intercept drones, to prevent
physical attacks to critical infrastructures, or privacy violations of private areas. Some of them use Radio Jamming in some opaque way, blocking all radio communications in a predefined set of frequencies, expecting that the drone is using one of them, to block the pilot commands, and make the drone to come back to the take off area by itself automatically, for example.
This solution, depending on the output power of the radio jamming, can bring legal issues due to emission restrictions, and causes interferences to “legit” applications without filter.
Many other products, detect the type of the drone by it’s WiFi configuration, based on MAC address, network name,
and some other data. Once detected, they can perform deauth. attacks to the drone WiFi network.
VI. CUSTOM PROTOCOL
A custom application-specific protocol has been developed to cover this scenario and make a robust communication,
adapted to the specific needing of drone piloting without changing the WiFi hardware.
If the main problem comes with the fact that a client (pilot) is associated with the drone, this protocol suggests that if you are not associated nobody can dissasociate you.
Taking advantage of monitor mode of WiFi adapters, this paper implements an alternative to normal WiFi communication.
Implementing a communication between pilot and drone, manipulating and sending the same packets that are used to announce a WiFi network, and punt the commands inside of them, we can have a radio-like system using standard WiFi hardware.
When client makes a request to take off the drone, the client application generates a fresh key that is sent via the normal WiFi system.
Once the key is loaded in the drone, both pilot and drone switch to this protocol, and all communications are protected by this key, and at the same time, nobody are able to perform any deauth attack.
“Illustration 1: Protocol implementation”
VII. PROOF OF CONCEPT PLATFORM
“Illustration 2: Atropos Quadrocopter”
Atropos is a reseach oriented quadrocopter based on Linux. It is auto-stabilized by an Inertial Measurement
Unit developed from zero, to avoid manufacturer restrictions.
VIII.PLATFORM ATTACKING CAPABILITIES
As shown in illustration 1, the proof of concept also is capable to perform WiFi attacks with a small Wifi Card Reader,
running also a custom Linux Image, designed for launching WPS bruteforcing, and all Aircrack capabilities, with automated scripts. All operations can be performed from ground station and in-flight.
This payload has been chosen because it has a tiny size (like a small flash pendrive), that can be mounted in almost any drone, and it could serve as flight control system due to its power.
IX. BETTER RANGE BEYOND NORMAL WIFI SCENARIO.
With this protocol, more range can be achieved with the same hardware. There is no 2-ways communication that has to be accomplished to establish the communication. In other words, relaxed protocol requirements make communication more robust than more exigent implementations.
REFERENCES
[1] “Hacker reveals $40 attack that steals police drones from 2km away”
http://www.theregister.co.uk/2016/04/01/hacker_reveals_40_attack_to_
steal_28000_drones_from_2km_away/
[2] “SkyJack is a drone engineered to autonomously seek out, hack, and
wirelessly take over other drones within wifi distance, creating an army
of zombie drones under your control”. http://samy.pl/skyjack/
