if you follow infosec news sources at all, by now you've probably heard about the claim made by an anonymous pair of ex-kaspersky employees that kaspersky labs weaponized false positives.
more specifically, the claim is that engineers at kaspersky labs were directed to reverse engineer competing products and use that knowledge to alter legitimate system files by inserting malicious looking code into them so that they would both seem like files that should be detected and be similar enough to the original file that the competing product will also act on the legitimate file and in so doing cause problems for users of those competing products.
i've heard this described as fake malware, but for the life of me i can't see why it should be called fake. the altered files may not do anything malicious when executed, but they're clearly designed to exploit those competing products. furthermore, there is clearly a damaging payload. this isn't fake malware, it's real malware. it may launch it's malicious payload in an unorthodox and admittedly indirect manner, but this is essentially an exploit.
some consider the detection of these altered files to be false positives because the files don't actually do anything themselves, but since they have malicious intent and indirectly harmful consequences, i think the only real false positives in play here are the original system files that are being mistaken for these modified files.
by all accounts, this type of attack on anti-malware products actually happened. what's new here is the claim that kaspersky labs was responsible at the direction of eugene kaspersky himself. there's a lot of room for doubt. the only data we have to go by so far, besides the historical fact of the attack's existence, is the word of anonymous sources (who potentially have an ax to grind) and some emails that, quite frankly, are easily forged. circumstantially there's also an experiment kaspersky participated in around the same time frame that has similar earmarks to what is being claimed except for the part about tricking competing products into detecting legitimate files as malware.
i don't expect we'll ever know for sure if kaspersky was behind the attacks. doubts have been expressed by members of the industry, but frankly i've seen too many things whitewashed or completely ignored (like partnerships with government malware writers) to take their publicly expressed statements at face value. there are certainly vendors i'd have a harder time believing capable of this but there just doesn't seem to be sufficient evidence that the claims are true. the problem is that i can't imagine any kind of evidence the anonymous sources are likely to have that isn't easy to repudiate. had they taken a stand at the time (like someone with actual scruples would have done) they would have been able to put their names behind their claims - they may have lost their jobs but they surely would have been able to find employment with a different vendor because hiring a whistle-blower would have been good PR.
however, as it stands now, the anonymous sources have to remain anonymous. if they're telling the truth then they are complicit in kaspersky's wrong-doing, and if they're lying they are throwing the entire industry under the bus for no good reason (because this claim fans the fires of that old conspiracy theory about AV vendors being the ones who write the viruses). Either way, to have this claim linked to their real identities now would make them radioactive in the industry. no one would touch them, and for good reason.
long ago it used to be that the industry only employed the highest calibre of researchers. people who were beyond reproach. naturally, in order to grow, the industry has had to hire ever increasing numbers of people and old safeguards against undesirable individuals joining the ranks don't scale very well. increasingly people who aren't beyond reproach are being found amongst the industry's ranks and there appears to be no scenario where these two anonymous sources don't fall into that category. the inclusivity that the general security community embraces (and that the anti-malware industry is increasingly mimicking) has the consequence that blackhats are included. the anti-malware industry is going to have to either figure out if they're ok with that or figure out a way to avoid what the general security community could not.
devising a framework for thinking about malware and related issues such as viruses, spyware, worms, rootkits, drm, trojans, botnets, keyloggers, droppers, downloaders, rats, adware, spam, stealth, fud, snake oil, and hype...
Showing posts with label malware. Show all posts
Showing posts with label malware. Show all posts
Tuesday, September 01, 2015
Tuesday, December 16, 2014
no malware defeats 90% of defenses
yesterday, 'security expert' robert graham penned a blog post claiming that all malware defeats 90% of defenses - a claim made in answer to the FBI's claim that the attack on sony would have been just as successful against 90% of other companies. as you might well imagine, however, robert graham was in error.
the error isn't a straight-forward one, but it is one that most of the security industry makes. it's an error in framing.
the security industry likes to frame the problem as automaton vs. automaton because that facilitates the comforting lie they tell their customers. businesses see security (not incorrectly) as something that costs them time and money and so they search for ways to cut those costs. the security industry, flush with skillful sales people, tells businesses what they want to hear: that they can cut costs and automate much of security, leaving only a handful of personnel left to operate a little like janitorial staff - cleaning up messes and keeping the automaton running smoothly. likewise, the security industry tells consumers what they want to hear as well: that they just need to install a product and that product will take care of security for them automatically.
in security, however, your adversary isn't a thing, it's a person. malware doesn't defeat defenses anymore than a pick and tension wrench defeats the tumblers in a lock. malware is an object, not a subject. it may have some small measure of autonomy (some more so than others), but it doesn't defeat anything - it's not the agent in that kind of scenario, it's simply a proxy for an intelligent adversary.
intelligent adversaries are notoriously good at outsmarting automatons. robert graham provided a wonderful example of that in his own post when he described creating brand new malware that went undetected by the anti-malware software being run by his targets. what he failed to do was take appropriate credit. it wasn't the malware the defeated those defenses, it was a person or persons with APT level skill (even if it didn't require quite that much skill to pull it off - he described it as easy, but easy is a relative term). the targets were compromised, not because they were using substandard defensive technology per se, but because they were relying on automatons to protect them against people.
in a battle of wits between an automaton and an intelligent adversary, the intelligent adversary has the advantage by definition.
the error isn't a straight-forward one, but it is one that most of the security industry makes. it's an error in framing.
the security industry likes to frame the problem as automaton vs. automaton because that facilitates the comforting lie they tell their customers. businesses see security (not incorrectly) as something that costs them time and money and so they search for ways to cut those costs. the security industry, flush with skillful sales people, tells businesses what they want to hear: that they can cut costs and automate much of security, leaving only a handful of personnel left to operate a little like janitorial staff - cleaning up messes and keeping the automaton running smoothly. likewise, the security industry tells consumers what they want to hear as well: that they just need to install a product and that product will take care of security for them automatically.
in security, however, your adversary isn't a thing, it's a person. malware doesn't defeat defenses anymore than a pick and tension wrench defeats the tumblers in a lock. malware is an object, not a subject. it may have some small measure of autonomy (some more so than others), but it doesn't defeat anything - it's not the agent in that kind of scenario, it's simply a proxy for an intelligent adversary.
intelligent adversaries are notoriously good at outsmarting automatons. robert graham provided a wonderful example of that in his own post when he described creating brand new malware that went undetected by the anti-malware software being run by his targets. what he failed to do was take appropriate credit. it wasn't the malware the defeated those defenses, it was a person or persons with APT level skill (even if it didn't require quite that much skill to pull it off - he described it as easy, but easy is a relative term). the targets were compromised, not because they were using substandard defensive technology per se, but because they were relying on automatons to protect them against people.
in a battle of wits between an automaton and an intelligent adversary, the intelligent adversary has the advantage by definition.
so long as the security industry continues to tell their customers what they want to hear instead of what they need to know, those customers are going to continue relying on a stupid box to fend off smart people. that is a recipe for failure no matter what technology is involved.
Tags:
automation,
malware,
robert graham,
security,
sony
Monday, December 31, 2012
formula for the future
while reading over some of the prediction-posts that tend to spring up towards the end of the year it struck me that many of these predictions follow from pretty basic axioms. sometimes they're particular to the malware world but other times they're even more general and are simply combined with a malware concept to make a malware prediction. at any rate, i thought perhaps i should point out some of these things and help prediction-makers in the future, as well as to offer a different perspective on predictions of these types.
- the end of something as we know it - the only constant is change, you can never step into the same river twice (because having stepped in it the first time changed it), etc, etc. things are always different in the future than they were in the past. note that the prediction is rarely about the end of something but rather the end of something as we know it. all that means is that that something is going to change in a way that some people will consider significant.
- the dynamic equilibrium between focusing on software exploits and social engineering will continue to be dynamic - when exploits are hard to come by the bad guys will focus on social engineering to get the job done, because it is a job and they want to get paid. when exploits are easy to come by, focus on using them will increase because it's easier to fool an automaton consistently than it is to fool people consistently.
- software that has been popular to exploit in the past will continue to be popular to exploit in the future - bad guys will continue to focus on many of the same pieces of software because that's what their victims use and because they've had so much success there in the past. it's where the money is. good guys will continue to focus on many of the same pieces of software because that's what many people use and thus where the greatest impact can be made. in essence, so long as frequently exploited software remains popular among users it will continue to be a valuable target.
- we will learn more things about more things because of attacks - attacks are generally disruptive in one way or another. even if it's an attack that simply compromises confidentiality rather than availability, it still disrupts the process of using a system or service even if the system or service isn't itself disrupted. disruption has a tendency to highlight things that we would never have known if everything continued to run smoothly and the disruption had never taken place. disruption gives us an indirect view into things that might otherwise remain opaque.
- trends that are increasing will continue to increase, trends that are decreasing will continue to decrease - inflection points are rare. if they weren't it would be much more difficult to recognize trends in the first place. as a corollary, emerging trends will go mainstream.
- the world is increasingly being made out of computers, and as new marriages of old-tech and computers become mainstream the resulting new-tech will become a target for attack - everything new opens up new possibilities for attack, and everything that is made new by sticking a computer in it opens up new possibilities for attacking that computer. furthermore, the more popular something is, the more profit can be had by attacking it, and so the more tempting a target it becomes.
- people will grow tired of defending themselves the same way they always have and try to find new alternatives - it is a quirk of human nature that we are always looking for new things. it is also true that we are largely unsatisfied with our current defensive capabilities (for whatever reason).
- new defenses will be developed to ward off new attacks and those defenses will be met with new offensive countermeasures - this is just the same offensive vs. defensive cat and mouse game that it's always been and always will be.
- new platforms will offer promise and seem secure, until they stop - figuring out how to successfully attack something without a lot of prior knowledge is difficult and time consuming, but it eventually happens, and the more it happens the faster additional attacks can be formulated until eventually we recognize that the platform wasn't the promised land we had hoped for.
- everything old will become new again - over time, as new people shift into a population and old people shift out, that population will collectively forget the past. at least for a while until someone figures out how to do new things using old concepts and then a renaissance occurs. we've already seen that occur with stealth, as well as boot sector infection/modification.
if you see the shadow of a prediction you've made in the list above, congratulations, you probably made a formulaic prediction. don't feel bad, you get better results using a formula than by trying to pluck the future out of thin air.
Tags:
malware,
prediction,
security
Monday, April 30, 2012
prediction vs. tempting fate
how many of you reading this remember conficker? i certainly remember it, but i have a long memory, especially when it comes to regrets. you may recall an apology i posted some years ago concerning the possibility that i might have made a small contribution to the feature-set of that malware by way of giving the bad guys ideas.
well, from where i sit, that may very well have happened again, only it wasn't me this time, it was an AV vendor. now you might expect that, as a result, said vendor may become much more scrupulous about censoring themselves. it's no easy task, let me tell you, but it's certainly something that some of you (and myself included) probably expect from the people who are supposed to be protecting us.
alternatively, you might expect just an apology, under the philosophy that it's better to ask forgiveness than permission. that would certainly be easier, although accepting responsibility for negative outcomes is not generally considered good for the public image of a company. as an individual, owning up to one's mistakes and accepting responsibility is considered a mark of maturity, but the rules for companies are unfortunately very different in this regard.
which brings us to the thing you might not have expected, but probably should have - bragging about it as though it were a "prediction":
that link, by the way, points to this story on informationweek.com which in turn points back to a post on the f-secure blog where it was suggested that if the people behind the flashback malware for the mac upgraded to unpatched java vulnerabilities (it had only been using exploits for old, already patched vulnerabilities before) they might affect a lot more people.
is that a prediction or an instruction? f-secure's blog, as you might be aware, is one of the most (perhaps the most) widely read blogs in the entire anti-malware field. it stands to reason that if the people behind flashback are reading any anti-malware blogs, that one is probably on their list. even if it isn't, that particular post was about their efforts and would most likely have been forwarded by someone who was aware of their work (just as, in a small software development company, every press release, news article, and TV spot that mentions your work gets sent to everyone in the company).
would they have upgraded to unpatched vulnerabilities without that suggestion being made? perhaps, perhaps not. we'll never know. do all malware profiteers who use exploits for patched vulnerabilities inevitably upgrade to ones for unpatched vulnerabilities? that's doubtful - exploits for unpatched vulnerabilities are much harder to come by than ones for vulnerabilities that have already been patched. the transition is anything but inevitable, so there exists the very real possibility that f-secure's "prediction" was more like a self-fulfilling prophesy.
but of course, it sounds better if you call it a prediction. it sounds like something that adds value to their voice (though they have plenty already without that) and so helps to build the brand.
it seems to me that openly predicting what the bad guys are going to do next, or speculating on what they could do better, only invites them to take your advice. you might then capitalize on that with liberal amounts of spin, but at the end of the day is giving them ideas really so much more benign than giving them code? don't you tempt fate either way?
well, from where i sit, that may very well have happened again, only it wasn't me this time, it was an AV vendor. now you might expect that, as a result, said vendor may become much more scrupulous about censoring themselves. it's no easy task, let me tell you, but it's certainly something that some of you (and myself included) probably expect from the people who are supposed to be protecting us.
alternatively, you might expect just an apology, under the philosophy that it's better to ask forgiveness than permission. that would certainly be easier, although accepting responsibility for negative outcomes is not generally considered good for the public image of a company. as an individual, owning up to one's mistakes and accepting responsibility is considered a mark of maturity, but the rules for companies are unfortunately very different in this regard.
which brings us to the thing you might not have expected, but probably should have - bragging about it as though it were a "prediction":
that link, by the way, points to this story on informationweek.com which in turn points back to a post on the f-secure blog where it was suggested that if the people behind the flashback malware for the mac upgraded to unpatched java vulnerabilities (it had only been using exploits for old, already patched vulnerabilities before) they might affect a lot more people.
is that a prediction or an instruction? f-secure's blog, as you might be aware, is one of the most (perhaps the most) widely read blogs in the entire anti-malware field. it stands to reason that if the people behind flashback are reading any anti-malware blogs, that one is probably on their list. even if it isn't, that particular post was about their efforts and would most likely have been forwarded by someone who was aware of their work (just as, in a small software development company, every press release, news article, and TV spot that mentions your work gets sent to everyone in the company).
would they have upgraded to unpatched vulnerabilities without that suggestion being made? perhaps, perhaps not. we'll never know. do all malware profiteers who use exploits for patched vulnerabilities inevitably upgrade to ones for unpatched vulnerabilities? that's doubtful - exploits for unpatched vulnerabilities are much harder to come by than ones for vulnerabilities that have already been patched. the transition is anything but inevitable, so there exists the very real possibility that f-secure's "prediction" was more like a self-fulfilling prophesy.
but of course, it sounds better if you call it a prediction. it sounds like something that adds value to their voice (though they have plenty already without that) and so helps to build the brand.
it seems to me that openly predicting what the bad guys are going to do next, or speculating on what they could do better, only invites them to take your advice. you might then capitalize on that with liberal amounts of spin, but at the end of the day is giving them ideas really so much more benign than giving them code? don't you tempt fate either way?
Sunday, February 12, 2012
is the iphone really malware free?
friday morning mikko hypponen posted a tweet about the folks behind flexispy changing the look of their site, and i took the opportunity to pose a question to him about iphone malware. you see, flexispy is (or was) a piece of mobile malware that f-secure posted about about 6 years ago. not only that, but there's a version of the software for the iphone, so i found mikko's repeated statement that there was no malware for the iphone to be a little strange in light of the fact that both he and his company have been aware of software that seems to contradict that claim for quite some time.
the resulting discussion with both mikko and his colleague sean sullivan lead in 2 separate directions, so let's look at them in turn. first mikko responded with the following:
so what people really mean when they say no malware for the iphone is that there's no malware in the app store. this is an important distinction, because the iphone ecosystem (and by extension, the threat landscape) extends beyond the app store. when chris di bona attempted to downplay the threat malware played to android devices by pointing to google's efforts to keep their android marketplace clean, a number of folks were quick to point out that the android ecosystem extended beyond google's android marketplace, so it seems strange that people would forget the same line of reasoning applies to the iphone as well.
one other thing (well, the only other thing, really) that mikko said was:
but such unqualified claims are, as mikko has revealed, not technically true. it's not that there's no malware for iphones, it's that there's no malware in the iphone app store.
but wait, is that really true? is there no malware in the app store at all? i'm not sure that's true when we've recently been made aware of apps in the app store that collect and send personal information to a remote server without the user's knowledge or consent. but it's about time i turned my attention towards the much more verbose and nuanced discussion that sean sullivan and i had on the subject. perhaps he can shed light on why these personal info stealing apps shouldn't be considered malware. while mikko didn't question the classification of flexispy as malware, sean informed me that f-secure no longer calls it malware.
why exactly that stops it from being malware in general or spyware in particular in the context of mobile device security i still can't fathom, but sean offered up two things by way of explanation. one being a concern over being sued... by malware vendors. this rationale is something i heard from dr. solomon years and years ago, but i have to admit i had hoped that the industry had become less spineless in the interim. i guess that was too much to hope for. google may stand up to the government on behalf of it's users (perhaps not always, and perhaps it doesn't always succeed, but it has tried), but apparently anti-malware vendors only stand up for their users when there's zero risk they'll be challenged.
the other thing he offered was the following definition of spyware from google:
now, sean also pointed me towards the anti-spyware coalition's risk model description document. i had hoped it would help me to learn more about this "self-install" concept that sean assured me was part of an industry agreed upon standard definition. things didn't turn out that way, since the term "self-install" doesn't appear in that document, but the topic of installation and distribution do figure prominently in the contexts of both risk factors and consent factors. unfortunately this document from 2007 appears once again to be geared to desktop computing rather than mobile computing. that's probably not too surprising considering it's 5 years old now, but it does highlight the age old problem of letting context into the classification process. mobile devices are easier to gain illicit physical access to, as well as being shared more freely (and more frequently) in social circumstances by their owners. the issue of consent at the point of install has far less significance as a risk mitigation for mobile devices. furthermore, the issue of consent at the point of install pretty clearly drops the ball in the case of trojans because it's not necessarily fully informed consent.
as the risk model description document demonstrates, somewhere along the line the industry gave up on basing it's classification system on functional definitions. sean insists that this is a "stricter process" but i think it's more correct to say that it utilizes more criteria than a functional definition system would. utilizing more criteria doesn't always lead to a stricter process because not all criteria are created equal and, at least in the case of the risk model description document, some of those criteria are used to create exceptions (which are generally not the hallmark of a strict process).
one of the last things sean wondered is how could the AV industry possibly use my (supposedly) broader definition(s) and not be accused of FUD. now, aside from the fact that the industry is already accused of FUD (and worse) pretty much regardless of what they do, i think it's important to spell out one of the key differences between a functional definition and the kind of definitions that sean sees in use. definitions that include contextual evaluation are judgements, they engender choice and leave room for agendas. a functional definition has no judgement, it is purely descriptive of the functional capabilities of what is being classified. you can no more be blamed for saying software that spies is spyware than you can for saying water is wet or the sky is blue. there's no silver bullet to make accusations go away, but if you take judgement out of the equation it should render those accusations baseless.
so why is all of this important? because it appears that we've somehow stumbled upon a way in which malware can be classified as "riskware" instead of malware. nobody hears about the riskware classification, nobody cares. they hear "No malware for iPhones" and they shut the rest out because that's all they needed to know (or at least according to traditional notions of malware that should have been all they needed to know). classifying malware as something other than malware seems to be what's enabling people to make the "No malware for iPhones" claim, like some kind of terminological shell game. "No malware for iPhones" makes people think the devices are safe and worry free, but there are risks, and not just for those who jailbreak."No malware for iPhones" is creating a false sense of security and with the revelations that have been made about apple's abject failure to lock down a particular type of personal information and the near ubiquitous exploitation of that failure by app developers, it seems like the stuff of snake-oil.
i tend to think that when people face risks they want to know about them rather than be told there's nothing to worry about, and i tend to think that when those risks come in the form of software that acts against the user's interests, informing the user is the AV industry's job. some people don't want that to happen, they want their own interests to take precedent. if the AV industry allows that to happen through inaction (or worse, facilitates it) then they don't deserve the reputation they have for protecting the user. the industry may not be able to put AV software on iphones yet, but they can certainly do a better job of raising awareness of the risks than going around telling people there's "No malware for iPhones". maybe when public awareness is raised apple will change their ways.
the resulting discussion with both mikko and his colleague sean sullivan lead in 2 separate directions, so let's look at them in turn. first mikko responded with the following:
@imaguid No malware for iPhones. If you jailbreak your phone: all bets are off. Flexispy runs on jailbroken only.now to me, this gets to one of the hearts of the matter. when people say there's no malware for the iphone, they're only talking about non-jailbroken phones. the pertinent difference between a normal iphone and a jailbroken iphone is that normal iphones can only install apps from the app store. the app store is a so-called walled garden where all the apps go through a screening process to keep out undesirable programs.
so what people really mean when they say no malware for the iphone is that there's no malware in the app store. this is an important distinction, because the iphone ecosystem (and by extension, the threat landscape) extends beyond the app store. when chris di bona attempted to downplay the threat malware played to android devices by pointing to google's efforts to keep their android marketplace clean, a number of folks were quick to point out that the android ecosystem extended beyond google's android marketplace, so it seems strange that people would forget the same line of reasoning applies to the iphone as well.
one other thing (well, the only other thing, really) that mikko said was:
@imaguid ...and to top it all: we couldn't do anything about iPhone malware anyway, as Apple won't allow Antivirus products to iPhone.and you know what? why should they allow them when there's apparently "No malware for iPhones"? whether or not there is malware for the iphone, apple doesn't want people to think there is. there is this (rather old) idea that computers can be as easy to use as an appliance (like a toaster). this idea is actually very appealing. it promises computers that just work, computers that don't get malware, computers that are easy and safe and worry free. that promise is part of the secret sauce behind apple's marketing, but if they allowed AV products in then it would dispel the illusion of the appliance computer and apple's products would lose their lustre. it's very convenient, then, that AV vendors are willing to be complicit in apple's marketing by repeating the claim that there's "No malware for iPhones".
but such unqualified claims are, as mikko has revealed, not technically true. it's not that there's no malware for iphones, it's that there's no malware in the iphone app store.
but wait, is that really true? is there no malware in the app store at all? i'm not sure that's true when we've recently been made aware of apps in the app store that collect and send personal information to a remote server without the user's knowledge or consent. but it's about time i turned my attention towards the much more verbose and nuanced discussion that sean sullivan and i had on the subject. perhaps he can shed light on why these personal info stealing apps shouldn't be considered malware. while mikko didn't question the classification of flexispy as malware, sean informed me that f-secure no longer calls it malware.
@imaguid @mikko But they then added an installation interface, and we have since categorized it as riskware.that's right - in spite of the fact that it is designed and marketed as a tool for spying on other people, it is not classified as spyware or malware because it was given an installation interface - meaning that the attacker has to have physical control of the phone for at least as long as it takes to install an app. now, on the desktop this might be a meaningful mitigating factor, but on mobile devices where physical access is so much easier to achieve? come on...
why exactly that stops it from being malware in general or spyware in particular in the context of mobile device security i still can't fathom, but sean offered up two things by way of explanation. one being a concern over being sued... by malware vendors. this rationale is something i heard from dr. solomon years and years ago, but i have to admit i had hoped that the industry had become less spineless in the interim. i guess that was too much to hope for. google may stand up to the government on behalf of it's users (perhaps not always, and perhaps it doesn't always succeed, but it has tried), but apparently anti-malware vendors only stand up for their users when there's zero risk they'll be challenged.
the other thing he offered was the following definition of spyware from google:
Software that self-installs on a computer, enabling information to be gathered covertly about a person's Internet use, passwords, etc.apparently it's not enough that the software spies on you in order for it to be called spyware, it has to "self-install" as well. now i'm sure i must be missing something, because this definition seems to exclude anything where the victim is socially engineered into installing the software (it's hard to call it self-installing if the victim is the one installing it). it also seems to exclude anything that utilizes the particular trojan horse case where the software actually does perform the function it claims to, so the payload is additional functionality instead of strictly misrepresented functionality. a game that also steals passwords, a text editor that also sniffs network traffic, webcam software that just happens to send the video stream to a second undisclosed location in addition to the intended recipient - all of these are examples of software that ought to be called spyware but which the victim actually knowingly installs (because the undesirable functionality is unreported) and thus fails to meet the "self-install" criteria. this is precisely the type of situation users of the photo sharing iphone app called path faced.
now, sean also pointed me towards the anti-spyware coalition's risk model description document. i had hoped it would help me to learn more about this "self-install" concept that sean assured me was part of an industry agreed upon standard definition. things didn't turn out that way, since the term "self-install" doesn't appear in that document, but the topic of installation and distribution do figure prominently in the contexts of both risk factors and consent factors. unfortunately this document from 2007 appears once again to be geared to desktop computing rather than mobile computing. that's probably not too surprising considering it's 5 years old now, but it does highlight the age old problem of letting context into the classification process. mobile devices are easier to gain illicit physical access to, as well as being shared more freely (and more frequently) in social circumstances by their owners. the issue of consent at the point of install has far less significance as a risk mitigation for mobile devices. furthermore, the issue of consent at the point of install pretty clearly drops the ball in the case of trojans because it's not necessarily fully informed consent.
as the risk model description document demonstrates, somewhere along the line the industry gave up on basing it's classification system on functional definitions. sean insists that this is a "stricter process" but i think it's more correct to say that it utilizes more criteria than a functional definition system would. utilizing more criteria doesn't always lead to a stricter process because not all criteria are created equal and, at least in the case of the risk model description document, some of those criteria are used to create exceptions (which are generally not the hallmark of a strict process).
one of the last things sean wondered is how could the AV industry possibly use my (supposedly) broader definition(s) and not be accused of FUD. now, aside from the fact that the industry is already accused of FUD (and worse) pretty much regardless of what they do, i think it's important to spell out one of the key differences between a functional definition and the kind of definitions that sean sees in use. definitions that include contextual evaluation are judgements, they engender choice and leave room for agendas. a functional definition has no judgement, it is purely descriptive of the functional capabilities of what is being classified. you can no more be blamed for saying software that spies is spyware than you can for saying water is wet or the sky is blue. there's no silver bullet to make accusations go away, but if you take judgement out of the equation it should render those accusations baseless.
so why is all of this important? because it appears that we've somehow stumbled upon a way in which malware can be classified as "riskware" instead of malware. nobody hears about the riskware classification, nobody cares. they hear "No malware for iPhones" and they shut the rest out because that's all they needed to know (or at least according to traditional notions of malware that should have been all they needed to know). classifying malware as something other than malware seems to be what's enabling people to make the "No malware for iPhones" claim, like some kind of terminological shell game. "No malware for iPhones" makes people think the devices are safe and worry free, but there are risks, and not just for those who jailbreak."No malware for iPhones" is creating a false sense of security and with the revelations that have been made about apple's abject failure to lock down a particular type of personal information and the near ubiquitous exploitation of that failure by app developers, it seems like the stuff of snake-oil.
i tend to think that when people face risks they want to know about them rather than be told there's nothing to worry about, and i tend to think that when those risks come in the form of software that acts against the user's interests, informing the user is the AV industry's job. some people don't want that to happen, they want their own interests to take precedent. if the AV industry allows that to happen through inaction (or worse, facilitates it) then they don't deserve the reputation they have for protecting the user. the industry may not be able to put AV software on iphones yet, but they can certainly do a better job of raising awareness of the risks than going around telling people there's "No malware for iPhones". maybe when public awareness is raised apple will change their ways.
![]() |
| image from secmeme.com |
Monday, May 23, 2011
the mac malware phenomenon
i posted something to twitter earlier (which was already too big to actually fit in a normal tweet) but i think there's more to be said.
those who downplay the mac threat landscape by comparing it to the pc are missing the point. the mac will never be the pc, it'll never follow the same path or be in exactly the same place, but the mac community was sold false hope and many of them are either unaware or in denial about the fact that they were lied to.
one of the most crippling thing about mac security awareness is the pc comparison. people can't look past the fact that things aren't as bad for the mac. does that really matter? crime in your neighborhood likely isn't as bad as crime in a ghetto (unless you happen to be unfortunate enough to be living in a ghetto), does that mean it's safe to leave the door to your house or car unlocked? no.
stop thinking about the comparison, stop thinking about the pc entirely. imagine there are no pc's. think about the things that have happened in the mac landscape over the past several years and what they mean to the various subsets of the mac user population.
there are users who believe macs are immune to viruses. that was proven technically false five years ago (i wrote about it here). the viruses that have been produced may have never reached epidemic proportions, but epidemics are a poor yardstick for measuring risk. car crashes aren't exactly an epidemic, but you should still fasten your seatbelt.
there are users who believe macs are inherently secure because of their *nix lineage. this, in spite of the fact that the initial academic investigation of the concept of computer viruses involved successful experiments in a professionally administered unix environment. also in spite of the fact that rootkits originally come from the *nix family of platforms. also in spite of the fact that a security researcher renowned for successfully attacking the platform on multiple occasions has explicitly contradicted the notion that macs are especially secure.
there are those who believe that for something to be a real threat it has to activate by itself without user intervention, that something that requires the user's help is only an issue for dumb users. this despite the obvious success of social engineering attacks like phishing that are already platform agnostic.
there are users who believe macs aren't really a target of criminals yet. they believe that the criminals have bigger fish to go after so the mac isn't worth the effort. they believe criminals have to make an either/or decision about which platform to attack. these beliefs are in stark contrast to a nearly 4 year old reality of professional cybercriminals attacking the mac platform - specifically the zlob gang taking their already successful windows trojan and porting the important functionality over to the mac (which i mentioned here and here). the more recent example of java based malware is an indication that the cybercriminals are trying to take the either/or question out of the equation entirely.
and then there are those wonderful users who are actually security aware but somehow believe the rest of the mac user community is largely like them so the efforts to raise awareness of security issues are pointless and alarmist. this is even though it's plain to see that security aware people are a minority in any population. and as far as the mac user population goes, apple's marketing was quite clearly designed to appeal to people based on style, image, and simplicity, and told users that security was something they didn't have to worry about. to imagine such a population is somehow better at dealing with security issues than the average person seems more than unjustifiably optimistic.
macs can be attacked, they have been attacked, their attackers are enjoying increasingly numerous successes, and not enough mac users know it. it's a growing threat and there has yet to be a compelling argument put forward that it won't continue to grow. knowledge is the first prerequisite for people to be able to protect themselves. stop pretending everyone knows what you know or are smart enough to make the threat a non-issue, there's just too much variety amongst humans for that to be true.
those who downplay the mac threat landscape by comparing it to the pc are missing the point. the mac will never be the pc, it'll never follow the same path or be in exactly the same place, but the mac community was sold false hope and many of them are either unaware or in denial about the fact that they were lied to.
one of the most crippling thing about mac security awareness is the pc comparison. people can't look past the fact that things aren't as bad for the mac. does that really matter? crime in your neighborhood likely isn't as bad as crime in a ghetto (unless you happen to be unfortunate enough to be living in a ghetto), does that mean it's safe to leave the door to your house or car unlocked? no.
stop thinking about the comparison, stop thinking about the pc entirely. imagine there are no pc's. think about the things that have happened in the mac landscape over the past several years and what they mean to the various subsets of the mac user population.
there are users who believe macs are immune to viruses. that was proven technically false five years ago (i wrote about it here). the viruses that have been produced may have never reached epidemic proportions, but epidemics are a poor yardstick for measuring risk. car crashes aren't exactly an epidemic, but you should still fasten your seatbelt.
there are users who believe macs are inherently secure because of their *nix lineage. this, in spite of the fact that the initial academic investigation of the concept of computer viruses involved successful experiments in a professionally administered unix environment. also in spite of the fact that rootkits originally come from the *nix family of platforms. also in spite of the fact that a security researcher renowned for successfully attacking the platform on multiple occasions has explicitly contradicted the notion that macs are especially secure.
there are those who believe that for something to be a real threat it has to activate by itself without user intervention, that something that requires the user's help is only an issue for dumb users. this despite the obvious success of social engineering attacks like phishing that are already platform agnostic.
there are users who believe macs aren't really a target of criminals yet. they believe that the criminals have bigger fish to go after so the mac isn't worth the effort. they believe criminals have to make an either/or decision about which platform to attack. these beliefs are in stark contrast to a nearly 4 year old reality of professional cybercriminals attacking the mac platform - specifically the zlob gang taking their already successful windows trojan and porting the important functionality over to the mac (which i mentioned here and here). the more recent example of java based malware is an indication that the cybercriminals are trying to take the either/or question out of the equation entirely.
and then there are those wonderful users who are actually security aware but somehow believe the rest of the mac user community is largely like them so the efforts to raise awareness of security issues are pointless and alarmist. this is even though it's plain to see that security aware people are a minority in any population. and as far as the mac user population goes, apple's marketing was quite clearly designed to appeal to people based on style, image, and simplicity, and told users that security was something they didn't have to worry about. to imagine such a population is somehow better at dealing with security issues than the average person seems more than unjustifiably optimistic.
macs can be attacked, they have been attacked, their attackers are enjoying increasingly numerous successes, and not enough mac users know it. it's a growing threat and there has yet to be a compelling argument put forward that it won't continue to grow. knowledge is the first prerequisite for people to be able to protect themselves. stop pretending everyone knows what you know or are smart enough to make the threat a non-issue, there's just too much variety amongst humans for that to be true.
Friday, September 10, 2010
what is scareware?
scareware (also called rogueware, fake AV, rogue AV, and a host of other names) is a type of malware that pretends to be legitimate security software, often for the purposes of extorting money from the user.
the traditional method of operation for scareware once it runs on the victim's machine is that it will pretend to have found security threats on the system but inform the user that in order to remove them the user must pay to register the fake security software first. the security threats that it claims to find are used to scare the user into complying with the request for registration, but they are generally either non-existent or they were purposefully planted there by the scareware.
scareware can be introduced into a system by any number of means, including drive-by downloads, installation by other malware such as bots, droppers, or downloaders, or they could even do their fake initial scan directly from the web page that sells the scareware (sometimes with hilarious inconsistencies like scanning windows folders when you're browsing from a mac computers).
because scareware pretends to be something which it is not in order to socially engineer the user into paying the malware writers who created it, it qualifies as a type of trojan horse program. it doesn't have to try to hard in order to trick the user as users are very willing to believe anything claiming to be security, especially when it says the user is unsafe, in large part because legitimate security vendors have long trained users to trust them without question.
back to index
the traditional method of operation for scareware once it runs on the victim's machine is that it will pretend to have found security threats on the system but inform the user that in order to remove them the user must pay to register the fake security software first. the security threats that it claims to find are used to scare the user into complying with the request for registration, but they are generally either non-existent or they were purposefully planted there by the scareware.
scareware can be introduced into a system by any number of means, including drive-by downloads, installation by other malware such as bots, droppers, or downloaders, or they could even do their fake initial scan directly from the web page that sells the scareware (sometimes with hilarious inconsistencies like scanning windows folders when you're browsing from a mac computers).
because scareware pretends to be something which it is not in order to socially engineer the user into paying the malware writers who created it, it qualifies as a type of trojan horse program. it doesn't have to try to hard in order to trick the user as users are very willing to believe anything claiming to be security, especially when it says the user is unsafe, in large part because legitimate security vendors have long trained users to trust them without question.
back to index
Tags:
definition,
malware,
scareware
Tuesday, September 07, 2010
well mine's infinity big
so sophos seems to be a little late to the mine's bigger party, but at least they're following the go big or go home philosophy to make sure everyone notices them. which is unfortunate - for sophos.
see, while the numbers game that most vendors play sometimes has the faint aroma of snake oil, kris braun's bold statement that sophos 'currently detects an infinite number of malicious files' (with a big infinity graphic, no less) has an overpowering stench of snake oil.
it's one thing to use big but meaningless and impossible to verify numbers, it's another thing to claim things that are literally false. sophos can't currently detect an infinite number of malicious files because an infinite number of malicious files do not currently exist.
claiming to detect not only more than you can verify you detect, but more than actually exist is ridiculous. you might as well say you recognize 15 different boolean outcomes or can write out all 57 letters of the english alphabet.
sophos may, arguably*, have the potential to detect an infinite number of things, but that's a lot different than being able to currently detect an infinite number of things, and you can bet that the average person not only can't tell the difference but will look at the claim of infinite detection much like they would a claim of perfect detection (in spite of kris' explanations to the contrary).
so congratulations go to sophos for the ignominious feat of innovating in the field of snake oil. now please do yourselves a favour and stop being so boastful.
(*technically, an infinite number of files would require that some of those files be infinitely long, since limiting them to a finite length would also limit them to a finite number. since there is not yet a computer capable of holding an infinitely large file let alone indexing one, there's strong evidence to suggest that sophos cannot actually detect those malicious files that happen to be infinitely large and thus cannot currently detect an infinite number of malicious files.)
see, while the numbers game that most vendors play sometimes has the faint aroma of snake oil, kris braun's bold statement that sophos 'currently detects an infinite number of malicious files' (with a big infinity graphic, no less) has an overpowering stench of snake oil.
it's one thing to use big but meaningless and impossible to verify numbers, it's another thing to claim things that are literally false. sophos can't currently detect an infinite number of malicious files because an infinite number of malicious files do not currently exist.
claiming to detect not only more than you can verify you detect, but more than actually exist is ridiculous. you might as well say you recognize 15 different boolean outcomes or can write out all 57 letters of the english alphabet.
sophos may, arguably*, have the potential to detect an infinite number of things, but that's a lot different than being able to currently detect an infinite number of things, and you can bet that the average person not only can't tell the difference but will look at the claim of infinite detection much like they would a claim of perfect detection (in spite of kris' explanations to the contrary).
so congratulations go to sophos for the ignominious feat of innovating in the field of snake oil. now please do yourselves a favour and stop being so boastful.
(*technically, an infinite number of files would require that some of those files be infinitely long, since limiting them to a finite length would also limit them to a finite number. since there is not yet a computer capable of holding an infinitely large file let alone indexing one, there's strong evidence to suggest that sophos cannot actually detect those malicious files that happen to be infinitely large and thus cannot currently detect an infinite number of malicious files.)
Tags:
anti-malware,
anti-virus,
kris braun,
malware,
snake oil,
sophos
Wednesday, September 01, 2010
of logic and malware
i've been accused of (among other far more odious things) having formal training/education in the area of logical debating. i don't actually have said training, but i do know a thing or two about logic, so when i read ed moyle's post on security curve about the industry's flawed logic as it relates to malcon it didn't take me long to realize how ed's logic (rather than the industry's) had gone pear-shaped.
to quote:
likewise ed's premises have problems. starting with his minor premise, the details about how to make the blue pill were actually not given out. those details were behind a pay-wall rather than being freely handed out at the talk. furthermore, the classification of the blue pill as malware is questionable at best. just because it's a so-called 'rootkit' doesn't mean it's malware - the reason being that current use of the term 'rootkit' has become so twisted (by which i mean anything that hides things gets called a 'rootkit' now) that even anti-malware products got called rootkits. the blue pill was a novel stealth proof of concept. it could have been used in conjuction with actual malware, but the blue pill itself was not malware.
that tells me, at the very least, that the blue pill was the wrong example for ed to use. we can correct that, however, by using a better example. the race to zero would be a much better example because it involved the creation of actual malware (modifying existing malware to make something that has never been seen before is for all intents and purposes the creation of new malware), which is precisely what malcon aims to facilitate and so makes for a much closer analogy.
unfortunately, even if we replace the reference to the blue pill with a reference to the race2zero, ed's minor premise is still problematic. is the race to zero still not a good enough example? is there a better one? the fact is, no matter what blackhat/defcon presentation you select as an example you will never be able to improve the premise because it would still be just one presentation. blackhat/defcon are about more than just the race to zero or the blue pill. the blackhat/defcon conference pair focus on a wide variety of security issues, many of which not only deserve to be highlighted but also contribute to the betterment of the security condition in three well defined ways. they highlight problems that:
we also gain no technical benefit by supposedly trying to open a dialog between malware writers and anti-malware researchers.
now the question one might be asking is, if ed's logic is flawed, what logic would be better? well, for starters i really don't like the major premise, minor premise, conclusion construct - i prefer the premise, inference [, inference...], conclusion construct.
to quote:
i can use a similar pattern to equally questionable results:
- Major premise: All conferences that provide details on how to create malware are a “bad idea”
- Minor premise: Blackhat/Defcon provide details on how to build malware (e.g. the Invisible Things Blue Pill presented at Defcon 2006; stated goal, “creating 100% undetectable malware”)
- Conclusion: Blackhat/Defcon is a “bad idea”.
- major premise: cats are furry
- minor premise: marmaduke is furry
- conclusion: therefore marmaduke is a cat
likewise ed's premises have problems. starting with his minor premise, the details about how to make the blue pill were actually not given out. those details were behind a pay-wall rather than being freely handed out at the talk. furthermore, the classification of the blue pill as malware is questionable at best. just because it's a so-called 'rootkit' doesn't mean it's malware - the reason being that current use of the term 'rootkit' has become so twisted (by which i mean anything that hides things gets called a 'rootkit' now) that even anti-malware products got called rootkits. the blue pill was a novel stealth proof of concept. it could have been used in conjuction with actual malware, but the blue pill itself was not malware.
that tells me, at the very least, that the blue pill was the wrong example for ed to use. we can correct that, however, by using a better example. the race to zero would be a much better example because it involved the creation of actual malware (modifying existing malware to make something that has never been seen before is for all intents and purposes the creation of new malware), which is precisely what malcon aims to facilitate and so makes for a much closer analogy.
unfortunately, even if we replace the reference to the blue pill with a reference to the race2zero, ed's minor premise is still problematic. is the race to zero still not a good enough example? is there a better one? the fact is, no matter what blackhat/defcon presentation you select as an example you will never be able to improve the premise because it would still be just one presentation. blackhat/defcon are about more than just the race to zero or the blue pill. the blackhat/defcon conference pair focus on a wide variety of security issues, many of which not only deserve to be highlighted but also contribute to the betterment of the security condition in three well defined ways. they highlight problems that:
- should not have happened
- can be fixed
- can be avoided in future designs now that we know what to watch out for.
we also gain no technical benefit by supposedly trying to open a dialog between malware writers and anti-malware researchers.
- for reactive defenses the only prospective benefit would be to help analysts understand the malware. but going back as far as 2006, the average piece of malware could be processed in as little as 5 minutes, so understanding malware doesn't really seem to be something analysts need help with.
- for proactive defenses the hypothetical benefit would be in letting the analysts know what sort of things are coming so that anti-malware products can catch them before they've even seen them. unfortunately this model is based on predicting the future precisely enough that we'd know specifically what to look for and, as such, is unworkable. the proactive defenses that work are the ones that actually know less, not more, about specific threats whether past present or future (thus why they're called generic techniques).
now the question one might be asking is, if ed's logic is flawed, what logic would be better? well, for starters i really don't like the major premise, minor premise, conclusion construct - i prefer the premise, inference [, inference...], conclusion construct.
- premise: malware is bad
- inference 1: since malware is bad, creating malware is bad (with the exception of benign exploits)
- inference 2: since creating malware is bad (with one exception), helping others create said malware by doing things that can reasonably be avoided is bad
- conclusion: since malcon will help people create malware by doing something that could reasonably be avoided, malcon is bad.
Tags:
defcon,
ed moyle,
malcon,
malware,
malware creation
Friday, August 06, 2010
why the stuxnet worm is an abject failure
in a previous post i called the stuxnet worm an abject failure, and intimated that it was because it was a worm. some might wonder why i said that when there have been a number of worms in recent memory (conficker, for example) that have spread far and wide and were considered successful, not just in spite of becoming widespread, but rather because of it. why should the stuxnet worm be subjected to an apparent double standard?
to understand why you have to look who the intended pool of victims are for the malware in question. for most common worms or viruses the goal is to infect or infest as many machines as possible. there is no special subset that is being targeted, they're just looking to add computing resources to their attack platform; where that attack platform can be used for anything from simply infecting/infesting still more machines to something as complex as building a botnet. anything where more is better.
in this kind of scenario there is a rather large number of machines for which public knowledge of the attack makes little or no difference with respect to whether the attack succeeds. the virus or worm will be able to thrive within this population because the machines are poorly administered, have misconfigured anti-malware software (assuming it's present and enabled at all), and no special mitigating steps have been taken to deal with the possibility of getting infected by the virus or worm (like disabling autorun, for example). if you guessed these were home user machines you'd be right (although there are a significant number of these in other environments as well). these are generally considered low value targets so the people charged with taking care of them generally don't do all that good a job.
the stuxnet worm, in contrast to this, was targeting machines that controlled industrial processes like manufacturing, power generation, water treatment, etc. these are, quite clearly, near the opposite end of the spectrum of valuable targets. as a result the people tasked with taking care of these machines are generally trained professionals who, in all likelihood, will take special steps to mitigate the threat of a new attack that specifically targets those machines once that attack becomes public knowledge.
and therein lies the rub. self-replicating malware does not stay below the radar. malware that makes copies of itself always winds up drawing attention to itself. each copy it makes increases the chance that someone will catch on, and when someone does that's the first step in the inevitable process of the attack becoming public knowledge.
consider the difference between plant eating animals and meat eating animals. plants don't generally react to protect themselves when they sense a plant eater coming near them, but prey animals definitely do react to protect themselves so meat eaters have to behave in a way that prevents their prey from knowing they're coming. if meat eaters bumbled along like plant eaters they'd never catch anything and eventually starve. they'd be abject failures just as the stuxnet worm is.
to understand why you have to look who the intended pool of victims are for the malware in question. for most common worms or viruses the goal is to infect or infest as many machines as possible. there is no special subset that is being targeted, they're just looking to add computing resources to their attack platform; where that attack platform can be used for anything from simply infecting/infesting still more machines to something as complex as building a botnet. anything where more is better.
in this kind of scenario there is a rather large number of machines for which public knowledge of the attack makes little or no difference with respect to whether the attack succeeds. the virus or worm will be able to thrive within this population because the machines are poorly administered, have misconfigured anti-malware software (assuming it's present and enabled at all), and no special mitigating steps have been taken to deal with the possibility of getting infected by the virus or worm (like disabling autorun, for example). if you guessed these were home user machines you'd be right (although there are a significant number of these in other environments as well). these are generally considered low value targets so the people charged with taking care of them generally don't do all that good a job.
the stuxnet worm, in contrast to this, was targeting machines that controlled industrial processes like manufacturing, power generation, water treatment, etc. these are, quite clearly, near the opposite end of the spectrum of valuable targets. as a result the people tasked with taking care of these machines are generally trained professionals who, in all likelihood, will take special steps to mitigate the threat of a new attack that specifically targets those machines once that attack becomes public knowledge.
and therein lies the rub. self-replicating malware does not stay below the radar. malware that makes copies of itself always winds up drawing attention to itself. each copy it makes increases the chance that someone will catch on, and when someone does that's the first step in the inevitable process of the attack becoming public knowledge.
consider the difference between plant eating animals and meat eating animals. plants don't generally react to protect themselves when they sense a plant eater coming near them, but prey animals definitely do react to protect themselves so meat eaters have to behave in a way that prevents their prey from knowing they're coming. if meat eaters bumbled along like plant eaters they'd never catch anything and eventually starve. they'd be abject failures just as the stuxnet worm is.
Monday, August 02, 2010
what is a crimeware kit?
a crimeware kit is a product and/or service that allows a prospective online criminal to carry out his/her criminal enterprise without needing the technical know-how to build that enterprise in the first place.
the technical aspects of an online criminal enterprise that a crimeware kit might typically provide for the criminal/customer include the malware itself which is often some sort of bot, a command and control interface, and potentially a facility for spreading the bot to new victims and thereby increase the size of the botnet.
by taking all the technically challenging parts of the online criminal enterprise out of the criminal's hands a malware kit could be said to create a turn-key system for online criminal enterprise. it's users could likewise be considered the professional criminal equivalent of script kiddies.
back to index
the technical aspects of an online criminal enterprise that a crimeware kit might typically provide for the criminal/customer include the malware itself which is often some sort of bot, a command and control interface, and potentially a facility for spreading the bot to new victims and thereby increase the size of the botnet.
by taking all the technically challenging parts of the online criminal enterprise out of the criminal's hands a malware kit could be said to create a turn-key system for online criminal enterprise. it's users could likewise be considered the professional criminal equivalent of script kiddies.
back to index
Tags:
crimeware kit,
definition,
malware
Monday, July 05, 2010
no i will not disable my anti-malware...
... or any part thereof just because you think it's causing your software to crash on my system.
and who is giving users the 'lower your guard for a better experience' advice today? why google of course.
and yes, i did notice that they only suggested disabling the internet monitoring; well guess where most new malware is coming from these day - yeah, that's right, the internet. some parts of an anti-malware product may be a little less useful than others but internet monitoring, when the internet is a major malware vector, is really kind of important.
i know google has a few smart folks when it comes to security, but they were also rather famously compromised using ancient microsoft software. one wonders if they disabled anti-malware protection in that case too. i'd like to see some of the security know-how that a few of them have distributed more broadly across the entire company so that well-meaning but misguided engineers don't give out dangerous advice in the name of improving the user experience with the browser.
and who is giving users the 'lower your guard for a better experience' advice today? why google of course.
Other software has incompatibilities with Google Chrome, but you may be able to solve your crash issues without disabling the entire software.now, to be fair they did also suggest upgrading, and that is a good option - in fact it should have been the only option they offered when it came potential anti-malware software conflicts for a couple of reasons.
If you have Internet Download Manager (IDM), disable the 'Advanced browser integration' option within IDM (go to Options > General).
If you have NVIDIA Desktop Explorer, try removing the nvshell.dll library using the steps on this site: http://www.spywareremove.com/security/how-to-remove-dll- files/
If you have FolderSize, try the fix on this site: http://sourceforge.net/tracker/?func=detail&aid= 2900504&group_id=127365&atid= 708425
If you have NOD32 version 2.7, upgrade to the latest version of NOD32 or disable internet monitoring in NOD32 2.7.
- turning things off is a lot less hassle than upgrading so if people think it'll work they're more likely to take that option
- the current landscape is such that anti-malware software is most people's only defense against malware.
and yes, i did notice that they only suggested disabling the internet monitoring; well guess where most new malware is coming from these day - yeah, that's right, the internet. some parts of an anti-malware product may be a little less useful than others but internet monitoring, when the internet is a major malware vector, is really kind of important.
i know google has a few smart folks when it comes to security, but they were also rather famously compromised using ancient microsoft software. one wonders if they disabled anti-malware protection in that case too. i'd like to see some of the security know-how that a few of them have distributed more broadly across the entire company so that well-meaning but misguided engineers don't give out dangerous advice in the name of improving the user experience with the browser.
Tags:
anti-malware,
google,
malware
Tuesday, June 22, 2010
general purpose, what's it good for? absolutely too much
here's a blast from the past. over at tenable security blog this article from january by marcus ranum discusses the possibility of developing special purpose computers for the sake of online banking.
he comes to an interesting conclusion that we may be seeing a market develop for non-general purpose computers but what we have to keep in mind is that it is not the operating system that determines whether a machine is general purpose or not - if we want special purpose machines we have to start at the hardware layer. i know some people find it hard to believe that it's not the operating system that enables malware to be a problem but to demonstrate that that is indeed a fact let's look back to the old bootsector infectors: viral malware which executes and infects before the operating system is even loaded into memory, using nothing but the hardware API's. clearly, generality transcends the OS.
in order to produce a machine which is guaranteed malware free (in order to use as a trusted endpoint in online banking) we have to address either the generality of interpretation (which most people don't really understand, but which is the cornerstone of general purpose computing) or the sharing of data (which would be counter to the design requirements of any system that needs to communicate with another system - such as an online banking dumb terminal). those are the 2 key elements of general purpose computing that enable malware to exist, and since we can't really get rid of sharing for the application in question that just leaves getting rid of the generality of interpretation in favour of fixed first order functionality.
the consequence of doing this (creating a radically different hardware architecture that only allows for fixed first order functionality) means that we can no longer use commodity hardware. that means we would no longer enjoy the benefits of commodity hardware pricing. that in turn means that the cost of ownership of one of these dumb terminals will be rather high compared to commodity computing counterparts. i don't know if the theoretical market for such special purpose computers can withstand the practical realities such a device would entail.
he comes to an interesting conclusion that we may be seeing a market develop for non-general purpose computers but what we have to keep in mind is that it is not the operating system that determines whether a machine is general purpose or not - if we want special purpose machines we have to start at the hardware layer. i know some people find it hard to believe that it's not the operating system that enables malware to be a problem but to demonstrate that that is indeed a fact let's look back to the old bootsector infectors: viral malware which executes and infects before the operating system is even loaded into memory, using nothing but the hardware API's. clearly, generality transcends the OS.
in order to produce a machine which is guaranteed malware free (in order to use as a trusted endpoint in online banking) we have to address either the generality of interpretation (which most people don't really understand, but which is the cornerstone of general purpose computing) or the sharing of data (which would be counter to the design requirements of any system that needs to communicate with another system - such as an online banking dumb terminal). those are the 2 key elements of general purpose computing that enable malware to exist, and since we can't really get rid of sharing for the application in question that just leaves getting rid of the generality of interpretation in favour of fixed first order functionality.
the consequence of doing this (creating a radically different hardware architecture that only allows for fixed first order functionality) means that we can no longer use commodity hardware. that means we would no longer enjoy the benefits of commodity hardware pricing. that in turn means that the cost of ownership of one of these dumb terminals will be rather high compared to commodity computing counterparts. i don't know if the theoretical market for such special purpose computers can withstand the practical realities such a device would entail.
Monday, June 21, 2010
mobile model won't stop malware
thanks to lysa myers for drawing my attention to this slate article about the security advantages of modern mobile device OSes like iOS (the OS for iphones, ipads, etc), android (google's mobile phone OS), and chromeOS (google's netbook OS).
i agree with lysa that it is a fairly well balanced article, in spite of the somewhat sensationalistic headline (and to the credit of a publication whose focus is not strictly about computer security). however, i also find it a bit short sighted.
i say this because the writing is already on the wall with respect to the future of malware, and that future is not encumbered by the modern mobile OS' attempts to be locked down.
i'm surprised that i haven't written about this concept earlier, i thought i had, but when it comes to chromeOS specifically, the reason such an OS has any chance at all is because more and more applications are moving onto the web, into the cloud. an operating system that only gives you access to the web browser wouldn't be very useful with the world wide web of 10 years ago, but now there are a wide variety of web apps to allow you to be productive with nothing more than the lowly web browser.
and where legitimate applications go, malware is sure to follow. we're already seeing malicious facebook apps, and malicious javascript that changes your router's DNS settings is not unheard of either. worms that spread on social networking sites instead of the user's computer are old news by now, and web-based spyware is out there. a locked down endpoint device is a non-issue to malware that operates in the cloud or finds other ways around actually changing the endpoint device itself.
mass adoption of these more stringently locked down platforms won't be the end of malware, it won't even mark a turning point in the evolution of malware since the development is already in progress. if such adoption takes place it would probably be most appropriate to think of it as punctuation in the evolution of malware.
i agree with lysa that it is a fairly well balanced article, in spite of the somewhat sensationalistic headline (and to the credit of a publication whose focus is not strictly about computer security). however, i also find it a bit short sighted.
i say this because the writing is already on the wall with respect to the future of malware, and that future is not encumbered by the modern mobile OS' attempts to be locked down.
i'm surprised that i haven't written about this concept earlier, i thought i had, but when it comes to chromeOS specifically, the reason such an OS has any chance at all is because more and more applications are moving onto the web, into the cloud. an operating system that only gives you access to the web browser wouldn't be very useful with the world wide web of 10 years ago, but now there are a wide variety of web apps to allow you to be productive with nothing more than the lowly web browser.
and where legitimate applications go, malware is sure to follow. we're already seeing malicious facebook apps, and malicious javascript that changes your router's DNS settings is not unheard of either. worms that spread on social networking sites instead of the user's computer are old news by now, and web-based spyware is out there. a locked down endpoint device is a non-issue to malware that operates in the cloud or finds other ways around actually changing the endpoint device itself.
mass adoption of these more stringently locked down platforms won't be the end of malware, it won't even mark a turning point in the evolution of malware since the development is already in progress. if such adoption takes place it would probably be most appropriate to think of it as punctuation in the evolution of malware.
Tags:
allysa myers,
android,
apple,
chrome os,
farhad manjoo,
google,
iphone,
malware,
slate
Thursday, May 27, 2010
man 'infects' self with computer virus?
that's pretty much what the story says (read it here) and if it were true (or even possible) then it would be a pretty boneheaded thing to do. and they call this guy "doctor".
but if you haven't figured it out by now, the whole thing is complete rubbish. over 4 years ago a bunch of researchers came up with some less than amazing research that showed that certain RFID tagging systems could be susceptible to compromise by malware stored on RFID tags themselves (which i wrote about here). specifically, the data on the tags could exploit programming flaws in the back-end database the system runs off of. in essence you could write malware (even viruses or worms) that operates in the context of the database, and you could use RFID tags as a storage and distribution medium.
4 years later and another bunch of researchers (including a one dr. mark gasson) have the (not so) bright idea to stick one of those RFID tags in a person. yeah, that really is all that happened here. that and some effective huckstering get into the media spotlight (if even only for a short while).
it really is quite unspectacular though. dr. gasson took something that supposedly contained a computer virus and then put that inside yet another container (his own body) and then called that container 'infected' as if that's all it took. by the same token i could put one of those tags in a tupperware container and call that 'infected' - and wouldn't that be something; not only 'infecting' something that's inanimate but well and truly inert. what's more, i could take one of these specially prepared RFID tags and put it between two slices of bread and make an 'infected' sandwich. i could even put one in a hole in the ground and 'infect' the planet. clearly this notion of 'infection' by containment is absurd.
but it gets a little more absurd, because dr. gasson claims to be the first. now a very clever commenter over at boingboing pointed out (here) that you get basically the same effect by sticking an infected USB thumb drive in your rectum. while you may consider that to be a juvenile observation to make, his assertion that it constitutes prior art has merit. USB thumb drives are small and portable and easily inserted into a variety of bodily cavities for the purposes of hiding or smuggling data. furthermore, USB thumb drives are notorious for hosting things like autorun worms. as such, with the bizarre "containment == 'infection'" logic being used, it's almost a certainty that dr. gasson was actually not the first human to be 'infected' by a computer virus in this (non)sense, he's simply the first to make a media spectacle of himself over the issue. (one might argue that unlike an RFID tag, a USB thumb drive wouldn't be able to pass on the infection once in your rectum - but it was never specified that the business end couldn't be left sticking out)
i can't discuss this topic without touching upon what i think is (at least partially) to blame for the ridiculous and rather scary statement being made by dr. gasson, though. it's one of my long-standing pet peeves: terminology misuse. you may have noticed my persistent decoration of words related to the word "infect". that's because it's been used in a sense that is so far from an reasonable meaning of the word infect that it doesn't deserve to be treated as a normal word. terminology misuse has become de rigeur to such an extent that even well known anti-malware personalities such as graham cluley and mikko hypponen endorse it for some terms. you can argue about natural semantic drift of words over time until you're blue in the face but technical jargon is not (and should not be) subject to the whim and whimsy of the unwashed masses (even when it comes to subjects that affect them). this particular instance of sensational absurdity is a consequence of and an argument against unfettered semantic drift in the realm of technical jargon. in no reasonable sense of the word was this person ever infected by a computer virus. absurd statements like the one the researcher is making are only possible because of slightly less absurd statements made before it that haven't been corrected yet, which in turn can eventually be traced back to basic terminology misuse.
but if you haven't figured it out by now, the whole thing is complete rubbish. over 4 years ago a bunch of researchers came up with some less than amazing research that showed that certain RFID tagging systems could be susceptible to compromise by malware stored on RFID tags themselves (which i wrote about here). specifically, the data on the tags could exploit programming flaws in the back-end database the system runs off of. in essence you could write malware (even viruses or worms) that operates in the context of the database, and you could use RFID tags as a storage and distribution medium.
4 years later and another bunch of researchers (including a one dr. mark gasson) have the (not so) bright idea to stick one of those RFID tags in a person. yeah, that really is all that happened here. that and some effective huckstering get into the media spotlight (if even only for a short while).
it really is quite unspectacular though. dr. gasson took something that supposedly contained a computer virus and then put that inside yet another container (his own body) and then called that container 'infected' as if that's all it took. by the same token i could put one of those tags in a tupperware container and call that 'infected' - and wouldn't that be something; not only 'infecting' something that's inanimate but well and truly inert. what's more, i could take one of these specially prepared RFID tags and put it between two slices of bread and make an 'infected' sandwich. i could even put one in a hole in the ground and 'infect' the planet. clearly this notion of 'infection' by containment is absurd.
but it gets a little more absurd, because dr. gasson claims to be the first. now a very clever commenter over at boingboing pointed out (here) that you get basically the same effect by sticking an infected USB thumb drive in your rectum. while you may consider that to be a juvenile observation to make, his assertion that it constitutes prior art has merit. USB thumb drives are small and portable and easily inserted into a variety of bodily cavities for the purposes of hiding or smuggling data. furthermore, USB thumb drives are notorious for hosting things like autorun worms. as such, with the bizarre "containment == 'infection'" logic being used, it's almost a certainty that dr. gasson was actually not the first human to be 'infected' by a computer virus in this (non)sense, he's simply the first to make a media spectacle of himself over the issue. (one might argue that unlike an RFID tag, a USB thumb drive wouldn't be able to pass on the infection once in your rectum - but it was never specified that the business end couldn't be left sticking out)
i can't discuss this topic without touching upon what i think is (at least partially) to blame for the ridiculous and rather scary statement being made by dr. gasson, though. it's one of my long-standing pet peeves: terminology misuse. you may have noticed my persistent decoration of words related to the word "infect". that's because it's been used in a sense that is so far from an reasonable meaning of the word infect that it doesn't deserve to be treated as a normal word. terminology misuse has become de rigeur to such an extent that even well known anti-malware personalities such as graham cluley and mikko hypponen endorse it for some terms. you can argue about natural semantic drift of words over time until you're blue in the face but technical jargon is not (and should not be) subject to the whim and whimsy of the unwashed masses (even when it comes to subjects that affect them). this particular instance of sensational absurdity is a consequence of and an argument against unfettered semantic drift in the realm of technical jargon. in no reasonable sense of the word was this person ever infected by a computer virus. absurd statements like the one the researcher is making are only possible because of slightly less absurd statements made before it that haven't been corrected yet, which in turn can eventually be traced back to basic terminology misuse.
Tags:
autorun worm,
hype,
infection,
malware,
mark gasson,
rfid,
virus,
worm
Saturday, December 12, 2009
why mac fanatics still believe they're virus free
(another post form the draft pile)
i stumbled across this article about why macs are still virus free and it occurred to me that there were a number of false premises that deserved highlighting to illustrate why mac users still think their beloved platform is so safe.
mac users have largely ignored the malware problem, which is probably why what little they know of the problem is generally either wrong or out of date. the malware problem isn't ignoring them, however. they have an opportunity to get ahead of the problem, but if they keep living in the past that opportunity will be squandered.
i stumbled across this article about why macs are still virus free and it occurred to me that there were a number of false premises that deserved highlighting to illustrate why mac users still think their beloved platform is so safe.
- the first thing i noticed was an ill-conceived notions of what a virus is (eg. "When I say virus I'm referring to a program which self-propagates and self-installs either by exploiting a back door in the operating system or another legitimate application"). by this definition most PC viruses (and i'm not using virus as a catch-all umbrella term here) are not actually viruses.
- next thing i noticed was the comparison of apples to fruit (eg. "So why don't Macs get viruses while Windows PC's seem to be facing a constant tsunami of malware, spyware, worms, trojans and botnets?"). compare mac viruses to pc viruses please, not mac viruses to pc viruses, worms, spyware, trojans, botnets, etc. either that or compare the gamut of mac malware to the gamut of pc malware.
- next on the list of wrong-headed thinking i picked up from that post was thinking malware authors are still just attention seekers (eg. " There are a lot of theories regarding install base and attention-seeking virus writers") when it has been demonstrated over and over again for the past several years that they're financially motivated now - the current trend is to follow the money.
- another bit of nonsense i noticed (which in fairness is bandied around by a lot of otherwise intelligent people) is thinking that going after the biggest group limits them to going after just one group (eg. "wanting to target the biggest market") when it has been demonstrated that professional malware gangs are targeting both platforms at the same time (see zlob gang).
- yet another wrong thought in the article was thinking that unix makes the difference (eg. "The real answer is UNIX") when in fact the first academic treatment of the virus problem (back when the term 'computer virus' was originally coined) had viruses successfully replicating across a user population in a professionally administered unix environment without cooperation from the admin.
- the most damning, however, is thinking in yesterdays terms. the very fact that they're still focusing on viruses rather than malware in general shows just how outdated the thinking really is. most of the malware currently attacking pc's these days is NOT viral (either by normal pc definitions, incorrect mac definitions, or formal definitions). furthermore viral malware isn't really the biggest malware problem these days. huge numbers of non-viral malware are the biggest problem facing pc's and the malware gangs have been targeting both pc's and macs for years now.
mac users have largely ignored the malware problem, which is probably why what little they know of the problem is generally either wrong or out of date. the malware problem isn't ignoring them, however. they have an opportunity to get ahead of the problem, but if they keep living in the past that opportunity will be squandered.
Sunday, December 06, 2009
malware classification fail
here's one from the drafts pile, hopefully it's not too stale
i'm wondering what the anti-malware world is coming to when the leading vendor classifies something as a trojan even though it clearly discloses what damage it does.
by this logic, every copy of every operating system also ships with a trojan horse program, either in the form of the delete command or the format command.
one of the basic requirements of a trojan is that it tricks the user into executing it - the original trojan horse wouldn't have gotten very far if there was a warning sign on the outside that said it contained enemy soldiers that would sack the city when night fell. so too would suspected malware not get very far if it plainly disclosed what it does.
this game is at worst a potentially unwanted program - in other words, grayware. we can't just go around calling every bad program (or even just every bad non-viral program) a trojan anymore than we can go around calling all malware viruses. not using the proper terminology is a great way to confuse everyone and confusion is something we don't want to sow, right?!?
i'm wondering what the anti-malware world is coming to when the leading vendor classifies something as a trojan even though it clearly discloses what damage it does.
by this logic, every copy of every operating system also ships with a trojan horse program, either in the form of the delete command or the format command.
one of the basic requirements of a trojan is that it tricks the user into executing it - the original trojan horse wouldn't have gotten very far if there was a warning sign on the outside that said it contained enemy soldiers that would sack the city when night fell. so too would suspected malware not get very far if it plainly disclosed what it does.
this game is at worst a potentially unwanted program - in other words, grayware. we can't just go around calling every bad program (or even just every bad non-viral program) a trojan anymore than we can go around calling all malware viruses. not using the proper terminology is a great way to confuse everyone and confusion is something we don't want to sow, right?!?
Tags:
classification,
greyware,
malware,
terminology misuse,
trojan
Thursday, October 08, 2009
what is credentialed malware?
credentialed malware is essentially (and perhaps more aptly described as) multi-user malware. not multi-victim malware, mind you, but multi-attacker - it is designed to be used by multiple attackers with differing levels of access to the malware's collection of functionality.
credentialed malware really only makes sense in the context of a criminal organization where different members of that organization have different roles and different levels of trust.
it also only make sense (from a tactical perspective) in cases where attackers would need to physically access the compromised machine(s) (ie. a public kiosk) in order to pull of a successful attack. if the machine could be accessed remotely or if the machine could send data out to remote destinations then there would be no need to employ multiple human agents to mask the maneuvers required to make the attack work.
back to index
(thanks go to nicholas percoco and jibran ilyas for introducing me to this concept)
credentialed malware really only makes sense in the context of a criminal organization where different members of that organization have different roles and different levels of trust.
it also only make sense (from a tactical perspective) in cases where attackers would need to physically access the compromised machine(s) (ie. a public kiosk) in order to pull of a successful attack. if the machine could be accessed remotely or if the machine could send data out to remote destinations then there would be no need to employ multiple human agents to mask the maneuvers required to make the attack work.
back to index
(thanks go to nicholas percoco and jibran ilyas for introducing me to this concept)
Tags:
credentialed malware,
definition,
malware
Saturday, July 25, 2009
all things come to an end - even endings
not too long ago i published a post called understanding malware growth in which i observed that the period of accelerated malware growth we had seen in previous years appeared to be over. unfortunately, according to new av-test.org statistics (as reported by mcafee) accelerated malware growth is back.
now one way you could take that is that i was wrong. perhaps i was, at least with regards to being optimistic - perhaps optimism was not called for. i wasn't wrong about the rapid expansion being over, though, the growth was more or less constant for the better part of a year. that is a distinct departure from the growth trend prior to august 2007. a year is a considerable amount of time for malware to languish.
another point i don't think i was wrong about was the nature of malware growth itself. if you read the previously mentioned post carefully you should have come away with the impression that, contrary to the naive malware growth forecasts, malware growth is punctuated. there was very clearly a point at which the rapid expansion of malware growth started, and just as clearly there was a point where that expansion came to an end, a point where whatever driving factor was resulting in the higher malware production rates had finally reached it's peak and the malware ecosystem returned to a kind of balance.
i had in mind the possibility that another disruption in malware growth could occur - if it can happen once it can happen again, but i didn't mention it because i didn't want to be negative, i didn't want to jinx our collective good fortune. had more up-to-date data been available, however, i would have known our good fortune had already come to an end when i wrote that post.
another disruptive event does appear to have occurred. continuing with some of the postulates from the previous post (namely that the mechanism for creating the bulk of the variants is server-side polymorphism), if we were to then go with the postulate that the web is the dominant malware delivery vehicle (as opposed to malware being carried directly in email or some other channel) then one of the key limiting factors in the automated creation of new minor variants is the problem getting victims to view malicious content.
there are 2 things in recent memory that i think could have lead to more browsers loading malicious content than before. one of those things is innovation in the field of social engineering - we've been seeing more fake celebrity news (especially deaths) recently than i seem to recall seeing in the past. hammering on a new hook that the public at large hasn't yet grown wise to could result in an increase in the success of social engineering that used that hook and thus trick more people than usual into browsing to malicious content.
the second thing that could be contributing to an increase in browsing malicious content is the increasing trend of mass website compromises through SQL injection. increasing the number of legitimate sites that serve malware (even if indirectly) increases the chances of web surfers stumbling across malicious content entirely by accident.
both of these things can lead to an increase in the browsing of malicious content, which in turn gives the server-side polymorphic engines responsible for handing out that content the opportunity to create that much more of it in an automated fashion. that said, both of these things will also reach a peak in their influence. the public will eventually grow wise enough to the fake celebrity death reports that the success rate of that ploy will drop back down to previous levels. successful sql injection will also eventually taper off as the content management systems being targeted get hardened by their vendors, or as the pool of potential victims shrinks when the entities in it realize they need to take steps to prevent this sort of compromise.
when these things happen malware growth will once again plateau (it might already be there, but it's far too soon to tell) - until the next disruptive malware innovation, that is.
now one way you could take that is that i was wrong. perhaps i was, at least with regards to being optimistic - perhaps optimism was not called for. i wasn't wrong about the rapid expansion being over, though, the growth was more or less constant for the better part of a year. that is a distinct departure from the growth trend prior to august 2007. a year is a considerable amount of time for malware to languish.
another point i don't think i was wrong about was the nature of malware growth itself. if you read the previously mentioned post carefully you should have come away with the impression that, contrary to the naive malware growth forecasts, malware growth is punctuated. there was very clearly a point at which the rapid expansion of malware growth started, and just as clearly there was a point where that expansion came to an end, a point where whatever driving factor was resulting in the higher malware production rates had finally reached it's peak and the malware ecosystem returned to a kind of balance.
i had in mind the possibility that another disruption in malware growth could occur - if it can happen once it can happen again, but i didn't mention it because i didn't want to be negative, i didn't want to jinx our collective good fortune. had more up-to-date data been available, however, i would have known our good fortune had already come to an end when i wrote that post.
another disruptive event does appear to have occurred. continuing with some of the postulates from the previous post (namely that the mechanism for creating the bulk of the variants is server-side polymorphism), if we were to then go with the postulate that the web is the dominant malware delivery vehicle (as opposed to malware being carried directly in email or some other channel) then one of the key limiting factors in the automated creation of new minor variants is the problem getting victims to view malicious content.
there are 2 things in recent memory that i think could have lead to more browsers loading malicious content than before. one of those things is innovation in the field of social engineering - we've been seeing more fake celebrity news (especially deaths) recently than i seem to recall seeing in the past. hammering on a new hook that the public at large hasn't yet grown wise to could result in an increase in the success of social engineering that used that hook and thus trick more people than usual into browsing to malicious content.
the second thing that could be contributing to an increase in browsing malicious content is the increasing trend of mass website compromises through SQL injection. increasing the number of legitimate sites that serve malware (even if indirectly) increases the chances of web surfers stumbling across malicious content entirely by accident.
both of these things can lead to an increase in the browsing of malicious content, which in turn gives the server-side polymorphic engines responsible for handing out that content the opportunity to create that much more of it in an automated fashion. that said, both of these things will also reach a peak in their influence. the public will eventually grow wise enough to the fake celebrity death reports that the success rate of that ploy will drop back down to previous levels. successful sql injection will also eventually taper off as the content management systems being targeted get hardened by their vendors, or as the pool of potential victims shrinks when the entities in it realize they need to take steps to prevent this sort of compromise.
when these things happen malware growth will once again plateau (it might already be there, but it's far too soon to tell) - until the next disruptive malware innovation, that is.
Tags:
av-test.org,
malware,
malware creation,
mcafee
Sunday, June 14, 2009
understanding malware growth
(this is actually kind of old now, but real life has a way of interrupting this whole blogging thing)
alex eckelberry posted some graphs depicting the size and growth of the malware samples collected by andreas marx/av-test.org. what most people will take away from it is that malware is growing at an incredible rate, and that's kind of depressing. there's more to the graphs than just that however, and not all of it is depressing - in fact it looks pretty good to me.
but to understand this i think i need to point out just how bad the forecast line of the graphs is. the line represents the expected value according to a particular model of malware growth. of course models and reality never match up absolutely perfectly, but the forecast suggests a fairly simplistic model and it appears that as time wears on it diverges more and more from reality. let's construct a model bit by bit based on some reasonable assumptions and see how close it matches reality.
let's first suppose that there are a constant number of malware creators with a fixed amount of resources (i don't mean money or computing power, i mean man-power resources - you can only do so much in a day, that sort of thing). let's further suppose that the amount of malware a malware creator can create with X number of resources is constant. what would that look like?

this depicts constant growth with a linear increase in population over time. this is not the final model, of course, but simply a starting point. one of the basic flaws with it is that it assumes that the population of malware creators themselves is constant. what if we instead suppose that the set of malware creators themselves were growing at a gradual but constant rate, what would that look like?

this depicts linear (rather than constant) growth in the malware because as the set of malware creators increases over time, so too should their malware output. it also shows a curve in the population vs time graph, although the curve isn't quite as pronounced as the one depicted in the forecast on the population graph on alex's blog and that's because in that case the forecast on the growth graph predicted non-linear growth.
how could we get non-linear growth? well another of our starting assumptions that we need modify is that the number of malware samples a malware creator can create with X number of resources is fixed. in reality malware creators come up with innovations and some of those innovations improve the efficiency of their malware creation efforts such that they can create more samples with the same effort as before. minor innovations in this area (minor in the sense that the efficiency improvement is small) probably happen all the time but major innovations are probably rare. furthermore, adoption of such innovations is not immediate, it takes time for the idea to spread amongst the malware creators. finally, such innovations may not apply to all sorts of malware so it may be that only part of the malware creator population ever adopts the new methods.
so now let's suppose one of those rare groundbreaking innovations happens - one malware creator comes up with a way to increase his malware creation rate by an order of magnitude. then he tells 2 friends (it may not actually work quite that way but one way or another the idea gets communicated to others) and they tell 2 friends, and so on until eventually they approach a peak number of creators using the new method and the rate at which creators switch from the old to new method slows to a trickle. what might that look like?

this depicts the same linear growth as before at the beginning (with the scale adjusted) followed by a period of rapid expansion as the new method reaches it's saturation point amongst the malware creators (most, but not all of them adopt the new method), and then it returns to mostly linear growth but with a stepped sort of appearance as individual adopters of the new method gradually continue to trickle in.
now, i don't know about you but to me this is starting to look rather familiar. it's not quite the same shape as the actual figures, mind you, that looks a lot less smooth than this, but it's a better approximation to the shape than the simple curve used in the forecast and it's based on an entirely reasonable set of forces that would affect malware growth.
as a final step, let's try to imagine why the real values don't follow such a smooth curve. so far we've been assuming that the population of malware creators only increases over time, but that's not entirely true, is it. there are any number of reasons why individuals might leave that population either temporarily (due to things like criminal prosecution, or collapse of particular infrastructure they were using), or permanently (due to things like retirement or death). if we were to take some of the malware creators in our model out of the picture temporarily at various points (and assume that the ones that ones that leave permanently will simply be replaced and so have the same effect as a temporary departure) what might that look like?

as you can imagine, because the malware creators using the new methods contribute so much more to the growth of malware than do the ones using old methods, when the population using the new methods drops slightly it has a much more noticeable effect on the graph than when the population using the old methods drop.
so how reasonable are these assumptions? are malware creators resources fixed? i've yet to see a way to increase the number of hours in a day so any individual malware creator is still limited in the number of man-hours he or she can devote to the task of malware creation.
can an innovation have a huge effect on the number of malware samples created? well just look at the massive number of variants that server-side polymorphism has lead to. you can basically think of those setups as variant factories and once they're constructed they really don't require any extra effort on the part of the malware creator in order to create more samples - it can be entirely automated and is then only limited by the number of victims who download samples.
would adoption of such an incredible innovation really be limited? again, look at server-side polymorphism, how well would that innovation apply to malware such as autorun worms? not that great actually. if you think about it you can probably come up with other examples of malware types and malware techniques that don't naturally go well together.
do people really leave the malware creator population either temporarily or permanently? well first of all people do actually die, and malware creators are among them so yes people do leave permanently - and again, with the example of server-side polymorphism, if the servers go down because for example the hosting ISP gets de-peered (as has famously happened a few times now) then yes the creators will temporarily be removed from the malware creator population until such time as they can set their operation back up somewhere else.
so what else can we take away from those graphs at alex's blog besides the fact that malware is increasing at an alarming rate? well, for my money it's that a big chunk of that alarming rate was due to an innovation (probably server-side polymorphism) that created a rapid expansion in the malware creation rate and that that rapid expansion seems to be over (in fact it looks like it came to an end nearly 2 years ago). that's not to say malware growth will begin to slow of course, but simply that the really scary part is behind us - the malware growth rate is still enormous, but it's not increasing at an exponential rate anymore. maybe a new innovation will come along and take us for another rough ride, maybe not, but as it stands right now catching back up to the bad guys (assuming you were of the school of thought that we needed to) looks a lot more feasible than it did before.
alex eckelberry posted some graphs depicting the size and growth of the malware samples collected by andreas marx/av-test.org. what most people will take away from it is that malware is growing at an incredible rate, and that's kind of depressing. there's more to the graphs than just that however, and not all of it is depressing - in fact it looks pretty good to me.
but to understand this i think i need to point out just how bad the forecast line of the graphs is. the line represents the expected value according to a particular model of malware growth. of course models and reality never match up absolutely perfectly, but the forecast suggests a fairly simplistic model and it appears that as time wears on it diverges more and more from reality. let's construct a model bit by bit based on some reasonable assumptions and see how close it matches reality.
let's first suppose that there are a constant number of malware creators with a fixed amount of resources (i don't mean money or computing power, i mean man-power resources - you can only do so much in a day, that sort of thing). let's further suppose that the amount of malware a malware creator can create with X number of resources is constant. what would that look like?

this depicts constant growth with a linear increase in population over time. this is not the final model, of course, but simply a starting point. one of the basic flaws with it is that it assumes that the population of malware creators themselves is constant. what if we instead suppose that the set of malware creators themselves were growing at a gradual but constant rate, what would that look like?

this depicts linear (rather than constant) growth in the malware because as the set of malware creators increases over time, so too should their malware output. it also shows a curve in the population vs time graph, although the curve isn't quite as pronounced as the one depicted in the forecast on the population graph on alex's blog and that's because in that case the forecast on the growth graph predicted non-linear growth.
how could we get non-linear growth? well another of our starting assumptions that we need modify is that the number of malware samples a malware creator can create with X number of resources is fixed. in reality malware creators come up with innovations and some of those innovations improve the efficiency of their malware creation efforts such that they can create more samples with the same effort as before. minor innovations in this area (minor in the sense that the efficiency improvement is small) probably happen all the time but major innovations are probably rare. furthermore, adoption of such innovations is not immediate, it takes time for the idea to spread amongst the malware creators. finally, such innovations may not apply to all sorts of malware so it may be that only part of the malware creator population ever adopts the new methods.
so now let's suppose one of those rare groundbreaking innovations happens - one malware creator comes up with a way to increase his malware creation rate by an order of magnitude. then he tells 2 friends (it may not actually work quite that way but one way or another the idea gets communicated to others) and they tell 2 friends, and so on until eventually they approach a peak number of creators using the new method and the rate at which creators switch from the old to new method slows to a trickle. what might that look like?

this depicts the same linear growth as before at the beginning (with the scale adjusted) followed by a period of rapid expansion as the new method reaches it's saturation point amongst the malware creators (most, but not all of them adopt the new method), and then it returns to mostly linear growth but with a stepped sort of appearance as individual adopters of the new method gradually continue to trickle in.
now, i don't know about you but to me this is starting to look rather familiar. it's not quite the same shape as the actual figures, mind you, that looks a lot less smooth than this, but it's a better approximation to the shape than the simple curve used in the forecast and it's based on an entirely reasonable set of forces that would affect malware growth.
as a final step, let's try to imagine why the real values don't follow such a smooth curve. so far we've been assuming that the population of malware creators only increases over time, but that's not entirely true, is it. there are any number of reasons why individuals might leave that population either temporarily (due to things like criminal prosecution, or collapse of particular infrastructure they were using), or permanently (due to things like retirement or death). if we were to take some of the malware creators in our model out of the picture temporarily at various points (and assume that the ones that ones that leave permanently will simply be replaced and so have the same effect as a temporary departure) what might that look like?

as you can imagine, because the malware creators using the new methods contribute so much more to the growth of malware than do the ones using old methods, when the population using the new methods drops slightly it has a much more noticeable effect on the graph than when the population using the old methods drop.
so how reasonable are these assumptions? are malware creators resources fixed? i've yet to see a way to increase the number of hours in a day so any individual malware creator is still limited in the number of man-hours he or she can devote to the task of malware creation.
can an innovation have a huge effect on the number of malware samples created? well just look at the massive number of variants that server-side polymorphism has lead to. you can basically think of those setups as variant factories and once they're constructed they really don't require any extra effort on the part of the malware creator in order to create more samples - it can be entirely automated and is then only limited by the number of victims who download samples.
would adoption of such an incredible innovation really be limited? again, look at server-side polymorphism, how well would that innovation apply to malware such as autorun worms? not that great actually. if you think about it you can probably come up with other examples of malware types and malware techniques that don't naturally go well together.
do people really leave the malware creator population either temporarily or permanently? well first of all people do actually die, and malware creators are among them so yes people do leave permanently - and again, with the example of server-side polymorphism, if the servers go down because for example the hosting ISP gets de-peered (as has famously happened a few times now) then yes the creators will temporarily be removed from the malware creator population until such time as they can set their operation back up somewhere else.
so what else can we take away from those graphs at alex's blog besides the fact that malware is increasing at an alarming rate? well, for my money it's that a big chunk of that alarming rate was due to an innovation (probably server-side polymorphism) that created a rapid expansion in the malware creation rate and that that rapid expansion seems to be over (in fact it looks like it came to an end nearly 2 years ago). that's not to say malware growth will begin to slow of course, but simply that the really scary part is behind us - the malware growth rate is still enormous, but it's not increasing at an exponential rate anymore. maybe a new innovation will come along and take us for another rough ride, maybe not, but as it stands right now catching back up to the bad guys (assuming you were of the school of thought that we needed to) looks a lot more feasible than it did before.
Tags:
malware,
malware creation
Subscribe to:
Posts (Atom)
