stuxnet revisited

(some of you may have seen a very  early draft of this in your RSS feeds - a slip of the finger caused a publishing mishap)

even though it wasn't that long ago that i posted a number of scathing criticisms of the stuxnet worm, new revelations about the worm and also some of the discussion in this computer world article that asks "is stuxnet the best malware ever?" (and many others i've seen since starting this post) have prompted me to re-examine my opinion on stuxnet.

there have actually been a number of really good technical analyses of stuxnet, but things seem to fall down when people try to turn their technical analysis into a tactical analysis.

what does stuxnet have?

1. 4 0-day exploits
2. additional non-0-day exploits
3. the ability to determine if it's running on a plant floor vs. a corporate network so that it can avoid using some of those exploits in environments where the 'noise' they produce would be noticed by IPS/IDS
4. a windows stealthkit (also erroneously known as a rootkit)
5. a SCADA PLC  stealthkit
6. digital signatures on 2 versions of it's code using private keys stolen from 2 different sources
7. a centralized command and control communications channel (now controlled by Symantec)
8. a P2P update communications channel
9. the ability to alter the way the SCADA system controls a very particular (and as yet unknown) process
10. the ability to spread itself over the internal network of an organization via network shares and vulnerabilities
11. the ability to spread itself beyond the confines of a particular organization's network using removable media and the 0-day exploit for the LNK vulnerability (and an unorthodox implementation of autorun before the LNK exploit was added)
12. at least 3 distinct versions (the one prior to the inclusion of the LNK 0-day, the first version containing the LNK 0-day compiled in march, and a second containing the LNK 0-day compiled in june and using a different digital signature)
13. an infection counter to (in theory) limit the spread of the worm

4 0-days is impressive, no doubt about that. the SCADA specific payload obviously required an engineer with knowledge and experience and (in all likelihood) access to a SCADA system that matched the intended target. many of stuxnet's properties are impressive, but some of them have additional significance.

the stealthkits are intended to provide stealth (obviously) so as to keep the window of opportunity for the attack to succeed open longer than it might otherwise be. this implies a persistent presence will be required for the attack to succeed.

the digital signatures on the code also provided some stealth from the heuristic engines of anti-malware products.

the IPS/IDS avoidance also qualifies as a kind of stealth.

the C&C channel (aside from making stuxnet a botnet on top of everything else) implies that the attack is not 100% autonomous. certain actions only happen when stuxnet receives commands to do them. as such, stuxnet will be waiting when it isn't being given commands and this will require a persistent presence.

the update functionality also implies an intent to maintain a persistent presence; and not just persistent over a short term, persistence over a long enough time frame that some part of the attack code becomes no longer fit for use and needs to be updated.

the release of the version with the second digital signature extended the useful lifetime of the signed binaries by several years, as the first was set to expire in june of this year.

as you can see, a considerable number of stuxnet's properties point towards a protracted operation. the payload shows a number of indications that a persistent presence on affected systems would be required for the intended attack scenario to play out as planned.

at the same time, however, the delivery mechanism thoroughly compromises that objective by being noisy and ultimately is the reason the worm and it's significance were uncovered. with each new system a virus tries to infect, the probability that the infection will fail catastrophically (and thereby draw attention to the virus' presence) goes up. while there was a mechanism in place meant to limit the self-replication (and therefore the probability of that catastrophic failure occurring) a simplistic infection counter was obviously not enough to keep the worm from spreading far and wide and drawing attention to itself. you don't take this risk unless you can't be more targeted (or unless you don't know what you're doing).

once the worm was found out, the fact that it was a technical marvel worked entirely against it. if stuxnet had simply been just another dumb autorun worm it probably would have remained in obscurity (and indeed the earlier version that was an autorun worm did remain in obscurity despite having been discovered previously), but because of the novelty of it's execution technique (the LNK 0-day) additional attention was paid to it and the SCADA-targeting payload was discovered and everything snowballed from there.

i have stated previously that i consider stuxnet a failure, and that much hasn't changed. the fact that it's a technical marvel doesn't mean it can't also be a tactical failure. the history of viruses is littered with examples of technically sophisticated viruses that never even made it into the wild while buggy, braindead viruses somehow
proliferated.

stuxnet at least made it into the wild, but the conflicting objectives between it's payload and it's distribution mechanism (one was targeted, the other was not; one was silent and patient, the other was more like a smash and grab) means that if the people behind it haven't already accomplished their objective, it's unlikely they will now.  the C&C channel is already lost to them, the P2P channel will almost certainly be monitored for new versions of the worm with new instructions and/or a new C&C channel. the entire population of infected machines they built up is now a complete write-off because they didn't know how to maintain harmony between the distribution mechanism and the payload.

furthermore, since they were still releasing new versions as late as june 14, it stands to reason they had not yet achieved their objective at that point.

to date, siemens have only found 14-15 SCADA systems that have been infected and as i understand it, none have had their PLC's altered. there really doesn't seem to be much evidence to suggest stuxnet's creators achieved their goals.

while there's a lot of speculation floating around that i don't agree with, i am willing to speculate that the people behind stuxnet are relatively new to the world of doing bad things with computers - i don't mean vulnerability reseach, by the way, since they clearly have some talented people in that arena - i'm talking about being new at mounting actual attacks. cybercriminals have adopted a proven strategy of 'keep it simple, stupid' (KISS) and it has served them well. on the other hand the stuxnet creators tried too hard, made their attack too complex, and generally didn't show the same kind of polish or experience at launching a successful targeted attack that cybercriminals have shown.

i think being relatively new at this is actually compatible with the possibility of them state-sponsored. while we often like to attribute supernatural powers to government efforts in the technical arena (ex. NSA's cryptographic capabilities are often believed to be light years beyond what the private sector can do), the US government made it abundantly clear that sometimes (especially when it comes to attacks in cyberspace) that faith is not always well founded. i don't expect nation states to have the experience that cybercriminals do because they aren't out there actually mounting attacks as frequently as cybercriminals are (if they were, the 'pain' suffered as a result of all those attacks would have triggered a war by now).

after being reminded of the US military's incompetence in 2008, i'm now more willing to believe that this failure was the work of a nation state. however, i'm still not completely ruling out other possibilities. while the industrial process altering payload does indeed change this from an issue of espionage to an issue of sabotage, that doesn't (in my mind) rule out rivalry between businesses. certainly legitimate businesses are not generally known for attempting to sabotage their competitors or others, but less legitimate businesses (say those with ties to traditional organized crime) certainly are.

the one piece of speculation i absolutely cannot abide by, however, is the one about the target of the stuxnet worm. the idea that a nation was the target is ridiculous - do you know how easy it would have been to limit the worm to only spread on computers running inside that nation? surely the geniuses behind it could have made the distribution mechanism much more targeted than it was had a nation been the target (or had a nation contained the entire target population). this more recent theory that it was targeted towards a particular iranian nuclear facility means that whoever was behind it was willing to risk causing an environment disaster, so you'd tend to think those who'd have something to lose by being nearby would know better than to try such a thing. one of the most ridiculous ideas is that stuxnet was targeted for a single system, unique in all the world, and that it's got a fingerprint of that system that it's looking for. in order to generate such a fingerprint in the first place, the attackers would need unprecedented access to such a target; the kind of access that would completely obviate the need for an untargeted distribution mechanism.

but people persist on thinking that iran was in some way the target, and i think i know why. it's because people are thinking of stuxnet like it's some sort of military-grade cyber missile. they see a pocket of high infection density and think they're looking at the electronic fallout of a cyber bomb. under these conventional kinetic warfare sorts of analogies you expect the target to be somewhere around the epicenter. but, and i cannot stress this enough, this is the WRONG mindset to use when you're talking about a virus and we are talking about a virus! if you're thinking about this in those sorts of kinetic warfare terms then you're head is in entirely the wrong place (interpret that as you will). computer viruses behave like a disease - stop thinking about ground zero and start thinking about patient zero - stop thinking of blast radius and start thinking about epidemiology. think about how difficult it is to control or even predict the movements of a biological vector in a biological attack. without a an agent friendly to the cause doing the dispersal, you can't know where it's going to go first or most often - and even if you do have a friendly agent doing the dispersal you can't know where the disease will spread to afterward or where it will thrive best.

you cannot tell who or what the target was by looking at where the most infected machines were. that only tells you where the worm enjoyed the most reproductive advantage - and most importantly (as kaspersky's alexander gostev rightly points out) the infection populations change over time. the only way you're going to find out what the target was forensically is by finding the PLC(s) it was designed to alter. then, and only then, will you actually know what the target is - and without knowing who/what the actual target was, you cannot make reasonable guesses about the specific motivations behind the attack, and by extension you cannot infer attribution based on who had the most to gain.

but maybe these questions should be reversed. instead of trying to figure out the likely culprit based on who the target was, perhaps it would be better to track down the culprit and ask them who the target is. the two private keys stolen from two different companies in the same area in taiwan seems unlikely to be a coincidence. someone there is involved - even if their sole involvement was selling keys they stole onto a 3rd party, that gets you a lot closer to the people responsible than searching for PLC needle in a haystack.

the benefits of scanning in the cloud

now i know a good chunk of the general security industry has been poo-pooing the cloud recently, and normally av is the security industry's favourite whipping boy, so maybe this is just a case of two bad tastes that taste bad together... that being said, the concept has significant promise to take back several tactical advantages that av hasn't had in, well, forever...

1. signature generation to client update time is reduced/minimized
   
   usually a good thing and this time it isn't at the expense of q/a because rather than cutting a corner that affects quality they're cutting the corner of updating the client in the first place... instead they'll be updating the cloud which they have direct control over (unlike the client) and then the client doesn't need to detect that it's out of date and try to update itself (and hope updating hasn't foolishly been disabled)... this potentially gives vendors time to do more q/a on their signatures and so reduce the bad signature release rate (though it's already pretty low)...


2. under-reporting of new samples is reduced/minimized
   
   under-reporting is the single biggest advantage that targeted attacks have... without the law of large numbers favouring someone noticing there's something fishy about a particular file, that file doesn't get submitted for analysis and nobody gets signature-based detection capabilities for it... in cloud-based scanning, however, just about everything (except those things the user feels are too sensitive to transmit, and as such are probably not malware) should get submitted to the cloud so that is no longer an issue...


3. greater situational awareness/intelligence than ever before
   
   data on detections can be correlated and analyzed, etc. providing the potential for virtually every client to become a sensor in a giant honeynet... geographic and demographic trends/patterns in the attacks have the potential to be more easily seen with so much more real-world data, and those are things that can be used to better predict who's at increased risk or maybe even help to pinpoint the source(s) of the attacks...


4. conventional malware q/a should be entirely thwarted
   
   the ease with which current malware evades known-malware scanning is on the verge of becoming history... the basic methodology for evasion is to iteratively produce samples and run them past a slew of scanners to see if it's different enough to avoid them all (or enough of them to be valuable)... this worked in the past because malware authors could do this without anti-malware vendors being any the wiser... with a cloud-based scanner you can't fully scan a new malware sample without the vendor getting a copy (either the sample is submitted to the servers controlled by the vendor, or the sample is not submitted and the malware author gets incomplete/inaccurate detectability results) and thus letting the cat out of the bag about not only what your new malware looks like but possibly also what the heck you're up to ("hello, police, i'd like to report a large number of new malicious programs being generated at the following IP address")...


5. scanner reverse engineering is almost completely nullified
   
   before what we now know of as malware q/a existed, the more clever malware authors were believed to have reverse engineered various scanners looking for information they could use to make sure their malware would better avoid detection... and even today, those who deal in vulnerabilities (either for the betterment of security or for malicious gain) will analyze scanners looking for flaws that an attacker could take advantage of... with the scanning engine no longer residing on the client computer the only kind of analysis anyone without source code access can do is black-box analysis (and if a botnet can detect attacks and protect itself a cloud-based scanner should conceivably be able to as well)... in this way the scanning algorithm becomes as inscrutable as any server-side polymorphic engine...

i'm going to exploit DNS

which is to say i'm going to exploit everyone's interest in the DNS vulnerability dan kaminsky discovered in order to draw eyeballs... in other words: made you look!...

actually, i read on the recurity labs blog that every computer security blog on the planet had written something about the DNS vulnerability, and since i hadn't done so yet i was technically making a liar out of that blogger and that's no good...

problem is, though, that for the most part i really have nothing to say about the DNS vulnerability... i don't like writing about things i don't know and DNS is one of the many times many things i don't know all that much about...

the disclosure argument that ensued was somewhat familiar territory but it wasn't until i read andre gironda's comments to rich mogull's post about whose interests are being served that things finally crystallized in my mind about this... in a nutshell, the information is such that the vast majority of people have no legitimate need or use for it and so to keep it out of the hands of the black hats it really shouldn't be broadcast for the world to see, but at the same time there are enough people that may have a legitimate need or desire to know the information that any centrally coordinated effort to inform them will fail to include many and will only result in an exercise in elitism...

believe it or not, there's actually an old lesson from the AV field to be learned here because the AV community has had to deal with a very similar situation somewhere on the order of about a million times now... long, long ago they came up with a solution that actually works pretty well: a kind of darknet where links are formed between individuals who know and trust each others motives, competence, and judgment - basically a web of trust for sharing malware samples... the benefits are that the adherents to this approach avoid contributing to the sharing of information/materials with people who have no business handling them while at the same time giving everyone who may have a legitimate need or desire for the information/materials has a fair opportunity (but not a guarantee) to acquire them by virtue of being connected to someone else (or better still, many others) who has the means and desire to acquire it themselves...

it's not a perfect system, of course... there have been some instances where the wrong person was trusted, prompting people to rethink how they decide who to trust... there has also been no shortage of lazy bums who can't be bothered to put in the work necessary to actually earn the trust of at least one of their peers and instead whine about how unfair and elitist it is, like some petulant child who feels entitled to receive whatever s/he asks for... there's nothing stopping them from building the relationships necessary to participate in such a network but some people just don't understand that nothing worthwhile in this world is free...

i really think that the wider security community would benefit from adopting a similar approach to 'disclosure', and certainly in the case of the DNS vulnerability there could have been benefits if such a distributed trust-based network had already been established and was utilized... i say "already been established" because it can take time for a trust-based network to get connected and mature; but really, from a tactical point of view, information/intelligence gathering/sharing in hostile territory (and when we talk about broadcasting things on the global stage, the presence of hostile agents is beyond doubt) requires the use of covert channels such as this...

on the application of legal pressure in the fight against malware

thanks to a reader i was pointed towards an article about kaspersky's efforts to make the law a more effective tactical device for use in the battle against malware...

using the law this way is not a new or unusual idea - there are many sides to the malware problem, it has many different dimensions, and some of those involve people rather than technology... from a strategic point of view it makes sense to try and address the problem on all fronts and one of those deals with the people responsible for the malware, be they malware creators or just purveyors... the only way to force them to stop being part of the problem (well, the only legal way to force them) is by using the law to catch and prosecute them...

doing so is not a mark of desperation, it's not something you do simply because you are being overwhelmed by the number of malware being created, it is something you do if you're smart... it is a strategy designed to subject the blackhats to the forces of attrition and thereby control (to some degree) the number of people creating/using malware and by extension the amount of malware being spread around and the amount of malware out there at any given time that qualifies as new...

it's controlling the amount malware that qualifies as new at any given moment that is the most interesting/tempting benefit here... whether an anti-virus company can keep up with the rate of malware creation or not it doesn't change the fact that as rate goes up the number of pieces of malware that can't yet be handled by known-malware scanning at a particular moment in time also goes up and therefore so does the user's chances of encountering such undetectable malware... now at 200 a day, most of which have very low distribution, and hourly updates available, those odds aren't necessarily cause for alarm but you wouldn't want them to keep growing unchecked...

of course if you are being overwhelmed by sheer numbers, it can help there too, but being overwhelmed (as opposed having already been overwhelmed) is just another way of saying you're currently operating at peak capacity with your current resources - it doesn't make too much sense to keep people around if you aren't making use of them after all... you can either acquire more/better resources (which costs money) or you can try to get law enforcement to reduce the demand for those resources (guess which one is better for the bottom line)...

an important thing to note however, is that the law isn't likely to be any more effective at addressing the problem of cyber crime than it is at addressing the problem of regular crime... as such, hinting around about solving the malware problem (which cyber crime is a part) as the article does about solving the malware problem is misleading... the law alone isn't going to do it, the law in combination with other tactics isn't going to do it, the law is just an additional measure to help mitigate the problem...