Kevin is a Senior Software Engineer at Department 13, but is perhaps best known for his prolific internet presence working by himself and with a community of passionate programmers worldwide to expose vulnerabilities in the drone hardware ecosystem.
You made quite the splash in the tech world this year by showcasing some of DJIs security vulnerabilities. What did you find, and where can readers dive in deeper to your work?
There were multiple facets to the DJI security reveals from this year. The first was in the form of discussion on how to first gain, and subsequently retain control over your own property. DJI has had a notoriously closed system for a number of years, despite the fact that they have used Open Source as their foundation. Right to repair conversations become a very big problem in the drone community when you have vendors like DJI placing encryption, and obfuscation in the way of end users being able to maintain & adjust their own gear. For quite some time rumors circulated about being able to “root” or “jailbreak” DJI drone platforms, however no tangible evidence was available. I put quite a bit of effort into doing the required research and shared my subsequent results. This ultimately helped form the current DJI reverse engineering and jailbreaking community. This community has a staunch determination to retain control of their aircraft, and be able to tweak them as they wish. DJI on the other hand uses the guise of “safety” to help maintain a strong grip on the innards of their platforms. This has literally turned into a security arms race at this point. Every new DJI version contains a new countermeasure, and every new countermeasure has an army of reverse engineers and hackers waiting to circumvent it. The landscape has evolved quite pleasingly in the last year.
On the flip side of the drone security coin opposite the actual drone platform security, is the security of the information systems that help keep these platforms usable for end users, and serviceable by the vendors. Additionally new regulatory mechanisms are forcing new means of accounting, and enforcement for the various end users, and where they may or may not fly. One of the current DJI incantations is to collect Personally Identifiable Information about the end users that are asking for No Fly Zone unlocks, or High level SDK access. There was unfortunately an amassing of this PII in the form of stored digital assets on DJI’s servers, and said data was made available due to a comedy of errors in DJI employee handing of company secrets. Several DJI employees were found to have left access keys for various services on GitHub, as well as Public buckets on Amazon AWS. In the end DJI attempted unsuccessfully to hide some of these errors via DMCA threats sent through GitHub, and a CFAA threat sent via their lawyers.
I have documented this story as much as I was able to in the following PDF: http://www.digitalmunition.com/WhyIWalkedFrom3k.pdf
Paul Dot Com Security Weekly also interviewed me on the subject capturing much of the story directly from my mouth:
Both the DMCA notice, and my counter notice can be located here:
DMCA Notice
Counter Notice
What are the top things drone hardware manufacturers need to consider to create properly secure hardware?
Security is flat out not something that you can just bolt on after the fact. You need to have a subject matter expert involved during your development, and planning phases. Additionally make sure that any IT assets that your platform requires will also have the appropriate IT staff with a mindset geared towards security. To me the choice to invest in security is binary, either you are doing it, or you aren’t.
How could DJI have better handled the publicized dispute over their bug bounty program?
DJI could have flat out come to the table prepared, but they did not, seemingly because the PR opportunity was much greater than the actual desire to seek out security solutions from the community. They should have engaged folks in the community that have done this before such as HackerOne, or Bugcrowd, or LutaSecurity. I think the response from the community was very clear, the “comments section” on various articles spoke very loudly about how NOT to treat folks that come to you with security research on good terms. DJI seems at many steps to have chosen to be poster child for how not to do Bounties.
There is a lot of taking advantage of open source and GPL in the drone industry… Why does this seem to happen so often?
Generally speaking there is no one there to enforce it unless it is egregious, most end users don’t “care”, or even know why to care about GPL violations. People don’t understand for example if there was no GPL code on Mavic, it would cost you a lot more because DJI would have had to invest in writing more code, instead of just borrowing it.
Seeing folks like VMWare get sued for abuse of GPL hasn’t occurred often enough for large companies to fear potential ramifications. The use of GPL by many commercial companies amounts to the old adage “no cop, no stop” when coming to a stop sign that appears to have no traffic.
Link
You’re a long-time drone enthusiast and creator, what are some hardware or software components or products that you would love to see developed someday?
If I were being selfish, I’d wish that the old OpenPilot project could have a proper rebirth. I used to love the attention to detail both on the hardware, and software QA for flight control. Much of the industry has been built on the back of unpaid volunteers in a small handful of Open Source projects. Commercialization has caused rifts in the communities, and created haves, and have nots with regard to resources and funding. Many projects and individual volunteers have fizzled out completely as a result. I would love to see a mechanism by which the open source community could be rewarded more for the foundation that they laid down. The process of productization of the old foundation often forgets all of the folks that served as stepping stones in community. More importantly the productization has also priced some of the original players out of playing in the sandbox that they helped create, which is kind of sad.
I wish some of the old “for fun” communities were still able to thrive with out the looming threat of cost (due to rapid prototyping of hardware), and competition, and IP theft from larger entities. There are many ideas and potential logic blocks that could become product if it weren’t for resource hurdles and the inability to compete with certain players in the industry. The risk to the individual is too great… we’ve lost some of the “fun” in the hobby, as the investors have moved in and set up shop.
You currently work in the counter-drone technology industry, which has grown increasingly competitive. What differentiates Department 13 from the other options out there?
“Protocol mitigations”, we don’t fall under the standard category of “jammer”. Our flagship product MESMER doesn’t need to spam a communication link in order to have an effective mitigation. Several of our mitigations are what we call “finesse”, in which the underlying protocol has been studied, understood, and replicated. With a deep understanding of how devices communicate with each other, it becomes much easier to insert ones self into the conversation, and pretend to be either party on the communication link. Under the right conditions, and with the right technical resources it is possible to spoof, or manipulate UAS communications in a predictable fashion in order to provide “positive control”. Think of it as the ability for me to stand in between you and another person talking, and convince you both that you were talking to each other, all the while I was the one relaying the bits of conversation on, as I saw fit, potentially omitting, or manipulating it as I went along. Traditional systems in the same scenario would instead just stand in the middle and yell as loudly as they could and hope that it prevented the two parties from talking.
Anything you want to showcase or promote to our readers?
In the past few years I have given several talks that highlight some of my work in the CUAS & drone security space, they can be found linked below.
What is some advice or resources for new companies that want to take QA seriously in their development processes?
From a code stand point one of the most important concepts to grok is “Input validation”… you should always strive to write more intelligent code. Preemptive logic to check for the most basic of errors, and attempts at intentional manipulation or fault injection can go a long way. “Output validation” goes hand in hand with this concept, your application should always be returning values and data that you expect. When performing testing, don’t settle for checking for success in your implementations, go out of your way to test for failure conditions, and try to cause them! Familiarize yourself with fuzzing, and fault injection techniques, and make use of them.
What are the most interesting open source resources available to companies getting into drone or autonomous vehicle manufacturing?
I have found that many developers are not familiar with static analysis techniques, and as such many drone vendors appear to allow various security issues to slip through the cracks. Static analysis can help across various touch points in the process of bringing a drone to market.
Legacy tools like FlawFinder, and RATS can help provide an understanding of the various types of weaknesses your code may have before you deploy it.
FlawFinder
RATS
Additionally tools to help you check for deployment mistakes are great to have on hand. If you accidentally leave the keys to the city laying out in the open, it is nice to have a tool to help alert you. TruffleHog can be used to root around in Git repos for secret nuggets that have been inadvertently left behind. Git-secrets will help prevent you from making the mistake of publishing your secrets in the first place. Hackers will most definitely Truffle Hog your repos… you better, before they do!
https://github.com/awslabs/git-secrets
https://github.com/dxa4481/truffleHog
Open source methodologies like OWASP will also help you rope in organizational level security issues by helping your development staff understand the most common ways for attackers to leverage weak code.
https://www.veracode.com/directory/owasp-top-10
OWASP frameworks also provide libraries for various languages that you can use to help mitigate potential code level issues.
Link 1
Link 2
What do you see as the use case for counter-drone technology that will see the most action out in the real world driving value for users?
Situational awareness with mitigation options. At the end of the day many parties simply need to have a reliable way to know what is overhead, and when. Forensic accounting of drone traffic is becoming more and more valuable as devices proliferate into the NAS. Being able to detect a drone is one of the first steps in being able to have an authorization, authentication and accounting framework for UAS traffic. The reality is that there are various forms of authorized and unauthorized drones, and a gradient range of threats to cover both types. CUAS platforms are one of few ways to put eyes on the current drone situation, so that we can continue to model threats, and determine the appropriate form of action, or in some cases even confirm that no action is required. There are currently two types of systems, detection only (like AeroScope) in which you can only *see* a drone, but can’t do anything about it, and the second type are systems that can provide mitigations to the the things they see. In the case of jamming systems there may not even be the need to *see* the target, you can just carte blanche “jam all the things” and have some level of effect. The differences in system types come down to: Can I see it? Do I need to see it? What can I do about it if I see it? What can I do about things I don’t see?