non-persistence in malware is a property whereby the malware doesn't get written to a persistent storage medium like the hard disk but instead resides only in RAM...
the primary advantage of this technique is that on-access scanners won't scan it because the condition that triggers on-access scanning is never met, and application whitelisting won't stop it because a non-persistent program requires exotic execution by definition...
a lesser appreciated benefit is that it circumvents outside-the-box analysis because the contents of RAM are supposed to be lost when the computer shuts down... recent developments suggest this benefit might not actually exist, however...
non-persistence can even have some advantages against behaviour blockers under certain circumstances (ex. if the malware injects itself into a process that is already authorized to perform all the behaviours the malware needs to perform then the behaviour blocker won't necessarily raise an alarm (unless it can detect the injection itself)...
on-demand scanning of RAM should be able to identify known non-persistent malware so long as it doesn't use stealth or any other countermeasures, however... further, since the network is nearly the only point of entry for completely non-persistent malware, scanning at the LSP level has a good chance of catching any known exploits it might use to get into the system in the first place...
back to index
Sunday, March 09, 2008
what is on-demand scanning?
on-demand scanning is a type of known-malware scanning where you select a resource (a file, a folder, a disk, etc.) and tell (demand) the scanner software to scan it (hence on-demand)...
unlike on-access scanning, this type of scanning generally does not go on in the background and is not invisible to the user - rather the scanner's user interface is displayed on the screen so that the user can monitor it's progress and tell it to abort if need be...
on-demand scanning is the type of scanning that's performed when doing a scheduled scan of a system (though the exact resources that get scanned are generally pre-selected for the user's convenience)... it's also the type of scanning that is performed when scanning a system from outside-the-box...
back to index
unlike on-access scanning, this type of scanning generally does not go on in the background and is not invisible to the user - rather the scanner's user interface is displayed on the screen so that the user can monitor it's progress and tell it to abort if need be...
on-demand scanning is the type of scanning that's performed when doing a scheduled scan of a system (though the exact resources that get scanned are generally pre-selected for the user's convenience)... it's also the type of scanning that is performed when scanning a system from outside-the-box...
back to index
what is on-access scanning?
on-access scanning is a type of known-malware scanning that scans file system objects when they get accessed (hence on-access)...
also known as real-time scanning or background scanning, this is the type of anti-malware protection that people are most familiar with as it comes closest to implementing the install-and-forget model that they've been tricked into expecting from anti-malware vendors...
this is also the type of scanning that shouldn't be performed by more than one product at the same time (and thus the reason anti-malware vendors use to justify suggesting you uninstall their competitors products before you install theirs)... when multiple on-access scanners are fighting over access to a file it can lead to unpredictable and undesirable results...
back to index
also known as real-time scanning or background scanning, this is the type of anti-malware protection that people are most familiar with as it comes closest to implementing the install-and-forget model that they've been tricked into expecting from anti-malware vendors...
this is also the type of scanning that shouldn't be performed by more than one product at the same time (and thus the reason anti-malware vendors use to justify suggesting you uninstall their competitors products before you install theirs)... when multiple on-access scanners are fighting over access to a file it can lead to unpredictable and undesirable results...
back to index
what is a cross-view diff?
a cross-view diff is a process for detecting the presence of active stealth techniques by looking for differences across two or more views of the same resource (often the file system)... when one view is different from the other it suggests that something is manipulating the results in an attempt to hide something...
the multiple views are generally accomplished by accessing the resource using multiple techniques - possibly a high-level API for one view and a lower level one for the other, though it's possible that if something is manipulating the results from one access technique it may also manipulate the results from the other...
another possibility is to get one view while the suspect system is running and other one from outside-the-box... this has the usual benefit of outside-the-box analysis in that the second view cannot be manipulated by any stealth malware because such malware won't be active...
looking for differences is fundamentally indistinguishable from change-detection, so this technique is essentially a type of integrity checking where the integrity of the resource access methods themselves are in question... compromising those methods is necessary for active stealth to work, so any evidence that their integrity is no longer intact is by extension evidence for the presence of stealth - and if an object (like a file) in the resource in question appears to be missing from the less trusted view then that is even stronger evidence for the presence of stealth...
back to index
the multiple views are generally accomplished by accessing the resource using multiple techniques - possibly a high-level API for one view and a lower level one for the other, though it's possible that if something is manipulating the results from one access technique it may also manipulate the results from the other...
another possibility is to get one view while the suspect system is running and other one from outside-the-box... this has the usual benefit of outside-the-box analysis in that the second view cannot be manipulated by any stealth malware because such malware won't be active...
looking for differences is fundamentally indistinguishable from change-detection, so this technique is essentially a type of integrity checking where the integrity of the resource access methods themselves are in question... compromising those methods is necessary for active stealth to work, so any evidence that their integrity is no longer intact is by extension evidence for the presence of stealth - and if an object (like a file) in the resource in question appears to be missing from the less trusted view then that is even stronger evidence for the presence of stealth...
back to index
what is outside-the-box analysis?
outside-the-box analysis refers to the practice of examining a suspect system from the outside using a trusted external environment while the suspect system's OS (and everything else installed on it) is inactive...
the primary benefit of this practice is that any malware on the suspect system will be unable to actively hide (using stealth) or actively defend itself against the tools used to perform the analysis because they won't be active in the first place... it is a long held axiom that you cannot trust a suspect system to accurately report it's own integrity because any active malware can force the system to lie or can even attack the software asking the questions... operating in an environment where this can't happen gives you an advantage over such malware...
in common practice there are two main ways of providing a trusted external environment in which to examine a suspect machine... the first is to use a second physical computer which you connect the suspect machine's hard disk to as a so-called 'slave' drive... this is a relatively straight-forward method that most people are able to do assuming they have a second machine available and can be talked through taking the hard disk out of the suspect machine and putting it in the second machine...
the second method is to boot the suspect system from an operating system on a known-clean removable medium like a floppy disk, CD, or USB flash drive... LiveCD's are a familiar concept to linux users, and old-timers will probably remember using known-clean bootable floppies on their old dos machines... for windows there is something similar called a pre-installation environment that provides much the same kind of functionality, but microsoft has been slow in recognizing the need to put that functionality in the hands of users which lead to the development of the BartPE disk (which has been mentioned many times on this blog before both by myself, and recently in a comment by vesselin, but is discussed even more by chris quirke in relation to the utility of a maintenance OS)...
back to index
the primary benefit of this practice is that any malware on the suspect system will be unable to actively hide (using stealth) or actively defend itself against the tools used to perform the analysis because they won't be active in the first place... it is a long held axiom that you cannot trust a suspect system to accurately report it's own integrity because any active malware can force the system to lie or can even attack the software asking the questions... operating in an environment where this can't happen gives you an advantage over such malware...
in common practice there are two main ways of providing a trusted external environment in which to examine a suspect machine... the first is to use a second physical computer which you connect the suspect machine's hard disk to as a so-called 'slave' drive... this is a relatively straight-forward method that most people are able to do assuming they have a second machine available and can be talked through taking the hard disk out of the suspect machine and putting it in the second machine...
the second method is to boot the suspect system from an operating system on a known-clean removable medium like a floppy disk, CD, or USB flash drive... LiveCD's are a familiar concept to linux users, and old-timers will probably remember using known-clean bootable floppies on their old dos machines... for windows there is something similar called a pre-installation environment that provides much the same kind of functionality, but microsoft has been slow in recognizing the need to put that functionality in the hands of users which lead to the development of the BartPE disk (which has been mentioned many times on this blog before both by myself, and recently in a comment by vesselin, but is discussed even more by chris quirke in relation to the utility of a maintenance OS)...
back to index
Wednesday, March 05, 2008
mebroot shouldn't be so scary
there's been a lot of attention paid to mikko hypponen's statement that “You can’t execute any earlier than that” in reference to the execution of the MBR of a mebroot (that bootroot derivative i previously posted about) afflicted system...
the news media must love that sound-byte - it sounds scary, doesn't it? after all, as i said for years in usenet (and fidonet before that), the code that runs first wins - and clearly the MBR runs first... but if you remember back far enough then you'll remember that this is pretty much the same problem we had with the entire class of malware known as boot sector viruses (most of which infected the MBR)...
how did we manage to circumvent that little problem? simple, we booted from known-clean external media (back then it was a floppy, but now it would probably be a cd or some other mass storage medium that can house tools for fixing a windows machine)... as such, we had trusted code executing not before the bad code but instead of it... not really difficult, just a little obscure by today's standards (though still something people should know how to do, even in the absence of mebroot, since old viruses never die)...
the news media must love that sound-byte - it sounds scary, doesn't it? after all, as i said for years in usenet (and fidonet before that), the code that runs first wins - and clearly the MBR runs first... but if you remember back far enough then you'll remember that this is pretty much the same problem we had with the entire class of malware known as boot sector viruses (most of which infected the MBR)...
how did we manage to circumvent that little problem? simple, we booted from known-clean external media (back then it was a floppy, but now it would probably be a cd or some other mass storage medium that can house tools for fixing a windows machine)... as such, we had trusted code executing not before the bad code but instead of it... not really difficult, just a little obscure by today's standards (though still something people should know how to do, even in the absence of mebroot, since old viruses never die)...
why anti-virus vendors are having such a hard time
ok, first of all, the fact that there are a bunch of links back to this blog has absolutely nothing to do with why i'm responding to a post about why anti-virus products are having a hard time... that said, wow, i'm glad somebody liked those posts...
the links just spelled out some backstory, as it were... the main thrust was to highlight two reasons why av products are (or at least seem to be) having a hard time...
the two reasons given are technically about why scanners specifically are becoming less effective against malware... i agree that the reasons given are contributing to problems for scanners - packers make it easy to turn a known piece of malware into an unknown piece of malware, and pre-release detection testing helps avoid releasing malware that heuristics would detect...
but both of these things (besides being outside the scope of what known-malware scanning is supposed to handle since they specifically deal with new/unknown malware) are largely out of the av vendor's control... there is something that av vendors do have control over that is contributing even more to av products seeming to have a hard time - that being a failure to adequately manage their users... they've failed to manage user understanding of threats, they've failed to manage user awareness of the tools available for mitigating the risk posed by those threats (leading to the notion that av products are just scanners - a notion that is so pervasive that most security bloggers, including the one whose article i'm responding to, give opinions and pose logical arguments based on the assumption that it's true), and ultimately (and as a result of their other failures) they've failed to manage user expectations about what those tools can do... the real reason scanners specifically are having such a hard time is that they don't get the backup they require... they were never meant to handle all malware problems (and certainly never capable of it), only known malware problems...
one of the most novel examples of this failure is the rising anti-botnet market as discussed in this eweek article on the said market... one of the first anti-botnet applications i heard about in the mainstream was the one being provided by symantec... they released it as a separate stand alone tool and though i hoped they'd see the light and integrate it into their main anti-malware offering it seems that they've decided instead to treat it as and exciting new potential revenue stream and started charging money for it (not that i think there's anything wrong with charging money for a product, but if it's product-ready then why is it separate from the rest of their anti-malware offerings? or alternatively, if they're going to offer individual tools as well as suites, why aren't there more stand-alone tools?)... this fracturing of the anti-malware market comes at the expense of being able to communicate a clear and comprehensive message to the user/customer about anti-malware security.... without anything else to tell them how anti-malware security works (and for the most part there isn't anything else that regular people would be exposed to), the way the technologies themselves are presented implicitly communicates this to the user and fracturing your own set of offerings to make some extra green is a failure to properly manage this implicit message...
the links just spelled out some backstory, as it were... the main thrust was to highlight two reasons why av products are (or at least seem to be) having a hard time...
the two reasons given are technically about why scanners specifically are becoming less effective against malware... i agree that the reasons given are contributing to problems for scanners - packers make it easy to turn a known piece of malware into an unknown piece of malware, and pre-release detection testing helps avoid releasing malware that heuristics would detect...
but both of these things (besides being outside the scope of what known-malware scanning is supposed to handle since they specifically deal with new/unknown malware) are largely out of the av vendor's control... there is something that av vendors do have control over that is contributing even more to av products seeming to have a hard time - that being a failure to adequately manage their users... they've failed to manage user understanding of threats, they've failed to manage user awareness of the tools available for mitigating the risk posed by those threats (leading to the notion that av products are just scanners - a notion that is so pervasive that most security bloggers, including the one whose article i'm responding to, give opinions and pose logical arguments based on the assumption that it's true), and ultimately (and as a result of their other failures) they've failed to manage user expectations about what those tools can do... the real reason scanners specifically are having such a hard time is that they don't get the backup they require... they were never meant to handle all malware problems (and certainly never capable of it), only known malware problems...
one of the most novel examples of this failure is the rising anti-botnet market as discussed in this eweek article on the said market... one of the first anti-botnet applications i heard about in the mainstream was the one being provided by symantec... they released it as a separate stand alone tool and though i hoped they'd see the light and integrate it into their main anti-malware offering it seems that they've decided instead to treat it as and exciting new potential revenue stream and started charging money for it (not that i think there's anything wrong with charging money for a product, but if it's product-ready then why is it separate from the rest of their anti-malware offerings? or alternatively, if they're going to offer individual tools as well as suites, why aren't there more stand-alone tools?)... this fracturing of the anti-malware market comes at the expense of being able to communicate a clear and comprehensive message to the user/customer about anti-malware security.... without anything else to tell them how anti-malware security works (and for the most part there isn't anything else that regular people would be exposed to), the way the technologies themselves are presented implicitly communicates this to the user and fracturing your own set of offerings to make some extra green is a failure to properly manage this implicit message...
Wednesday, February 27, 2008
availability > confidentiality + integrity?
umm, no...
chris hoff makes a valiant attempt at arguing for availability being more important that confidentiality and integrity combined (alluding to a previous discussion on the matter) using the example of the recent conflict between youtube and pakistan that left youtube offline for an hour over the weekend...
unfortunately, what he doesn't mention is that the availability problem that youtube suffered was as a direct result of the corruption of the routing information for youtube... in other words, unavailability was a symptom of an integrity problem...
which reminds me (because anton brought it back to the surface) of another recent article concerning the CIA triad... richard bejtlich posted his observation on the attack trends over the years and from his perspective availability (in the form of bandwidth) was the first to fall victim back in the mid 90's...
i don't think it would be unfair to suggest that richard comes from a network security background and views things through that lens, and i can certainly see where he's coming from given that... once again, though, this looks at a symptom rather than a cause...
causative agents don't generally reside in the network, they reside on devices (though sometimes they are the devices) and when they don't belong on the device they usually qualify as malware... malware goes back quite a bit further than the mid 90's and malware intrusion has always been fundamentally an integrity problem... this is why generic detection was traditionally performed using integrity checking, and even today many current generic controls have an integrity validation component...
of course that's just the lens that i see things through, but i'm not about to turn things around and say that integrity is a bigger deal than availability and confidentiality (especially since i can envision a third perspective where confidentiality is key)... ultimately i think the notion that availability trumps other aspects of security comes from the notion of aligning security with business... the alignment is often one-sided (security changes but management doesn't) and availability (and it's affect on the bottom line) is the thing that management understands best so that's what business-aligned security focuses on most... i wonder what it would be like if aligning security and business was a 2-way street...
chris hoff makes a valiant attempt at arguing for availability being more important that confidentiality and integrity combined (alluding to a previous discussion on the matter) using the example of the recent conflict between youtube and pakistan that left youtube offline for an hour over the weekend...
unfortunately, what he doesn't mention is that the availability problem that youtube suffered was as a direct result of the corruption of the routing information for youtube... in other words, unavailability was a symptom of an integrity problem...
which reminds me (because anton brought it back to the surface) of another recent article concerning the CIA triad... richard bejtlich posted his observation on the attack trends over the years and from his perspective availability (in the form of bandwidth) was the first to fall victim back in the mid 90's...
i don't think it would be unfair to suggest that richard comes from a network security background and views things through that lens, and i can certainly see where he's coming from given that... once again, though, this looks at a symptom rather than a cause...
causative agents don't generally reside in the network, they reside on devices (though sometimes they are the devices) and when they don't belong on the device they usually qualify as malware... malware goes back quite a bit further than the mid 90's and malware intrusion has always been fundamentally an integrity problem... this is why generic detection was traditionally performed using integrity checking, and even today many current generic controls have an integrity validation component...
of course that's just the lens that i see things through, but i'm not about to turn things around and say that integrity is a bigger deal than availability and confidentiality (especially since i can envision a third perspective where confidentiality is key)... ultimately i think the notion that availability trumps other aspects of security comes from the notion of aligning security with business... the alignment is often one-sided (security changes but management doesn't) and availability (and it's affect on the bottom line) is the thing that management understands best so that's what business-aligned security focuses on most... i wonder what it would be like if aligning security and business was a 2-way street...
what is integrity checking?
integrity checking is the process of comparing the current state of stored data and/or programs to a previously recorded state in order to detect any changes (and so it sometimes called change detection)...
generally the state information that gets used in the comparison is in the form of a hash of some kind and ideally the baseline state that the current state is compared to was generated when their was nothing wrong with the system...
the reasoning behind this technique is that for anything bad to happen on a system something on that system must change, so then detecting when something bad has happened simply requires detecting changes that shouldn't have happened...
integrity checking is generally considered one of the strongest anti-malware controls, since it has the potential to detect and locate all persistent malware intrusions along with any additional persistent changes to the system that malware could have made... unfortunately it is a detective, rather than preventative control - it can only detect when prevention has failed and so is only good after the fact... it also places a fair bit of burden on the user to be able to tell good changes from bad ones...
back to index
generally the state information that gets used in the comparison is in the form of a hash of some kind and ideally the baseline state that the current state is compared to was generated when their was nothing wrong with the system...
the reasoning behind this technique is that for anything bad to happen on a system something on that system must change, so then detecting when something bad has happened simply requires detecting changes that shouldn't have happened...
integrity checking is generally considered one of the strongest anti-malware controls, since it has the potential to detect and locate all persistent malware intrusions along with any additional persistent changes to the system that malware could have made... unfortunately it is a detective, rather than preventative control - it can only detect when prevention has failed and so is only good after the fact... it also places a fair bit of burden on the user to be able to tell good changes from bad ones...
back to index
Saturday, February 23, 2008
yes mr. rothman, there is a defense against drive-by downloads
in fact, there are several...
mike rothman's days of incite #5 for 2008 was about malware, and while he makes a good point about the inevitability of getting compromised by malware (it's something you really need to be prepared for, though some of us are still waiting) due in part to lack of user input needed for drive-by downloads to work and the difficulty in avoiding exposure to them, he manages to sow some fear, uncertainty, and doubt in the process by stating that there are no defenses against drive-by downloads...
well not to be contrarian, but there are in fact defenses against drive-by downloads... known-malware/exploit scanning in a layered service provider will block the old ones that get re-used (and we know old exploits get re-used) before they reach the browser or any other web content rendering component on the host...
a behavioural HIPS (or possibly even simple application whitelisting, depending on the circumstances) can conceivably stop known or unknown malware injected into the system through a drive-by download...
also, browsing from a sandbox will generally stop most things (known or unknown) coming in through a drive-by download from getting a foothold in the actual host system (leaving the intrusion in the sandbox itself)...
finally, not having the web rendering component that a particular drive-by download exploits installed and/or using a web-content whitelisting technology (such as the noscript firefox extension) can significantly reduce the vulnerable surface you present to the internet and thereby reduce your chances of being compromised...
remember folks, for every measure there is a counter-measure - drive-by downloads are not a magical super-attack that can't be stopped, they're just means of automatically installing malware when you visit a web page and the process can be blocked...
mike rothman's days of incite #5 for 2008 was about malware, and while he makes a good point about the inevitability of getting compromised by malware (it's something you really need to be prepared for, though some of us are still waiting) due in part to lack of user input needed for drive-by downloads to work and the difficulty in avoiding exposure to them, he manages to sow some fear, uncertainty, and doubt in the process by stating that there are no defenses against drive-by downloads...
well not to be contrarian, but there are in fact defenses against drive-by downloads... known-malware/exploit scanning in a layered service provider will block the old ones that get re-used (and we know old exploits get re-used) before they reach the browser or any other web content rendering component on the host...
a behavioural HIPS (or possibly even simple application whitelisting, depending on the circumstances) can conceivably stop known or unknown malware injected into the system through a drive-by download...
also, browsing from a sandbox will generally stop most things (known or unknown) coming in through a drive-by download from getting a foothold in the actual host system (leaving the intrusion in the sandbox itself)...
finally, not having the web rendering component that a particular drive-by download exploits installed and/or using a web-content whitelisting technology (such as the noscript firefox extension) can significantly reduce the vulnerable surface you present to the internet and thereby reduce your chances of being compromised...
remember folks, for every measure there is a counter-measure - drive-by downloads are not a magical super-attack that can't be stopped, they're just means of automatically installing malware when you visit a web page and the process can be blocked...
what is an LSP (layered service provider)?
layered service providers are a technology provided by microsoft to enable developers to insert their programs into the TCP/IP stack in windows... in layman's terms, this means that a developer who implements an LSP is making a program that will sit between the network(internet) and any network clients (such as browsers or email clients) running on the machine...
some malware has been known to be implemented as an LSP in order to intercept outgoing traffic and redirect it or send copies of it to malicious 3rd parties...
spyware isn't the only application for LSPs, however... it's also possible for an anti-malware vendor to implement an LSP that performs known-malware scanning (or sometimes more specifically known-exploit scanning) in order to catch and block attempts to exploit vulnerabilities in browsers and other network clients before they can ever reach those clients...
[see this link for more information on layered service providers]
back to index
some malware has been known to be implemented as an LSP in order to intercept outgoing traffic and redirect it or send copies of it to malicious 3rd parties...
spyware isn't the only application for LSPs, however... it's also possible for an anti-malware vendor to implement an LSP that performs known-malware scanning (or sometimes more specifically known-exploit scanning) in order to catch and block attempts to exploit vulnerabilities in browsers and other network clients before they can ever reach those clients...
[see this link for more information on layered service providers]
back to index
what is behaviour blocking?
behaviour blocking is the process of monitoring the behaviour of software running on a system and stopping any behaviour that is considered unauthorized or bad...
in the distant past behaviour blockers blocked a relatively simple list of behaviours without regard for which program was performing them... in effect, they enforced simple behavioural blacklists... even with a simple list of behaviours there was no behaviour that was unique to malware so there were times when the behaviours being intercepted needed to be allowed to continue - leading behaviour blockers to continually ask the user whether this or that behaviour should be allowed...
over the years the concept has become much more sophisticated and configurable - monitoring more types of behaviours and allowing certain behaviours to go unchallenged when performed by programs that are authorized to perform them (in essence adding behavioural whitelisting to it's repertoire) while blocking others automatically... this type of sophisticated behaviour blocker is now more widely referred to as an HIPS (though it's not the only thing referred to as such)...
back to index
in the distant past behaviour blockers blocked a relatively simple list of behaviours without regard for which program was performing them... in effect, they enforced simple behavioural blacklists... even with a simple list of behaviours there was no behaviour that was unique to malware so there were times when the behaviours being intercepted needed to be allowed to continue - leading behaviour blockers to continually ask the user whether this or that behaviour should be allowed...
over the years the concept has become much more sophisticated and configurable - monitoring more types of behaviours and allowing certain behaviours to go unchallenged when performed by programs that are authorized to perform them (in essence adding behavioural whitelisting to it's repertoire) while blocking others automatically... this type of sophisticated behaviour blocker is now more widely referred to as an HIPS (though it's not the only thing referred to as such)...
back to index
what is application whitelisting?
application whitelisting is, as the name suggests, an example of whitelisting whereby only applications that are authorized get to be executed/interpreted/run...
in the case of application whitelisting the whitelist itself is the list of authorized programs (generally with some integrity information like a cryptographic hash to ensure that a given program is actually the same as the one on the list rather than just having the same name)...
if the whitelist itself is provided by a vendor then it will necessarily be very large (as they have to account for all good programs that anyone might use) and may not include everything a user needs... if, on the other hand, the whitelist is provided by the user him/herself then it will likely only contain the programs that are relevant to the user, but the user will have to decide for him/herself which programs are trustworthy enough to put on the list... either way, the whitelist would need to be updated at least as often as the user's set of authorized software changes...
the anti-malware applications of this technique rely on malware never getting on the whitelist... so long as the whitelist remains malware-free then (barring exotic execution) malware shouldn't be able to run... a second, lesser understood requirement is that the application whitelist be able to recognize everything that qualifies as a program, lest some program types get executed without whitelist-based oversight...
back to index
in the case of application whitelisting the whitelist itself is the list of authorized programs (generally with some integrity information like a cryptographic hash to ensure that a given program is actually the same as the one on the list rather than just having the same name)...
if the whitelist itself is provided by a vendor then it will necessarily be very large (as they have to account for all good programs that anyone might use) and may not include everything a user needs... if, on the other hand, the whitelist is provided by the user him/herself then it will likely only contain the programs that are relevant to the user, but the user will have to decide for him/herself which programs are trustworthy enough to put on the list... either way, the whitelist would need to be updated at least as often as the user's set of authorized software changes...
the anti-malware applications of this technique rely on malware never getting on the whitelist... so long as the whitelist remains malware-free then (barring exotic execution) malware shouldn't be able to run... a second, lesser understood requirement is that the application whitelist be able to recognize everything that qualifies as a program, lest some program types get executed without whitelist-based oversight...
back to index
what is known-malware scanning?
known-malware scanning is the process of scanning a computer resource (be it a file, an email, an entire disk, etc) for malware that matches a malware signature and is therefore known to the scanner (hence 'known-malware' scanning)...
known-malware scanning (more often referred to as virus scanning despite the fact that scanners have been detecting non-viral malware for a long time now) is a blacklist-based technique for detecting/blocking known bad programs... the blacklist itself is the set of signatures the scanner uses to try and match samples against...
known-malware scanning is obviously only effective against malware that is known...
back to index
known-malware scanning (more often referred to as virus scanning despite the fact that scanners have been detecting non-viral malware for a long time now) is a blacklist-based technique for detecting/blocking known bad programs... the blacklist itself is the set of signatures the scanner uses to try and match samples against...
known-malware scanning is obviously only effective against malware that is known...
back to index
what is a sandbox?
in the anti-malware sense a sandbox is a (generally) simulated computer environment in which untrusted software (ie. potential malware) can be run while still keeping the trusted host environment isolated from it...
a sandbox can be implemented in more than one way, the most well known is probably the virtual machine... a virtual machine based sandbox is one where the computer hardware itself is simulated and an OS and other software run on top of that simulated hardware...
another type of sandbox is one that simulates access to resources (such as files or the registry) of an existing system by trapping attempts by programs running in the sandbox to access those resources and redirecting those access attempts to copies residing within the sandbox environment... this uses less resources than a traditional virtual machine and can be used in a more transparent way by end users because it doesn't set up a completely separate system which may or may not be similar to the host system they're likely familiar with (nor do they have to try to wrap their heads around the idea of a computer within a computer)...
a third (but much more primitive) technique which could arguably be considered a kind of sandbox is the use of different drive images to separate the main computing environment from other environments used for running untrusted code... this has the problem that the environment for trusted programs and the one for untrusted programs can't be in operation on the same computer at the same time, which makes it a little inconvenient if you only have one physical system...
ultimately these technologies are all meant to try to replace the original practice of using a physically separate computer dedicated to testing... a second physical computer for untrusted programs is probably the least convenient way to isolate a trusted environment from untrusted code but it is also probably the most secure...
back to index
a sandbox can be implemented in more than one way, the most well known is probably the virtual machine... a virtual machine based sandbox is one where the computer hardware itself is simulated and an OS and other software run on top of that simulated hardware...
another type of sandbox is one that simulates access to resources (such as files or the registry) of an existing system by trapping attempts by programs running in the sandbox to access those resources and redirecting those access attempts to copies residing within the sandbox environment... this uses less resources than a traditional virtual machine and can be used in a more transparent way by end users because it doesn't set up a completely separate system which may or may not be similar to the host system they're likely familiar with (nor do they have to try to wrap their heads around the idea of a computer within a computer)...
a third (but much more primitive) technique which could arguably be considered a kind of sandbox is the use of different drive images to separate the main computing environment from other environments used for running untrusted code... this has the problem that the environment for trusted programs and the one for untrusted programs can't be in operation on the same computer at the same time, which makes it a little inconvenient if you only have one physical system...
ultimately these technologies are all meant to try to replace the original practice of using a physically separate computer dedicated to testing... a second physical computer for untrusted programs is probably the least convenient way to isolate a trusted environment from untrusted code but it is also probably the most secure...
back to index
what is a whitelist?
in contrast to the blacklist, a whitelist is a list of known good things that we don't need to avoid, block, or weed out... a whitelist is generally used in situations where nothing is allowed except those things on the whitelist... this is sometimes referred to as 'default deny'...
a classical real world example of a whitelist is the guest list for an exclusive social function (where you don't get in unless you're on the list)... further examples include the list of things you're allowed to put in your recycling bin, the list of foods and drugs approved by the FDA, or the set of people you'd trust with a secret...
in the anti-malware context the most well known example (to average users) of a whitelist is the list of applications allowed by a software firewall to connect to the internet... you can also have a list of applications allowed to execute (or perform any other function), a list of websites allowed to execute scripts in your browser, a list of email senders allowed past your spam filter, etc...
back to index
a classical real world example of a whitelist is the guest list for an exclusive social function (where you don't get in unless you're on the list)... further examples include the list of things you're allowed to put in your recycling bin, the list of foods and drugs approved by the FDA, or the set of people you'd trust with a secret...
in the anti-malware context the most well known example (to average users) of a whitelist is the list of applications allowed by a software firewall to connect to the internet... you can also have a list of applications allowed to execute (or perform any other function), a list of websites allowed to execute scripts in your browser, a list of email senders allowed past your spam filter, etc...
back to index
what is a blacklist?
a blacklist is, simply put, a list of known bad things that we would like to avoid, block, weed out, etc... a blacklist is generally used in situations where everything is allowed by default except those things on the list... this is sometimes referred to as 'default allow'...
a classical real world example would be the TSA's no-fly list, an example that's often dredged up to support the argument that blacklists are themselves bad... another example would be the registered sex offenders list, a third would be the list of things you shouldn't take when you're pregnant, and a fourth would be the list of things you tell your child not to do... the argument against blacklists in general starts to fall down when you start to consider those kinds of examples - whether a particular blacklist is bad or not is not determined by the mere fact that it's a blacklist...
in the anti-malware context, the most well known example of a blacklist is a known-malware scanner (more commonly referred to as a virus scanner)... that's just a blacklist of bad programs, however... you can also have lists of bad behaviours, behaviour combinations, bad websites, bad (spammy) words in emails, etc...
back to index
a classical real world example would be the TSA's no-fly list, an example that's often dredged up to support the argument that blacklists are themselves bad... another example would be the registered sex offenders list, a third would be the list of things you shouldn't take when you're pregnant, and a fourth would be the list of things you tell your child not to do... the argument against blacklists in general starts to fall down when you start to consider those kinds of examples - whether a particular blacklist is bad or not is not determined by the mere fact that it's a blacklist...
in the anti-malware context, the most well known example of a blacklist is a known-malware scanner (more commonly referred to as a virus scanner)... that's just a blacklist of bad programs, however... you can also have lists of bad behaviours, behaviour combinations, bad websites, bad (spammy) words in emails, etc...
back to index
what is anti-malware / anti-virus software?
anti-malware is basically the idea of being against malware, it's creation, it's malicious dissemination, etc... anti-malware software, therefore, is software meant to stop, detect, or otherwise clean up after malware... it's an umbrella term that covers basically all technologies that can be used in the fight against malware...
the term anti-virus arose at a time when almost all malware was viral in nature (in fact at a time before there was even a need for an umbrella term like malware) and so anti-virus software was anti-malware software for the single type of malware that was an issue... over time malware has diversified into many different types and as that has occurred anti-virus software has branched out into dealing with those other types as well... further, the underlying concepts behind virtually all of today's anti-malware technology originally came from the anti-virus field... as such anti-virus is basically a synonym for anti-malware...
back to index
the term anti-virus arose at a time when almost all malware was viral in nature (in fact at a time before there was even a need for an umbrella term like malware) and so anti-virus software was anti-malware software for the single type of malware that was an issue... over time malware has diversified into many different types and as that has occurred anti-virus software has branched out into dealing with those other types as well... further, the underlying concepts behind virtually all of today's anti-malware technology originally came from the anti-virus field... as such anti-virus is basically a synonym for anti-malware...
back to index
Monday, February 18, 2008
when all you have is a hammer, everything looks like a nail
i've got a bone to pick with the av industry (don't look so surprised, i've been critical of them before) that has been stewing for a while now and recent conversations i've had elsewhere have convinced me that it's time to say something...
the problem is the apparent near-exclusive focus on known-malware scanning... don't get me wrong, old malware certainly lingers and known-malware scanning is a quick and easy way to make old malware a non-issue in your environment, but that only works for old malware...
known-malware scanning is not now, nor has it ever been the appropriate tool for dealing with new/unknown malware... for the armchair strategists out there, imagine a situation where you have no intelligence on enemy and then imagine trying to use tactics that require such intelligence in order to be effective... the very notion of using known-malware techniques against unknown malware is an oxymoron - and yet as the set of malware that qualifies as new/unknown at any given time increases, the most obvious reaction from vendors has been to release signatures faster... it's as if they believe they can somehow change the character of the problem of new malware so that known-malware scanning can be the 'solution' to this part of the malware problem too... like they can fix the problem that prevents known-malware scanning from working on unknown malware...
but of course, they don't actually accomplish that... they narrow the window of opportunity a bit for some of the malware, but not enough and certainly not entirely... no matter how quickly signatures are released there's going to be a period of time after the malware's release where it qualifies as unknown and no known-malware technique is going to be suitable for it... furthermore, as the rate of malware production increases the total number of malware samples in that unknown-malware window will increase... while it's certainly necessary to release more signatures per week/month/whatever, getting them out the door faster instead of focusing on more appropriate ways of dealing with the unknown malware problem isn't helping anyone...
instead what it accomplishes is: to cut quality assurance corners (which is the cheapest and easiest way to speed up delivery of anything) resulting in bad signatures that hose customer systems, to make the industry look like a one-trick pony by virtue of the ever escalating effort applied to this single technology, to reinforce in dumb customers the notion that they are staying on top of the problem just by keeping their scanner up to date, and to make smart customers question whether anti-virus has any value at all...
oh, and if you think heuristics are a known-malware scanner's saving grace then you haven't been reading the same retrospective scanner test results i have... the latest retrospective report available from av-comparatives.org (november '07 at the time of writing) shows that by and large the ability of scanners to detect malware using heuristics alone is dismal... only 3 of the 13 products tested managed to score above 50% and even then the best was only 81% (and that product was penalized in the overall rating due to a high false positive rate)... sure 81% is pretty good for heuristics, but it's not good enough to rely on exclusively for protection from new/unknown malware and most were less than half that effective...
av vendors need to start making a much more visible effort in the realm of generic detection techniques, they need to empower people to use those techniques, and they need to stop promulgating this farcical 'solution' snake-oil that makes people think one thing is all you need and instead represent their technologies as tools... that way it's more intuitive that different technologies do different things and that it's often desirable to utilize more than one because there's more than one job to do (more than one problem to deal with)... it makes no intuitive sense to need more than one solution (and believe me when i say people will view the different parts of a security suite as more than one solution) but it makes perfect sense to have a toolbox with more than one tool in it...
the problem is the apparent near-exclusive focus on known-malware scanning... don't get me wrong, old malware certainly lingers and known-malware scanning is a quick and easy way to make old malware a non-issue in your environment, but that only works for old malware...
known-malware scanning is not now, nor has it ever been the appropriate tool for dealing with new/unknown malware... for the armchair strategists out there, imagine a situation where you have no intelligence on enemy and then imagine trying to use tactics that require such intelligence in order to be effective... the very notion of using known-malware techniques against unknown malware is an oxymoron - and yet as the set of malware that qualifies as new/unknown at any given time increases, the most obvious reaction from vendors has been to release signatures faster... it's as if they believe they can somehow change the character of the problem of new malware so that known-malware scanning can be the 'solution' to this part of the malware problem too... like they can fix the problem that prevents known-malware scanning from working on unknown malware...
but of course, they don't actually accomplish that... they narrow the window of opportunity a bit for some of the malware, but not enough and certainly not entirely... no matter how quickly signatures are released there's going to be a period of time after the malware's release where it qualifies as unknown and no known-malware technique is going to be suitable for it... furthermore, as the rate of malware production increases the total number of malware samples in that unknown-malware window will increase... while it's certainly necessary to release more signatures per week/month/whatever, getting them out the door faster instead of focusing on more appropriate ways of dealing with the unknown malware problem isn't helping anyone...
instead what it accomplishes is: to cut quality assurance corners (which is the cheapest and easiest way to speed up delivery of anything) resulting in bad signatures that hose customer systems, to make the industry look like a one-trick pony by virtue of the ever escalating effort applied to this single technology, to reinforce in dumb customers the notion that they are staying on top of the problem just by keeping their scanner up to date, and to make smart customers question whether anti-virus has any value at all...
oh, and if you think heuristics are a known-malware scanner's saving grace then you haven't been reading the same retrospective scanner test results i have... the latest retrospective report available from av-comparatives.org (november '07 at the time of writing) shows that by and large the ability of scanners to detect malware using heuristics alone is dismal... only 3 of the 13 products tested managed to score above 50% and even then the best was only 81% (and that product was penalized in the overall rating due to a high false positive rate)... sure 81% is pretty good for heuristics, but it's not good enough to rely on exclusively for protection from new/unknown malware and most were less than half that effective...
av vendors need to start making a much more visible effort in the realm of generic detection techniques, they need to empower people to use those techniques, and they need to stop promulgating this farcical 'solution' snake-oil that makes people think one thing is all you need and instead represent their technologies as tools... that way it's more intuitive that different technologies do different things and that it's often desirable to utilize more than one because there's more than one job to do (more than one problem to deal with)... it makes no intuitive sense to need more than one solution (and believe me when i say people will view the different parts of a security suite as more than one solution) but it makes perfect sense to have a toolbox with more than one tool in it...
why proactive anti-malware controls are dumb
no, i'm not trying to insult proponents of proactive techniques... i'm not trying to say that using proactive controls is dumb, but rather that the controls themselves are dumb...
the diametrical relationship between proactive and reactive preventative controls can be considered equivalent to the one between generic and malware-specific (aka known-malware) techniques respectively... to be truly proactive means to be able to do something about or block a piece of malware before anyone knows anything about it - therefore it can't be malware-specific because a malware-specific control can't be built until after knowledge of the malware is acquired...
therefore proactive/generic controls lack the knowledge component that reactive/malware-specific techniques have and so are stupid... by extension, built-in knowledge is a luxury only reactive/malware-specific techniques can have... of course it is entirely possible to have a little bit of both and provide some shades of gray between these black and white polar opposites...
being stupid isn't necessarily a bad thing in a control, mind you... sharks are often referred to as being perfect killing machines but you won't catch anyone accusing them of being unusually intelligent... so using a dumb control can still be smart if the control is effective... in fact, one could even say that using a dumb control effectively requires intelligence because it doesn't come with any of it's own...
the diametrical relationship between proactive and reactive preventative controls can be considered equivalent to the one between generic and malware-specific (aka known-malware) techniques respectively... to be truly proactive means to be able to do something about or block a piece of malware before anyone knows anything about it - therefore it can't be malware-specific because a malware-specific control can't be built until after knowledge of the malware is acquired...
therefore proactive/generic controls lack the knowledge component that reactive/malware-specific techniques have and so are stupid... by extension, built-in knowledge is a luxury only reactive/malware-specific techniques can have... of course it is entirely possible to have a little bit of both and provide some shades of gray between these black and white polar opposites...
being stupid isn't necessarily a bad thing in a control, mind you... sharks are often referred to as being perfect killing machines but you won't catch anyone accusing them of being unusually intelligent... so using a dumb control can still be smart if the control is effective... in fact, one could even say that using a dumb control effectively requires intelligence because it doesn't come with any of it's own...
Saturday, February 09, 2008
the state of anti-virus
there have been some posts and discussions recently about anti-virus that i thought were interesting (and not just because my name was invoked) and rather that split my thoughts between multiple sites i've opted to combine everything here... thankfully most involved welcome open debate on the subject, though others not so much - but refusing to believe malware and vulnerabilities are orthogonal to one another kinda limits where the discussion can go, so oh well...
so i'm going to start with michael's post over at mcwresearch.com... now i hope michael doesn't take this the wrong way, but i quite enjoyed the irony of his post's title - "AV must innovate or die"... michael of course comes from a behaviour-based HIPS background and behaviour-based HIPS (or at the very least it's precursor) began it's life in an anti-virus product...
furthermore, as i've mentioned before, anti-virus isn't just blacklist-based scanners... rather it's an archaic term for anti-malware and since HIPS is itself a type of anti-malware technology, HIPS is fundamentally part of the same industry that michael is criticizing - which means he himself is making that innovation happen and making sure 'anti-virus' doesn't die...
of course, when michael used the term anti-virus, he really was just talking about known-malware scanners and criticizing them for not being able to do what is totally outside the scope of a known-malware scanner - block unauthorized behaviour... that's actually a pretty unfair criticism since he's only considering the scanner technology itself and no technology (not scanners or HIPS) is perfect, they all do different things and they all have their limitations... he's mentioned in the past that anti-virus needs to get it's peanut butter mixed in with IPS's chocolate so i'm going to give michael a treat... symantec has HIPS, mcafee has HIPS, trend micro has HIPS, sophos has HIPS, kaspersky has HIPS built into KIS, f-secure has HIPS, panda has HIPS, etc... perhaps in the future michael will consider all the technologies that traditional av vendors make available so that he doesn't have to compare apples to oranges anymore...
the other post that caught my eye was this one by lonervamp (he's also a michael but let's not get ambiguous) about where he sees the state of anti-virus being... he also refers to anti-virus in a strictly known-malware scanning context and discusses the role it's supposed to play in a defensive strategy and how it's benefits have waned with the development of procedural and technological layers that complement it's use... i would actually tend to agree with that observation, but i'd also note that being complementary is a commutative property - known-malware scanning complements those other layers as well... could you go without scanning entirely? sure, just like you could use only scanning, but they're better together than they are on their own... that the benefits of known-malware scanning wane in the presence of complementary layers is entirely understandable and expected as the layers in a multi-layered defense will generally partially overlap each other... it's because of that overlap that the benefits of any individual layer may wane, but a layer isn't redundant or useless unless it's completely overlapped by the other layers...
so a question that is perhaps of interest to both posters is at what point does known-malware scanning become entirely redundant?... personally, i don't think it ever does... any given technology has an achilles heel that can allow a piece of malware to get past it... for known-malware scanning this achilles heel is novelty - new/unknown malware is clearly not something known-malware scanning can deal with... other technologies have their own weaknesses too but as weaknesses go novelty is unique because it's the only one that wears off... the media makes quite a big deal out of all the new malware being created and how it keeps getting past known-malware scanners, and at the same time it rarely mentions cases of malware incidents involving old malware... this leads to the erroneous impression that one needn't worry about old malware... old malware still pops up for a variety of different reasons and although it may use tricks that can still allow it to get past other technologies, by the time it gets old it's not going to be getting past a known-malware scanner anymore...
lonervamp also made a distinction between home use and business use, suggesting that known-malware scanning was more likely to be displaced in the business than in the home... i can certainly see that - one of the strengths of known-malware scanning is that the expertise that makes it work is embedded in the product so that the user is relieved of having that burden... many other technologies require knowledge and skill from the customer that may or may not be there... in a business you're much more likely to have trained, knowledgeable individuals (the IT staff) who can make the intelligent decisions necessary for products with more client side configuration to work effectively... that means that alternative technologies become a more feasible option in that environment...
that isn't to say i'd suggest dropping known-malware scanning though... even in a business i think it has it's place... i don't think it should be the only type of technology used, mind you - there are many types of technology available (sometimes even from a single vendor) and they're just waiting to be used... if i were going to suggest anything it would be more comprehensive layering, not simply different layers... the goal should be better overall coverage and substituting one layer for another isn't necessarily the way to get there...
so i'm going to start with michael's post over at mcwresearch.com... now i hope michael doesn't take this the wrong way, but i quite enjoyed the irony of his post's title - "AV must innovate or die"... michael of course comes from a behaviour-based HIPS background and behaviour-based HIPS (or at the very least it's precursor) began it's life in an anti-virus product...
furthermore, as i've mentioned before, anti-virus isn't just blacklist-based scanners... rather it's an archaic term for anti-malware and since HIPS is itself a type of anti-malware technology, HIPS is fundamentally part of the same industry that michael is criticizing - which means he himself is making that innovation happen and making sure 'anti-virus' doesn't die...
of course, when michael used the term anti-virus, he really was just talking about known-malware scanners and criticizing them for not being able to do what is totally outside the scope of a known-malware scanner - block unauthorized behaviour... that's actually a pretty unfair criticism since he's only considering the scanner technology itself and no technology (not scanners or HIPS) is perfect, they all do different things and they all have their limitations... he's mentioned in the past that anti-virus needs to get it's peanut butter mixed in with IPS's chocolate so i'm going to give michael a treat... symantec has HIPS, mcafee has HIPS, trend micro has HIPS, sophos has HIPS, kaspersky has HIPS built into KIS, f-secure has HIPS, panda has HIPS, etc... perhaps in the future michael will consider all the technologies that traditional av vendors make available so that he doesn't have to compare apples to oranges anymore...
the other post that caught my eye was this one by lonervamp (he's also a michael but let's not get ambiguous) about where he sees the state of anti-virus being... he also refers to anti-virus in a strictly known-malware scanning context and discusses the role it's supposed to play in a defensive strategy and how it's benefits have waned with the development of procedural and technological layers that complement it's use... i would actually tend to agree with that observation, but i'd also note that being complementary is a commutative property - known-malware scanning complements those other layers as well... could you go without scanning entirely? sure, just like you could use only scanning, but they're better together than they are on their own... that the benefits of known-malware scanning wane in the presence of complementary layers is entirely understandable and expected as the layers in a multi-layered defense will generally partially overlap each other... it's because of that overlap that the benefits of any individual layer may wane, but a layer isn't redundant or useless unless it's completely overlapped by the other layers...
so a question that is perhaps of interest to both posters is at what point does known-malware scanning become entirely redundant?... personally, i don't think it ever does... any given technology has an achilles heel that can allow a piece of malware to get past it... for known-malware scanning this achilles heel is novelty - new/unknown malware is clearly not something known-malware scanning can deal with... other technologies have their own weaknesses too but as weaknesses go novelty is unique because it's the only one that wears off... the media makes quite a big deal out of all the new malware being created and how it keeps getting past known-malware scanners, and at the same time it rarely mentions cases of malware incidents involving old malware... this leads to the erroneous impression that one needn't worry about old malware... old malware still pops up for a variety of different reasons and although it may use tricks that can still allow it to get past other technologies, by the time it gets old it's not going to be getting past a known-malware scanner anymore...
lonervamp also made a distinction between home use and business use, suggesting that known-malware scanning was more likely to be displaced in the business than in the home... i can certainly see that - one of the strengths of known-malware scanning is that the expertise that makes it work is embedded in the product so that the user is relieved of having that burden... many other technologies require knowledge and skill from the customer that may or may not be there... in a business you're much more likely to have trained, knowledgeable individuals (the IT staff) who can make the intelligent decisions necessary for products with more client side configuration to work effectively... that means that alternative technologies become a more feasible option in that environment...
that isn't to say i'd suggest dropping known-malware scanning though... even in a business i think it has it's place... i don't think it should be the only type of technology used, mind you - there are many types of technology available (sometimes even from a single vendor) and they're just waiting to be used... if i were going to suggest anything it would be more comprehensive layering, not simply different layers... the goal should be better overall coverage and substituting one layer for another isn't necessarily the way to get there...
Wednesday, February 06, 2008
samples, variants, and signatures - oh my
last week anton chuvakin characterized the new av-test.org results as "widely ridiculed"... this struck me as odd because i hadn't seen any ridicule so i asked for links... that didn't get me anywhere so i took to googling for the answer and trying to guess what keywords might match this nebulous ridicule anton was speaking of...
now, while i didn't find ridicule, per se, i did find some significant criticism in a thread at wilderssecurity.com by none other than paul wilders himself (i really need to find a way to aggregate web forums so i can actually follow these sorts of discussions instead of finding out about them after the fact)... the criticisms weren't totally unreasonable, in fact i even agree with one (that a good test needs thorough supporting documentation on things like test methodology, sample acquisition, test bed maintenance, etc - how i wish we could see documentation as thorough as the vtc used to put out) but some i think were a little off...
one such criticism had to do with comparing apples to oranges, or in this case the number of samples used in the test to the number of signatures in a product's database - which, when taken with some of the confusion that lead to, makes me think a discussion of what these things are might be in order...
a sample is just a file containing a piece of malware... you distinguish one sample from the next by simple binary comparison - if the files are different then the samples are different, otherwise they're just copies of the same sample...
a variant is a member of a malware family... one variant is distinguished from another by being sufficiently different from that other variant that it makes sense to consider it a different thing, but that is a subjective determination usually made in the context of what makes sense for a particular detection technology... there is no objective, technology-neutral standard by which we can say sample X represents a different variant than sample Y, therefore the distinction between variants is a technology-dependent logical construct... as an example, for a scanning engine that looks at every single byte of a piece of malware it would make sense to be a lot more granular in drawing distinctions between variants than for one that only looks at at most N bytes somewhere within the body of the malware... more generally, technologies that use fundamentally different approaches to malware recognition can likewise result in different delineations between variants... this is one of the reasons why they say each vendor counts viruses/malware differently...
signatures are chunks of data that tell a scanner what a particular piece of malware looks like... they can be a selection of bytes from the actual malware (ie. a scan string), a hash value (for non-parasitic, non-polymorphic malware), a regular expression, or something written in a proprietary virus(malware) description language... the conceptual ideal is that there is a 1-to-1 correlation between signatures and variants but in practice multiple signatures may be required for a single variant (as has sometimes been the case for handling polymorphism) or alternatively a single signature might handle multiple variants or even an entire family...
now obviously, given the above descriptions, comparing samples to signatures or variants doesn't make a lot of sense, but a variant-centric focus when evaluating a test of anti-malware products is not altogether unfamiliar... in a detection test it's important to make sure you include all (or as many as possible) significant members of the malware population and also to make sure that no member is included more than any other so that detection of each is given equal weight/importance... back in the days when viruses ruled the earth it was actually necessary to try and look at things from a variant-centric perspective (subjective as it was) because of how viruses worked... the way file infecting viruses operated, it was trivial to imagine many samples containing not just the same variant of a virus but instances that were all offspring of a common parent... this made it necessary to try to tag samples with variant id's in an effort to enforce good coverage and uniformity...
these days the kind of complications that parasitic self-replication create in malware detection tests are much less of an issue because malware exhibiting those properties make up a much smaller proportion of the malware population... malware that exists as a stand-alone file is now the norm so the simpler sample-centric approach (at least for the non-viral samples) becomes more reasonable...
one potential complication that might still make a variant-centric approach necessary is packed malware or more generally malware incorporating server-side polymorphism... at least that's an argument one might bring up (and i think packed malware was mentioned in the thread) but i think there's a stronger argument to be made for server-side polymorphism in the general case producing distinctly new variants in spite common root malware that they all came from... this is because the resulting malware is the product of both relatively old malware (though the root malware may not technically qualify as known) and unknown and unguessable transformations... likewise with packing in particular, not all scanning engines deal with repacked malware equally well (even though we know many packers, the packers themselves can be altered to produce something we couldn't have guessed) so arguing that many samples created from the same root piece of malware are all the same variant may not be reasonable in light of the subjectivity of the variant concept...
given all this, from the information available in the test results in question, there really doesn't seem to be anything all that wrong... that said, without the thorough supporting documentation, we can't really verify that things are all that right either so those who really can and do read more than just the executive summary are stuck taking the results of this test with a grain of salt (in addition to the grain of salt one takes any detection test in isolation with, since the relative effectiveness of various products can change pretty quickly over a short time)...
(and anton will just have to believe what he wants to believe about whether the results that seem worthy of ridicule point to a cherry-picked test bed or not - which would be some feat, considering it's size)
now, while i didn't find ridicule, per se, i did find some significant criticism in a thread at wilderssecurity.com by none other than paul wilders himself (i really need to find a way to aggregate web forums so i can actually follow these sorts of discussions instead of finding out about them after the fact)... the criticisms weren't totally unreasonable, in fact i even agree with one (that a good test needs thorough supporting documentation on things like test methodology, sample acquisition, test bed maintenance, etc - how i wish we could see documentation as thorough as the vtc used to put out) but some i think were a little off...
one such criticism had to do with comparing apples to oranges, or in this case the number of samples used in the test to the number of signatures in a product's database - which, when taken with some of the confusion that lead to, makes me think a discussion of what these things are might be in order...
a sample is just a file containing a piece of malware... you distinguish one sample from the next by simple binary comparison - if the files are different then the samples are different, otherwise they're just copies of the same sample...
a variant is a member of a malware family... one variant is distinguished from another by being sufficiently different from that other variant that it makes sense to consider it a different thing, but that is a subjective determination usually made in the context of what makes sense for a particular detection technology... there is no objective, technology-neutral standard by which we can say sample X represents a different variant than sample Y, therefore the distinction between variants is a technology-dependent logical construct... as an example, for a scanning engine that looks at every single byte of a piece of malware it would make sense to be a lot more granular in drawing distinctions between variants than for one that only looks at at most N bytes somewhere within the body of the malware... more generally, technologies that use fundamentally different approaches to malware recognition can likewise result in different delineations between variants... this is one of the reasons why they say each vendor counts viruses/malware differently...
signatures are chunks of data that tell a scanner what a particular piece of malware looks like... they can be a selection of bytes from the actual malware (ie. a scan string), a hash value (for non-parasitic, non-polymorphic malware), a regular expression, or something written in a proprietary virus(malware) description language... the conceptual ideal is that there is a 1-to-1 correlation between signatures and variants but in practice multiple signatures may be required for a single variant (as has sometimes been the case for handling polymorphism) or alternatively a single signature might handle multiple variants or even an entire family...
now obviously, given the above descriptions, comparing samples to signatures or variants doesn't make a lot of sense, but a variant-centric focus when evaluating a test of anti-malware products is not altogether unfamiliar... in a detection test it's important to make sure you include all (or as many as possible) significant members of the malware population and also to make sure that no member is included more than any other so that detection of each is given equal weight/importance... back in the days when viruses ruled the earth it was actually necessary to try and look at things from a variant-centric perspective (subjective as it was) because of how viruses worked... the way file infecting viruses operated, it was trivial to imagine many samples containing not just the same variant of a virus but instances that were all offspring of a common parent... this made it necessary to try to tag samples with variant id's in an effort to enforce good coverage and uniformity...
these days the kind of complications that parasitic self-replication create in malware detection tests are much less of an issue because malware exhibiting those properties make up a much smaller proportion of the malware population... malware that exists as a stand-alone file is now the norm so the simpler sample-centric approach (at least for the non-viral samples) becomes more reasonable...
one potential complication that might still make a variant-centric approach necessary is packed malware or more generally malware incorporating server-side polymorphism... at least that's an argument one might bring up (and i think packed malware was mentioned in the thread) but i think there's a stronger argument to be made for server-side polymorphism in the general case producing distinctly new variants in spite common root malware that they all came from... this is because the resulting malware is the product of both relatively old malware (though the root malware may not technically qualify as known) and unknown and unguessable transformations... likewise with packing in particular, not all scanning engines deal with repacked malware equally well (even though we know many packers, the packers themselves can be altered to produce something we couldn't have guessed) so arguing that many samples created from the same root piece of malware are all the same variant may not be reasonable in light of the subjectivity of the variant concept...
given all this, from the information available in the test results in question, there really doesn't seem to be anything all that wrong... that said, without the thorough supporting documentation, we can't really verify that things are all that right either so those who really can and do read more than just the executive summary are stuck taking the results of this test with a grain of salt (in addition to the grain of salt one takes any detection test in isolation with, since the relative effectiveness of various products can change pretty quickly over a short time)...
(and anton will just have to believe what he wants to believe about whether the results that seem worthy of ridicule point to a cherry-picked test bed or not - which would be some feat, considering it's size)
what is packed malware?
packed or repacked malware is malware that has been modified using a runtime compression (or encryption) program...
runtime compression programs compress an executable file and prepend or *append a stub to the file containing the code to decompress it at runtime...
malware authors (or even just people deploying malware) use this functionality as a cheap and easy way to turn a known piece of malware into something 'new' that no one has ever seen before and that known-malware scanners can't detect... this is one of the many possible ways to implement the transformation function of server-side polymorphism...
although the malware is transformed in a manner similar to how conventional polymorphic viruses transformed themselves, the generic solution that worked so well for polymorphism doesn't necessarily work as well for packed malware because the size of todays malware combined with the potential to chain multiple packing transformations together make the amount of work necessary to emulate the full unpacking operation much more expensive and time consuming in comparison... that said, dynamic translation promises speed improvements over conventional emulation so that generic unpacking may still be workable...alternatively, some vendors have taken to (or at least considered) identifying packers that are used primarily/exclusively for obfuscating malware and alerting on any file packed by such a packer...
*a less general approach, but one with a little more heuristic value is to identify those packers used primarily/exclusively for obfuscating malware and alert on any file packed by such a packer...
*the most straightforward approach, is of course to have a library of unpacking algorithms for known packers and use those to unpack the malware - however this packer-specific approach has many of the same (or at least analogous) limitations that known-malware scanning itself has as even minor variations in the packing/unpacking algorithm (which can easily be made for malicious purposes) can potentially result in a failure to detect which packer was used and/or unpack the malware properly...
[* corrections/clarifications prompted by vesselin bontchev]
back to index
runtime compression programs compress an executable file and prepend or *append a stub to the file containing the code to decompress it at runtime...
malware authors (or even just people deploying malware) use this functionality as a cheap and easy way to turn a known piece of malware into something 'new' that no one has ever seen before and that known-malware scanners can't detect... this is one of the many possible ways to implement the transformation function of server-side polymorphism...
although the malware is transformed in a manner similar to how conventional polymorphic viruses transformed themselves, the generic solution that worked so well for polymorphism doesn't necessarily work as well for packed malware because the size of todays malware combined with the potential to chain multiple packing transformations together make the amount of work necessary to emulate the full unpacking operation much more expensive and time consuming in comparison... that said, dynamic translation promises speed improvements over conventional emulation so that generic unpacking may still be workable...
*a less general approach, but one with a little more heuristic value is to identify those packers used primarily/exclusively for obfuscating malware and alert on any file packed by such a packer...
*the most straightforward approach, is of course to have a library of unpacking algorithms for known packers and use those to unpack the malware - however this packer-specific approach has many of the same (or at least analogous) limitations that known-malware scanning itself has as even minor variations in the packing/unpacking algorithm (which can easily be made for malicious purposes) can potentially result in a failure to detect which packer was used and/or unpack the malware properly...
[* corrections/clarifications prompted by vesselin bontchev]
back to index
Saturday, February 02, 2008
when is a PUP not a PUP?
when it hides itself...
i came across a post on the mcafee avert labs blog the other day talking about potentially unwanted programs adding 'rootkit' functionality and i was struck by the absurdity of it...
if a PUP is using stealth and taking steps to avoid detection, why are we bothering with the euphemistic classification of 'possibly unwanted program'?
that a program is possibly unwanted implies that there is also the possibly that it is wanted, but taking steps to avoid detection implies that the program's creators don't care if the user wants the program or not and are in fact anticipating that the user won't want it...
if the creators of the software don't genuinely believe people want their software, why are we giving them the benefit of the doubt? i can see some legitimate reasons for software to hide other things on a system (to protect them from uninformed alteration, for example) but i can't see any legitimate reason for a program to hide it's own presence...
i'm not going to call a spade a spade, i'm going to call it a god damned shovel - if what used to be called a potentially unwanted program has added stealthkit functionality then it's no longer a potentially unwanted program, it's fully fledged malware... not all spyware/adware/what-have-you qualified as potentially unwanted programs in the first place, it was always a very special and very tenuous distinction that applied only to the most benign instances... actively avoiding detection isn't the mark of something benign...
i came across a post on the mcafee avert labs blog the other day talking about potentially unwanted programs adding 'rootkit' functionality and i was struck by the absurdity of it...
if a PUP is using stealth and taking steps to avoid detection, why are we bothering with the euphemistic classification of 'possibly unwanted program'?
that a program is possibly unwanted implies that there is also the possibly that it is wanted, but taking steps to avoid detection implies that the program's creators don't care if the user wants the program or not and are in fact anticipating that the user won't want it...
if the creators of the software don't genuinely believe people want their software, why are we giving them the benefit of the doubt? i can see some legitimate reasons for software to hide other things on a system (to protect them from uninformed alteration, for example) but i can't see any legitimate reason for a program to hide it's own presence...
i'm not going to call a spade a spade, i'm going to call it a god damned shovel - if what used to be called a potentially unwanted program has added stealthkit functionality then it's no longer a potentially unwanted program, it's fully fledged malware... not all spyware/adware/what-have-you qualified as potentially unwanted programs in the first place, it was always a very special and very tenuous distinction that applied only to the most benign instances... actively avoiding detection isn't the mark of something benign...
Monday, January 28, 2008
you can't win for trying
first, waves upon waves of people complain that signatures are the wrong way to go, that heuristics are too weak and need to be stronger
then, in reaction to that the vendors make the heuristics more strict and guess what happens - false alarms increase and people think anti-virus is getting 'dumb'...
the truth is anti-virus is no more dumb than it ever was, it's simply less tolerant...
now i'm sure there will be waves upon waves of people calling for other things - among them probably smarter heuristics.. to those people i'd like to say this: show me your solution to the halting problem and i'll show you a smarter heuristic...
sure you could make heuristics that are better able to distinguish between past malware and legitimate files without solving the halting problem, and no doubt that is one of the many things designers of heuristic analysis engines are constantly trying to do... unfortunately future malware is the class of malware that most needs alternative detection technologies like heuristics (because past malware is where signatures actually shine)... future malware is, by definition, different from past malware and since malware is created by intelligent adversaries, optimizing for accuracy on past malware doesn't help with future malware... in fact, there's no guarantee stricter heuristics will help either (at least not against those malware writers who use scanners to help optimize their malware for non-detection), but it does have a better chance and frankly, for a business the cost to of a false positive is generally a lot less than the cost of a false negative...
as for making heuristics that are better able to distinguish between future malware and legitimate files, not only would such a heuristic engine need to be better able to determine what a file does by analyzing it's contents (a necessity due to not knowing beforehand what future malware will look like, and a pursuit where the halting problem has real and significant relevance) but also be better able to determine factors that are actually beyond the scope of computation such as the context in which such code would be executed (ie. at what point do you definitively label format.com with a possibly different filename as good or bad)... as such, even if we could solve the halting problem we still wouldn't have a perfect heuristic engine, only a smarter one - and without the contextual understanding, smarter might not even turn out to be that much better...
then, in reaction to that the vendors make the heuristics more strict and guess what happens - false alarms increase and people think anti-virus is getting 'dumb'...
the truth is anti-virus is no more dumb than it ever was, it's simply less tolerant...
now i'm sure there will be waves upon waves of people calling for other things - among them probably smarter heuristics.. to those people i'd like to say this: show me your solution to the halting problem and i'll show you a smarter heuristic...
sure you could make heuristics that are better able to distinguish between past malware and legitimate files without solving the halting problem, and no doubt that is one of the many things designers of heuristic analysis engines are constantly trying to do... unfortunately future malware is the class of malware that most needs alternative detection technologies like heuristics (because past malware is where signatures actually shine)... future malware is, by definition, different from past malware and since malware is created by intelligent adversaries, optimizing for accuracy on past malware doesn't help with future malware... in fact, there's no guarantee stricter heuristics will help either (at least not against those malware writers who use scanners to help optimize their malware for non-detection), but it does have a better chance and frankly, for a business the cost to of a false positive is generally a lot less than the cost of a false negative...
as for making heuristics that are better able to distinguish between future malware and legitimate files, not only would such a heuristic engine need to be better able to determine what a file does by analyzing it's contents (a necessity due to not knowing beforehand what future malware will look like, and a pursuit where the halting problem has real and significant relevance) but also be better able to determine factors that are actually beyond the scope of computation such as the context in which such code would be executed (ie. at what point do you definitively label format.com with a possibly different filename as good or bad)... as such, even if we could solve the halting problem we still wouldn't have a perfect heuristic engine, only a smarter one - and without the contextual understanding, smarter might not even turn out to be that much better...
Friday, January 11, 2008
vulnerability research vs. malware research
well, i said i was tempted to write a post on this topic, and even though it turns out i've written about it several times in the past (viruses and disclosure, malware and disclosure, full disclosure to name but a few) i'm going to try it again in hopes that after this one i won't ever have to repeat myself on this subject again (yeah, as if)...
as always, the most interesting debates wind up being about meaning, so lets define some terms for the sake of this discussion... a vulnerability is in essence a mistake that allows a component or service of a system to behave in an unexpected and unintended way that has a negative impact on the security of the system (i know not everyone ascribes to the mistake definition, but it's useful to draw a distinction between those vulnerabilities which can be fixed and those that can't - rest assured i will cover the alternative later)... vulnerability research, then, is the process of discovering these mistakes; sometimes by looking at source code, sometimes by reverse engineering the vulnerable system, sometimes even by accidentally or intentionally triggering the unintended behaviour... now there's a pretty broad consensus (with the exception of the bad guys) that vulnerabilities are bad so naturally we want to get rid of them, and because they're mistakes they can be fixed... however, because vulnerability research is often performed by people other than those who made the vulnerable system in the first place, it becomes necessary to find a way to demonstrate the existence of the vulnerability to others... further, those tasked with fixing the vulnerability require a reliable means of triggering the unintended behaviour in order to determine why that behaviour occurs and in order to ensure that whatever fix they put in place actually fixes the vulnerability... therefore we need an exploit to trigger the unintended behaviour so that the vulnerability can be demonstrated to others to convince them that a fix is needed, and also to test for the presence of the vulnerability when developing (or even applying) a fix...
of course with those uses in mind it's important to make the distinction that what we want in the way of exploits are actually benign exploits (as opposed to malicious/weaponized ones)... for example, when dealing with an arbitrary code execution vulnerability, an exploit that launches notepad is preferable to one that launches tftp with command line parameters to download something malicious from the internet and then subsequently launch that... you see exploits can be used for malicious purposes as well as the positive ones already described, and the less benign the exploit is the easier it is for a bad guy to do something bad with it...
now so far i've described exploits as things that are able to demonstrate the existence of a mistake that we want to fix... clearly when that mistake isn't present the exploit shouldn't work so we can say that the exploit depends on the existence of the mistake/vulnerability...
malware is a different beast entirely because it doesn't (in general) depend on the existence of a mistake or vulnerability... what does it depend on? well, from one of the seminal pieces of research on viruses we know that self-replicating malware depends on 3 things: the ability to share data (necessary for the attacker to get his malicious software from his own machine to the victim's machine), the ability to pass data that's been shared with you along to others (sharing transitivity - necessary for self-replicating malware to spread or pass itself along), and the ability to interpret data that's been shared with you as program code (ie. the ability to add to or change the set of things the computer is willing to execute - the generality of interpretation - necessary for the computer to be able to execute the new incoming malware)... none of these things can really be considered flaws or mistakes, in fact it's hard to imagine computers being as useful as they are without them... without sharing there would be no internet, no floppy/cd/dvd drives or printers (they would allow sharing over the sneakernet), no store-bought software (you'd have to make all the software, including the operating system, yourself), etc... not being able to pass anything along would be equally bizarre (though that's the world that hollywood envisions and tries to make real through the use of DRM), it would also make the division of labour very hard to manage because hierarchies would be impossible (your boss wouldn't be able to pass along to you anything his boss had given him, nor would he be able to pass along to his boss anything you had produced)... not being able to interpret data as program code would be the most profound change of all as it is this property that makes the general purpose computer a general purpose computer rather than a pocket calculator - it allows a single computer to be flexible enough to be used for many changing purposes and without that flexibility we'd need a different piece of hardware specially designed for each and every new task that came our way... it should be clear that these are things we neither can nor want to 'fix' and so self-replicating malware will always be possible... it turns out that all sharing transitivity does for self-replicating malware is allow it to spread, so we can therefore say that in general non-replicative malware doesn't need it (though that doesn't necessarily mean some specific instances won't use it, such as for the command and control of more sophisticated botnets)... there are no additional dependencies worth mentioning for non-replicative malware in general (the exception being exploits, which can be considered a type of malware and obviously depend on vulnerabilities) because the underlying functionality they use is the same functionality used by normal software, it's just that that functionality is used to perform actions we don't want performed... communicating with a remote site the way RATs, botnets, and spyware does is just sharing of messages, and we've already covered sharing... writing to the hard disk is pretty fundamental and can even be considered a kind of sharing between sessions or a prerequisite of media-based sharing... outputting to the screen (something adware necessarily has to do) is necessary in order for the user to properly interact with the computer (and really all input and output can be considered as falling under the umbrella of sharing)... since there are no dependencies in general that can be 'fixed', this case therefore covers the alternative of the vulnerability that isn't a mistake...
now a clever reader at this point would be asking him/herself how much sense it makes to perform the previously described type of vulnerability research on a vulnerability that can't be fixed... a knowledgeable reader would know the answer: it doesn't make sense to perform that sort of research... an argumentative reader might point out that such malware can exploit fixable vulnerabilities too, but the answer to that is to research the fixable vulnerability and look at the exploit for that on its own rather than connected to more general malware...
so how does that change the nature of research around malware? well for one thing the previously discussed benefits of creating benign exploits don't apply in malware research because they were all predicated on the idea that what allowed the thing to exist could be fixed... we know that's not generally true for malware and in the cases where it is true it's because the malware contains an exploit that can exist separate from the malware and be used that way instead of connected to the malware (which only serves to make the exploit less benign)... additionally, because malware in general depends on non-fixable properties of a system (not to mention they're less benign), the benefits that society reaps from sharing benign exploits with the public at large also don't apply to malware for essentially the same reason...
another, more intrinsic difference between the two research fields is that in vulnerability research we create a special kind of malware called exploits as indicators of the presence of the vulnerability but in malware research we do not create any kind of malware as an indicator of the presence of malware (that just wouldn't make sense)... creating malware in the course of doing malware research would actually be analogous to creating vulnerabilities in the course of doing vulnerability research... the reason we create indicators for vulnerabilities is that the vulnerabilities themselves are not exactly visible or shareable, they aren't distinct entities in and of themselves, whereas if i want to show you a piece of malware i give you the actual malware...
a third difference between the two research fields is that there is (according to popular informed opinion) a discrete, finite number of vulnerabilities while the number of possible malware is, theoretically, countably infinite - limited in practice only by the available storage space... so while it may make a certain kind of sense to enumerate vulnerabilities, making an exploit for each one so that the vulnerability can be mitigated (hopefully before it gets used by the bad guys), it's a very different idea to try and enumerate all possible malware in hopes of being able to mitigate all of them (because there's just too many of them and because there are so many, most will actually never actually be made by either the good guys or the bad guys)... furthermore, while it might seem feasible (or at least within the realm of hope) to stay ahead of the bad guys with regards to vulnerabilities, no matter how many pieces of malware we preemptively make in order to mitigate them the chances that we will block a bad guy by beating him to the creation of a particular piece of malware is essentially zero... the malware we might make is practically guaranteed to be different from the malware the bad guys will make...
by now you should be starting to see how different malware research is from vulnerability research and how pointless creating malware for the purposes of malware research is compared to creating benign exploits for the purposes of vulnerability research... instead, malware research focuses on malware that has already been made and classes of malware that already exist... rather than creating malware and hoping in vain that the bad guys malware will have the same properties, malware researchers share data with each other about new malware trends while they're still in their early stages and make educated guesses about what the next step will be... sometimes their predictions are right (such as storm botnet nodes being used in phishing, which was predicted when it was observed that the botnet was becoming segmented) and sometimes they aren't (or at least aren't yet, like some of the more ambitious predictions about mobile malware)... as such, malware researchers also look at the human attackers creating/using the malware - trying to guess their motivations, gaging their skill level, determining their connections with others, etc, because all those things are important in predicting what they might do next... enumerating possible future malware is not nearly as useful or accurate as a predictive tool in malware research as it's counterpart is in vulnerability research...
given these profound differences, it really makes very little sense to treat malware research the same as vulnerability research or malware in general the same as a benign exploit...
as always, the most interesting debates wind up being about meaning, so lets define some terms for the sake of this discussion... a vulnerability is in essence a mistake that allows a component or service of a system to behave in an unexpected and unintended way that has a negative impact on the security of the system (i know not everyone ascribes to the mistake definition, but it's useful to draw a distinction between those vulnerabilities which can be fixed and those that can't - rest assured i will cover the alternative later)... vulnerability research, then, is the process of discovering these mistakes; sometimes by looking at source code, sometimes by reverse engineering the vulnerable system, sometimes even by accidentally or intentionally triggering the unintended behaviour... now there's a pretty broad consensus (with the exception of the bad guys) that vulnerabilities are bad so naturally we want to get rid of them, and because they're mistakes they can be fixed... however, because vulnerability research is often performed by people other than those who made the vulnerable system in the first place, it becomes necessary to find a way to demonstrate the existence of the vulnerability to others... further, those tasked with fixing the vulnerability require a reliable means of triggering the unintended behaviour in order to determine why that behaviour occurs and in order to ensure that whatever fix they put in place actually fixes the vulnerability... therefore we need an exploit to trigger the unintended behaviour so that the vulnerability can be demonstrated to others to convince them that a fix is needed, and also to test for the presence of the vulnerability when developing (or even applying) a fix...
of course with those uses in mind it's important to make the distinction that what we want in the way of exploits are actually benign exploits (as opposed to malicious/weaponized ones)... for example, when dealing with an arbitrary code execution vulnerability, an exploit that launches notepad is preferable to one that launches tftp with command line parameters to download something malicious from the internet and then subsequently launch that... you see exploits can be used for malicious purposes as well as the positive ones already described, and the less benign the exploit is the easier it is for a bad guy to do something bad with it...
now so far i've described exploits as things that are able to demonstrate the existence of a mistake that we want to fix... clearly when that mistake isn't present the exploit shouldn't work so we can say that the exploit depends on the existence of the mistake/vulnerability...
malware is a different beast entirely because it doesn't (in general) depend on the existence of a mistake or vulnerability... what does it depend on? well, from one of the seminal pieces of research on viruses we know that self-replicating malware depends on 3 things: the ability to share data (necessary for the attacker to get his malicious software from his own machine to the victim's machine), the ability to pass data that's been shared with you along to others (sharing transitivity - necessary for self-replicating malware to spread or pass itself along), and the ability to interpret data that's been shared with you as program code (ie. the ability to add to or change the set of things the computer is willing to execute - the generality of interpretation - necessary for the computer to be able to execute the new incoming malware)... none of these things can really be considered flaws or mistakes, in fact it's hard to imagine computers being as useful as they are without them... without sharing there would be no internet, no floppy/cd/dvd drives or printers (they would allow sharing over the sneakernet), no store-bought software (you'd have to make all the software, including the operating system, yourself), etc... not being able to pass anything along would be equally bizarre (though that's the world that hollywood envisions and tries to make real through the use of DRM), it would also make the division of labour very hard to manage because hierarchies would be impossible (your boss wouldn't be able to pass along to you anything his boss had given him, nor would he be able to pass along to his boss anything you had produced)... not being able to interpret data as program code would be the most profound change of all as it is this property that makes the general purpose computer a general purpose computer rather than a pocket calculator - it allows a single computer to be flexible enough to be used for many changing purposes and without that flexibility we'd need a different piece of hardware specially designed for each and every new task that came our way... it should be clear that these are things we neither can nor want to 'fix' and so self-replicating malware will always be possible... it turns out that all sharing transitivity does for self-replicating malware is allow it to spread, so we can therefore say that in general non-replicative malware doesn't need it (though that doesn't necessarily mean some specific instances won't use it, such as for the command and control of more sophisticated botnets)... there are no additional dependencies worth mentioning for non-replicative malware in general (the exception being exploits, which can be considered a type of malware and obviously depend on vulnerabilities) because the underlying functionality they use is the same functionality used by normal software, it's just that that functionality is used to perform actions we don't want performed... communicating with a remote site the way RATs, botnets, and spyware does is just sharing of messages, and we've already covered sharing... writing to the hard disk is pretty fundamental and can even be considered a kind of sharing between sessions or a prerequisite of media-based sharing... outputting to the screen (something adware necessarily has to do) is necessary in order for the user to properly interact with the computer (and really all input and output can be considered as falling under the umbrella of sharing)... since there are no dependencies in general that can be 'fixed', this case therefore covers the alternative of the vulnerability that isn't a mistake...
now a clever reader at this point would be asking him/herself how much sense it makes to perform the previously described type of vulnerability research on a vulnerability that can't be fixed... a knowledgeable reader would know the answer: it doesn't make sense to perform that sort of research... an argumentative reader might point out that such malware can exploit fixable vulnerabilities too, but the answer to that is to research the fixable vulnerability and look at the exploit for that on its own rather than connected to more general malware...
so how does that change the nature of research around malware? well for one thing the previously discussed benefits of creating benign exploits don't apply in malware research because they were all predicated on the idea that what allowed the thing to exist could be fixed... we know that's not generally true for malware and in the cases where it is true it's because the malware contains an exploit that can exist separate from the malware and be used that way instead of connected to the malware (which only serves to make the exploit less benign)... additionally, because malware in general depends on non-fixable properties of a system (not to mention they're less benign), the benefits that society reaps from sharing benign exploits with the public at large also don't apply to malware for essentially the same reason...
another, more intrinsic difference between the two research fields is that in vulnerability research we create a special kind of malware called exploits as indicators of the presence of the vulnerability but in malware research we do not create any kind of malware as an indicator of the presence of malware (that just wouldn't make sense)... creating malware in the course of doing malware research would actually be analogous to creating vulnerabilities in the course of doing vulnerability research... the reason we create indicators for vulnerabilities is that the vulnerabilities themselves are not exactly visible or shareable, they aren't distinct entities in and of themselves, whereas if i want to show you a piece of malware i give you the actual malware...
a third difference between the two research fields is that there is (according to popular informed opinion) a discrete, finite number of vulnerabilities while the number of possible malware is, theoretically, countably infinite - limited in practice only by the available storage space... so while it may make a certain kind of sense to enumerate vulnerabilities, making an exploit for each one so that the vulnerability can be mitigated (hopefully before it gets used by the bad guys), it's a very different idea to try and enumerate all possible malware in hopes of being able to mitigate all of them (because there's just too many of them and because there are so many, most will actually never actually be made by either the good guys or the bad guys)... furthermore, while it might seem feasible (or at least within the realm of hope) to stay ahead of the bad guys with regards to vulnerabilities, no matter how many pieces of malware we preemptively make in order to mitigate them the chances that we will block a bad guy by beating him to the creation of a particular piece of malware is essentially zero... the malware we might make is practically guaranteed to be different from the malware the bad guys will make...
by now you should be starting to see how different malware research is from vulnerability research and how pointless creating malware for the purposes of malware research is compared to creating benign exploits for the purposes of vulnerability research... instead, malware research focuses on malware that has already been made and classes of malware that already exist... rather than creating malware and hoping in vain that the bad guys malware will have the same properties, malware researchers share data with each other about new malware trends while they're still in their early stages and make educated guesses about what the next step will be... sometimes their predictions are right (such as storm botnet nodes being used in phishing, which was predicted when it was observed that the botnet was becoming segmented) and sometimes they aren't (or at least aren't yet, like some of the more ambitious predictions about mobile malware)... as such, malware researchers also look at the human attackers creating/using the malware - trying to guess their motivations, gaging their skill level, determining their connections with others, etc, because all those things are important in predicting what they might do next... enumerating possible future malware is not nearly as useful or accurate as a predictive tool in malware research as it's counterpart is in vulnerability research...
given these profound differences, it really makes very little sense to treat malware research the same as vulnerability research or malware in general the same as a benign exploit...
Wednesday, January 09, 2008
follow-up on the ethical conflict in the webappsec domain
well, it's been several days now and there have been a number of reactions (such as the comment thread for the article i originally linked to or christofer hoff's reaction to my previous post on the subject)...
i wanted to post a follow-up to address robert hansen's reaction to my post and i was actually planning on posting it sooner but now i'm glad i didn't because i get to throw in material from mike rothman as well...
i'm going to start with mike, actually, since i can at least link to what he wrote (though past experience trying to comment on his blog has been less than stellar - ie. the comments seem to get lost)... mike posted his reaction in today's daily incite and although he thinks he knows what my argument is about he actually gets it rather spectacularly wrong...
creating threats, increasing the total number of threats out there is not something white hats are supposed to be doing... that contributes to the problem, not the solution...
popularizing the threat means that the bad guys' adoption of this class of threat agent will speed up, in other words the arrival of xss worms and other web-based malware (which are probably an inevitability given our current trend towards web-based computing) happen sooner...
both of which ultimately benefit mr. hansen...
moving right along to robert hansen's reaction (which, for previously described reasons, i'm not comfortable linking to so the quotes will just have to be good enough):
and of course there were numerous comments in support of mr. hansen's actions... from christofer hoff:
from digi7al64:
malware materials belong in the hands of the public about as much as infectious biological disease samples do...
from someone calling themselves spyware:
the ability to support malware such as worms and viruses an inherent property (rather than a flaw that can be corrected) of any system where sharing is allowed, where that sharing is transitive (what i share with you, you can share with others), and where data can be interpreted as program code... nothing in the particular implementations or even in larger patterns one sees in groups of implementations of xss worms is ultimately going to be able to stop xss worms once and for all - only stopping xss itself or all active content stops those things which allow xss worms to be...
from the very briefly named xs:
and from robert (presumably a different robert than mr. hansen who prefers to go by the pseudonym rsnake):
for example, you would not benefit if your personal details (full name, mailing address, telephone number, financial information, etc) became less obscure...
and that's where things stood the last time i checked... nobody (and i mean nobody) seems to get the argument about the contest leading to the threat class entering the mainstream sooner... mr. hansen came closest when he disingenuously tried to refute the argument that he stood to gain from the problem becoming worse... but the real head scratcher, the thing that i've found most frustrating of all is how people like to apply vulnerability research logic to malware research issues... i'm actually tempted to write a new post specifically about just that...
i wanted to post a follow-up to address robert hansen's reaction to my post and i was actually planning on posting it sooner but now i'm glad i didn't because i get to throw in material from mike rothman as well...
i'm going to start with mike, actually, since i can at least link to what he wrote (though past experience trying to comment on his blog has been less than stellar - ie. the comments seem to get lost)... mike posted his reaction in today's daily incite and although he thinks he knows what my argument is about he actually gets it rather spectacularly wrong...
Kurt thinks that this is going to uncover an attack that wouldn't have been discovered otherwise and that's a bad thing.no, i think that the contest is going to a) create new threat agents (ie. worms - that is the point of the contest after all) and b) popularize this class of threat...
creating threats, increasing the total number of threats out there is not something white hats are supposed to be doing... that contributes to the problem, not the solution...
popularizing the threat means that the bad guys' adoption of this class of threat agent will speed up, in other words the arrival of xss worms and other web-based malware (which are probably an inevitability given our current trend towards web-based computing) happen sooner...
both of which ultimately benefit mr. hansen...
That we shouldn't trust these researchers because they think like hackers.no, we shouldn't trust them because they act like bad guys... creating malware and/or requesting the creation of malware is fundamentally not a white hat activity because it contributes to the malware problem (the way dropping litter on a littered street contributes to the litter problem)...
My point is that in all likelihood they are working on smaller footprint and more innovative XSS attacks and they are going to figure stuff out.indeed they may well do so, but they sure as hell shouldn't receive help from us in order to get there...
So we need to engage in similar tactics to understand the attack surface and protect our stuff.similar tactics? defense is not the same as attack, they don't use the same tactics - and even if it were appropriate to use tactics similar to the bad guys (and there's a serious question of how we differentiate ourselves from the bad guys if we do), the bad guys are NOT doing their research in the public sphere... they at least have the good sense to use darknet channels to avoid helping us... that is the tactic we should be copying...
How will we defend ourselves if we aren't doing similar research?by analyzing threats rather than creating new ones... there is no real reason to expect the malware we write and the malware they write will be similar enough for defenses against our own malware to automatically work against theirs as well...
Kurt's entire argument is based on the assumption that the bad guys aren't going to figure the stuff out anyway.and once again, spectacularly wrong... my argument is based on the principle of not being part of the problem... it doesn't matter if they figure this stuff out on their own or not, we shouldn't be helping them...
But playing the ostrich game and hoping the problem goes away doesn't work very well.playing dumb and ignoring the unintended consequences of your own actions doesn't work very well either...
moving right along to robert hansen's reaction (which, for previously described reasons, i'm not comfortable linking to so the quotes will just have to be good enough):
Clearly, and admittedly most of these people have no background in the issue and have never read this siteand then there's me who both has a familiarity with worms and reads the site...
as there is lots of samples of existing worm code in lots of places on the Internet now. Just because they don’t know about it doesn’t mean it’s not there.and just because it's out there doesn't mean you should add to it...
I’ve always said, you don’t understand a problem until you see it and play with it.playing with malware and creating new malware are not on the same level...
If working to help the understanding of worm propagation makes me evil, so be it.understanding may be the ends but those ends don't justify the means... not everything done under the banner of a laudable goal is alright...
I’d rather be evil and be able to help solve problems than be good and be useless at solving the problemthough i've never personally referred to mr. hansen as evil, his current path will make the problem worse, not better, and it most certainly won't solve the problem... worms are not a solvable problem...
Will this empower bad guys? I’d be nieve to say there’s no chance of that.in truth some of the bad guys will gain at least as much knowledge from this experiment as the good guys will... further, the knowledge this produces will be directly usable by them, not us... the contest is advancing the art of xss worm creation (creating new threat agents is the job of the attacker, not the defender), with the intention that the results will be usable in a second stage of research into xss worm mitigation...
For people who liken me to an anti-virus company writing viruses,i think the closest anyone came to making that comparison was me, but what i actually compared mr. hansen to to was an anti-virus vendor motivating others to create malware that would ultimately benefit that vendor... and i made that comparison because, with the exception that mr. hansen isn't an anti-virus vendor, that's exactly what's going on...
I’d like to point out the fact of the matter which is that I don’t get paid to consult with browser companies on browser securityfine, the browser companies don't pay him, but the companies hoping to avoid getting hit by xss worms (among other things) do... the more popular that threat becomes, the greater the chance such companies will get hit and therefore the greater the demand for his services...
To date I also have never been paid by any company who has ever been hit by an XSS worm.yeah "to date"... that's because the number is still relatively low... but as i said, he does get paid by companies hoping to avoid that fate...
Also, unlike an anti-virus company, I don’t have a security product in development.instead he has services and a brand and who knows what he'll be able to leverage that into in the future... jamie butler wasn't part of an anti-stealthkit company when he was writing and popularizing stealthkits - it wasn't until later that he became the CTO of a government funded anti-stealthkit startup aiming to solve the problem he helped create...
Think the bad guys are going to stop their own research if we stop talking about it?no, i just think they won't get a helping hand anymore... or has the idea of not being part of the problem gone out of fashion?
But through it all, I’m 100% confident that this will lead to previously non-published/understood results about worm propagationand i'm 100% confident that he will hasten the onset of the web-based malware problem by popularizing it as he does...
Time to start working on solutions, rather than trying to keep the research quiet.said as if those two things were mutually exclusive... they aren't...
and of course there were numerous comments in support of mr. hansen's actions... from christofer hoff:
I found it rather interesting that Kurt took the tact that he did. I think his point regarding the potential for misuse of code generated as a result of the contest is plausible but unlikely.it was also the lesser of the two issues i was bringing up... however, since the bad guys have shown that they are in fact willing to use proof of concept code written by the good guys (see: bootroot) it's still something one should take seriously...
Honestly, PoC code for any sort of exploitable vulnerability has the potential for misuse, so I’m not convinced this is a corner case that deserves the flambe treatment it’s getting.apparently i'm going to have to get used to saying 'except these are worms, not just exploits' (because i already said it a couple times on hoff's own blog)...
However, I found it a bit of a reach to accuse you of ethical violations and seeding the world with Malware so you could profit from the results as part of a giant conspiracy theory.i didn't say he was seeding the world with malware, i said he was increasing the xss worm's mindshare... this contest does increase the raw number of xss worms, but it's worst impact is that it captures the imagination of more bad guys and makes them more apt to jump into this problem space sooner...
It’s clear that many of those posting their opinions fail to recognize which side of the fence you sit and the contributions toward making the world “better” you have made.the side of the fence on which he intends to sit and the one he winds up on are not necessarily the same thing... the road to hell is said to be paved with good intentions after all... whatever contributions he may have made, they have to be taken in context of how they were made...
from digi7al64:
Also in response to this from Dr. Vesselin Bontchev who stated “Respectable security researchers don’t encourage the creation of malware by running contests for it!”. Sir, I don’t believe that a single entity of peers should be solely those with the knowledge to determine who and when the general public should be “allowed” this type of information.and the reason s/he (sorry, but the pseudonym does not convey a definite gender) believes that is because s/he is either naive, believes malware research is the same as vulnerability research, or is ignorant of malware research/creation history...
malware materials belong in the hands of the public about as much as infectious biological disease samples do...
from someone calling themselves spyware:
Hiding the problem instead of stopping it? What are we, scared? Afraid for the consequences? Act NOW and you are safe.this person is obviously someone who believes xss worms can be stopped once and for all (thereby making one 'safe')... that's not going to happen unless xss itself can be wiped out (which doesn't require worm research much less worm creation) or unless the entire web regresses to purely static content...
the ability to support malware such as worms and viruses an inherent property (rather than a flaw that can be corrected) of any system where sharing is allowed, where that sharing is transitive (what i share with you, you can share with others), and where data can be interpreted as program code... nothing in the particular implementations or even in larger patterns one sees in groups of implementations of xss worms is ultimately going to be able to stop xss worms once and for all - only stopping xss itself or all active content stops those things which allow xss worms to be...
from the very briefly named xs:
Education should never be considered unethical.education at the expense of others may well be unethical depending on the nature of that expense...
and from robert (presumably a different robert than mr. hansen who prefers to go by the pseudonym rsnake):
Security Through Obscurity has never been a good approach,relying on obscurity for your security is not a good approach, but there are plenty of things for which removing obscurity does not help you...
for example, you would not benefit if your personal details (full name, mailing address, telephone number, financial information, etc) became less obscure...
and that's where things stood the last time i checked... nobody (and i mean nobody) seems to get the argument about the contest leading to the threat class entering the mainstream sooner... mr. hansen came closest when he disingenuously tried to refute the argument that he stood to gain from the problem becoming worse... but the real head scratcher, the thing that i've found most frustrating of all is how people like to apply vulnerability research logic to malware research issues... i'm actually tempted to write a new post specifically about just that...
Saturday, January 05, 2008
eEye and malware creation ethics
wow, i just got done throwing out a mention to the new MBR stealthkit and now i find out it's pedigree...
folks, it's time you go over your malware researchers with a fine-tooth comb because i don't think anybody in the industry really wants to be responsible for another proof of concept getting into the wild...
that is, unless you're eEye digital security, apparently... not only was it their researchers derek soeder and ryan permeh that created bootroot and presented it at blackhat in 2005, but even as i type eEye is hosting that malware on their website right now...
this is absolutely NOT responsible behaviour and the people who were and are responsible for both the stealthkit and the company should be ashamed of themselves for being part of the problem instead of part of the solution... anti-malware researchers and companies should not be creating and distributing malware - this is so fundamentally wrong i'm actually tongue-tied trying to describe how wrong it is... needless to say i won't be touching anything of theirs with a 10 foot barge pole and others might want to consider the same...
*update* - tyler reguly caught or otherwise helped me see a factual error i made... the stealthkit in the wild is not the exact one developed and distributed by eEye but rather is a modified version of it... that doesn't really change much, however, because they still armed the bad guys...
folks, it's time you go over your malware researchers with a fine-tooth comb because i don't think anybody in the industry really wants to be responsible for another proof of concept getting into the wild...
that is, unless you're eEye digital security, apparently... not only was it their researchers derek soeder and ryan permeh that created bootroot and presented it at blackhat in 2005, but even as i type eEye is hosting that malware on their website right now...
this is absolutely NOT responsible behaviour and the people who were and are responsible for both the stealthkit and the company should be ashamed of themselves for being part of the problem instead of part of the solution... anti-malware researchers and companies should not be creating and distributing malware - this is so fundamentally wrong i'm actually tongue-tied trying to describe how wrong it is... needless to say i won't be touching anything of theirs with a 10 foot barge pole and others might want to consider the same...
*update* - tyler reguly caught or otherwise helped me see a factual error i made... the stealthkit in the wild is not the exact one developed and distributed by eEye but rather is a modified version of it... that doesn't really change much, however, because they still armed the bad guys...
everything old is new again
well, it seems like the past is coming back into style again...
there's behavioural detection in anti-virus suites, there's boot sector malware (even though it never really went away, it just died down to background noise levels) in the form of a new MBR stealthkit (anyone want to hazard a guess what this will mean for the wipe and re-install folks? 'cause format doesn't touch the MBR and fdisk isn't necessarily as straightforward as an average user would like), and now there's home made anti-virus signatures?
yup, jose nazario posts to show how to create clam anti-virus signatures for the latest storm trojan emails...
y'know, i remember when more mainstream anti-virus products had virus description languages that were simple enough that arbitrary people could create their own signatures... however, that was back in the early '90s when they were still growing out of being simple string scanners - when handling polymorphism simply meant using wildcard characters in the scan string (the precursor of today's virus signature, composed of a sequence of bytes often in hexadecimal form)...
i can honestly say i was surprised to find out that such an ancient technique could still be used with clamav; and if you think i'm being too critical of clam, look closely at the instructions in the article - those appear to be quite literally scan strings (and apparently no wildcards) in ascii form...
there's behavioural detection in anti-virus suites, there's boot sector malware (even though it never really went away, it just died down to background noise levels) in the form of a new MBR stealthkit (anyone want to hazard a guess what this will mean for the wipe and re-install folks? 'cause format doesn't touch the MBR and fdisk isn't necessarily as straightforward as an average user would like), and now there's home made anti-virus signatures?
yup, jose nazario posts to show how to create clam anti-virus signatures for the latest storm trojan emails...
y'know, i remember when more mainstream anti-virus products had virus description languages that were simple enough that arbitrary people could create their own signatures... however, that was back in the early '90s when they were still growing out of being simple string scanners - when handling polymorphism simply meant using wildcard characters in the scan string (the precursor of today's virus signature, composed of a sequence of bytes often in hexadecimal form)...
i can honestly say i was surprised to find out that such an ancient technique could still be used with clamav; and if you think i'm being too critical of clam, look closely at the instructions in the article - those appear to be quite literally scan strings (and apparently no wildcards) in ascii form...
no more non-distribution for virustotal
the hispasec folks announced thursday that they would be getting rid of the virustotal feature that allowed people to scan samples without submitting those samples to anti-malware companies when appropriate...
i think that's great news, because it makes it that much harder for the bad guys to use the feature maliciously... now the hispasec folks may want to believe that wasn't really an issue but lets face it, if there are still script kiddies asking for malware on usenet (and it does happen from time to time) then it stands to reason that some malware writers would misuse virustotal to test their malware... they're people, not perfectly rational automatons, they do things that don't always make sense to us - sometimes because what they know and what we know doesn't always completely overlap, sometimes just because they're cheap and lazy (and aren't we all to some extent?)...
the article also points out that there's a technical reason why using virustotal to test malware with isn't useful for the malware writers - the results don't tell the whole story with regards to the detectability of the malware sample by the various anti-malware products used because virustotal only uses the scanner portion of those products... now, while non-scanner based anti-malware components in anti-malware suites are nothing new, they did fall out of favour for quite a while... thankfully, as the hispasec folks point out, they're coming back and that renders virustotal results meaningless to a malware writer... what they don't point out, however, is that it also renders virustotal results meaningless for thecomplete tools anti-virus critics who use virustotal results against new malware as proof that anti-malware companies aren't able to stay ahead of the threat...
there are 2 things in the article that baffle me though... first is how anyone could think they're protecting confidential documents by using the non-distribute feature (hello, you're submitting the file to a 3rd party, confidentiality is lost at that moment, not when that 3rd party shares copies with other 3rd parties)... the second is why legitimate anti-malware vendors would need to use virustotal with the non-distribute feature when the bad guys have shown us it's easy enough to setup your own multi-product scanning system...
but all in all i always think it's good when we find ways to be less helpful to the bad guys...
i think that's great news, because it makes it that much harder for the bad guys to use the feature maliciously... now the hispasec folks may want to believe that wasn't really an issue but lets face it, if there are still script kiddies asking for malware on usenet (and it does happen from time to time) then it stands to reason that some malware writers would misuse virustotal to test their malware... they're people, not perfectly rational automatons, they do things that don't always make sense to us - sometimes because what they know and what we know doesn't always completely overlap, sometimes just because they're cheap and lazy (and aren't we all to some extent?)...
the article also points out that there's a technical reason why using virustotal to test malware with isn't useful for the malware writers - the results don't tell the whole story with regards to the detectability of the malware sample by the various anti-malware products used because virustotal only uses the scanner portion of those products... now, while non-scanner based anti-malware components in anti-malware suites are nothing new, they did fall out of favour for quite a while... thankfully, as the hispasec folks point out, they're coming back and that renders virustotal results meaningless to a malware writer... what they don't point out, however, is that it also renders virustotal results meaningless for the
there are 2 things in the article that baffle me though... first is how anyone could think they're protecting confidential documents by using the non-distribute feature (hello, you're submitting the file to a 3rd party, confidentiality is lost at that moment, not when that 3rd party shares copies with other 3rd parties)... the second is why legitimate anti-malware vendors would need to use virustotal with the non-distribute feature when the bad guys have shown us it's easy enough to setup your own multi-product scanning system...
but all in all i always think it's good when we find ways to be less helpful to the bad guys...
ethical conflict in the webappsec domain
anyone remember back in 2005 when the folks at dvforge decided to give malware authors an incentive to create mac os x malware? well don't look now but something very similar has just happened with regards to xss worms...
yes, folks... robert hansen (aka rsnake), the founder and ceo of sectheory, felt it would be a good idea to hold a contest to see who could create the smallest xss worm... ok, so there's no money changing hands this time, but that doesn't mean the winner isn't getting rewarded - there are absolutely rewards to be had for the winner of a contest like this and that's a big problem because lots of people want rewards and this kind of contest will make people think about and create xss worms when they wouldn't have before...
would you trust your security to a person who makes or made malware? how about a person or company that intentionally motivates others to do so? why do you suppose the anti-virus industry works so hard to fight the conspiracy theories that suggest they are the cause of the viruses? at the very least mr. hansen is playing fast and loose with the publics trust and ultimately harming security in the process, but there's a more insidious angle too...
while the worms he's soliciting from others are supposed to be merely proof of concept, the fact of the matter is that proof of concept worms can still cause problems (the recent orkut worm was a proof of concept)... moreover, although the winner of the contest doesn't get any money, at the end of the day there will almost certainly be a windfall for mr. hansen - after all, what do you suppose happens when you're one of the few experts on some relatively obscure type of threat and that threat is artificially made more popular? well, demand for your services goes up of course... this is precisely the type of shady marketing model i described before where the people who stand to gain the most out of a problem becoming worse directly contribute to that problem becoming worse... it made greg hoglund and jamie butler household names in security circles, and it made john mcafee (pariah though he may be) a millionaire...
and just in case you bought into that argument that the idea was to distill the samples down to the pure essence of what a xss worm is without all that obfuscation muddying the waters, consider this: in every past instance of extreme code size optimization (which is a forgone conclusion in a contest to find the smallest anything) the final outcome has actually been made more obscure by virtue of the hacks and tricks used to squeeze out as many unnecessary bytes as possible...
how is it that the security industry has arrived at a state where the people in it promote the threats they're supposed to be helping protect against? how does making problems worse serve the greater good?
*update* - there's now a follow-up to this article here
yes, folks... robert hansen (aka rsnake), the founder and ceo of sectheory, felt it would be a good idea to hold a contest to see who could create the smallest xss worm... ok, so there's no money changing hands this time, but that doesn't mean the winner isn't getting rewarded - there are absolutely rewards to be had for the winner of a contest like this and that's a big problem because lots of people want rewards and this kind of contest will make people think about and create xss worms when they wouldn't have before...
would you trust your security to a person who makes or made malware? how about a person or company that intentionally motivates others to do so? why do you suppose the anti-virus industry works so hard to fight the conspiracy theories that suggest they are the cause of the viruses? at the very least mr. hansen is playing fast and loose with the publics trust and ultimately harming security in the process, but there's a more insidious angle too...
while the worms he's soliciting from others are supposed to be merely proof of concept, the fact of the matter is that proof of concept worms can still cause problems (the recent orkut worm was a proof of concept)... moreover, although the winner of the contest doesn't get any money, at the end of the day there will almost certainly be a windfall for mr. hansen - after all, what do you suppose happens when you're one of the few experts on some relatively obscure type of threat and that threat is artificially made more popular? well, demand for your services goes up of course... this is precisely the type of shady marketing model i described before where the people who stand to gain the most out of a problem becoming worse directly contribute to that problem becoming worse... it made greg hoglund and jamie butler household names in security circles, and it made john mcafee (pariah though he may be) a millionaire...
and just in case you bought into that argument that the idea was to distill the samples down to the pure essence of what a xss worm is without all that obfuscation muddying the waters, consider this: in every past instance of extreme code size optimization (which is a forgone conclusion in a contest to find the smallest anything) the final outcome has actually been made more obscure by virtue of the hacks and tricks used to squeeze out as many unnecessary bytes as possible...
how is it that the security industry has arrived at a state where the people in it promote the threats they're supposed to be helping protect against? how does making problems worse serve the greater good?
*update* - there's now a follow-up to this article here
Subscribe to:
Posts (Atom)