numbers, context, and background

one of the things i've come across while reading various sources is an attempt to pin down an intended target nation for the stuxnet worm based on prevalence data. the theory goes something like 'since nation X is where most instances of stuxnet are found, therefore nation X was the intended target (because obviously more work was put into spreading it there)'.

this theory has some problems, however. first and foremost is that not all the numbers agree. while we have symantec saying that ~60% is in Iran, we also have eset saying that ~60 are in the US just 3 days earlier. they can't both be right - or can they? and if they are, what are the implications for the targeted nation theory?

as is always the case when there are contradictory numbers, we have to look at how those numbers were arrived at. in fact, even when there aren't contradictory numbers, we should still be paying close attention to how those numbers were arrived at.

close examination of vikram thakur's post on the symantec site suggests that there number represents actual infected machines trying to connect to their C&C server (on top of everything else, stuxnet is also a botnet) during a 3 day period between july 19 and july 22. they were able to gather this data because they redirected the domains hosting the C&C servers to themselves so it seems like it would be a pretty accurate snapshot of the pool of infected machines at a particular point in time.

eset's numbers in david harley's post came from their installed clients throughout the world. their cloud-based technology reported the instances - however, since stuxnet employs stealth it's more likely that rather than reporting infected machines (where it would be active and hidden) it's actually reporting infected USB drives. it could also be reporting both if eset's products can see through the stealth, but the key point is that eset's numbers almost certainly include infected USB drives while symantec's do not. the USB numbers are important because that's how this worm spreads and if one were going to work on targeting a particular nation, spreading infected USB drives in that nation would be the way to do it.

furthermore eset's numbers appear to be from the time detection for the worm was added until the time the statistic was reported, rather than just the 3 day period covered by symatec's figures. this means that eset's figures represent a measurement of how many instances of the worm there were over it's detected lifetime to that point, while symantec's figures represent a measurement of how many infected machines remained at that point. this is important because by the time symatec started collecting it's data, negative population controls had already been in effect for some time.

controls which, like worms they intend to control, are not necessarily uniformly effective across the entire globe. some products have greater market share in some regions that they do in others, and the dominant product in certain regions might be poor at controlling particular worms and thus allow those worms greater reproductive advantages in those regions than they might find in others. the presence of population controls like anti-malware software affects both the death and birth rates of worm instances and as anyone who's heard johnny long discuss hackers for charity knows, such controls are not uniformly present or effective across all regions.

there are a actually a variety of other factors, in addition to such controls, that contribute to how well and in what way a worm or virus spreads, as discussed in some detail by jeff kephart, david chess, and steve white in "Computers and Epidemiology". some of these factors, like the degree of connectedness of susceptible hosts (and how often adequate contact between such hosts happens), can be influenced by computing culture, which in turn can be influenced by culture in the more general sense, geopolitical climate, and even socioeconomic considerations. hypothetically speaking, a nation that is cut off from US technologies due to trade sanctions (as metioned by by brian krebs) could well exhibit a higher rate of software sharing as part of 'alternative' procurement techniques and in so doing raise the region above the epidemic threshold for some unspecified worm.


ultimately both symantec and eset could be right since they were measuring different things over different periods of time. what that means for the targeted nation theory is that things aren't as clear-cut as either set of numbers would suggest on their own. what we do know is that stuxnet appeared to enjoy more reproductive success in Iran than elsewhere. whether that's down to purely epidemiological factors or intentional injection of the worm into the local computing population by a malicious actor is unclear, but eset's data would support an argument against the latter option as the effort seems to have been expended elsewhere. on the other hand, if we were to entertain the notion that the US was the target based on the amount of infected materials floating around the computing population, then we are left once again with the conclusion that stuxnet was a failure since in spite of all that effort the prevalence of actual infected machines in the US was minuscule.

i don't think much can be read into the fact that there were more infected machines in Iran than elsewhere since such pockets of infection are actually normal - especially for self-replicating malware that must be spread by physical media. some region had to draw the short straw and this time it was Iran.

poking holes in trojans

it seems like only days ago when this blog's longest comment thread in recent memory drew to a close after a heated discussion on the definition of trojan and now it seems that not long after both chet wisniewski and david harley posted blog entries featuring that very classification.

not only that but chet's usage of the word as an umbrella term for all non-replicative malware doesn't seem to match david's usage - nor does it agree with my definition (which i imagine probably doesn't exactly match david's either). all of which just goes to show that there really isn't a universally agreed upon definition of trojan. no matter which definition you use there are always some problems with it.

that being said, there are some ideas in chet's post that mirror topics brought up in the aforementioned comment thread and that i think should be brought out front and center.

starting with the low-hanging fruit, let's look chet's example of a trojan that you don't have to execute in order to become a victim of - that being the drive-by download. now i realize that my computer science background has allowed me to develop some rather transcendent notions of what execution means (even going beyond this), but i really don't think one needs to go that far to get the concept that when you open a web page you're executing it's contents. a web page is a container for data and a wide variety of executable content (from javascript to flash to activex to silverlight, etc) and, rather than bog down the user experience with endless prompts to execute this, that, and the other thing, browser developers decided that opening a webpage should result in the execution of whatever executable content it contains. this is something that doesn't get nearly as much attention as it probably should and as a result most people aren't aware of this rather significant detail (otherwise more people would be using noscript) and consequently make bad decisions about how to use the web. i expect that chet himself is all too aware of the executable potential of web content but he's not passing that knowledge on to the reader when he tells them that drive-by downloads don't require any user interaction. the user opened the page in the first place (or opened another page that lead to the drive-by download page being opened) so they did interact in the sense of executing something. clicking a link in your web browser isn't that much different than clicking an *.exe in your file browser, and if more people understood that they might be more careful online.

more generally, the notion that something can be a trojan without requiring the user to execute something seems very odd to me. it seems to me that a piece of malware that doesn't need the user to execute it, that doesn't need the victim to let it in past the defenses, simply doesn't bare much similarity to the legendary strategem from which the name trojan horse program is derived.

i realize that analogies shouldn't be carried too far but to say that all malware that doesn't self-replicate (basically everything that's left over once you remove viruses and worms) is a trojan horse makes me wonder why on earth they chose the term trojan horse in the first place. the definition and the name seem to have no obvious connection. perhaps at the time they simply hadn't conceived of any malware that didn't conform to the paradigm used by the ancient greeks, but is that still true today or could i conjure up some malware examples that just don't seem like they should be called trojans at all? for example, when we think about malicious software we often think about that which runs on the victim's computer, but what about malicious software that runs on the attacker's computer? a participatory DoS tool, for example, would certainly seem to belong to the malware set since it's malicious software, and it certainly doesn't belong to the self-replicating set, but can you imagine something whose malicious functions are both known and advertised being called a trojan horse? should we call every implement of war a trojan horse instead of just the actual hollow wooden horses? catapults will henceforth be known as trojan horses, trenches also, swords and guns and chemical weapons, all of it. while we're being absurd let's call everyone bruce in order to avoid confusion. g'day bruce.

how about an example that does execute on the victim's machine? now remember i'm trying to steer clear of anything the victim user would let in past his/her defenses so the question you might be asking yourself (after taking into account just how liberal my concept of execution really is) how on earth such malware would get onto the victim's system? the answer, of course, is that it's planted there by an attacker who has already gained access to the system. back in the early 90's (perhaps even earlier) there was this attack technique whereby an unsecured system would be used to sniff out enough information (generally login credentials) to compromise a more secure system (because users of the unsecured system might on occasion access resources on another system), which in turn would then be used to sniff out information to compromise an even more secure system and so on and so forth until the attacker reached his/her goal. the attacker would use a collection of tools, often including some sort of back door in the form of a modified system binary as well as a password sniffing program, that were at least in the beginning known as toolkits (eventually one of these toolkits got named "rootkit" and the rest, as they say, is history). now i'll admit that the modified system binary that provides a back door does seem to bare at least a passing similarity to what we'd think of as a trojan horse program even if the victim didn't let it in him/herself (it's something that the victim could have easily let through the gates if given the chance), but in this context, rather than baring a similarity to the trojan horse of old, this bares more similarity to converting an existing agent into a double-agent. additionally a password sniffer in and of itself doesn't necessarily strike me as being particularly trojan-like. it's a packet sniffer that filters what it captures. it's not even clear that it's malicious until you take the context of it's use into account.

that sort of context sensitivity is often cited as a property of the trojan set but i believe it is a property of the malware set (of which the trojan set is a proper subset). in fact i think the trojan set inherits that property from the malware set. i also think that at the end of the day it's that property which makes the question of how to define such a set pointless. the term "trojan horse program" should probably go down in infamy as one of the anti-malware community's great failures because in it's unqualified form it has been one of the most singularly unhelpful classifications. back when there were only 3 major subclassifications for malware (virus, worm, and trojan, as chet mentioned in his post) we had quite a successful anti-virus industry that handily took care of viruses and worms, but not really trojans. both viruses and worms have functional definitions and trojans (whether you consider them the complement of the self-replicative set within the malware set or something more specific) do not. it wasn't until we started carving out functionally defined subsets of the trojan set (such as spyware and adware) that we started to actually get a handle on trojans. problems need to be well-defined before we can hope to address them.

so maybe we should all just forget about trojan as an unqualified term and only use it when we're talking about things like remote access trojans or downloader trojans. while we're at it, let's make sure we continue to carve out new functionally defined subsets of the malware set when fundamentally new behaviour comes along so that we don't sit around gazing at our navels and lamenting how difficult it is to classify things as belonging to an ill-defined set. we've already had an anti-spyware industry, an anti-trojan industry, an anti-rootkit industry, etc. due to slow response by anti-malware incumbents - we don't need to keep doing that.

what's in a malware name

...that which we call conficker by any other name would taste as sour.

david harley, tom kelchner, and mary landesman have all posted their responses to an infosecurity article questioning the apparent lack of consistency in malware naming.

they all say more or less the same thing about the deluge of modern malware making harmonization of names impossible and to a certain extent they're right, but to a certain extent they're also wrong - not so much in the technical details of their answer but more in the way they're framing the problem that the infosecurity article was underlining.

now the truth is i had actually planned on writing about malware naming some time ago in response to another of david harley's articles in which he basically says malware names are irrelevant. i can see where he's coming from with that, and probably you can too. a malware detector doesn't care what the name of the malware is, only whether it's there or not - and the consumer of the malware detector generally won't care that much about the name either (certainly not whether it's the same name that all the other vendors use). in the consumer's worst case scenario all they really need is some sort of unique identifier, be it a number, a GUID, or some made up nonsense word (oh, wait, that's what they get now) in the event that they need to call up the vendor for support.

but there's a problem with this line of thinking and i'll demonstrate it with a little thought experiment. let's take all the bones in the human body and replace their current identifiers (such as scapula, ulna, radius, etc) with numbers, or GUIDs, or made up nonsense words. now try having an intelligible discussion about bones you've broken over your lifetime with someone. can you imagine how much more difficult that would be? obviously replacing their current names with the made up nonsense words would just pose difficulty in adjusting to new names but GUIDs would be far too unwieldy for people to use, and numbers would have numerical relationship baggage that would confuse the issues. let's take one more step in this thought experiment, however. let's say there are 50 different people, each with their own different set of replacement identifiers for the bones in the human body, and let's say that they collectively are trying to advise people on bone health. how well is that really going to work? not very well, obviously.

while it is true that malware today is far too numerous to harmonize the naming for each and every instance, we can't let the great become the enemy of the good. if the anti-malware world revolved exclusively around the production and consumption of malware detectors then names really would be unimportant and irrelevant, but the fact is in such a world people like david harley and tom kelchner and mary landesman wouldn't be blogging about such things because those blogs would also be irrelevant.

the thought experiment above demonstrates when names are important and why consistent names are important. names are important when you're dealing with people rather than just technology. they are important when you are trying to communicate information about threats, trends, etc. to people. people need names for things, and frankly they need to be fairly simple names - that's why storm, loveletter, and code red catch on while waledac, virut, and sality wallow in obscurity, and why people keep misspelling conficker. heck, it's why meteorologists name significant weather formations like hurricanes using human given names like harry or katrina. people also need for multiple authorities to agree on the names for things or else they can't integrate data from multiple sources and are left disoriented and confused.

again, we can't let the great (harmonizing the naming of all malware instances) become the enemy of the good (harmonizing the naming of the relative handful of malware instances the industry considers significant enough to write about in things like year-end threat reports). it may be impossible to coordinate names for each malware instance in existence and entirely pointless even if it were possible, but the same does not hold true for the small set of malware that vendors write about by name. just so we're clear, i'm not suggesting that such coordination need take place before releasing detection for the aforementioned malware. what i have in mind is something not unlike the now defunct common malware enumeration with the exception of using names instead of numbers - a post hoc harmonized second name (a common name or layman's name) for those few pieces of malware that the industry feels they need to communicate to the masses about.

of course, after all that is said and done, even if naming were consistent i fully realize that different vendors reports would list different sets of malware and to that end people still need to understand that such reports reflect not the actual threat landscape but what the vendor has seen of the threat landscape. to that end there should still be overlap between the sets of malware used by different vendors in their reports, and if there isn't that suggests sampling bias pronounced enough to render those models of the threat landscape irrelevant.

mcafee and malware creation

if you hadn't already heard, mcafee plans to teach a class on "malware experience" at a 4 day security conference they're holding this coming week. there were only a couple of reactions to it that i saw, notably david harley's post at threatblog and michael st. neitzel's post on the sunbelt blog. the sunbelt post in particular drew the attention of mcafee's dave marcus who clarified exactly what was going to be going on - to the extent that the controversy around the promise of showing attendees how to create new malware seems to have died a quiet death.

i could have weighed in when i first read about this but the wheels of change had already started to turn and i wanted to see where things went before i said anything. the end result, however, seems to be mcafee has placated people's concerns with hollow promises that instead of teaching people how to make malware from scratch, they'll instead be using an existing toolkit to create the malware. the implication is that since this toolkit produces malware that is already detectable (at least as far as mcafee's product goes) then they aren't really contributing to the malware problem. if you're detecting the distinct aroma of a barnyard right now, you're not alone.

there are a couple of problems here so lets go through them one at a time. the first is the simple fact that mcafee is in the anti-malware business. i've said this before and i'll say this again - if you're anti-X you shouldn't go around making X's and you sure as hell shouldn't encourage others to do so. the company's namesake reputedly got into trouble with the rest of the industry by offering such encouragement in the form of financial incentives (paying for new viruses). now in this new case it's all going to be done inside a closed environment to prevent undesirable consequences so there should be no problems, right?

wrong. the work in the classroom will take place in a closed environment, but i have no doubt that some of the attendees will subsequently play the home version of the game, running malware toolkits on their own environments and creating malware in less secured environments (you can't really believe that they'll learn everything they need to to handle malware safely in those 4 hours the class will run). a class like this encourages precisely this behaviour. it makes it seem ok for less experienced people to handle malware, and to that end even people who never attended the class will also play the home game if such behaviour is endorsed.

think that sounds far-fetched? it isn't, there are already well intentioned but ultimately unqualified people playing with malware and inadvertently contributing to the malware problem. it's been going on for years. sarah gordon covered this in her paper "The Generic Virus Writer II". that's a pill that the technologically inclined don't want to swallow, they think they understand malware well enough to prevent unintended consequences, but the reality is that most people lack the wisdom to appreciate the extent of their own ignorance.

finally, given the probable result of people playing the home game with the same malware toolkit used in the class, should they contribute to the malware problem they will do so in a way that benefit's mcafee because their product already detects all the output of the toolkit. they will be breeding demand for their product in an absolutely unethical way - by teaching people just enough to cause problems that their product can fix (others may as well, but it's impossible to know at this point).

mcafee is behaving irresponsibly and unethically, and i'm struck by how things seem to have gone full circle with them. while others seem to have let them off the hook because they're using a toolkit instead of teaching how to create malware from scratch, as far as i'm concerned the only difference is the sophistication of the malware creators they are going to produce. mcafee will be teaching a new breed of script kiddie and tarnishing the industry's reputation once again. congratulations on being part of the problem, mcafee folks.

the future of malware past

in the two most recent posts on eset's threatblog david harley has been talking about old malware... i don't just mean a couple months or even years old - seriously old malware from over a decade ago that none-the-less continues to cause problems for people...

in the first post david asked how this could be (and in the second pointed out that my answer was to more of a 'why' question than a 'how' one - just the kind of kick in the butt i need to remember to think twice and speak once)...

indeed, if you've got an on-access scanner you ought to be protected from old malware without even thinking about it, right? that simplistic view is certainly what most people have learned but if the infected disk isn't accessed until the computer is booting (a time when neither the on-access scanner nor the operating system itself are loaded yet) then that same simplistic view is proven to be a false sense of security...

that being said, the reason people don't think about or talk about or otherwise take special cases like this into consideration is the widespread (and false) belief that malware eventually becomes extinct... i've already stated numerous times that old viruses never die but what harm could that little mental shortcut really do? well, for one thing when left unchallenged it becomes a dominant pervasive belief... a belief so strong that certain best practices and safe hex behaviours like manually scanning disks before using them even though they're from your own backups or changing the boot priority in the BIOS to prevent possible boot sector infectors from getting an opportunity to execute fall out of common use and knowledge... a belief so strong that vendors may actually remove virus signatures from their signatures databases for performance reasons and eventually allowing viruses that have no good reason to still be around to once again cause problems for many people...

on the other hand, there's no way any reasonable person would accept a belief system that says old malware remains as much a threat now as it did when it was first released, so how should we think about this problem? i suggest that we think of old malware the way we think of landmines - long forgotten and unused but not entirely gone, and one false step and you may be hosed...

this goes for all malware, however one may rightly suggest that some malware won't age as well as others... malware that relies on some sort of infrastructure probably won't do so well in 10 years (when it's command and control network no longer exists or no one's listening to the domain it sends it's logs to)... older (pre-commercial) malware didn't tend to rely on such things though and viruses (due to their infectious nature) are more likely to find their way into backups and so be re-encountered weeks/months/years later... BSI's specifically may well prove to be the longest lived in practice because of their independence from and execution priority over the OS or most any other software component of the system... and of course since they're some of the oldest viruses (the first pc virus was a boot sector infector) and one of the first types to fall out of fashion, and since they're still causing problems, they're already off to a fine start...

foolishly forgetting or recklessly ignoring the the threat posed by old malware will ultimately make utilizing backups, archives, and just plain old media a bit like strolling through a minefield without a map... old malware won't go away, it will just lie dormant in the nooks and crannies of the computer world until we take that one wrong step and it comes back anew...