Most counter-UAV techniques are illegal or very closely regulated outside of a war zone. The proliferation of consumer and commercial UAVs is prompting people to consider ways to disable them or take them down outside war zones. So far, we have seen shotguns, brooms and even kangaroos. How about some more precise options?
What follows is a thought exercise. Jamming, firing weapons indiscriminately, and even taking down a UAV with a net are all likely to be illegal wherever you might be reading this.
Most UAVs are controlled by a pilot using a radio transmitter or by a ground control system that instructs the UAV to fly to a particular set of waypoints. It is possible to jam the control signal, monitor the data channel, and even hijack the UAV. (A subject for another post.) This activity is certainly illegal.
A simple physical approach:
Acquiring and targeting a small UAV in motion with the Mark 1 human eyeball is tough. Attempting to shoot it down with a normal firearm is harder still. Doing so would violate several fundamentals of firearm safety:
- Always keep the muzzle pointed in a safe direction
- Be sure of your target and what’s beyond it.
If you really want to physically take down a UAV using a projectile weapon, consider using a net gun or a paintball rifle. (More on that later.)
Let us put aside “how to bring down the UAV” for a moment and address UAV detection. There are commercial solutions in this space and interested parties should explore those options for definitive, professional solutions. For the sake of this exercise, lets consider something like the Bluetooth Sniper Rifle.
Many consumer UAVs use 2.4GHz for command & control or data links. Such a “rifle” should detect a UAV using 2.4GHz at long range. Mount such a device on a tripod with a gimbal driven by a system that can point the detector in the direction of maximum signal strength. (Exercise left to the reader, as my professors used to say.) This provides a bearing and elevation from your location to the device you are targeting. You’ll have to spray the air space with rounds as you don’t have range information to provide a precise targeting solution but you could have the paintball gun fire in a pattern to place shots around the target. A few paintballs in the rotors should do the trick.
Now, tie two or more of these targeting systems together and you’ll have bearing, elevation, and range to the target. If you know the ballistics of your paintball rifle, you could probably place some pretty precise shots rather than spraying the air. It has been awhile since I used a paintball rifle but I recall that figuring out the trajectory of a paintball round was quite difficult.
[If anyone wants to try building this, please let me know and I’ll help.]
TrackingPoint – a precision solution:
TrackingPoint has a commercial solution for calculating targeting solutions for rifles, what they call “precision guided firearms”. Their solution uses a human to acquire and mark the target and then fire the round. Once the human marks a target, a computer tied into the rifle calculates the appropriate solution and guides the human to make the precise shot.
So the system takes targeting information in electronic form and uses it to provide a targeting solution. Can’t we take the targeting data from something similar to what we postulated above and use it to guide the human? I imagine so. (I asked TrackingPoint about this possibility and received no response.)
Keep the human on the trigger and use frangible, rubber, or other non-lethal rounds. You may have a long distance, precise, counter-UAV solution.
I will be presenting on forensic analysis processes and techniques at the following conferences this summer:
To whet your appetite for the presentation, here is an outline of the talk. You’ll note that we cover everything from why you should be interested in this material to an overview of a typical UAV to an analysis process to specific analysis steps for each component to real time analysis techniques.
Update: 5 days later. Frontier still can’t tell me anything, but they asked me to check with Mediacom. Mediacom agrees, Frontier is dropping the traffic, it is Frontier’s problem.
Hey David, Thanks for contacting us via email! I'm sorry to hear about the issues you're encountering when trying to access Frontier.com. Looking over the trace route since it's dropping on Frontier's end there is not much we can do from our side. Since you've already submitted a ticket with Frontier the best option would be to wait until they can resolve this issue. If you have any other issues or questions feel free to contact us again here! Thanks, Chris
Update: 12 hours later, Frontier still has no explanation for their apparent blocking of Mediacom IP addresses:
Ask Frontier @AskFrontier @dckovar Hi David, I wanted to let you know that we are still investigating this for resolution. -KH
I’ve been trying to pay my Frontier phone bill for a week now. Sure, I could use a check, but this is the age of the Internet and I’d also like to set up automatic billing.
But I cannot get to http://www.frontier.com. For days.
It finally dawns on me to do a traceroute:
traceroute to frontier.com (18.104.22.168), 64 hops max, 52 byte packets 1 router.asus.com (192.168.1.1) 2.671 ms 0.996 ms 1.035 ms 2 * * * 3 * * * 4 172.30.89.97 (172.30.89.97) 119.509 ms 12.377 ms 16.368 ms 5 172.30.35.69 (172.30.35.69) 29.432 ms 172.30.9.161 (172.30.9.161) 19.789 ms 14.916 ms 6 22.214.171.124 (126.96.36.199) 25.615 ms 25.803 ms 25.520 ms 7 cr2.kc9mo.ip.att.net (188.8.131.52) 33.190 ms 39.948 ms 31.791 ms 8 cr2.sl9mo.ip.att.net (184.108.40.206) 31.831 ms 30.923 ms 35.987 ms 9 cr2.cgcil.ip.att.net (220.127.116.11) 35.811 ms 32.269 ms 31.755 ms 10 ggr2.cgcil.ip.att.net (18.104.22.168) 96.169 ms 173.662 ms 31.426 ms 11 22.214.171.124 (126.96.36.199) 29.736 ms 29.467 ms 28.955 ms 12 ae2---0.cor01.chcg.il.frontiernet.net (188.8.131.52) 31.577 ms 33.271 ms 38.361 ms 13 ae1---0.car01.ftwy.in.frontiernet.net (184.108.40.206) 44.077 ms 46.896 ms 44.600 ms 14 * * * 15 * * * 16 * * * 17 * *^C
That is via a Mediacom connection. I switched over to a Frontier connection that I happen to have handy and ran the traceroute again:
traceroute to frontier.com (220.127.116.11), 64 hops max, 52 byte packets 1 192.168.1.1 (192.168.1.1) 3.033 ms 2.051 ms 1.182 ms 2 50-109-64-1.bltn.il.frontiernet.net (18.104.22.168) 25.556 ms 27.117 ms 24.808 ms 3 ae01---0.car02.bltn.il.frontiernet.net (22.214.171.124) 23.762 ms 35.961 ms 23.907 ms 4 ae3---0.car01.bltn.il.frontiernet.net (126.96.36.199) 38.245 ms 37.857 ms 36.997 ms 5 ae7---0.cor01.chcg.il.frontiernet.net (188.8.131.52) 91.912 ms 37.640 ms 27.502 ms 6 ae1---0.car01.ftwy.in.frontiernet.net (184.108.40.206) 115.455 ms 38.203 ms 38.660 ms 7 220.127.116.11 (18.104.22.168) 36.852 ms 41.143 ms 36.730 ms 8 22.214.171.124 (126.96.36.199) 38.250 ms 41.218 ms 37.705 ms 9 188.8.131.52 (184.108.40.206) 42.477 ms 37.212 ms 38.697 ms 10 * * * 11 * * * 12 ftr.com (220.127.116.11) 38.683 ms 38.508 ms 38.329 ms
It seems that 0.car01.ftwy.in.frontiernet.net does not accept traffic from a Mediacom source.
I’m sure this is legal, but it certainly makes me rethink using Frontier for any services.
Proper forensic analysis of anything starts with proper forensic collection of whatever it is that needs to be analyzed. UAVs are no different. As noted in an earlier post, there are a lot of components in a UAV system – radio controller, ground station, data/video link, and of course the aircraft itself.
We developed a UAS Acquisition Form to assist law enforcement and other interested parties in the collection process.
Consumer and commercial drones are hot – they are changing the way we farm, they are crashing on the White House lawn, they are leading to $50 million VC investments, and they are firing the imagination of Amazon, Google, and Facebook. And they’re not even legal for most people or companies to operate in the U.S.
They are also vehicles for malware, mischief, and cyber mayhem.
Let’s take a look at the cybersecurity landscape around non-military drones. And remember, a drone is really part of a sUAS – a small unmanned aerial system. (See my earlier post on this topic.)
First off, why might I want to launch a cyber attack against a drone?
- I could steal the entire aircraft – a DJI Phantom can go for $1,000 on eBay. Or just sell it for parts – a DJI camera and gimbal goes for $650, some cameras used for film making go for $20,000 and a LIDAR sensor can go for $50,000.
- I could steal the data, possibly without physically touching the aircraft and without the operator’s knowledge. Releasing film of a breaking news event would garner valuable attention while film of a private celebrity wedding would be worth tens of thousands of dollars. Crop data from a research farm would be valuable to competitors while data from a research track would be of great interest to a competing automobile manufacturer or race team. This data could be captured from another operator’s drone with little investment or risk on the part of the thief.
- I could hijack the aircraft and use it as a weapon or use it in a way that would generate bad publicity for the vendor or operator.
- I could disable, DDOS, the drone thus affecting the business operating it or the vendor. This could cause short and/or long term financial impact, even going so far as to put a competitor out of business.
- I could use the drone to inject malware into the ecosystem supporting it.
All of these are potential cyberattacks on someone else’s drone to affect the operator, the vendor, or an unrelated third party. If you use, develop, or support drones, you should consider your flight operations program, your critical assets, the possible effects on your sUAS, and very quickly start developing your risk management strategy.
There are some simple, classic, steps you can take:
- Insure your equipment and operations. Hull and liability insurance is available for sUAS.
- Physically secure your equipment. Someone with physical access can remove or compromise your sUAS.
- Operate using Visual Line of Sight guidelines. If your sUAS starts going off course, have a response plan in place to track and recover it in a timely manner
- Stay current on firmware updates. Unfortunately, the security measures implemented by the vendors are minimal or non-existent, but you should still try.
- Lacking firewalls in the sUAS environment itself, construct firewalls or air gaps around it. Use dedicated hardware to support it rather than using your personal mobile device for flight operations, for example. Be aware of opportunities for an attacker to remotely access it. Do not connect sUAS components to your corporate network.
- Configure your sUAS to fail safe. Ensure that the return to home feature is engaged and the home point is set for each flight.
- Choose sUAS solutions with inherent security. One popular vendor uses wifi for the data and control link, exposing their system to a wide variety of attacks. Using something other than wifi or bluetooth for the data link would greatly reduce the attack surface.
There are also some long term solutions, some of which benefit the entire community:
- Get involved with policy making. The US is on a road towards a very confusing patchwork of regulations at the state and federal level with respect to sUAS operations and cybersecurity in general. Advocate for clear, actionable regulation in both areas.
- Develop an in house cybersecurity program and ensure that it takes sUAS operations into account.
- Analyze the security of various sUAS offerings, share your findings, and encourage vendors to build security into their products.
sUAS, aka drones, are here to stay. We need to start securing them now, before they become embedded in our businesses, society, and lives.
So there I was, holding a dd image of a JFFS2 filesystem dumped from a drone. Great, good to go! Let’s start our analysis! Not so fast, mounting one of these things is non-trivial. After much trial and error, and some Google-fu, I got the following to work in the SIFT3 forensics VM (Ubuntu).
First, test to see if the image is recognized:
khorog:dot2 kovar$ file root.dd root.dd: data
Not a recognized filesystem and the most likely issue is big vs little endian. Let’s fix that:
apt-get install mtd-utils jffs2dump -b -c -r -e dest_file.little src_file.big
Note: The ‘-r’ was critical and none of the Google hits I found on this topic included it. This option “recalc name and data crc on endian conversion”.
Now, check the file again:
khorog:dot2 kovar$ file root-swap.dd root-swap.dd: Linux jffs2 filesystem data little endian
Then install a lot of kernel modules. (Some of these failed in Ubuntu 14 but the mount worked anyhow.)
modprobe mtdcore modprobe jffs2 modprobe mtdram modprobe mtdchar modprobe mtdblock
Now, mount the image:
dd if=root-swap.dd of=/dev/mtdblock0 mount -t jffs2 /dev/mtdblock0 /mnt/jffs2
[This is the first in a series of posts about the forensic analysis of drones leading up to presentations at BSides NOLO and SANS DFIR Summit in Austin.]
Drones (properly known as small unmanned aerial systems – sUAS) are all the rage. The market is roughly $600 million this year and is expected to be $5 billion by 2021. Drones will touch many aspects of your life, overtly and behind the scenes. They are already used commercially for mapping, precision agriculture, film making, and damage assessment. Illegal uses range from commercial services in violation of FAA regulations to surveillance and drug smuggling. And the hobby community is booming with drones as one of the hottest Christmas presents of the season.
With all of these drones in the air, the forensic analysis of drones is already important and making headlines. Who didn’t hear about the one that crashed on the White House lawn? The demand for analysis that will stand up in court is present and increasing. Tools will not solve the problem alone – we need forward thinking analysts who can work in a variety of disciplines, write their own tools, and go beyond existing techniques. Why? The key is in the final ‘S’ in uSAS. They are small unmanned aerial systems, these are entire networks with multiple operating systems in flight and spread across miles of terrain.
Let’s take a look at all the components of a popular consumer drone.
There are seven components in this unmanned aerial system:
- Radio controller
- Wifi range extender
- Mobile device
Each of these components potentially contains evidence relating to the incident you are investigating. The aircraft contains multiple sensors, a flight controller, radio links, a camera, motors, and more. The radio controller is pretty dumb but there are configuration settings stored in it that contribute to understanding the full environment. The laptop was probably used to maintain and configure many of the other components and will likely have artifacts relating to that work, along with the traditional Internet history, email, and messaging that might significant context. Even the battery stores digital artifacts about its history and health.
The analyst needs to physically collect and document all of these components, a potentially daunting process given that the components might be separated by time and distance. The type of motor, the custom labels on the radio controller, and the wear and tear on the propellers all tell their own piece of the story and must be correctly documented and analyzed.
Once the analyst obtains access to the physical components, they need to gain access to a variety of digital containers, and then analyze digital artifacts that range from firmware to EXIF data in photos to plists, registry settings, and /etc/mount files.
Here is a breakdown on some of the containers and artifacts associated with each physical component:
- Two Linux systems
- OneOpenWRT runningBusybox
- flight controller, media server
- Filesystem – squashfs, overlayfs, jffs2
- One Ambarella A5s IP Camera Reference Platform running Linux
- camera controller
- Filesystems – ubifs
- OneOpenWRT runningBusybox
- One micro SD card
- OpenWRT Linux system
- Wifi range extender
- squashfs, overlayfs, jffs2
- One USB port to configure the controller
- Queried via USB port on aircraft when attached to maintenance application on OS X or Windows
- IOS or OS X
- Many possible apps, including home-grown
A complete analysis of this system will be non-trivial, and a single tool will not give the analyst access to all the relevant information. There are several different flavors of Linux, at least one mobile operating system and at least one standard operating system. There are at least five different file systems, many of which are not recognized by commercial tools. Some artifacts are only accessible via USB and vendor defined protocols. Others require accessing the sUAS’s network and using ssh to connect to the systems. Some systems are running on flash media and maintain no state information after loss of power.
To further complicate the situation, each vendor will use a different collection of components, and those components will vary within their product line and new vendors will enter the market monthly. The open nature of the mission planning software and the flight controllers encourages customization. New sensors and new uses for drones will push both the application of drones as well as the legal and social borders around them.
The forensic analysis of drones, and the larger cybersecurity landscape around them, will be very complex, very fluid, and very exciting. Stay with us as we explore it in depth.