We’re always looking at new ways to extend the mobile development opportunities at RIIS. Recently we’ve worked on a series of mobile apps that control drones for a client and started thinking about how to make it secure. In the early days of any new technology security is never top of the agenda. That seems to apply whether it’s mobile, IoT, connected cars etc. So here’s some basic information you need if you’re going to write your own secure mobile drone app.

How to Hack a Drone

There isn’t any definitive list of existing hacks on Drones but this Medium article does a really good job of covering the basic attack types for a number of different consumer drones. Hackers can connect to the Drone itself and start killing processes, or they can intercept the radio communication using Gnu Radio, hijack the video or jam the signal and if all else fails people have resorted to shooting them down. But often hackers are just looking for the weakest link and the mobile apps that control a lot of these drones is what interests us.

What We’re Going to Cover

In this blog we’re going to look at how to secure just one slice of the drone attack surface, namely the mobile apps that interact with these drones using the developer SDKs released by the manufacturers. Figure 1 – from the DJI developer website – shows how third party drone apps exist with the DJI eco system, but it could just as easily be another manufacturer’s SDK such as 3DR or Yuneec.

Figure 1: Mobile apps and Manufacturer’s SDK

Drone Mobile Apps

Here’s a sample of some drone mobile apps, that are done by third parties using manufacturers SDKs, Litchi for DJI, Solex for 3dr Solo, Precision Flight and Skydrones again for DJI. These apps are available for both iOS and Android. There are plenty of other similar apps.  They each offer something over and above what the DJI Go app or the 3DR Solo app, mostly that they just done one task very well.

Litchi on it’s own has proved that there’s a business model here with 50-100k downloads on Android at $29.99 and presumably a similar or greater number of purchases on iOS. Go to http://developer.dji.com, http://developer.3dr.com, http://developer.parrot.com or http://developer.yuneec.com if you want to see how to get started writing your own drone app.

OWASP Mobile Top 10 Risks

We’ve written about the OWASP mobile top ten risks in the past. It’s a great resource which was last updated in 2016. Rather than going through the entire top 10, let’s talk about the following areas which are most relevant for drones.

• M2 – Insecure Data Storage

• M3 – Insecure Communication

• M5 – Insecure Cryptography

• M6 – Insecure Authorization

• M9 – Reverse Engineering

There are 3 general areas that we’re interested in protecting, firstly the static data in the Android or iOS code – such as hard coded encryption or API keys. Secondly we’re looking at any dynamic data that’s stored in shared preferences or sqlite databases on the phone while the drone operator is using the app. Finally we’re looking at where any video or images are stored on the back end servers and if we can see how the app is logging in to these back end servers in case it’s doing it insecurely. Keep those in mind as we’re going through our top risks.

M2 – Insecure Data Storage

In M2 we’re talking about the user’s dynamic info here. If someone backs up your app on their Android phone they can see information similar to the Figure 2. Lots of databases, cached files and shared preferences. Be careful what you put here and don’t put any sensitive information such as passwords or location information.

Figure 2: Dynamic data

In Figure 2 we see three folders for databases (db), files (f) and shared preferences (sp) for the SkyDrone app. Much of this information if DJI data. The br.skydrones.skydronecapture_preferences.xml is where the user information is stored, see Listing 1. In this case nothing sensitive is stored, just email addresses and the user’s first and last name.

<?xml version='1.0' encoding='utf-8' standalone='yes' ?><map> <string name="UserCountry">AMERICAN SAMOA</string> <string name="UserId">1162</string> <string name="UserType">2</string> <boolean name="IsFirstTimeLaunch" value="false" /> <string name="UserEmail">info@riis.com</string> <string name="UserLastName">Nolan</string> <boolean name="IsFirstMission" value="false" /> <string name="UserFirstName">Godfrey</string></map>

Listing 1: Shared Preferences file

M3 – Insecure Communication

Normally when you’re talking at insecure communication you’re trying to secure people in a coffee shop. Here the hacker is listening to the traffic from their phone to the cloud to see if they can find information to hack the back end server. Figure 3 shows just such a Man in the Middle attack – with an image borrowed from the FTC.

Figure 3: Man in the Middle Attack.

SSL is broken. Using a tool like Charles Proxy the hacker can download root SSL certificates to a phone and spoofs the companies SSL cert to see the https traffic. Figure 4 shows just an example so you can see for yourself.

Figure 4: HTTPS calls shown in cleartext.

In the Precision Flight calls above you can see the https://www.precisionmapper.com API call is not encrypted. There’s nothing hackable in this call. Hackers are looking to see where the calls are going and what is being transmitted to see if they can change the values and break into something they shouldn’t. It’s also worth noting that you can see a bunch of calls to DJI and Skypixel showing that the app is built on top of the DJI Mobile SDK. There really isn’t any foolproof solution to this problem. You can use a technique called SSL pinning but you also have to kick your users out of the app if the phone is rooted otherwise they can bypass the pinning and still see the traffic.

M5 – Insecure Cryptography 

If you want to secure your user’s password information, the first inclination is to encrypt the data and put the key somewhere in the code. But if the key is in the code then a hacker is probably going to find it. However you can use RSA, i.e. public – private keys where only the public key is stored in the phone. It does mean that the password can only be decrypted on the server and you have to be connected to the internet to use it, but this is a much safer than using a hard coded symmetric key.

M6 – Insecure Authorization

In Figure 5 we see some decompiled code which seems to show the code for uploading a drone’s logfiles onto Amazon. The initASWSDK() method shows the credentials to connect to the app’s Amazon’s S3 bucket and the filename is generated using the user’s installation id stored in the shared preferences.

Figure 5: Decompiled code

Once the hacker has the recipe for how you’re storing your files they can either guess other user’s ids or alternatively use a brute force attack to find InstallationId’s and their logfiles.  Just like encryption keys in the last section don’t hard code API keys. Someone will find them.

M9 – Reverse Engineering

Android apps can be downloaded from a phone or a website such as apkpure.com and reverse engineered into code like that shown in Figure 5 using a tool called Jadx. Turn on Proguard in the build.gradle file to make it harder to follow the code or use a commercial obfuscation program such as DexGuard, see our earlier post for more information.

iOS apps can’t be decompiled, but it can be disassembled and then analyzed using Hopper or IDA Pro. It’s much harder to understand than using something like Jadx but it still provides valuable information.

Best Practices

So how can you protect your apps from someone carving them apart in this way? We can collect some basic best practices that you might want to adopt.

• Don’t store any sensitive user info locally, store it on the server

• Don’t hard code API keys in your app, someone will find it

• Use SSL pinning and Google’s SafetyNet API to see if the phone is rooted

• Expire sessions, some of these apps never expire. If someone picks up your old phone they can impersonate you and see your saved images and videos

• Trust but verify, if the user authenticates on the mobile app, make sure you are authenticating them again on the server.

• Turn on obfuscation such as ProGuard.

Conclusion

At this stage I guess it’s just human nature for developers to ignore security until they’re forced to by some external forces. So it shouldn’t come as any surprise that apps for drones would be insecure. Take the leap before you get hacked and follow our best practices guide and the test your app using the OWASP Mobile Top 10 Risks.

Also understand that hackers don’t linearly follow the OWASP Top 10.  Finding where the data goes (M3) is usually just the first part of a hack. They can then look at the code (M9) and insecure data storage (M2) to potentially gain access to the back end server. In drone apps the hacker is using the data in shared prefs or plists files together with the source code to get videos and images from where they’re stored on Amazon. So you may need to apply some lateral thinking when you’re protecting your apps.