if you haven't heard about flexispy (the first spyware trojan for symbian cell phones) then i'd suggest reading about it here and here...
i don't really think it's all that interesting that someone has finally made spyware for cellphones - what i think is amazing, however, is that a member of the commercial spyware industry (vervata) seems to actually not understand why their product (flexispy) is being called a spyware trojan by f-secure...
imagine, you make software that you yourself call a "spy application" and then don't understand why people call it spyware... hello!?!? it's software that spies on you, what do you think people are going to call it?... are these guys for real? well, either they really don't get it, or they think that there are enough other people who don't get it that it's worth it to bother making such a ridiculous argument...
but why is that? well, i think it serves as a stong indication that the anti-malware industry/community in general, and the anti-spyware industry/community in particular, have failed the public in an important way... they've failed to make the threats understandable to ordinary people... look at the anti-spyware coalition's glossary, is their definition of spyware as straight forward as 'software that spys on you'? no, in fact they have 2 separate and contradictory definitions, one of which makes spyware an umbrella term... i've already blogged about stopbadware.org's use of a colloquialism from wikipedia as their definition for spyware, and then there's sunbelt's listing criteria that i was recently made aware of and which is about as easy to read as an end user license agreement unless you already have some familiarity with the malware field...
how are people suppose to get this stuff with literature like that? if it were common knowledge that spyware is software that spies on you then vervata would have no reasonable way to claim ignorance, much less argue the fact... and if it were common knowledge that trojans were programs that do bad things that you thought they didn't do then vervata also should have known that their product (which fails to disclose it's true nature) can be made into a trojan simply by saying it's something good or by installing it on someone's phone and leading (or leaving) them to believe that everying on the phone is normal...
of course, i'm not all about pointing the finger at other people here... while writing this i've realized that even my own definitions could stand some improvement in this area... as much as i try to make the definitions themselves short and sweet (with explanations afterwards for those interested in more detail) they could still be simpler and retain their correctness at the same time... i think we need to compose our definitions like we were talking to 4 year olds, not because people are stupid but because most simply don't have enough of a foundation here to grasp our meaning when we write for other people people in the anti-malware field... i think if we really understand what we're talking about then that shouldn't be too difficult a task... so i guess i'll be tweaking some existing blog entries in the not too distant future..
Thursday, March 30, 2006
what is a cracker?
a cracker is a person who breaks/breaches the security of a system...
this is not confined to computer realm... terms like cracking the code and safe cracker illustrate that this term goes beyond just breaking into computer systems...
in the context of computers, the media has been doing it's best to replace this term with the more generic (and neutral) term hacker, probably to avoid using a word that also happens to be a racial slur (although they could have added a qualifier like the word safe in safe cracker)... as a result most people don't realize that when they say hacker they're really talking about a person such as this...
it could be argued, of course, that crackers are actually a specific type of hacker (one that solves a very particular type of computer related problem, and usually not for the benefit of the computer's owner) but most old-school hackers would find that characterization offensive...
back to index
this is not confined to computer realm... terms like cracking the code and safe cracker illustrate that this term goes beyond just breaking into computer systems...
in the context of computers, the media has been doing it's best to replace this term with the more generic (and neutral) term hacker, probably to avoid using a word that also happens to be a racial slur (although they could have added a qualifier like the word safe in safe cracker)... as a result most people don't realize that when they say hacker they're really talking about a person such as this...
it could be argued, of course, that crackers are actually a specific type of hacker (one that solves a very particular type of computer related problem, and usually not for the benefit of the computer's owner) but most old-school hackers would find that characterization offensive...
back to index
what is a hacker?
a hacker is a person who utilizes hacks in order to solve problems... usually when used without a qualifying modifier, the term hacker is used to indicate a computer hacker (someone who utilizes hacks to solve computer related problems)...
this is probably one of the first terms i saw the media twist into something new... over the past decade and a half (at least) the term hacker has taken on a more sinister connotation involving the breaking of security systems and intruding onto machines where they don't belong... i suspect at least one reason is that the actual term for this (cracker) happens to also be a racial slur and the media needed to pick an alternative word to describe the people who engaged in these sorts of activities and hacker (as a generic umbrella-like term) easily fit that bill...
the old timers still remember that hackers were really just computer enthusiasts who knew how to solve problems in clever ways, but unfortunately the public at large has been brainwashed by the media to adopt the new meaning...
the old meaning of hacker is making a comeback (at least outside of the computer hacker domain) with terms like life hacker - perhaps the proper usage of computer hacker will be restored one day...
back to index
this is probably one of the first terms i saw the media twist into something new... over the past decade and a half (at least) the term hacker has taken on a more sinister connotation involving the breaking of security systems and intruding onto machines where they don't belong... i suspect at least one reason is that the actual term for this (cracker) happens to also be a racial slur and the media needed to pick an alternative word to describe the people who engaged in these sorts of activities and hacker (as a generic umbrella-like term) easily fit that bill...
the old timers still remember that hackers were really just computer enthusiasts who knew how to solve problems in clever ways, but unfortunately the public at large has been brainwashed by the media to adopt the new meaning...
the old meaning of hacker is making a comeback (at least outside of the computer hacker domain) with terms like life hacker - perhaps the proper usage of computer hacker will be restored one day...
back to index
Wednesday, March 29, 2006
what is a hack?
a hack is a clever (and usually simple) solution to some problem... not necessarily a good solution, mind you, but often any solution will do...
for example: in programming, when encountering what appears to be a timing problem, an obvious hack is to introduce a wait() statement of some sort is often considered a code hack... this is actually an example of a bad solution as it ignores the the fact that the timing may behave entirely differently on a different system and the wait() statement could then cause a problem instead of solving it...
programming is one of the few places where hacks tend to be frowned on, but there are all kinds of other areas where hacks can be made, such as mind hacks, health hacks, life hacks, etc...
a computer hack, then, would be a clever solution to a computer (not necessarily programming related) problem... figuring out how to make the system boot faster, for example, or how to undelete files with a sector editor, or how to feed continuous serial I/O to a program with a batch file and a null modem cable could all be considered hacks...
back to index
for example: in programming, when encountering what appears to be a timing problem, an obvious hack is to introduce a wait() statement of some sort is often considered a code hack... this is actually an example of a bad solution as it ignores the the fact that the timing may behave entirely differently on a different system and the wait() statement could then cause a problem instead of solving it...
programming is one of the few places where hacks tend to be frowned on, but there are all kinds of other areas where hacks can be made, such as mind hacks, health hacks, life hacks, etc...
a computer hack, then, would be a clever solution to a computer (not necessarily programming related) problem... figuring out how to make the system boot faster, for example, or how to undelete files with a sector editor, or how to feed continuous serial I/O to a program with a batch file and a null modem cable could all be considered hacks...
back to index
the rise of whitelisting
application whitelisting, the practice of keeping a list of known good applications (a whitelist, as opposed to a blacklist) and only allowing those applications to run, is not a new idea... it's a good idea certainly, but not new... nick fitzgerald, for example, has been calling for the development and deployment of just this type of technology for years now... i myself utilize the application launch control functionality (a sort of whitelist) in kerio personal firewall (which is more interesting to me than the actual firewall part)...
today, however, there was a post on the nod32 news blog about whitelisting that i think underlines the need to delve into the strengths and weaknesses of the technology...
at the most fundamental level an application whitelist needs to know 2 things, what sorts of things are programs and which of them are known to be good...
determining what is a program and what isn't is not as simple as it sounds - in fact it's an intractable problem (unless someone solved the halting problem without telling me)... that's not to say we can't make that determination accurately most of the time... basically we're limited to detecting known program types - new types of script programs and that sort of thing are always going to exist and always going to be left out because they're too new... at any rate, this level of detection is always hard-coded into the whitelist system by the developers - there's no real way to add new program type detection on-the-fly on the end user's machine...
where things really get interesting is when we're trying to identify the known good programs... there are 2 main paradigms we can follow: either the 'goodness' is determined by the end user and is specific to his/her machine only, or the 'goodness' is determined by some central body somewhere that decides what's good for everyone... it's also possible to combine these two but let's look at them individually first...
in decentralized whitelist management (where the end user decides what's good) the list of known good things is relatively small and can be updated whenever the user needs to but there is a serious problem trying to enable end users to accurately determine the trustworthiness of new software... most people just don't have the expertise or inclination to perform the necessary research to find out if something should be allowed to run on their machine... frankly, if they were any good at making those kinds of decisions, email worms (and just about every other type of malware out there) would never have become as big a problem as it is today...
in centralized whitelist management (where a central body decides what's good) it's possible to have lots of expertise on hand to determine whether a specified program is good or not but the list of known good things needs to be huge in order to cover everything that everyone might use... one of the arguments against known virus scanning and in favour of whitelisting is that keeping track of all the known bad things (essentially a known virus scanner implements a blacklist) is that the number of known bad things is very large and ever-growing, but a centralized whitelist has this same problem in spades as determining if something is good is just as hard as determining if something is bad, there are far more good programs out there than there are bad ones, and the list grows even faster... in addition, the central organization will undoubtedly have finite resources with which to work so adding updated programs (a number of programs out there do tend to have regular security updates) to the global whitelist may not happen in as timely a fashion as we might like... finally, it puts the central organization in a position where they could exercise undue influence over which legitimate applications get to run on end users machines (presence on the whitelist would effectively be a certification and has many of the same undesirable properties that the system where a certifying authority digitally signs the known good programs so that people would know which ones they could trust)...
combining these two into a hierarchical whitelist management system (where the global whitelist serves to help the end user determine the trustworthiness of programs most of the time) would seem like it would give the best of both worlds but that's not necessarily the case... giving the end user the power to add a program to his/her local whitelist gives him/her the power to make the same mistakes s/he'd be making with a fully decentralized whitelist system - with the understanding that the global whitelist isn't always going to be completely up to date a piece of malware need only advertise itself as the latest security update of some widely deployed program (like part of the operating system, for example) in order to get the user to add it to the local whitelist... also, giving the end user the power to add programs to his/her local whitelist doesn't obviate the need to make the global whitelist as thorough and up-to-date as possible, nor does it make the task any easier or less time-consuming/resource-intensive... further, the absense of a program on the global whitelist could still communicate a lack of trustworthiness to the end users and bias them against a particular legitimate application...
even if you could solve all these problems, it's still possible to make good programs do bad things... and i'm not just talking about buffer overflows and other software exploits, the whitelist can't know that you want Format.com to run sometimes but not others... it can't know that Regedit.com should import the *.reg file with your personal configuration preferences in it but the *.reg file that disables the whitelist on the next reboot and causes the download and execution of some piece of malware... it can't know that your SQL server should run the query that selects all your customer table but not the one that self-replicates all through that same table... it also does nothing to stop malware that exists only in memory, nor malware that executes outside the scope of the operating system (like bootsector malware)
all that said, it should be fairly obvious that if you only let known good programs execute, then the bad programs (known and unknown alike) generally won't be able to run on your system... with a whitelist in place monitoring the attempted launching of applications you'll also get alerted when something you don't know about tries to run... finally, with a relatively small and static set of applications allowed to run, the security of the system is more easily analyzed and modelled...
application whitelisting, like integrity checking/change detection before it, may offer a technically superior security technology in theory, but in practice it is not a panacea... it's not a magical cure-all and it really doesn't eliminate the need for conventional anti-virus/anti-malware scanning... like all anti-malware technology, it is best when used in conjunction with complementary technologies and techniques...
today, however, there was a post on the nod32 news blog about whitelisting that i think underlines the need to delve into the strengths and weaknesses of the technology...
at the most fundamental level an application whitelist needs to know 2 things, what sorts of things are programs and which of them are known to be good...
determining what is a program and what isn't is not as simple as it sounds - in fact it's an intractable problem (unless someone solved the halting problem without telling me)... that's not to say we can't make that determination accurately most of the time... basically we're limited to detecting known program types - new types of script programs and that sort of thing are always going to exist and always going to be left out because they're too new... at any rate, this level of detection is always hard-coded into the whitelist system by the developers - there's no real way to add new program type detection on-the-fly on the end user's machine...
where things really get interesting is when we're trying to identify the known good programs... there are 2 main paradigms we can follow: either the 'goodness' is determined by the end user and is specific to his/her machine only, or the 'goodness' is determined by some central body somewhere that decides what's good for everyone... it's also possible to combine these two but let's look at them individually first...
in decentralized whitelist management (where the end user decides what's good) the list of known good things is relatively small and can be updated whenever the user needs to but there is a serious problem trying to enable end users to accurately determine the trustworthiness of new software... most people just don't have the expertise or inclination to perform the necessary research to find out if something should be allowed to run on their machine... frankly, if they were any good at making those kinds of decisions, email worms (and just about every other type of malware out there) would never have become as big a problem as it is today...
in centralized whitelist management (where a central body decides what's good) it's possible to have lots of expertise on hand to determine whether a specified program is good or not but the list of known good things needs to be huge in order to cover everything that everyone might use... one of the arguments against known virus scanning and in favour of whitelisting is that keeping track of all the known bad things (essentially a known virus scanner implements a blacklist) is that the number of known bad things is very large and ever-growing, but a centralized whitelist has this same problem in spades as determining if something is good is just as hard as determining if something is bad, there are far more good programs out there than there are bad ones, and the list grows even faster... in addition, the central organization will undoubtedly have finite resources with which to work so adding updated programs (a number of programs out there do tend to have regular security updates) to the global whitelist may not happen in as timely a fashion as we might like... finally, it puts the central organization in a position where they could exercise undue influence over which legitimate applications get to run on end users machines (presence on the whitelist would effectively be a certification and has many of the same undesirable properties that the system where a certifying authority digitally signs the known good programs so that people would know which ones they could trust)...
combining these two into a hierarchical whitelist management system (where the global whitelist serves to help the end user determine the trustworthiness of programs most of the time) would seem like it would give the best of both worlds but that's not necessarily the case... giving the end user the power to add a program to his/her local whitelist gives him/her the power to make the same mistakes s/he'd be making with a fully decentralized whitelist system - with the understanding that the global whitelist isn't always going to be completely up to date a piece of malware need only advertise itself as the latest security update of some widely deployed program (like part of the operating system, for example) in order to get the user to add it to the local whitelist... also, giving the end user the power to add programs to his/her local whitelist doesn't obviate the need to make the global whitelist as thorough and up-to-date as possible, nor does it make the task any easier or less time-consuming/resource-intensive... further, the absense of a program on the global whitelist could still communicate a lack of trustworthiness to the end users and bias them against a particular legitimate application...
even if you could solve all these problems, it's still possible to make good programs do bad things... and i'm not just talking about buffer overflows and other software exploits, the whitelist can't know that you want Format.com to run sometimes but not others... it can't know that Regedit.com should import the *.reg file with your personal configuration preferences in it but the *.reg file that disables the whitelist on the next reboot and causes the download and execution of some piece of malware... it can't know that your SQL server should run the query that selects all your customer table but not the one that self-replicates all through that same table... it also does nothing to stop malware that exists only in memory, nor malware that executes outside the scope of the operating system (like bootsector malware)
all that said, it should be fairly obvious that if you only let known good programs execute, then the bad programs (known and unknown alike) generally won't be able to run on your system... with a whitelist in place monitoring the attempted launching of applications you'll also get alerted when something you don't know about tries to run... finally, with a relatively small and static set of applications allowed to run, the security of the system is more easily analyzed and modelled...
application whitelisting, like integrity checking/change detection before it, may offer a technically superior security technology in theory, but in practice it is not a panacea... it's not a magical cure-all and it really doesn't eliminate the need for conventional anti-virus/anti-malware scanning... like all anti-malware technology, it is best when used in conjunction with complementary technologies and techniques...
Monday, March 27, 2006
anti-virus companies don't hire virus writers
this is an urban myth/conspiracy theory that pops up again and again... some people are convinced that the anti-virus industry hires virus writers, either to put their 'virus writing expertise' to good use stopping viruses, or to actually write viruses to keep the anti-virus industry in business...
it's absurd...
first of all, writing a virus isn't the slightest bit comparable to writing detection algorithms to find thousands of viruses... virus writing isn't actually all that difficult a task in and of itself, and it's made even easier by the existence of published code to do just about anything a new virus writer might want... in order to evade detection a virus need only have an implementation that is new in a sufficiently non-trivial way... anti-virus development, on the other hand, involves reverse engineering, code emulation, and a host of other skills that are really orthogonal to writing viruses... the average virus writer's skill set just isn't useful in anti-virus development...
second, under most versions of the conspiracy theory, hiring virus writers is supposed to be a clever move by the anti-virus companies but this cleverness doesn't hold up under scrutiny... why hire virus writers to write viruses when there are (provably) lots and lots of people willing and able to make viruses for free?... that would be the opposite of clever...
finally, any anti-virus company that hired a virus writer would be crucified by it's competitors in the court of public opinion... these are businesses, they are motivated by money and if they can get more money at the expense of one or more of their competitors they will... and it's not like you can keep something like this secret - disgruntled employees will leak the info, employees who switch companies will leak the info, etc... that's a risk no anti-virus company can afford...
just keep these things in mind next time you hear the silly conspiracy theory...
it's absurd...
first of all, writing a virus isn't the slightest bit comparable to writing detection algorithms to find thousands of viruses... virus writing isn't actually all that difficult a task in and of itself, and it's made even easier by the existence of published code to do just about anything a new virus writer might want... in order to evade detection a virus need only have an implementation that is new in a sufficiently non-trivial way... anti-virus development, on the other hand, involves reverse engineering, code emulation, and a host of other skills that are really orthogonal to writing viruses... the average virus writer's skill set just isn't useful in anti-virus development...
second, under most versions of the conspiracy theory, hiring virus writers is supposed to be a clever move by the anti-virus companies but this cleverness doesn't hold up under scrutiny... why hire virus writers to write viruses when there are (provably) lots and lots of people willing and able to make viruses for free?... that would be the opposite of clever...
finally, any anti-virus company that hired a virus writer would be crucified by it's competitors in the court of public opinion... these are businesses, they are motivated by money and if they can get more money at the expense of one or more of their competitors they will... and it's not like you can keep something like this secret - disgruntled employees will leak the info, employees who switch companies will leak the info, etc... that's a risk no anti-virus company can afford...
just keep these things in mind next time you hear the silly conspiracy theory...
Sunday, March 26, 2006
what is a downloader?
a downloader is a program that downloads and installs/executes one or more other instances of malware from the internet...
the downloader is similar in purpose to the dropper, it's a means of getting malware into a machine while bypassing the security checks at the entrance... the difference here is that while the dropper carries the malware inside of itself the downloader doesn't, so even if a scanner were able to see through all possible ways of hiding a known piece of malware, a new unknown downloader would be able to get past it because the known malware the scanner could have detected wouldn't actually be present yet...
once again, active monitoring and/or sandboxing can mitigate (but not eliminate) the risk posed by this type of malware... once the known malware is downloaded active monitoring should be able to detect it, and if a downloader tried to download and execute the known malware in a sandboxed environment it should also be detected...
just as with droppers, downloaders secretly introduce malware into the system and are thus a type of trojan... unlike droppers, however, the downloader method isn't geared towards hiding anything so it's completely unrelated to stealth - instead it's more like a backdoor for the particular malware it downloads...
back to index
the downloader is similar in purpose to the dropper, it's a means of getting malware into a machine while bypassing the security checks at the entrance... the difference here is that while the dropper carries the malware inside of itself the downloader doesn't, so even if a scanner were able to see through all possible ways of hiding a known piece of malware, a new unknown downloader would be able to get past it because the known malware the scanner could have detected wouldn't actually be present yet...
once again, active monitoring and/or sandboxing can mitigate (but not eliminate) the risk posed by this type of malware... once the known malware is downloaded active monitoring should be able to detect it, and if a downloader tried to download and execute the known malware in a sandboxed environment it should also be detected...
just as with droppers, downloaders secretly introduce malware into the system and are thus a type of trojan... unlike droppers, however, the downloader method isn't geared towards hiding anything so it's completely unrelated to stealth - instead it's more like a backdoor for the particular malware it downloads...
back to index
Saturday, March 25, 2006
magic at sunbeltblog.blogspot.com
so there appears to be some vanishing act going on at the sunbelt blog... in a recent article there talking about how pamela parker got it wrong i made a comment about how alex eck wasn't exactly on the money himself...
now the original url points nowhere and the original comments link has been replaced with a new one that was showing no comments...
i suspect this is nothing more than the consequences of editing the original article to remove a paragraph defending aim against being called adware (sorry, i could find no cache of the original article, you'll just have to take my word for it that said paragraph existed) combined with the vagaries of how blogspot handles edits and how haloscan (the comment service provider there) handles changes to the article's permalink... i haven't checked to see if blogspot really changes the url when you edit an already published article, but i do have some articles where the permalink has a number at the end like the new link for the sunbelt article in question...
just in case the original comment link goes on walkabout as well, here's a quote of what i posted to it:
as i said before, i don't think there was any funny business going on here, i think it was probably just an edit to correct an already published article which in turn had some interesting side effects...
and now you know why i don't provide for comments on this blog - if i should happen to edit something (and there are some things i can see myself modifying on occasion, like adding citations to my definition posts) i wouldn't want to have to deal with the consequences...
now the original url points nowhere and the original comments link has been replaced with a new one that was showing no comments...
i suspect this is nothing more than the consequences of editing the original article to remove a paragraph defending aim against being called adware (sorry, i could find no cache of the original article, you'll just have to take my word for it that said paragraph existed) combined with the vagaries of how blogspot handles edits and how haloscan (the comment service provider there) handles changes to the article's permalink... i haven't checked to see if blogspot really changes the url when you edit an already published article, but i do have some articles where the permalink has a number at the end like the new link for the sunbelt article in question...
just in case the original comment link goes on walkabout as well, here's a quote of what i posted to it:
i'm going to both agree and disagree...
i agree that pam's got it all wrong - adware is more than just ad-supported software... it's got to actually DISPLAY ads, not just be supported by them... there are plenty of ad supported programs out there that leave the ad serving up to a completely different program...
i disagree about aim (and others) not being adware, however... the qualifier you use to justify that distinction is that the 'primary purpose' of adware is to display ads, but i contend that trying to determine the 'primary purpose' of an application is a subjective property... it's a bad defining quality and ruins what could otherwise be a perfectly good *functional* definition...
for example, say someone comes along and makes an instant messaging service that's functionally identical to aim, but they do it not to provide the world with yet another instant messaging application but rather to deploy a platform which not only serves ads but baits users into looking at the ad serving window by putting useful functionality on it... this is still all functionally identical to aim, but it's purpose is to display ads and the instant messaging is just to keep people looking in the direction of those ads... something doesn't stop being adware just because you shoe-horn useful functionality into the ad serving client, and there's really no way to know if the functionality is there to help the ads or if the ads are there to pay for the functionality...
of course, it's not necessary to go through that convolution... aim, like most of the mainstream instant messaging clients, has at various times erected barriers to interroperability both with other im services and with 3rd party clients... the only purpose interroperability barriers serve is to guard a captive audience, which are themselves only good practicing various types of persuasion (like advertising)... so the idea that aim's primary purpose is not providing advertising is questionable at best...
moreover, if the anti-adware/anti-spyware industry persists in using such a definition (yes, i noticed that the anti-spyware coalition's definition shares the same 'feature') the adware industry could easily just port their technology into dlls and activex controls that are bundled by way of integrating them into the 3rd party's application... they'd still be capable of doing all the bad things that people hate about adware but they'd no longer be separate from the programs they're bundled with and the 'primary purpose' of the main app would then exclude such a hybrid from the adware set...
as i said before, i don't think there was any funny business going on here, i think it was probably just an edit to correct an already published article which in turn had some interesting side effects...
and now you know why i don't provide for comments on this blog - if i should happen to edit something (and there are some things i can see myself modifying on occasion, like adding citations to my definition posts) i wouldn't want to have to deal with the consequences...
what is a dropper?
a dropper is a program that carries an (often hidden) instance of some already known malware within itself and drops (extracts and runs) the malware it carries when it itself gets executed...
droppers are a means of getting malicious content past gateway security checking practices such as scanning downloads and email... they're generally easy to create by performing some arbitrary transformation (like run-time compression or encryption or some other type of encoding) on the malware it carries (which is then reversed when the malware gets dropped) but not necessarily easy for a scanner to see through programmatically unless it has prior knowledge of the transformation algorithm... in it's transformed state the malware may not be recognizable to the security applications that checked the dropper as it entered the machine and if that happens then the malware may go undetected when it gets dropped unless additional measures such as real-time monitoring or sandboxing are used...
the dropper represents a kind of (usually) temporary camoflage and as such is a distant relative of the more conventional stealth techniques... because they secretly introduce malware into a system they are also a type of trojan horse program in their own right...
back to index
droppers are a means of getting malicious content past gateway security checking practices such as scanning downloads and email... they're generally easy to create by performing some arbitrary transformation (like run-time compression or encryption or some other type of encoding) on the malware it carries (which is then reversed when the malware gets dropped) but not necessarily easy for a scanner to see through programmatically unless it has prior knowledge of the transformation algorithm... in it's transformed state the malware may not be recognizable to the security applications that checked the dropper as it entered the machine and if that happens then the malware may go undetected when it gets dropped unless additional measures such as real-time monitoring or sandboxing are used...
the dropper represents a kind of (usually) temporary camoflage and as such is a distant relative of the more conventional stealth techniques... because they secretly introduce malware into a system they are also a type of trojan horse program in their own right...
back to index
Thursday, March 23, 2006
are good spyware simulators still a bad idea
so apparently someone came up with the idea of creating spyware simulators collectively known as spycar (apparently a play on the eicar test file) for testing the effectiveness of anti-spyware applications...
the idea, basically, is that a bunch of these tiny applications could be written that each do some small spyware-like thing... supposedly this is meant to test how well an anti-spyware app can detect spyware they don't already know about - the more of these spyware simulators the anti-spyware detects the better it is (in theory)...
this idea came up before in the virus realm years ago and i'll direct you now to sarah gordon's paper are good virus simulators still a bad idea... i suggest reading the entire thing through but for now just scroll down to the conclusion and replace "virus" with "spyware" and it will be about as valid...
essentially, for testing the effectiveness of your security app, using simulators only tells you how good the app is at detecting simulations rather than the real thing... to assume that anti-spyware vendors won't simply add signatures for the simulations is naive, especially when their work starts being judged on how well it detects the simulations... there's no way this effort on it's own is ever going to force the vendors to improve their generic detection techniques, it's just not a cost effective way for the vendors to deal with the simulations...
as for using these things as test files to see if your anti-spyware app is installed correctly (as their namesake the eicar standard anti-virus test file was intended for) the anti-spyware vendors could just as easily use the eicar test file directly for that purpose... there's no need to implement any particular behaviour in the test file if all you're doing is checking if the app can detect something it already knows about; it's not like the eicar test file has any virus-like behaviours, nothing of the sort was required to test the sanity of an installation, all it does is display a string of text on the screen (at the command prompt) when executed...
clearly, if folks in the anti-spyware field are just now coming up with an idea that was debunked in the anti-virus field over a decade ago, the anti-spyware field isn't anywhere near as mature... the question is are the anti-spyware principals looking into learning from what the anti-virus community and industry have already figured out?...
the idea, basically, is that a bunch of these tiny applications could be written that each do some small spyware-like thing... supposedly this is meant to test how well an anti-spyware app can detect spyware they don't already know about - the more of these spyware simulators the anti-spyware detects the better it is (in theory)...
this idea came up before in the virus realm years ago and i'll direct you now to sarah gordon's paper are good virus simulators still a bad idea... i suggest reading the entire thing through but for now just scroll down to the conclusion and replace "virus" with "spyware" and it will be about as valid...
essentially, for testing the effectiveness of your security app, using simulators only tells you how good the app is at detecting simulations rather than the real thing... to assume that anti-spyware vendors won't simply add signatures for the simulations is naive, especially when their work starts being judged on how well it detects the simulations... there's no way this effort on it's own is ever going to force the vendors to improve their generic detection techniques, it's just not a cost effective way for the vendors to deal with the simulations...
as for using these things as test files to see if your anti-spyware app is installed correctly (as their namesake the eicar standard anti-virus test file was intended for) the anti-spyware vendors could just as easily use the eicar test file directly for that purpose... there's no need to implement any particular behaviour in the test file if all you're doing is checking if the app can detect something it already knows about; it's not like the eicar test file has any virus-like behaviours, nothing of the sort was required to test the sanity of an installation, all it does is display a string of text on the screen (at the command prompt) when executed...
clearly, if folks in the anti-spyware field are just now coming up with an idea that was debunked in the anti-virus field over a decade ago, the anti-spyware field isn't anywhere near as mature... the question is are the anti-spyware principals looking into learning from what the anti-virus community and industry have already figured out?...
Wednesday, March 22, 2006
stopbadware.org should check their own sources
in the recently released report on kazaa, stopbadware.org states:
unfortunately, if they'd actually read the anti-spyware coalition's glossary they'd know that in technical settings the anti-spyware coalition uses a definition not unlike sharman networks' definition...
this isn't a deal-killer... at least some of the adware bundled with kazaa is also spyware (even by narrow definitions like my own or the anti-spyware coalition's narrow spyware definition), so sharman networks' claim of no spyware is false...
the problem is what is being communicated to the reader... stopbadware.org is using wikipedia's entry alone as their definition and in my experience wikipedia is not a good authoritative source (a fine informative source, mind you) on much of anything malware related... as the anti-spyware coalition's glossary clearly states, that is not the industry agreed upon definition for spyware - it is a colloquialism that they are forced to recognize in popular usage...
so what? well think about this: with the people backing stopbadware.org, they are invariably going to be regarded by most as authorities in the field - so their use of colloquial definitions rather than formal technical definitions will only serve to reinforce the misconceptions those colloquial definitions represent and lead astray those members of the public who are actually trying to distill meaning out of the various souces in this field...
part of me is tempted to say oh well... after all, what do you expect from people who invented the term "badware" (apparently not aware that the "mal" in malware comes from latin and means "bad") to describe "malicious software that tracks your moves online and feeds that information back to shady marketing groups", which basically boils down to advertising-related spyware (which is a much more descriptive term, come to think of it)... but you know what, misinformation coming from a source this high profile and seemingly authoritative is just not a good thing...
Sharman Networks claims that Kazaa has "NO SPYWARE", based on a highly restricted definition of spyware (namely, that no personally identifiable information is sent by the program). However, Kazaa's installation includes several bundled programs that are considered spyware under the common definition of spyware as software that subverts the computer's operation for the benefit of a third party (see Anti-Spyware Coalition and Wikipedia's article on "Spyware").
unfortunately, if they'd actually read the anti-spyware coalition's glossary they'd know that in technical settings the anti-spyware coalition uses a definition not unlike sharman networks' definition...
this isn't a deal-killer... at least some of the adware bundled with kazaa is also spyware (even by narrow definitions like my own or the anti-spyware coalition's narrow spyware definition), so sharman networks' claim of no spyware is false...
the problem is what is being communicated to the reader... stopbadware.org is using wikipedia's entry alone as their definition and in my experience wikipedia is not a good authoritative source (a fine informative source, mind you) on much of anything malware related... as the anti-spyware coalition's glossary clearly states, that is not the industry agreed upon definition for spyware - it is a colloquialism that they are forced to recognize in popular usage...
so what? well think about this: with the people backing stopbadware.org, they are invariably going to be regarded by most as authorities in the field - so their use of colloquial definitions rather than formal technical definitions will only serve to reinforce the misconceptions those colloquial definitions represent and lead astray those members of the public who are actually trying to distill meaning out of the various souces in this field...
part of me is tempted to say oh well... after all, what do you expect from people who invented the term "badware" (apparently not aware that the "mal" in malware comes from latin and means "bad") to describe "malicious software that tracks your moves online and feeds that information back to shady marketing groups", which basically boils down to advertising-related spyware (which is a much more descriptive term, come to think of it)... but you know what, misinformation coming from a source this high profile and seemingly authoritative is just not a good thing...
Tuesday, March 21, 2006
practical suggestions for bundling adware
i was reading a blog post over at stopbadware.org about adware bundling and it struck me that there doesn't really seem to be much in the way of constructive practical suggestions for those software developers who are in the unfortunate position of needing financial assistance from an adware company...
as the stopbadware post suggests, if the adware you bundle with is bad you are going to be held accountable for it's actions because you chose to bundle it so lets go through some steps that may help to avoid that...
i know that sounds like an aweful lot of work but guess what, there's no such thing as a free lunch and making the choice to bundle adware isn't a way to get free money...
i don't know how easy it will be to find an adware provider that meets these requirements, perhaps there aren't any yet but you know what? adware companies don't get any money unless people bundle their software so as much as you may need them they need you too so don't be afraid to put some pressure on them to get the terms you want, eventually an adware company will come along that's willing to do business on those terms if there's enough demand for it... they're businesses after all and they have to bend to market pressure or go out of business... it's just another form of voting with your wallet...
and what should you do if you still feel like you have no leverage over the adware company? do what many groups of 'little guys' have done before you - organize... find like-minded software developers who also need the help of an adware company but are uncomfortable with the typical adware's shenanigans and go after what you want as a united group... and i'm not just talking about folks who haven't signed up with an adware company yet; there are plenty of folks who came before who wish their current agreement with their adware partner was better than it is - these are people who are in the market for a new adware partner and so can be added to your collective voice...
as the stopbadware post suggests, if the adware you bundle with is bad you are going to be held accountable for it's actions because you chose to bundle it so lets go through some steps that may help to avoid that...
- be up front about the presence of the adware, say right on your front page or on your download page (and not in a small font) that the software is ad supported... you should even go so far as to specify the adware provider so that people downloading your product know what they're getting... i know this will probably drive away customers because of the bad name adware has (often deservedly so) but if you don't tell them then it will be much worse for the long term viability of your product... better to have slow adoption than a big backlash...
- take personal responsibility for the quality of the adware you're bundling - make sure it's not buggy, make sure it doesn't contain spyware or take any other actions that would send personal information back to anyone, make sure it doesn't install silently/secretly, make sure it uninstalls cleanly, make sure it doesn't install anything unexpected or provide a platform for advertisers to install things secretly/silently through the ad windows themselves, make sure it doesn't interfer with what the user is trying to do by popping up lots of windows or playing with window z order or any other tricks to put their ads overtop of what the user is working on...
- make sure your contract with the adware company clearly specifies what kind of behaviour is acceptable from their adware so they can't play any kind of bait and switch game using an innocuous test version and an offensive upgrade, and make sure they can't change the terms of that contract unilaterally...
- research the company's history in order to get some idea of how likely they are to keep their word/not violate that contract, also to get an idea of what kind of ethics they've displayed in the past and how good they've been about fixing bugs and addressing concerns...
- keep up to date on issues relating to the adware in your bundle... for example if there's a bug, post information about it on your site and direct affected users to where ever they need to go to correct the problem...
- inform your users of the exact measures you go through to make sure the adware you're bundling with is safe for them to install...
i know that sounds like an aweful lot of work but guess what, there's no such thing as a free lunch and making the choice to bundle adware isn't a way to get free money...
i don't know how easy it will be to find an adware provider that meets these requirements, perhaps there aren't any yet but you know what? adware companies don't get any money unless people bundle their software so as much as you may need them they need you too so don't be afraid to put some pressure on them to get the terms you want, eventually an adware company will come along that's willing to do business on those terms if there's enough demand for it... they're businesses after all and they have to bend to market pressure or go out of business... it's just another form of voting with your wallet...
and what should you do if you still feel like you have no leverage over the adware company? do what many groups of 'little guys' have done before you - organize... find like-minded software developers who also need the help of an adware company but are uncomfortable with the typical adware's shenanigans and go after what you want as a united group... and i'm not just talking about folks who haven't signed up with an adware company yet; there are plenty of folks who came before who wish their current agreement with their adware partner was better than it is - these are people who are in the market for a new adware partner and so can be added to your collective voice...
Thursday, March 16, 2006
a little clarity on the RFID virus issue
you may have read recently about the newly discovered possibility of using RFID tags as a vector for viruses and worms... there seems to be some confusion about this and to be honest that's not unexpected when even the researchers who came up with this are unclear on the matter of viruses and worms (they use the old erroneous distinction between worms and viruses where worms don't require interaction from the user even though neither their worms nor their viruses require interaction)...
first off, the RFID tags are a storage medium (not unlike a floppy disk or USB flash drive) with a very small capacity (1024 bits or 128 bytes)... they don't get infected, per se, they just hold the code and nothing more...
second, the data stored on the RFID tag can be malformed in such a way as to exploit a vulnerability in the system that reads and stores the data, such as an SQL injection attack that executes a self-replicating query...
third, although the main example given in the source material doesn't infect any host programs it's not inconceivable that an actual infector could be written (for example an SQL query that infects stored procedures)...
fourth, this isn't a concern for regular folks, only for warehouses and shipping centers and other similar places that would be actively using RFID tags and entering their data into some sort of system... the 'virus' can't magically jump out of the RFID tag and infect your computer, nor can it hop from one RFID tag to another (although once the 'virus' copies itself over other tag data in the database it may get written back to other RFID tags by the system)...
this really isn't as technologically ground breaking as it might first seem... viruses and worms exploit vulnerabilities in order to self-replicate on a frequent enough basis - the only addition here is using RFID tags as a storage and distribution medium...
first off, the RFID tags are a storage medium (not unlike a floppy disk or USB flash drive) with a very small capacity (1024 bits or 128 bytes)... they don't get infected, per se, they just hold the code and nothing more...
second, the data stored on the RFID tag can be malformed in such a way as to exploit a vulnerability in the system that reads and stores the data, such as an SQL injection attack that executes a self-replicating query...
third, although the main example given in the source material doesn't infect any host programs it's not inconceivable that an actual infector could be written (for example an SQL query that infects stored procedures)...
fourth, this isn't a concern for regular folks, only for warehouses and shipping centers and other similar places that would be actively using RFID tags and entering their data into some sort of system... the 'virus' can't magically jump out of the RFID tag and infect your computer, nor can it hop from one RFID tag to another (although once the 'virus' copies itself over other tag data in the database it may get written back to other RFID tags by the system)...
this really isn't as technologically ground breaking as it might first seem... viruses and worms exploit vulnerabilities in order to self-replicate on a frequent enough basis - the only addition here is using RFID tags as a storage and distribution medium...
Tuesday, March 14, 2006
why virtual machine based 'rootkits' won't be the next big problem
ok, ignoring the issue of what rootkits really are for the moment, let's examine this idea of rootkits that are so low level they're even below the OS...
first, as greg hoglund points out you're pretty much guaranteed to notice the performance hit when your entire OS gets dropped into a virtual machine...
second, as pointed out on the f-secure blog it's actually been done before over a decade ago, back when stealth was still called stealth...
but really, i think i'm going to go them both one better (at least) and say that we solved the full stealth problem over a decade ago... that solution was called booting from a known clean bootable floppy disk and scanning with a known virus scanner...
"but kurt, how are we supposed to use our generic rootkit detection technology if the rootkit isn't active?" - simple, you aren't... those sorts of generics require the malware to be active, which gives it a tactical advantage (it's able to actively defend itself then)... it also allows the malware to know more about the security application than the security application knows about the malware, which is another tactical advantage for the malware... if you're unfamiliar with what sun tsu had to say about engaging the enemy when you're at a disadvantage then i suggest you go do your homework right now... you can't rely solely on generics that way - known-malware techniques (know your enemy) must be employed in an environment and under conditions of your choosing in order to maximize your tactical advantage, and the generics are then used in a supporting role to partially cover what that strategy can't...
now, those of you who've been following things for a few years now you probably know that microsoft screwed that option up with the advent of NTFS... no version of MSDOS is capable of parsing an NTFS partition natively and microsoft seems unwilling to do much about that - probably because so far there really hasn't been that great a need these days... however, should the need arise a fair amount of effort has gone into correcting microsoft's oversight... things like bart's pe disk, NTFS4DOS, or any one of the many recovery oriented live-cd linux distributions can give you access to an NTFS partition after booting from a known clean bootable medium...
all in all, the majority of what's being said out there about microsoft's subvirt and the technology it represents is just hype... in the very unlikely event that anyone ever actually bothers trying to deploy it in the wild, it's an old problem that we've had a solution for for some time now...
[obligatory terminology rant]
of course all of this is one of the consequences of the rootkit redefinition... it clouds the issues in both the rootkit problem-space and the stealth problem-space... we wouldn't be forgetting this history if stealth was still called stealth, and then maybe the brain-trust at microsoft wouldn't have to spend untold millions reinventing the wheel that we already know how to deal with...
[/obligatory terminology rant]
first, as greg hoglund points out you're pretty much guaranteed to notice the performance hit when your entire OS gets dropped into a virtual machine...
second, as pointed out on the f-secure blog it's actually been done before over a decade ago, back when stealth was still called stealth...
but really, i think i'm going to go them both one better (at least) and say that we solved the full stealth problem over a decade ago... that solution was called booting from a known clean bootable floppy disk and scanning with a known virus scanner...
"but kurt, how are we supposed to use our generic rootkit detection technology if the rootkit isn't active?" - simple, you aren't... those sorts of generics require the malware to be active, which gives it a tactical advantage (it's able to actively defend itself then)... it also allows the malware to know more about the security application than the security application knows about the malware, which is another tactical advantage for the malware... if you're unfamiliar with what sun tsu had to say about engaging the enemy when you're at a disadvantage then i suggest you go do your homework right now... you can't rely solely on generics that way - known-malware techniques (know your enemy) must be employed in an environment and under conditions of your choosing in order to maximize your tactical advantage, and the generics are then used in a supporting role to partially cover what that strategy can't...
now, those of you who've been following things for a few years now you probably know that microsoft screwed that option up with the advent of NTFS... no version of MSDOS is capable of parsing an NTFS partition natively and microsoft seems unwilling to do much about that - probably because so far there really hasn't been that great a need these days... however, should the need arise a fair amount of effort has gone into correcting microsoft's oversight... things like bart's pe disk, NTFS4DOS, or any one of the many recovery oriented live-cd linux distributions can give you access to an NTFS partition after booting from a known clean bootable medium...
all in all, the majority of what's being said out there about microsoft's subvirt and the technology it represents is just hype... in the very unlikely event that anyone ever actually bothers trying to deploy it in the wild, it's an old problem that we've had a solution for for some time now...
[obligatory terminology rant]
of course all of this is one of the consequences of the rootkit redefinition... it clouds the issues in both the rootkit problem-space and the stealth problem-space... we wouldn't be forgetting this history if stealth was still called stealth, and then maybe the brain-trust at microsoft wouldn't have to spend untold millions reinventing the wheel that we already know how to deal with...
[/obligatory terminology rant]
Monday, March 13, 2006
the final word on crazy world
so it's come to this has it? guillermito was found guilty and his appeal failed... he's got to pay big bucks because tegam didn't like being made fools of... well, i hope tegam gets their money's worth because the streisand effect generally doesn't work in favour of those trying to cover things up...
there's really nothing left to say about it though... it's over... tegam 'won', the people of france lost, and security research in that country will never be the same... pretty sad, really...
there's really nothing left to say about it though... it's over... tegam 'won', the people of france lost, and security research in that country will never be the same... pretty sad, really...
Sunday, March 12, 2006
the adware comment thread to end all adware comment threads
story time folks... currently i'm embroiled quite the debate in the comments section of a posting over at sunbeltblog and in true vitalsecurity.org fashion i thought i'd offer up my observations here...
first i'll confess to making an error, i started out by misinterpreting the source material, i thought an anti-spyware app had been labelled rogue simply because it had been bundled with adware... the interesting thing is that people actually defended this interpretation - that is, if my interpretation had been what actually happened they would defend that action apparently just because the adware in question was produced by a company with a shady past...
now, i hate adware as much as the next guy and i certainly wouldn't touch this thing with a 10 foot barge pole (at least not outside of a virtual environment), but i'm honest enough with myself to admit that that is purely on suspicion alone, whereas the overwhelming opinion of the other participants seems to be that if the software is made by bad people or even people who have done bad things in the past then the software itself is bad... it's been these kinds of peculiar ideas that have kept me going back...
now i've known for a long time that the malware problem has many dimensions, it's not just the software that we need to concern ourselves with, but when we are dealing with the software part of the problem should we let things like the creator's past cloud the issue? no, of course not, that's a different part of the malware problem and it's best dealt with in a different way... when we classify malware we're concerned with whether or not the software itself poses a risk, not whether it further's some corporation's nefarious agenda... internet explorer furthered a corporation's nefarious agenda (just ask the department of justice) but that doesn't make it malware...
another peculiar idea i encountered was that if you don't deal with the question of whether the people who made the software are bad when you're deciding whether the software itself is bad then somehow you're not addressing the badness of the people at all... come on, the malware problem is a complex one, and the secret to dealing with complex problems is to break them into their component parts and deal with those parts separately... just because you aren't dealing with the people when you're dealing with the software doesn't mean you aren't dealing with the people at all, just that you've compartmentalized your efforts... is that a bad thing? no, certainly not, in fact it means you're much less likely to try and use your software solution on a people problem... and lets face it, software doesn't solve people problems - it solves problems for people, but not problems with people...
first i'll confess to making an error, i started out by misinterpreting the source material, i thought an anti-spyware app had been labelled rogue simply because it had been bundled with adware... the interesting thing is that people actually defended this interpretation - that is, if my interpretation had been what actually happened they would defend that action apparently just because the adware in question was produced by a company with a shady past...
now, i hate adware as much as the next guy and i certainly wouldn't touch this thing with a 10 foot barge pole (at least not outside of a virtual environment), but i'm honest enough with myself to admit that that is purely on suspicion alone, whereas the overwhelming opinion of the other participants seems to be that if the software is made by bad people or even people who have done bad things in the past then the software itself is bad... it's been these kinds of peculiar ideas that have kept me going back...
now i've known for a long time that the malware problem has many dimensions, it's not just the software that we need to concern ourselves with, but when we are dealing with the software part of the problem should we let things like the creator's past cloud the issue? no, of course not, that's a different part of the malware problem and it's best dealt with in a different way... when we classify malware we're concerned with whether or not the software itself poses a risk, not whether it further's some corporation's nefarious agenda... internet explorer furthered a corporation's nefarious agenda (just ask the department of justice) but that doesn't make it malware...
another peculiar idea i encountered was that if you don't deal with the question of whether the people who made the software are bad when you're deciding whether the software itself is bad then somehow you're not addressing the badness of the people at all... come on, the malware problem is a complex one, and the secret to dealing with complex problems is to break them into their component parts and deal with those parts separately... just because you aren't dealing with the people when you're dealing with the software doesn't mean you aren't dealing with the people at all, just that you've compartmentalized your efforts... is that a bad thing? no, certainly not, in fact it means you're much less likely to try and use your software solution on a people problem... and lets face it, software doesn't solve people problems - it solves problems for people, but not problems with people...
Saturday, March 11, 2006
mac computers and viruses
there's been a lot of coverage lately of the issue of mac security, unix, and viruses, and i think it's time to dispell a few myths...
- macs are immune to viruses...
they most certainly are not... OSX/Leap is an overwriting virus and instant messenger worm that operates on the mac osx platform... - macs were immune to viruses...
they were never immune to viruses - no general purpose computer system can be immune to viruses... - macs were virus-free before OSX/Leap...
OSX/Leap wasn't the first mac virus, it was just the first virus for mac osx... previous versions of the mac operating system had other viruses... not to mention some ms office macro viruses were able to operate on macs just like on windows machines, because ms office is a platform in and of itself... - the fact that it took so long for mac osx to get compromised means that mac osx is more secure than windows...
it actually means no such thing... because of the smaller user-base a compromise of the mac osx platform has less payoff for the attacker community, therefore they aren't as interested in it, therefore there are fewer people working on it, therefore there are less man-hours going into the effort, therefore it takes longer and/or has a lower probability of success... mac osx may or may not be more secure than windows, but the key to it's apparent resistance to attack is that it's a lower risk platform (there's a big difference between security and risk, but i'll leave that for another time)... - mac osx is more secure and/or immune against viruses because it's based on unix...
the first academic study of viruses was carried out by fred cohen on a professionally administrated unix system and the virus(es) still worked (see this paper for details)... unix is just as capable of supporting viral infection as any other OS... - mac osx is more secure than windows...
maybe (and so this isn't technically a myth) but that doesn't mean there aren't security vulnerabilities or that mac users don't have to worry about security... with the release of viruses for the platform and the discovery of arbitrary code execution exploits it's clear that macs have many of the same security problems that windows has and as macs become more popular more and more effort will go into finding them... also consider that, due in part to these myths, mac users are less accustomed to thinking about security and so can be fool by less sophisticated ploys... users are a big part of the security of the system (often users are the weakest link in that security) so mac users really should not be taking security lightly as they're at greater risk than they probably realize...
Monday, March 06, 2006
MARA is holding the Crossover virus sample hostage
read this securityfocus article and that's the conclusion you should probably come to - MARA is holding the Crossover virus sample hostage; they'll give anti-virus companies the sample if the anti-virus companies will give MARA access to their own virus databases...
this is not how you build trust in the anti-virus industry... an act of good faith, giving the sample to the people who can use it to help protect everyone without any strings attached, would have been much better...
apparently MARA isn't known for being a whiter-than-white-hat in the security field, however... the article above points to evidence of virus writer involvement, for example...
the way i look at this is this: until the existence and nature of Crossover can be confirmed by others (like members of the anti-virus community) the sample effectively does not exist and MARA's press on the matter is no better than FUD... the anti-virus companies should not give in to MARA's extortion scheme - if the virus never goes into the wild then MARA's leverage becomes impotent - if the virus does go into the wild then a victim will send the anti-virus companies a sample and MARA can be blamed for not being more forthcoming and for requiring anti-virus companies to violate responsible viral material handling guidelines just to get a sample...
my message to MARA is this: get bent...
this is not how you build trust in the anti-virus industry... an act of good faith, giving the sample to the people who can use it to help protect everyone without any strings attached, would have been much better...
apparently MARA isn't known for being a whiter-than-white-hat in the security field, however... the article above points to evidence of virus writer involvement, for example...
the way i look at this is this: until the existence and nature of Crossover can be confirmed by others (like members of the anti-virus community) the sample effectively does not exist and MARA's press on the matter is no better than FUD... the anti-virus companies should not give in to MARA's extortion scheme - if the virus never goes into the wild then MARA's leverage becomes impotent - if the virus does go into the wild then a victim will send the anti-virus companies a sample and MARA can be blamed for not being more forthcoming and for requiring anti-virus companies to violate responsible viral material handling guidelines just to get a sample...
my message to MARA is this: get bent...
Sunday, March 05, 2006
Thursday, March 02, 2006
what is a botnet?
a botnet is a network of bots (sometimes explained as a contraction of the word "robots")... essentially a bot is a program that, much like a RAT, allows a 3rd party to direct the affected machine to perform certain tasks; however, unlike a RAT, bots don't sit around on the affected machine waiting for a 3rd party to find and connect to them - instead they go out and connect to one or more communication points where other instances of the bot have also connected to and await instruction... in this way the 3rd party can give instructions thousands of affected computers at once...
the simplest botnet configuration is where all the bots connect to a single hub (such as an IRC chat room) where the bot master (the 3rd party controlling the bots) will give them instructions... although this is conceptually simple, it suffers from problems of scale - the more bots connected to a central communication server the harder it will be for that server to cope with all the connections...
a hierarchical network, where the bot master communicates with only a few (hundred?) bots which in turn each command a few (hundred?) more and so on, is also possible... this has the benefit of scaling better and allowing the bot master to cultivate a much larger botnet...
a third possible configuration is a peer to peer network between bots so that the bot master need only communicate with a single bot which in turn spreads the command to it's bot peers... a peer to peer configuration can help with scaling as well but the more significant strength is it's non-reliance on a central communication point that might get attacked and/or shut down...
in addition to the more sophisticated communication pathway between the machine and the remote 3rd party another difference between a bot and a RAT is that, although a bot gives control of the affected machine to a remote 3rd party, a bot would never be used for remote administration purposes... a botnet's strength is in aggregating control over huge numbers of machines and while a remote control software may be a legitimate means to perform quick and dirty remote administration of one or two machines, when you get to large numbers more formal techniques and technologies (such as group policy or active directory) become appropriate...
one way bots can get installed on a system by tricking the user into running an email or instant message attachment or other file downloaded from the internet and in this case the bot would qualify as a trojan horse at the very least... bots also are often able to spread themselves to systems by self-replication either as worms or viruses or both... in fact self-replication is often the best way to affect large numbers of systems (as we have seen time and again with worms like blaster and slammer)...
back to index
the simplest botnet configuration is where all the bots connect to a single hub (such as an IRC chat room) where the bot master (the 3rd party controlling the bots) will give them instructions... although this is conceptually simple, it suffers from problems of scale - the more bots connected to a central communication server the harder it will be for that server to cope with all the connections...
a hierarchical network, where the bot master communicates with only a few (hundred?) bots which in turn each command a few (hundred?) more and so on, is also possible... this has the benefit of scaling better and allowing the bot master to cultivate a much larger botnet...
a third possible configuration is a peer to peer network between bots so that the bot master need only communicate with a single bot which in turn spreads the command to it's bot peers... a peer to peer configuration can help with scaling as well but the more significant strength is it's non-reliance on a central communication point that might get attacked and/or shut down...
in addition to the more sophisticated communication pathway between the machine and the remote 3rd party another difference between a bot and a RAT is that, although a bot gives control of the affected machine to a remote 3rd party, a bot would never be used for remote administration purposes... a botnet's strength is in aggregating control over huge numbers of machines and while a remote control software may be a legitimate means to perform quick and dirty remote administration of one or two machines, when you get to large numbers more formal techniques and technologies (such as group policy or active directory) become appropriate...
one way bots can get installed on a system by tricking the user into running an email or instant message attachment or other file downloaded from the internet and in this case the bot would qualify as a trojan horse at the very least... bots also are often able to spread themselves to systems by self-replication either as worms or viruses or both... in fact self-replication is often the best way to affect large numbers of systems (as we have seen time and again with worms like blaster and slammer)...
back to index
what is a RAT?
a RAT, or remote access trojan (sometimes remote administration tool) is a program that listens for and accepts connections from a remote 3rd party and carries out the commands that 3rd party gives it... essentially it's a server that provides remote control functionality...
as is traditionally the case with trojans, there are some circumstances where this functionality is legitimate or even desirable and some circumstances where it is not... it is legitimate and desirable when you are the administrator of the system with the remote control software on it and are personally using the software to administer the system remotely...it is not legitimate when you are tricked into installing it or are otherwise unaware that it is installed on your computer and unaware that someone else has control of that system (most responsible remote administration tools are made in such a way as to not be easy to install without the user's knowledge or consent)...
it is only in the circumstances where it is not legitmate or desirable that such a remote control program qualifies as a remote access trojan...
back to index
as is traditionally the case with trojans, there are some circumstances where this functionality is legitimate or even desirable and some circumstances where it is not... it is legitimate and desirable when you are the administrator of the system with the remote control software on it and are personally using the software to administer the system remotely...it is not legitimate when you are tricked into installing it or are otherwise unaware that it is installed on your computer and unaware that someone else has control of that system (most responsible remote administration tools are made in such a way as to not be easy to install without the user's knowledge or consent)...
it is only in the circumstances where it is not legitmate or desirable that such a remote control program qualifies as a remote access trojan...
back to index
what is a backdoor?
a backdoor is simply a way of accessing something through alternative, often unwanted means...
this can come in many forms, from a bug in a program that allows illegitimate access to data when some condition is met to a piece of software specifically written to allow remote access to a computer...
backdoors are security vulnerabilities that ideally should be kept to a minimum or eliminated entirely if possible... the computer owner may actually make use of some backdoors but that is a security trade-off that should only be made when fully aware of the potential consequences...
back to index
this can come in many forms, from a bug in a program that allows illegitimate access to data when some condition is met to a piece of software specifically written to allow remote access to a computer...
backdoors are security vulnerabilities that ideally should be kept to a minimum or eliminated entirely if possible... the computer owner may actually make use of some backdoors but that is a security trade-off that should only be made when fully aware of the potential consequences...
back to index
Wednesday, March 01, 2006
what is spyware?
spyware is any program that reports information about you, your activities, or your system back to a 3rd party...
like adware, spyware can sometimes have legitimate uses... for example winamp can (if so configured) report usage statistics back to nullsoft... windows xp, upon encountering a crashed application will offer to send a memory dump of the application to microsoft... even your browser reports information about you back to the websites you're on so that those websites can show you data that is appropriate for you such as the contents of your online shopping cart if you happen to be on an online store's site...
as the name suggests, however, there are more sinister uses for spyware such as stealing passwords or credit card information... this type of spyware generally gets installed or reports to a 3rd party without the user's knowledge and/or permission...
spyware that spies on you without your knowledge and/or permission qualifies as a type of trojan... in fact, the term spyware is so pejorative that it is almost exclusively used to refer to those examples that also qualify as trojan horse programs...
there is a complication in the spyware landscape, however... this complication arises because sometimes the user of a computer and the owner of that computer are not the same person... some organizations use spyware to monitor what their workers are doing on the organization's computers and while the spyware qualify as a trojan in more conventional circumstances it's (arguably) not a trojan in these particular contexts because it has permission from the person/people who matter...
back to index
like adware, spyware can sometimes have legitimate uses... for example winamp can (if so configured) report usage statistics back to nullsoft... windows xp, upon encountering a crashed application will offer to send a memory dump of the application to microsoft... even your browser reports information about you back to the websites you're on so that those websites can show you data that is appropriate for you such as the contents of your online shopping cart if you happen to be on an online store's site...
as the name suggests, however, there are more sinister uses for spyware such as stealing passwords or credit card information... this type of spyware generally gets installed or reports to a 3rd party without the user's knowledge and/or permission...
spyware that spies on you without your knowledge and/or permission qualifies as a type of trojan... in fact, the term spyware is so pejorative that it is almost exclusively used to refer to those examples that also qualify as trojan horse programs...
there is a complication in the spyware landscape, however... this complication arises because sometimes the user of a computer and the owner of that computer are not the same person... some organizations use spyware to monitor what their workers are doing on the organization's computers and while the spyware qualify as a trojan in more conventional circumstances it's (arguably) not a trojan in these particular contexts because it has permission from the person/people who matter...
back to index
what is adware?
adware is any program that displays advertisements for something other than itself...
sometimes the display of such advertisements is completely benign and serves as a means of subsidizing the development of software or the provision or services... for example, older versions of the opera web browser displayed ads to users who hadn't paid for the browser in order to help pay for the cost of development of the software... users had the option of using the free version and letting the advertisements take up a certain portion of the screen or paying for the ad-free version and getting more screen real-estate with which to browse with... another example is the internet service providers that used to (and perhaps still do in some locales) provide free internet service so long as you used their custom connection software which utilized part of your screen real-estate to display ads...
while all that sounds ok, that's just the well behaved adware... sometimes 3rd party adware is bundled with software the user downloads... ideally the presence of this adware is made obvious during installation and the user given an opportunity to opt out of the installation - also ideal would be that the adware is easy to find and uninstall once on the system... however, often the presence of the adware is hidden in an EULA (End User License Agreement) that no one reads and is installed in such a way as to make it difficult for the user to find it and/or remove it...
when adware is installed in secret and/or is made difficult to find and/or remove it qualifies as a trojan horse program and it is this combination of adware and trojan that most people are talking about when they speak of adware in a malware context...
back to index
sometimes the display of such advertisements is completely benign and serves as a means of subsidizing the development of software or the provision or services... for example, older versions of the opera web browser displayed ads to users who hadn't paid for the browser in order to help pay for the cost of development of the software... users had the option of using the free version and letting the advertisements take up a certain portion of the screen or paying for the ad-free version and getting more screen real-estate with which to browse with... another example is the internet service providers that used to (and perhaps still do in some locales) provide free internet service so long as you used their custom connection software which utilized part of your screen real-estate to display ads...
while all that sounds ok, that's just the well behaved adware... sometimes 3rd party adware is bundled with software the user downloads... ideally the presence of this adware is made obvious during installation and the user given an opportunity to opt out of the installation - also ideal would be that the adware is easy to find and uninstall once on the system... however, often the presence of the adware is hidden in an EULA (End User License Agreement) that no one reads and is installed in such a way as to make it difficult for the user to find it and/or remove it...
when adware is installed in secret and/or is made difficult to find and/or remove it qualifies as a trojan horse program and it is this combination of adware and trojan that most people are talking about when they speak of adware in a malware context...
back to index
Subscribe to:
Posts (Atom)