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.
I’d been thinking about this for awhile, but conversations with Rob Lee and then a presentation with him really helped me clarify my thinking on this issue. Here goes:
If you are doing incident response, you are psychologically, if not operationally, in a reactive rather than proactive mode. To do it right, incident response needs to be part of your ongoing daily business process. True incident response only occurs during major breaches. As part of your incident management, you proactively – days, months, even years in advance – address the issues that might create a need to respond to an incident.
By managing incidents rather than responding to them, you:
- Reduce the severity of the incidents that do occur.
- Reduce the number of incidents that do occur.
- Shift from responding to incidents to managing incidents as part of your normal operations
- Reduce unforeseen expenses related to incident investigations
- Increase your visibility within the business, and thus the support for your organization
- Strengthen security posture (Thank you to Corey)
- Reduce stress on your staff and increase their job satisfaction (unless they are adrenalin junkies)
An incident management mindset depends on accepting a truism:
Compromise Is Inevitable – Something truly malicious has been in, is in, and will be in your environment.
If you accept that compromise is inevitable, why wait for it to happen? Why not get ahead of it, reduce its impact, and increase your resilience?
Which leads me to my second point – traditional emergency management has been doing this for decades. If you do a search for “Emergency management cycle”, you will find many images similar to the following:
Tornados, earthquakes, fires, automobile accidents, heart attacks, and many more emergencies happen daily. Rather than treating these as one off incidents that require all hands on deck, emergency services plan, recruit, train, and respond in a very calm, business like manner because it is their normal business. (I speak from 15 years of emergency management experience. Find a fire fighter in your organization and run this past them.) When a fire engine rolls up to a fire, does everyone jump out, run around, and add to the chaos? No, they respond in a very consistent, calm, and methodical manner.
Take a hard look at ICS – Incident Command System. FEMA has several short, online courses to familiarize you with it. Step back and think about how it might apply to your organization. The modular, scalable nature of ICS enables effective response to incidents by multiple agencies. Sounds like something that might apply to a breach investigation? (You don’t need to buy into all the labels. Just think about the core concepts.)
In closing, let me ask you to think on two points:
- Manage incidents, and the entire lifecycle, in a way that enables you to treat incidents as part of your normal operational tempo.
- Pay attention to how traditional emergency management works and learn from them. An enormous amount of thought and effort has been invested in emergency management already. Build on that rather than try to recreate everything.
I gave a presentation at SANS DFIR Summit in Prague this morning. My presentation was designed to introduce DFIR practitioners to the larger business context that they might be working within. This could help with career progression, avoiding frustration in the workplace, or developing your reputation within your firm to name just a few possibilities.
Any and all feedback on the presentation is welcome.
David Cowen announced that he has submitted a patent application for NTFS TriForce. Let me start off by stating that I admire David quite a bit, I think TriForce is very useful and pushes into new territory, and that I am not angry at anyone, least of all David.
That said, I’m very concerned. The discussion is going on over in G+. Here is my very off the top of my head contribution to what may be a very interesting discussion. I hope others chime in.
From the G+ post:
I think my response may have been phrased in overly strong language. I’ve given some thought to why – why I am concerned and why my response was more emotional than the situation warranted.
My perception was that your tool was well supported by the community, and that through your beta program, presentations, and blog posts you were engaging with the community to help develop it. I, rightly or wrongly, mentally lumped it in with other reasonably priced tools that were closely tied to the DFIR community. So when I saw your patent post my immediate thought was “There’s another tool that I’m not going to want to support any more.”
Your post set off warning bells in my hindbrain. My experience with patents has almost always been negative, and in some very personal ways at times. I’ve had colleagues say “I’m doing this for all of us” on more than one occasion. Even when they were being honest, there were negative repercussions.
I think you’re going to run into prior art issues, and quite a few of them. I think that this may be part of my emotional reaction. My perception is that the prior art may be the DFIR community’s work and I’m reacting to the perception that you may be trying, directly or indirectly, to patent the work of many other people.
I fear that you may set off an arms race in the DFIR community. Maybe it is going to happen anyhow and you’re just getting there first. I don’t really want to be a part of that, and I’m not going to be thrilled about watching it happen if it does occur.
Guidance is a very poor example to cite of good behavior with respect to public relations, community engagement, and good business decisions. If they are your model for pretty much anything, you’re elevating my level of concern.
There are other ways to protect and control your intellectual property without patents. Sharing your thoughts on why you’re going with patents rather than licensing would be helpful.
Someone asked me if I am angry. I’m not. I am quite concerned though and I look forward to seeing how this plays out.
ircollect is a Python tool designed to collect files of interest in an incident response investigation or triage effort. This is very beta code. I’m hacking on it regularly, using it to learn about internal structures, finding minor and major issues, …. Use it at your own risk! If you have advice on how to address issues I’ve encountered, please share ….
In the process of writing this, I added data run parsing and ADS detection to analyzeMFT so those are now available.
The github site has more details and will be updated much more regularly than this blog.
Running as local admin, it:
- Opens the raw disk
- Reads the master boot record, collects a copy of it, and uses the MBR to find partition and disk information
- Using the MBR information, it finds the NTFS partitions.
- Working from the start of the NTFS partition, it finds the $MFT
- It collects a copy of the $MFT and then builds a list of all the files on the system and their data runs
- Using the file list and data runs, it collects interesting files through direct reads from the disk, bypassing access controls.
All collected files are stored in a directory specified with the -d option. They are further organized by hostname and the date-time the script was run.
pip install analyzemft
VERY beta. Active development daily, often hourly.
Currently collects master boot record, $MFT, and live (corrupted) registry hives. User can modify table in ircollect.py to specify any files they desire.
Thank you to:
- Jamie Levy for mbr_parser
- Willi Ballenthin – bit manipulation code, lots of useful tips for analyzeMFT