The Lawfare Drone Smackdown started as a fake grudge match with Alice Beauheim and a demonstration project in the proliferation of cheap, powerful robotic technologies to the consumer. But it ended with a different lesson: Cybersecurity is really important, and one ignores it at one’s great peril. Let me start by acknowledging that my victory today in the Smackdown is really the victory of a team---and not a small team either. What we came to call Operation Stux2bu (or sometimes Operation Suxnet, since the security on the Parrot AR.Drone kind of sucks) was a collaborative project of six people---all of whom contributed meaningfully to today's triumph. I coordinated the team and the weapons development and flew the drone, but I had an 11-year-old accomplice and a 14-year-old accomplice---who actually did the real-time drone hacks and the WiFi jamming. On the development side, my friends Robert Calhoun, David Rochberg, and Brian Lantz together taught us how the Parrot AR.Drone 2.0 communicates with an iPhone or iPad and how one might, uh, reeducate it to crash itself and then refuse to restart. Lantz helped me think through the physical side of drone offense, and Rochberg spent a number of hours writing attack software to automate one of the hacks he and Calhoun had taught us. The problem of the Smackdown turns out to be a far more interesting one than I understood when Alice and I first agreed to a drone dogfight. The reason is that the Parrot AR.Drone 2.0 is, at once, much more fragile and much more resilient than someone who has not played with one would intuit. It is fragile in the sense that it is easy to knock out of the air. Any slight interference with its rotors (a tree branch, say), and the drone simply shuts down and crashes to protect itself from greater damage. So causing a drone to crash is no problem---a point that tends to make offense easy and defense hard. But the AR.Drone is also strangely robust. Because it shuts down so quickly, before it is really hurt, it actually can be very hard to damage. It crashes, and then its owner simply relaunches it---perhaps with a scratch or two, but basically unharmed. The rules of the Smackdown require one not merely to crash the opponent drone but to prevent it from getting back up again. This turns out to be hard---a point that tends to make defense easy and offense very tricky. There’s another problem on the offensive side: The drone’s payload is extremely limited, and adding any weight to it will tend to impair flight. So in other words, the victorious drone will have to have a weapon that is (a) remotely-operable, (b) light enough for the drone to carry without impairing its flight, and (c) lethal enough not merely to cause an opponent drone to crash but to damage it beyond further flight. The more I played with the AR.Drone, the less convinced I was that this problem was reliably solvable by conventional means on a budget of $200. The conceptual breakthrough---turning to cyberwarfare---came from the 11-year-old accomplice (there’s a scary process point in that), who asked me one day as we were struggling with these tricky problems, “Why don’t we just hack the drone?” He emailed Rob Calhoun, and Operation Stux2bu was born. To understand Operation Stux2bu, consider how the Parrot AR.Drone actually works. It is not simply a remote control toy---like, say, a car controlled by a radio control module held by the user. It is built around a full-fledged computer, which is getting directions from another computer---the iPhone or iPad---which is in turn getting directions from the human controller. The on-board computer is running an embedded variant of the popular open-source operating system Linux, which hosts an all-important application that controls the drone’s flight. The flight control application listens for commands from the user and combines them with measurements from its various sensors to determine how fast to spin each of the four rotors in order to maintain stable flight. The result is remarkably effective; the AR.Drone easily recovers from, for example, external attempts to push it out of a hover position, and it still flies straight even after suffering the inevitable rotor damage that results from a crash. The flight control application can also engage in certain autonomous flight operations, such as going into a stable hover mode automatically on takeoff, or whenever it loses contact with its controller. The other applications running on the device support the video cameras, WiFi networking, file transfers, and so forth. The AR.Drone is actually a remarkable piece of engineering that is doing a lot of things along many axes for very little money. This fact makes it an unusually fun toy. Parrot also provides a well-documented API that allows the user to direct the flight control application at a low level. And this openness of the AR.Drone’s system also makes it an outstanding platform for the amateur hacker or roboticist, allowing the device to be customized using readily-available software tools. But the same openness that makes the AR.Drone so easy to play with makes it a bit of a nightmare from a cybersecurity perspective. The WiFi network is unsecured, meaning that you don’t need a password to connect to a drone’s network, and all transmissions are unencrypted---meaning that anyone can eavesdrop on the wireless communication stream. And once you do connect, the root (superuser) account onboard computer has no password---meaning that anyone who knows how to connect to it can have full control of the device. The only security a lay user can deploy, in fact, is a simple pairing function---which is to say that there’s a setting in the control software that lives on the iPhone that can exclude communications from other sources. This setting is turned off by default. In other words, there are two big vulnerabilities from which Parrot has left the AR.Drone entirely unprotected: the onboard control station---to which one might send unwanted commands---and the communications link that permits the user to operate his or her drone. As I say, Parrot has an excellent excuse here; the company is not designing a weapon or, indeed, anything that needs to be secure. It’s designing a toy that is supposed to link up with any iPhone that anyone wishes to use to control it. So this kind of free-access platform is surely a virtue in the company’s eyes. But notice how quickly that virtue becomes a vice when you actually have to rely on that platform to do something---anything---that someone else might wish to prevent you from doing. We developed four distinct attacks on the AR.Drone---each with different advantages and disadvantages. Two are meant to kill the opponent drone entirely, by shutting down its flight control software. (We looked into trying to control an opponent’s drone, rather than simply shutting it down, but that was significantly more work.) The first of these works with devastating speed if the opponent’s operator fails to turn on the pairing feature. Working around the pairing is a more complicated, error-prone, and time-consuming process, creating some time for the opponent to operate against our drone (and this attack thus incurs some vulnerability to us), but the net result is the same: a disabled drone. A third attack, my own creation, targets the WiFi link. It doesn’t kill the opponent drone, but it causes the opponent to lose control over it and puts the drone into hover mode while the opponent scrambles to regain control. Finally, we built one crude physical attack designed to finish off a drone that had been stunned using the WiFi attack---and as a hedge against a clever opponent who had taken steps to harden his or her drone against our two primary cyber attacks. (Having some Rube Goldbergesque contraption on our own drone also helps draw attention away from more effective attacks.)  We took rudimentary precautions to harden our own drone against similar attacks—though the WiFi attack actually resists easy defense and we remained vulnerable to that throughout the Smackdown. To be sure, if one were really serious about taking out defenseless toys, one would combine all of these attacks into a fully-automated script that searched the airwaves for drones and tried multiple attack techniques as quickly as possible, while at the same time implementing real security on one’s own system. But in the interest of sportsmanship (and laziness), we just assembled some basic tools and left the details of each attack in the competent hands of the youthful accomplices. Here’s a brief account of each of the attacks, along with some explanatory video.  

Attack #1: Quick Death With No Security

An opponent who has not thought through these issues at all and does not know to turn on pairing is in real trouble. From the moment he plugs in his battery, his drone is running a WiFi network that any computer can attach to---and the drone is not shutting out communications from computers other than his own control iPhone. So all an attacker has to do is connect to the target drone’s WiFi network, link up to the onboard computer (which has a standard default IP address) using “telnet,” and then instruct the onboard computer to reboot. This will crash the drone, as its computer system stops flying, shuts down, and restarts itself. The AR.Drone can’t fly without the flight control application, so the easiest way to make it stay down after reboot is to prevent the flight control application from running when the reboot takes place. As we are magnanimous in victory, we wanted something that could be easily reversed after the cessation of hostilities. We therefore followed Rob Calhoun’s suggestion of logging in, renaming the flight control application to something else, and rebooting the AR.Drone, When the drone reboots, it can’t find the file to which it looks to get its flight instructions and commands, and it thus won’t be able to fly. The drone is unhurt---assuming it wasn’t badly damaged in the initial crash---but it is also completely paralyzed. This attack can all happen in a few seconds---indeed, before the opponent even launches the drone if we want. Here’s how. While the opponent plugs in the battery, the 11-year-old accomplice scans the available WiFi networks on a laptop computer. He figures out which one corresponds to the new drone. He then connects to it as he would to any WiFi network. Using any a terminal program, he identifies the IP address of the drone (usually 192.168.1.1) and connects to it using “telnet.” In the AR.Drone’s default configuration, with pairing off, this command will give him root access to the onboard computer. If pairing is on, this will not work---as the drone will reject communications from the new source---and we need to use Attack #2. If Attack #1 is a go, the 11-year-old accomplice has only two quick tasks to perform. First, he changes the name of the flight control application (“program.elf”) to something else---anything else: “mv /bin/program.elf /bin/program-stux2bu.elf” will do nicely. Now, when the drone next looks for its program.elf file, which it needs to fly, it won’t find it. The job is finished with a simple “reboot.” The flight controller exits on reboot and the drone falls from the sky. After the reboot, the computer is perfectly healthy, but it is no longer running the flight control application. Game over. To restore the drone to normal operation, you simply log back in, rename the application to the original file name, and reboot once more. Here’s a video of the 11-year-old accomplice implementing and explaining Attack #1:

In two of our rounds today, this attack proved to be all we needed. Neither Alice nor John Procter turned on the pairing function on their iPhone, so the result---in both cases---was a very quick kill.  

Attack #2: Spoofing an iPhone with Pairing On

If the opponent has drunk her cybersecurity coffee, she will---at a minimum---have turned on the pairing function. This makes accessing the opponent drone’s computer more difficult and time-consuming. The pairing function will cause the drone to exclude communications from computers other than the one with which it is paired. To attack it, we have to convince it that our computer is the one with which it is paired­—before giving it its instructions to rename the flight control application and reboot. At the nuts and bolts level, the Parrot AR.Drone’s pairing is implemented with a Linux firewall rule that make it ignore network traffic from any device that does not have the MAC address (“Media Access Control”, nothing to do with Apple) of the paired device. MAC addresses are burned into every piece of networking hardware and are globally unique, so Attack #1’s method of simple walking through the front door won’t work: Grandma will only open the door for Little Red Riding Hood. The work-around of this method is that we can make our attack computer lie about its MAC address, essentially claiming that the wolf is Little Red Riding Hood. Since the drone has no cryptographic verification of identity, it accepts the lie. This is known as MAC address spoofing. David Rochberg was good enough to write a series of commands that automate parts of the process. This speeds matters up considerably, though the attack is still more cumbersome than Attack #1. It is also finicky in execution, and far less reliable---at least in our inexpert hands---and we went into the Smackdown not looking forward to having to use it. Here’s how it works in practice. Recall that the 11-year-old accomplice knows almost instantly whether pairing is on---figuring this out simply by attempting to access the opponent drone using telnet. If that attempt fails, he ditches Attack #1 and gets to work on Attack #2. The first thing we need for this attack is to know the MAC address of the iPhone we wish to spoof. David wrote a script (a “tcpdump” analyzer) that eavesdrops on a WiFi connection and returns the IP address and MAC address of each machine on that network. After running this dumper script, the 11-year-old accomplice identifies the controlling iPhone’s MAC address and runs another script that sets the MAC address of the accomplice’s machine to that of the legitimate controller. This defeats the firewall rule, and the AR.Drone can then be disabled using the same approach as in Attack #1---which we also automated.  Here’s a video implementing and explaining Attack #2:

The first line of protection against attacks of this nature is to make root access to the machine harder. The version of Linux shipped with the Parrot AR.Drone doesn’t have any provision for assigning a password to the root user, so we configured our version of telnetd to execute a simple password-challenge script when anyone connects. Because all communications with the drone are transmitted in plaintext---that is, unencrypted---this really isn’t much in the way of security. In fact, it is about the most pathetic authentication challenge imaginable---except that it’s better than none at all. If you want to get serious about defending your Parrot AR.Drone from evil-doers, Calhoun tells me you should start by encrypting the wireless transport layer. One approach is to switch the drone from "ad hoc" networking mode to "infrastructure" mode---that is to make the drone a client of some other WiFi network, rather than the base of its own insecure one. This can be done by configuring the drone to connect to a password-protected external base station. Directions for this are available. Switching to an infrastructure WiFi network should also increase wireless range, because WiFi base stations have better antennas. Beyond that, Calhoun says, you could look into recompiling the Linux kernel with the usual suite of cryptographic libraries. But this is far beyond our efforts. The problem with Attack #2 is that, in real time, it can be hard to pull off. The dumper program often takes a while to deliver the needed MAC address. The spoofing sometimes fails. And for reasons none of us could discern, the drone would sometimes boot us from its network spontaneously---or reject efforts to attach---when pairing was on. In practicing Attack #2, we often failed to do it successfully. And even when we succeeded, it sometimes took a while, and multiple tries. So while lethal, the attack was not reliable—and while we struggled to pull it off, our drone would remain a sitting duck. In practice, we never actually needed this attack. Only one of our opponents--Paul Rosenzweig--had pairing on. And in that instance, Attack #3 proved so effective that it ended the match just as the 11-year-old accomplice was ready to send the drone a kill. In retrospect, he and I are confident that it would have worked, but it didn't turn out to be necessary.  

Attack #3: Buying Time with a Handy WiFi Jamming Approach

I was concerned about Attacks #1 and #2, because---while lethal---they left gaps. What if an opponent set a drone password? What if he turned on pairing and Attack #2 took too long---or we failed to execute it properly---and he attacked us in the meantime? What if we ended up in a three-way round and needed to attack two drones at once? (This possibility was eventually obviated when the Smackdown judge, Shane Harris, organized the event without any three-way rounds.) We needed an attack we could deploy very quickly and which would hold off an opponent drone while we attacked it, finished off another drone, or simply regrouped and figured out what to do. I went on YouTube and Google looking for information about WiFi jamming. I figured that there simply had to be, somewhere on the market, a cheap product (under $200) that could jam a WiFi network. In fact, I learned, I already owned such a product: An old Android phone I no longer used. This Handy YouTube video claimed I could turn it into a WiFi jamming device and promised I could use it to clear out a Starbucks by making its WiFi network unusable (I haven’t tried that, and you shouldn't either. It's surely illegal.):

The attack has additional benefits. Even when the 14-year-old accomplice turns off the jamming---say, to allow the 11-year-old to access the WiFi channel to pursue his evils ends---the user usually still has to disconnect from the channel and then reconnect in order to reestablish control over the drone. Sometimes, we found to our delight, doing so causes the drone to ground itself---meaning that the attack could sometimes be more lethal than we originally understood. But this attack too has its weaknesses. For one thing, it is not a kill. For another, while we could deploy it very quickly, it’s not 100 percent reliable. Sometimes, we found as we tested it, the user could regain control of the drone, despite the jamming. Sometimes, control would flit in and out. We came to think of it as a great emergency measure---and potentially crucial in a three-way dogfight or in situation in which pairing is on---but more of a stopgap measure to buy ourselves time than our best initial attack. We also found that we could use it while implementing Attack #2---most of which involves configuring one’s own computer to spoof an iPhone and requires relatively little actual communication with the drone itself. Here is a video of the 14-year-old accomplice demonstrating and explaining the WiFi jamming attack:

One additional note about this attack: We remained entirely vulnerable to it throughout the Smackdown. As noted above, there are ways to secure the WiFi channel the drone uses and to encrypt its communications with its control module. But this is beyond me. So the way we fought, it was plausible that we might end up with a Drone Smackdown stalemate in which both combatants simply jammed the other’s WiFi signal---thereby preventing either from controlling their drones. We all live with risk, and Operation Stux2bu swallowed this risk. If Alice Beauheim figured out the WiFi jamming attack, we’d have to call it a draw. WiFi jamming was key to our initial victory against Paul Rosenzweig and we used it again when, in the middle of the final round, John Procter sent his drone careening into the field of battle. In both cases, it performed exceptionally well---causing almost instantly a total lack of control over the drone from which our opponents did not recover.  

Attack #4: Finishing Off a Stunned Drone with Dental Floss

Operation Stux2bu was left with the problem of a password-protected opponent drone. We could stun such a drone and hold it off using Attack #3, but we had no way actually to kill it. What’s more, an opponent who knew not merely to use pairing but to password protect her drone as well was likely to be an opponent whose offensive systems we had to fear. We needed a physical attack we could use against a stunned drone in the event that both primary cyber attacks failed. Brian Lantz and I had talked at great length about physical attacks, and he had built---out of wire and aluminum tubing---this nifty little windmill contraption that was designed to be mounted on the front of the drone and there to interfere with and damage the opponent drone’s rotors. Once we had the WiFi jamming attack working, however, we had no need to fly in such close quarters to another drone in order to interfere with its rotors. So another of Brian’s ideas began to appeal to me instead: dangling thin line with a light fishing weight at its end above a stunned drone and getting the line tangled in the rotors. We found that dental floss unfurled quickly and easily and suspected it would be harder to disentangle from the rotors than fishing line, and I also rigged this contraption to link the dental floss to the deployment of rubber cement: The idea was that we could simply hover a meter or so above a stunned drone, get the dental floss caught in the rotors, and the let the rotors pull the stopper out of the rubber cement container. We were never able to test this contraption in live action, however, because we only had one drone and didn’t want to damage it, but it seemed promising in the event we had to actually use the drone for combat. There was one problem, as things turned out: It was two heavy for the drone to carry. So in the end, we used the simplest of contraptions: a dental floss dispenser with a fishing weight on the end attached to the drone with Velcro. In the Smackdown itself, we never got to test that contraption either---since we just hovered while our cyber attacks took out the other drones---though Paul and his grandson took a similar approach and found the effect devastating when their lines at one point got entangled in their own rotors.  

The Slight Problem of Legality

Operation Stux2bu had one other problem we had to overcome: the law. The rules of the Smackdown made clear we were not allowed to violate any laws applicable in Washington D.C., and federal law does inconveniently make it a felony to maliciously hack computer systems. I wasn’t really concerned about prosecution, since the Smackdown was obviously a game, but I was concerned that one of my opponents might point out that Operation Stux2bu, by violating the Computer Fraud and Abuse Act, violated the rules of the Smackdown. I did what any executive branch official would do under such circumstances: I sought a friendly legal opinion from a lawyer who works with me. In a highly-classified opinion, a a redacted version of which I can now make public, the Office of Lawfareblog Counsel advised me that by entering the Smackdown, all of my opponents authorized attacks on their drones---including the computer systems on their drones. In the final round of rule revisions, which I drafted and on which all other entrants in the Smackdown signed off, the combatants all agreed on the following language: “all entrants in the Smackdown acknowledge the possibility of their drone’s destruction and authorize any and all efforts by other Smackdown participants to destroy their drone.” They also agreed to my carefully-drafted ban on ground-to-air attacks, a ban written specifically so as to exclude cyber attacks: “ballistics, battering devices, projectiles, nets, and water guns must be mounted on a combatant drone and cannot be launched from the ground.” Finally, OLC advised me that under the Constitution’s Editor in Chief Clause, I had the power to disregard mere acts of Congress that might inconvenience my efforts at victory in the Smackdown. The moral of this story is very simple: In any negotiation about LOAC, it pays to be the draftsman, and it pays as well to think hard about what sort of attacks you want to conduct before writing or signing onto rules.