April 10, 2012

A cyber weapon

Posted in Exploits, Uncategorized at 15:22 by Alex McGeorge

There’s been a lot of discussion in the security industry recently around exploits, 0-day, ethics and how the government fits in to all of this. I disagree with some points in the recent Washington Post article, specifically how they (and presumably the Pentagon) are defining a ‘cyber weapon’ and a few other things*.

Word Count: ~850

At RSA 2012 Dave Aitel made a presentation wherein he defined cyber weapons a bit outside of how people normally think. The tried and true metaphor (which I admit to using) is that exploits or frameworks are like guns, and if they’re like guns then it’s easy to classify them as ‘cyber weapons’. There has been some recent criticism of this idea which I think is well deserved.

Dave went in a different direction and gave Wikileaks and The Pirate Bay as examples of cyber weapons. The Pirate Bay being aimed directly at the MPAA/RIAA and Wikileaks primarily being used on the US government (though with more targeting options than TPB). I think Dave is probably right in classifying cyber weapons this way but one thing bothered me: a government can’t really field either of those two examples. So what does a .gov weapon look like?

Another point that Dave made was that a lesson of Stuxnet is “any factory, any time.” If we’re moving away from the idea of pieces of software being cyber weapons then I think it makes sense that the program (organizationally speaking) that made Stuxnet happen is a government cyber weapon. Consider some of the components and very specialized skill sets required to make this happen.

Let’s say that your program is designed to receive input in terms of a resource or ability you want to deny someone and the output of this program is a software product that affects that denial. As an example we’ll use a factory scenario, someone above you has decreed that factory X must be disabled for at least 30 days. For whatever reason it is not appropriate to conduct traditional sabotage and you don’t want to flatten the factory.

You need the ability to receive intelligence about the target quickly, like photos of the inside of the factory that show you all the different machines involved in making widgets. This is a substantial challenge given the levels of bureaucracy inherent in any government, I have to imagine it is difficult to pick up the phone and say “Yo, I need the pictures of this factory” and receive them in a timely manor.

You’ll need an industrial engineer to interpret the processes in place at the factory. What do I have to break or modify in order to keep the factory down for the maximum amount of time? It will probably be multiple pieces of machinery, for discussion let’s just say you need to control over a widget-maker.

Next you need to get the relevant design schematics of that widget-maker, all firmware versions that have been released to date and if possible access to physical widget-makers to practice on/test with. That has be acquired, installed and ready for testing ASAP.

Now you’ve got your team that reverses that firmware quickly and pulls out the bugs. Unless you know exactly what version of the firmware your target widget-makers are running you’ll need to find bugs that span across every version. You may very well be able to determine the firmware version but you can’t rely on it.

Next you have your team (which may be different from the previous team) to write up the exploits that affect the widget-maker in the way you want using the bugs previously found. Do you want to introduce subtle defects? Do you want to dump tons of hot iron slag onto a factory floor?

Finally you have a software engineering team, how am I going to deliver this into a factory? What other exploits from the shelf am I going to use and how do I integrate those? Remember that this type of software is more than just exploits, it may need to operate autonomously after you deploy it on a network you may not have a clear idea of.

In the end you get a USB stick that your field man plugs into something very specific at the factory.

The unit/program/organization that produced the software on the USB stick is your cyber weapon. The efficacy of that weapon is how quickly your program takes to deliver a software product that you can hand to some operator for their use.

Given the above example I think you’re looking at a development time of at least a few months. The Pirate Bay works somewhat similarly: your prep window is the time between when the movie starts filming and the premier, you have that long to engineer stealing it. Another interesting thought is that there’s nothing so specialized about this work that it can’t happen in private industry, which it seems the Pentagon is counting on according to the Washington Post article mentioned earlier.

This blog post brought to you by: The CLR Podcast

* The idea that these pieces of software are ‘stored somewhere’ seems a bit antiquated. I’d love to see a ‘cyber armory’ that’s a big room with stacks of USB drives.

%d bloggers like this: