Cyberwar: When the Drones Come To Roost
Summary: Allegedly, US Drone control computers are infected with a persistent piece of malware (a virus) that is logging pilots keystrokes as they fly their missions. So far the Air Force appears to be playing it as “no big deal” but we can imagine some of the consequences of it not being so benign.
“We keep wiping it off, and it keeps coming back”
- Anonymous government source, according to WIRED Magazine
- Malware in places malware shouldn’t be
- Data Leaks
- About the author, including links to other posts in this series
- Other chapters in this series
(1) Malware in places malware shouldn’t be
WIRED Magazine reports that the US drone fleet’s command-and-control systems at Creech Air Force Base are compromised by a piece of malware that appears to be logging keystrokes and otherwise, “We think it’s benign.” If having a keylogger on a weapons system’s command-and-control console is “benign” we don’t want to know what “malicious” is – though perhaps the operators of the Iranian reactor at Beshehr could share some of their experiences. There is, simply put, no way that malware should be able to get onto competently built control systems. There are plenty of ways it could get onto incompetently built control systems, starting with:
- Poor configuration management: Airman Bob installs some entertaining game software that happens to be infected with a malware loader.
- Cross-purpose usage: Airman Bob fires up a browser and surfs the web from the console, then goes to a site that hits the console with a malware loader.
- Deliberate infection: Airman Bob wants to be the next Bradley Manning and is thinking about how to collect some interesting material for wikileaks.
- Suborned administration: Contractor Phil, who works for the system integrator that built the console and/or its management network, added a little “extra something” when nobody was looking.
- Corrupted supply chain: One of the components of the system was deliberately targeted – similarly to the way Stuxnet was ‘aimed’ at Beshehr and Natanz – knowing that it would eventually be incorporated into a command-and-control console.
Those are all obvious possibilities and any information security practitioner with beginner-level expertise would be able to recommend counter-measures for the first three (don’t allow software installs, don’t allow Airman Bob to log in as local administrator, install execution control and system logging on the console, perform system integrity checks, lock down the USB ports and DVD-rw drives, etc.) It is, literally, basic stuff: my 70+ year-old musicologist mother’s computer is secure against those first three avenues of attack.
The last two of those potential avenues of attack are harder to protect against, but are also fairly typical system security issues that can be addressed by: regression testing and baselining, using a configuration management tool that tracks system changes and who performed them and when and why, bringing critical parts of system construction in-house, and isolating consoles into private or virtualized private networks.
(2) Data Leaks
We already can guess that the builders of the drones’ software took short-cuts. In 2009, it was discovered that militants were accessing data-feeds from the drones using a $26 piece of software that was developed during NATO’s intervention in Kosovo. The military’s response to these sorts of leaks has typically been “no classified material was leaked.” The lawyerly thinking behind this is apparently that battlefield intelligence – collected real-time by a possibly hostile force – isn’t “classified” it’s just important.
Some people apparently did not absorb the lesson of the leaked video of a
BBC Reuters news crew being massacred in Iraq. That was a public relations disaster of the first degree, which could replay itself if keystrokes and who knows what else leak straight from the command console of a drone. These kind of leaks don’t show us anything we don’t already suspect — but the difference between “intelligence” and “suspicion” is being able to confirm your suspicions with data. What we learn is that “misfeatures” of a critical system that were identified in 1999 remain unfixed in 2011. And, apparently, basic information security 101 principles remain “not in effect” in such a critical program (see note #1 below).
Let’s imagine something unlikely. Let’s imagine that the malware infecting the drone consoles is analyzed and, as the analysis proceeds, it begins to appear that the Government of Iran is behind it. Then, what do we do? The US and Israel have been standing around coyly saying, in effect, “you deserved it” to the Iranians with regards Stuxnet. Nobody from the US Government has publicly decried the Stuxnet attacks or even issued a denial of involvement. On the contrary, William Lynn put a heaping helping of waffle on his plate when asked about Stuxnet.
“[T]his is not something that we’re going to be able to answer at this point”
- William Lynn in response to the question “was the US involved in Stuxnet?”
Now, imagine that a very cramped shoe is on the other foot: how do you suppose we’d react? In ‘a Whole New Quagmire: Part 4“, the story ended with an unknown malware outbreak at Oak Ridge National Labs. At the time, my intent was to point to the question of how the US will respond if we’re served in kind. The Pentagon’s cybersecurity strategy says that acts of war in cyberspace will be treated like acts of war. So the question is, “was Stuxnet an act of war?” and, if the answer is no, then is our response to the Air Force drone-heads, “suck it up”? Or, if we found that it was plausibly the act of another power, with attribution comparable to that which exists for Stuxnet, would we be saber-rattling?
I’m surprised that as of 8:16pm EST, October 7 there haven’t been any fingers in Washington pointed toward Asia. Yet.
(1) “The story as I heard it” from several sources is that encryption was left out of the drone systems because, if it had been incorporated, it would have brought that program under the aegis of the National Security Agency, which specifies, implements, and controls encryption for the DoD. It was felt, probably correctly, that if NSA got involved in drone-building, the drone would become “gold plated” and would include ‘do not touch!’ classified black boxes that would cause design conflicts, cost overruns, affect battery life, etc. While that may be true, it seems completely absurd that some programmer didn’t take advantage of any number of software encryption approaches that would have inexpensively raised the barrier to entry. Inexpensive hobbyist r/c craft and utility/fire department/police drones use encryption.
(5) About the author, including links to other posts in this series
See the About the Authors page for information about Marcus J. Ranum
Other publications by Ranum:
- “The Problem with Cyberwar“, Rear Guard Security
The series Cyberwar: a Whole New Quagmire, by Marcus J. Ranum:
- The Pentagon Cyberstrategy, 2 September 2011
- “Do as I say, not as I do” shall be the whole of the law, 11 September 2011
- Conflating Threats, 14 September 2011
- About Stuxnet, the next generation of warfare?, 29 September 2011
- When the Drones Come To Roost, 8 October 2011
- About Attribution (identifying your attacker), 21 October 2011
(6) For More Information
Other posts about UAVs on the FM website
- “Filling the skies with Assassins” by Tom Engelhardt, 12 April 2009
- America’s dominance of the sky slowly erodes – inevitable or avoidable?, 22 September 2009
- The march of technology brings “The Forty-Year Drone War”, 26 January 2010
- James Bond is not just our hero, but the model for our geopolitical strategy, on the FM website, 18 May 2010
- America plays the Apollo Option: killing from the sky, Chet Richards (Colonel, USAF, retired), 26 August 2010
- Killing Machines: Promises and Limits, 17 February 2011
- The Psychology of Killer Drones – action against our foes; reaction affecting us, 28 September 2011
- Cyberwar: a Whole New Quagmire – When the Drones Come To Roost, 8 October 2011