that's right, the blue pill is not 100% undetectable...
i was amazed at the number of writers swallowing the "100% undetectable" bit hook, line, and sinker... clearly people aren't really thinking things through...
and i'm not even referring to my previous post on the blue pill, that was really just conjecture... i don't know it will work, nobody knows what will work against the blue pill because nobody's seen the blue pill yet except the researchers involved... i suspect that a pre-emptive tactical move to secure privileged virtualization resources can be used to foil next-gen vm-based stealth but it's all just guesses right now...
no, now i'm going to go back to first principles... let's start with some background - there is no perfect protection... this is a truism, an axiom, and something that the bad guys will tell you ad nauseam* in trying to show you that your security mechanisms, no matter how good, are flawed... and you know what they're absolutely right, there is no perfect protection - but watch out if you try to turn that attitude around on them 'cause you will get flamed... you see there are true believers out there, pro-malware zealots who in one breath will gleefully expound on how your security efforts are vulnerable to this or that in an attempt to feel superior for being on the supposed winning side in the malware/anti-malware battle and then in the next breath go ballistic when you suggest that the same principle applies to the tricks and techniques that malware writers use to protect their malware from security apps...
yes, that's right, stealth is nothing more than a protection mechanism (one of many as a matter of fact) that facilitate malware persistence and if there can be no perfect protection then there can be no perfect stealth, no 100% undetectability... nada, zilch... if the blue pill were to turn out to be the exception then we would study it and learn from it and build more perfect protection techniques - the same fundamental principles that apply to good software must apply to bad software too and vice versa, it's all just software after all...
what's more, i can't believe nobody is catching the scent of snake oil... i mean come on, 100% undetectable should sound as impossible as 100% detection...
no, the blue pill is not 100% undetectable, it cannot be, it would violate one of the most fundamental principles in security... it may very well be undetectable by current products but that's just not the same thing... by that logic new viruses are 100% undetectable --- until they're not...
[edit * thanks for the spelling correction, edgewalker]
Thursday, June 29, 2006
Wednesday, June 28, 2006
the blue pill is hard to swallow
i've blogged before about virtual machine based stealthkits and i was pretty dismissive of the idea so you might think there was nothing more for me to say about the subject now that another one has been proposed (except maybe to say "not another one!")...
well here's my mea culpa... while the method of booting clean to get a baseline snapshot of the system to compare to when trying to generically detect the presence of active stealth techniques (outside-the-box cross-view difference detection) is still quite effective against conventional stealth malware, joanna rutkowska presents an idea for stealth where that just won't work... in memory only malware won't be found on the disk after a clean boot so the outside-the-box method won't work... also, stealth born out of moving the entire operating system into a virtualization layer (vm-based stealth) has the potential to make the malware invisible in memory - so it would seem like it's the perfect stealth...
and indeed it's getting called completely undetectable, but for me that's a little hard to swallow so i got to thinking - how would you attack something like this?.. the best way to attack malware is to find some scenario where it's not in control... clean booting doesn't get us there in this case because the malware will be entirely gone so there won't be anything to find... in-situ cross-view analysis won't work either because everything's within the malware's virtualization layer...
but what if something wasn't inside the malware's virtualization layer? in fact, what if the malware itself got executed inside of a virtualized system? a sandbox using virualization technology as advanced as that which the malware uses, designed not to do bad things but rather to look for the tell-tale signs of active stealth (especially vm-based stealth)...
if undetectable virtualization technology can be used to hide the presence of malware, then equally undetectable virtualization technology pre-emptively deployed on the system should be able to detect the undetectable vm-based stealth malware if/when it is encountered...
well here's my mea culpa... while the method of booting clean to get a baseline snapshot of the system to compare to when trying to generically detect the presence of active stealth techniques (outside-the-box cross-view difference detection) is still quite effective against conventional stealth malware, joanna rutkowska presents an idea for stealth where that just won't work... in memory only malware won't be found on the disk after a clean boot so the outside-the-box method won't work... also, stealth born out of moving the entire operating system into a virtualization layer (vm-based stealth) has the potential to make the malware invisible in memory - so it would seem like it's the perfect stealth...
and indeed it's getting called completely undetectable, but for me that's a little hard to swallow so i got to thinking - how would you attack something like this?.. the best way to attack malware is to find some scenario where it's not in control... clean booting doesn't get us there in this case because the malware will be entirely gone so there won't be anything to find... in-situ cross-view analysis won't work either because everything's within the malware's virtualization layer...
but what if something wasn't inside the malware's virtualization layer? in fact, what if the malware itself got executed inside of a virtualized system? a sandbox using virualization technology as advanced as that which the malware uses, designed not to do bad things but rather to look for the tell-tale signs of active stealth (especially vm-based stealth)...
if undetectable virtualization technology can be used to hide the presence of malware, then equally undetectable virtualization technology pre-emptively deployed on the system should be able to detect the undetectable vm-based stealth malware if/when it is encountered...
Tuesday, June 13, 2006
surprised by malicious software removal tool statistics
if you follow such things, i'm sure you've seen quite a few posts about microsoft's new malicious software removal tool study...
of course some folks can't manage to properly interpret the stats in it, prompting microsoft to issue a clarification (they did not find bots on ~60% of all computers scanned, only on ~60% of computers they cleaned), but i can sort of see where those people are coming from... we've sort of become accustomed to the idea that malware really is that prevalent - that's certainly the message the media has been pushing for a long time... microsoft's study is saying something very different, however:
now, i imagine if microsoft agreed to add detection/removal for their own spyware the percentage would be much higher so there might arguably be an issue of malware prevalence being under reported in order to allow practices that would result in most other supposed security vendors being labelled rogue...
another reason to suspect under reporting is that microsoft is complaining about the difficulty of dealing with tens of thousands of peices of malware when the anti-virus industry has been dealing with hundreds of thousands of peices of malware for some time now:
i don't know, maybe microsoft's numbers are right... there's not a lot to compare them to - i haven't really seen similar types of metrics coming out of other vendors for the most part (probably because most vendors' products don't report their results back to their creator(s) ... and why does microsoft's do that again?)...
if the numbers are right, it certain adds a new perspective on things... but as with all statistics it needs to be taken with a grain of salt...
of course some folks can't manage to properly interpret the stats in it, prompting microsoft to issue a clarification (they did not find bots on ~60% of all computers scanned, only on ~60% of computers they cleaned), but i can sort of see where those people are coming from... we've sort of become accustomed to the idea that malware really is that prevalent - that's certainly the message the media has been pushing for a long time... microsoft's study is saying something very different, however:
As of the writing of this report, Microsoft has shipped 15 additional enhanced versions of the tool and continues to ship a new version on the second Tuesday of each month, each adding new prevalent malware to detect and remove. Since the initial release of the MSRT, the tool has been executed approximately 2.7 billion times by at least 270 million unique computers....
in 15 months of operation they've scanned ~270 million unique computers and removed malware from only 5.7 million?... that's just 2.1%... that seems surprisingly low to me...
The MSRT has removed 16 million instances of malicious software from 5.7 million unique Windows-based computers over the past 15 months. On average, the tool removes at least one instance of malware from every 311 computers it runs on.
now, i imagine if microsoft agreed to add detection/removal for their own spyware the percentage would be much higher so there might arguably be an issue of malware prevalence being under reported in order to allow practices that would result in most other supposed security vendors being labelled rogue...
another reason to suspect under reporting is that microsoft is complaining about the difficulty of dealing with tens of thousands of peices of malware when the anti-virus industry has been dealing with hundreds of thousands of peices of malware for some time now:
A significant challenge we have today is the large number of active malware samples, totaling in the order of tens of thousands, and increasing rapidly.
i don't know, maybe microsoft's numbers are right... there's not a lot to compare them to - i haven't really seen similar types of metrics coming out of other vendors for the most part (probably because most vendors' products don't report their results back to their creator(s) ... and why does microsoft's do that again?)...
if the numbers are right, it certain adds a new perspective on things... but as with all statistics it needs to be taken with a grain of salt...
Friday, June 09, 2006
can joe barr's opinion of the malware industry be trusted?
well, joe barr is at it again... i've blogged about joe once before and where the previous article i wrote about seemed to just be a case of false authority syndrome, this new one about whether the anti-malware industry can be trusted seems to be a more deliberate smear campaign...
when he's not throwing out non-sequiturs like what happened to dan greer formerly of @stake (which isn't really part of the anti-malware industry), he's redressing other non-sequiturs to look like they're actually relevant... for example:
then there's innuendo about timing things specifically to make OSX look bad:
there's some crazy re-interpreting of that same report, too:
the real meat of the article doesn't come until the section entitled "From Russia with malice", however... joe barr clearly has a venomous contempt for kaspersky labs, he goes on and on about supposed wrong-doings, such as:
of course, since he was chronicling all the perceived misdeeds of kaspersky he had to include 'the case of the non-viral virus' that i de-debunked previously, but then he goes on to describe his disbelief over their linux malware report that showed there were 91 viruses for the linux platform:
his final bit of evidence against kaspersky came from the recently noted intended macro virus which caused the confusion i wrote about earlier:
joe barr concludes that the anti-malware industry cannot be trusted and he attributes all these misdeeds to a desire for more money - so what should we attribute joe barr's misdeeds (ie. his FUD) to?
when he's not throwing out non-sequiturs like what happened to dan greer formerly of @stake (which isn't really part of the anti-malware industry), he's redressing other non-sequiturs to look like they're actually relevant... for example:
US-Cert knows about the problem of the super-inflated malware numbers in their summary,except that cert doesn't count malware, they count vulnerabilities - ergo what cert is or isn't doing, what they do or don't know has no bearing on whether the anti-malware industry can be trusted...
then there's innuendo about timing things specifically to make OSX look bad:
The SANS Institute, -- a name which sounds all officious and possibly not profit oriented, but which is owned by the mysterious but definitely for-profit Escal Institute of Technology -- recently did an unusual update to its Top 20 list of vulnerabilities.what mr.barr fails to acknowledge, however, is that there's a 3rd event in this coincidence - that being the dramatic change in the security landscape of OSX around the same time... 2 viruses and a spate serious vulnerabilities - issuing a report to inform people of the new state of things was a responsible thing for SANS to do...
They issued their "update" in order to trumpet the assertion that Apple OS X is now just as exposed and vulnerable to malware as Windows. The timing of the release of this unusual "update" is suspicious, coming as it did on the eve of the new advertising campaign by Apple which plays up the fact that Apple is pretty much immune to the types of malware infestations that plague Windows. Previous updates to this list have usually come in the fall: November, 2005; October, 2004; October, 2003; and October, 2002.
there's some crazy re-interpreting of that same report, too:
The SANS Institute announcement seemed to be designed to destroy -- or at least bring into question -- the idea that Apple OS X is more secure than Windows. In a document sent to members of the press prior to the teleconference, the SANS Institute wrote:now, how exactly can the report destroy or bring into question the idea that OSX is more secure than windows when his own quote of the report explicitly says that OSX is still safer than windows? and his later jab (by way of quoting a 3rd party) at the supposed claim that OSX's security reputation is in tatters? the quote clearly shows that the report said OSX's reputation for being bullet-proof was in tatters - which it is... it can't be considered bullet-proof anymore, it's been proven that it's not totally immune to threats...During the past few months, Apple Safari browser users faced their first zero-day attack. A zero-day attack is one that causes damage to users even before the vendor makes a patch available. In this case, Safari users who just browsed a malicious web site found their computers automatically downloading and executing a malicious file. The user made no error other than to visit the web site. Apple patched Safari to fix this flaw, but almost immediately had to issue a second patch to stop another attack involving email attachments. The experts involved in the 2006 Top 20 Spring update agree that OS/X still remains safer than Windows; but its reputation for offering a bullet-proof alternative to Windows is in tatters. As attackers are increasingly turning their attention to the platform, OS/X vulnerabilities are being discovered at a rapid pace, which could erode this safety in the future.
the real meat of the article doesn't come until the section entitled "From Russia with malice", however... joe barr clearly has a venomous contempt for kaspersky labs, he goes on and on about supposed wrong-doings, such as:
Kaspersky Lab, a Russian Internet security company which operates around the globe, including here in the USA, has been spreading FUD about malware targeting Linux for years. I've cited this example from 2001 before, but here it is again, and it still appears on their Web site. Hey, maybe the SANS Institute used it as a template for their anti-Apple effort. I quote:while one would probably not consider ramen going into the wild to be comparable with the windows worm epidemics like blaster or sasser, compared with other linux malware it was a very big deal... as for pelf, cross-platform infectors have long been considered the means by which self-replicating linux malware would become really widespread and pelf was an indication that such infectors were coming...Predictions regarding a world epidemic of Linux-viruses have come true in the first quarter of 2001. The latest incidents caused by the Ramen Internet-worm and its numerous modifications, as well as the multi-platform virus Pelf (Lindose) and other Linux-targeted malicious code, have proved that this operating system, (previously considered as the most protected software), has fallen victim to computer viruses.
of course, since he was chronicling all the perceived misdeeds of kaspersky he had to include 'the case of the non-viral virus' that i de-debunked previously, but then he goes on to describe his disbelief over their linux malware report that showed there were 91 viruses for the linux platform:
I asked Kaspersky Lab if they had any documentation to back up that claim. Jennifer Jewett, a public relations person representing Kaspersky, told me "the documentation sighting the viruses is included in the Encyclopedia on Kaspersky's Viruslist site: http://www.viruslist.com/en/viruses/encyclopedia."strangely, when i did a search for linux viruses on that site, i got 92 hits not 972... just one more than was indicated in the report - most without actual descriptions but at least they include the aliases that other products use so that one can corroborate their existence... is he incapable of using a search engine or just so biased against kaspersky that he can't manage due dilligence? he knew the result set shouldn't have been anywhere near that big, he should have refined his search to narrow it down to just viruses (972 would have been the list of all linux malware, not just viruses, though the number now stands at 976 and will probably change again as time wears on)...
I searched the encyclopedia for Linux viruses and came up with an astounding 972 hits. But just the barest hint of an analysis of those hits reveal that the number would break an industrial-strength bogusity-meter.
his final bit of evidence against kaspersky came from the recently noted intended macro virus which caused the confusion i wrote about earlier:
After this story was submitted, and the week following another black-eye for Microsoft security in the form of malevolent macros in MS Word, Kaspersky Lab issued another headline-grabbing but bogus alert for a proof-of-concept of the same type of attack on MS Word's largest competitor, OpenOffice.org. Was the timing once more just a coincidence? I don't think so.since the existence of the malware was independently confirmed and since kaspersky labs didn't create it themselves, the timing was entirely out of their hands... it gets discovered when it gets discovered... should they have kept the first openoffice malware a secret? would it have really served the public to sit on the fact that openoffice is now being targeted by at least one malware writer? somehow that doesn't seem likely...
joe barr concludes that the anti-malware industry cannot be trusted and he attributes all these misdeeds to a desire for more money - so what should we attribute joe barr's misdeeds (ie. his FUD) to?
Thursday, June 08, 2006
mcafee on the possibility of cell phone stealthkits
the mcafee avert blog has a post on it expressing concerns that the recent release of symbian ROM images and research may lead to the development of stealthkits (what mcafee and most of the rest of the industry are currently referring to as rootkits) for cell phones...
after their stealthkit report of a couple of months ago it would be easy to interpret their newly expressed concern as meaning they feel that the ROMs and research should not have been released...
i don't know if that was actually the intention of the mcafee blogger in question, but just in case: you cannot use the threat that security research could be used for nefarious purposes as a means to justify stifling the public dissemination of any arbitrary type of security research...
while it is a risk in all public disclosure of security research, only some types of research documents (generally actual malware) fail to give the security benefits when shared publicly that justify public disclosure... i may have agreed with the sentiment from mcafee that stealthkit disclosure shouldn't be afforded the same respect that normal full disclosure enjoys, but i think this case (that doesn't disclose actual malware but just research that malware creators might be able to use) legitimately falls under full disclosure... there are plenty of security benefits that can be had by examining the symbian OS...
after their stealthkit report of a couple of months ago it would be easy to interpret their newly expressed concern as meaning they feel that the ROMs and research should not have been released...
i don't know if that was actually the intention of the mcafee blogger in question, but just in case: you cannot use the threat that security research could be used for nefarious purposes as a means to justify stifling the public dissemination of any arbitrary type of security research...
while it is a risk in all public disclosure of security research, only some types of research documents (generally actual malware) fail to give the security benefits when shared publicly that justify public disclosure... i may have agreed with the sentiment from mcafee that stealthkit disclosure shouldn't be afforded the same respect that normal full disclosure enjoys, but i think this case (that doesn't disclose actual malware but just research that malware creators might be able to use) legitimately falls under full disclosure... there are plenty of security benefits that can be had by examining the symbian OS...
Wednesday, June 07, 2006
the stardust dustup
i've been seeing a number of posts like this lately, talking about how the new staroffice/openoffice macro virus is just hype...
statements like this are really telling:
there's lots of talk about how kaspersky labs is misleading the public and hyping up a non-existent threat... about how nothing in stardust is really new and how it's not really a vulnerability but rather a misuse of legitimate functionality... well, here's the thing:
statements like this are really telling:
In a statement prominently displayed on the OpenOffice.org home page, the group also disputes applying the label “virus” to Stardust, the proof-of-concept exploit discovered last week by Kaspersky Labs.you see, stardust is an intended virus as mentioned by both mcafee and kaspersky... unfortunately, kaspersky labs didn't mention it was broken in their first blog post on it, only in the actual encyclopedia description which the media (mainstream and blogosphere alike) didn't bother to read and/or understand, thus necessitating the second blog post to clarify the issue...
there's lots of talk about how kaspersky labs is misleading the public and hyping up a non-existent threat... about how nothing in stardust is really new and how it's not really a vulnerability but rather a misuse of legitimate functionality... well, here's the thing:
- while it's true kasperky labs could have made a more informative blog post the first time 'round, the place where they said further details would be clearly stated the virus was broken...
- what's new here is that someone is trying to write viruses for the staroffice/openoffice platform and they may eventually succeed or someone else may fix the bugs in the current attempts and thereby succeed in making a virus for that platform... stardust is the first attempt, and the fact that someone is making that attempt is new and newsworthy... there might not be an actual virus yet, but one (or more) is coming...
- of course it's just a misuse of legitimate functionality - that's true for viruses in general... they aren't made possible only because of security defects, they're inherent to the general purpose computing platform and if you're going to provide a reasonably powerful macro programming facility in your office suite you're going to invariably wind up supporting macro viruses...
what is a macro virus?
a macro virus is a virus written in a macro programming language (a programming language for embedding simple programs within documents)...
most (but not all) macro viruses are written to operate in microsoft applications such as word or excel or powerpoint... these macro viruses contain one or more macros with the same name as a macro that is built into the microsoft application they're running under... then, when the ms application tries to execute it's own macro it finds the one in the document first and executes it (which makes it kind of like a companion infection technique)... since the applications in question have macros for all kinds of standard functions (like file->save or file->open) macro viruses don't have any trouble getting executed...
although it is often said that macro viruses infect documents this does not mean it's a type of virus that infects data... for one thing word/excel/powerpoint (OLE2) documents are not pure data - they're more like little file systems that contain both data and (macro) programs, not unlike your C: drive... so when someone says "my document is infected with a virus" it's comparable to the colloquialism "my computer is infected with a virus"... also, technically what a macro virus is infecting is another macro...
additionally, the operating system that uses those little file systems is the ms application that opens the document - that's why macro viruses can often operate on both windows and macs without being classified cross-platform... whether it's a windows machine or a mac machine a word macro virus runs on the ms word platform...
back to index
most (but not all) macro viruses are written to operate in microsoft applications such as word or excel or powerpoint... these macro viruses contain one or more macros with the same name as a macro that is built into the microsoft application they're running under... then, when the ms application tries to execute it's own macro it finds the one in the document first and executes it (which makes it kind of like a companion infection technique)... since the applications in question have macros for all kinds of standard functions (like file->save or file->open) macro viruses don't have any trouble getting executed...
although it is often said that macro viruses infect documents this does not mean it's a type of virus that infects data... for one thing word/excel/powerpoint (OLE2) documents are not pure data - they're more like little file systems that contain both data and (macro) programs, not unlike your C: drive... so when someone says "my document is infected with a virus" it's comparable to the colloquialism "my computer is infected with a virus"... also, technically what a macro virus is infecting is another macro...
additionally, the operating system that uses those little file systems is the ms application that opens the document - that's why macro viruses can often operate on both windows and macs without being classified cross-platform... whether it's a windows machine or a mac machine a word macro virus runs on the ms word platform...
back to index
Tuesday, June 06, 2006
what is a companion virus?
a companion virus is a virus that exists as a separate (companion) program to the host program...
it may not be obvious how something like this would be able to meet the definine criteria of a virus and may sound more like a worm, however a companion virus is able to infect host programs without modifying their contents (that is how they can be separate programs)... it does this by taking advantage of operating system features that allow it to be executed instead of it's host program...
for example - in DOS if you type a program name without specifying the path and that program happens to not be in the current directory, DOS will search each directory in your PATH sequentially until it finds a program with that name or it reaches the end of your PATH... a path companion virus need only assume the same name as an existing program on your computer but place itself in a directory closer to the beginning of your PATH so that DOS finds the viral program first and executes it instead of the program the user intended...
another type of companion infection utilizes the fact that if a program name is specified without a file extension, DOS will look for *.com files before it looks for *.exe files so the virus need only copy itself as ProgramName.com in the same directory as the original ProgramName.exe in order to get executed...
some flavours of *nix (as well as some alternative DOS shells) have a command alias facility that can also be used for companion infection...
additionally, a virus could rename or make a backup copy of the host program and then replace the original with itself and be yet another kind of companion virus...
the original program is generally retained so that the companion virus can execute it after the virus itself gets executed - this makes the system appear to behave properly since the program you intended to execute does get executed....
back to index
it may not be obvious how something like this would be able to meet the definine criteria of a virus and may sound more like a worm, however a companion virus is able to infect host programs without modifying their contents (that is how they can be separate programs)... it does this by taking advantage of operating system features that allow it to be executed instead of it's host program...
for example - in DOS if you type a program name without specifying the path and that program happens to not be in the current directory, DOS will search each directory in your PATH sequentially until it finds a program with that name or it reaches the end of your PATH... a path companion virus need only assume the same name as an existing program on your computer but place itself in a directory closer to the beginning of your PATH so that DOS finds the viral program first and executes it instead of the program the user intended...
another type of companion infection utilizes the fact that if a program name is specified without a file extension, DOS will look for *.com files before it looks for *.exe files so the virus need only copy itself as ProgramName.com in the same directory as the original ProgramName.exe in order to get executed...
some flavours of *nix (as well as some alternative DOS shells) have a command alias facility that can also be used for companion infection...
additionally, a virus could rename or make a backup copy of the host program and then replace the original with itself and be yet another kind of companion virus...
the original program is generally retained so that the companion virus can execute it after the virus itself gets executed - this makes the system appear to behave properly since the program you intended to execute does get executed....
back to index
what are intended viruses?
an intended virus (or sometimes just intended) is a piece of malware that would have been a virus were it not for bugs that prevent it from fulfilling the basic requirements of a virus... in other words, it's something that would have been a virus if it weren't broken...
an intended may have a payload that may still work (to a greater or lesser degree) so it may still qualify as some other form of malware, such as a trojan or rat or keylogger or any number of other malware types...
additionally, although the current version is only an intended virus, a future version will probably be a real virus because viruses tend to get refined over time...
back to index
an intended may have a payload that may still work (to a greater or lesser degree) so it may still qualify as some other form of malware, such as a trojan or rat or keylogger or any number of other malware types...
additionally, although the current version is only an intended virus, a future version will probably be a real virus because viruses tend to get refined over time...
back to index
Sunday, June 04, 2006
greg hoglund thinks rootkits AREN'T malware
that was just about the funniest thing i've read all day... greg hoglund, of rootkitDOTcom fame, has written a little piece about the threat posed by the fact that the malware term (rootkit) he and his 'rootkit' community hijacked so many years ago is getting associated with malware... well duh!
he starts out with a straight-forward statement:
he goes on to say:
some of the things he's written are just wacky, like:
another off the wall statement is the following:
hiding things is an ethical issue, and he recognizes that when he writes:
he ends off with:
he starts out with a straight-forward statement:
Rootkits are under attack in the press and it’s very important for the rootkit community to stand up for their technology.and that statement happens to be correct, the media are vilifying stealthkits (what passes for a rootkit now-a-days)... they've got a good reason, though - stealth is being used almost exclusively for bad deeds, be it in spyware or botnets or DRM...
he goes on to say:
Rootkits are about hiding data. There are legitimate reasons to hide data both personally and in the enterprise.which i agree with to a point, there are circumstances where you want to prevent idle tampering by some users in order to keep them from damaging the system, but the stealth technology he's talking about goes far beyond that - it hides things even from the administrator and there's no justification for that...
some of the things he's written are just wacky, like:
Many people are implying that rootkits are inherently deceptive. Deceptive is a strong word, too strong. Deception is an intent, not a technology.the technology manipulates part of the system in order to make it lie to other parts of the system and/or the user about what is really there... i can't see how one would not interpret lying and manipulation as deception...
another off the wall statement is the following:
Rootkits would be unnecessary if the operating system already had reliable data hiding features. Current operating system security controls, such as the “hidden” property on a file, are easily defeated. Overall, the operating system does not supply the required architecture enabling us to hide data.apparently hoglund has never heard of file system permissions, a feature available on NTFS as well as most *nix-related file systems... sure the administrator can bypass those - because s/he's the administrator... the administrator of a machine has legitimate authority to control what goes on on that machine - i don't care what you think your stealth technology may be protecting, your right to protect it does not supersede the rights of the system administrator to control that machine (a variation on the "your right to swing your fists ends at my nose")... of course file system permissions are not totally secure - but then again, nothing is... barring exploits or configuration errors, a more limited user should not be able to bypass the restrictions enabled through file system permissions and that should be as reliable as any stealthkit...
hiding things is an ethical issue, and he recognizes that when he writes:
The ethical question tends to orbit the idea of “user control”. Some people argue that because rootkits thwart user control, they are unethical. But there is a very simple answer to this: if a rootkit can be removed from a system (by authorized personell) with no long lasting repercussion upon the system then user-control is maintained. Of course, the employee might not agree, but they are not the user in this case. The administrators of the network are the legitimate users and they never lose control.but what he doesn't seem to realize is that when the stealthkit hides things from even the administrator, regardless of whether or not the administrator can remove it, the administrator has lost control... removing the malware is just an attempt at regaining control, not an indication that control was never lost... while it was hiding things (from even the administrator) there are all kinds of things it could have done that could go undetected and remain that way once removed like leaking sensitive information, giving remote access to a 3rd party, or carrying out various types of network attacks... none of those things would have long lasting repercussions that could be directly linked with the stealth technology with any degree of certainty...
he ends off with:
The rootkit community contributes a wealth of information and capabilities for those of us who protect networks and data. Rootkits are as good as you want them to be.but when he also says things like:
Rootkits are largely security through obscurity.and:
As usual, we have to take measures of control based on security through obscurity (which, debatedly, is the most effective kind of security - supposedly secure non-obscure systems have been exploited ad nauseum).you better believe we don't want that kind of protection for our data and networks... i mean come on, security through obscurity? is someone unfamiliar with shannon's maxim? stealth security absolutely is an obscurity-based attempt at security, he's right about that, but thinking that we'd want that (or worse that it's actually effective?) is absurd...
Wednesday, May 31, 2006
what is an expert?
an expert is someone that YOU feel has advanced knowledge or skills in a certain field...
the classification is an entirely subjective and personal matter... calling someone an expert is a sign of respect that a person or persons can show to another person, however there are certain ways in which the label can lose it's meaning...
one way the title of the title of expert can lose it's meaning is when the the person holding the title of expert gave him/herself that title... this is the self-proclaimed expert that most people recognize as not being a REAL expert, at least when they recognize that the title was self-given... you see it's easy to identify a self-proclaimed expert when the person actually calls themself an expert, but it can much harder to identify them when they simply act like they're experts... one tell tale sign of an implicit self-proclaimed expert is making claims and then failing to back them up in a reasonable and logical way... it's not always so clear, however, so the line between the implicit self-proclaimed expert and the person who is just confident that s/he is right can become quite blurred... that's one of the reasons why i occasionally take it upon myself to explicitly state that i am not an expert, so that people won't mistake me for a self-proclaimed (or even real) expert...
another way the title of expert can lose it's meaning is when it's applied through the 'friend of a friend' approach... this is where person A says person B is an expert and instead of taking that declaration with a grain of salt (as one should) and determining for yourself if person B really deserves to be called an expert, you simply take person A's word for it for whatever reason... this effectively gives person B respect (your respect) that person B hasn't earned - and respect is something that should definitely be earned, not just given away...
back to index
the classification is an entirely subjective and personal matter... calling someone an expert is a sign of respect that a person or persons can show to another person, however there are certain ways in which the label can lose it's meaning...
one way the title of the title of expert can lose it's meaning is when the the person holding the title of expert gave him/herself that title... this is the self-proclaimed expert that most people recognize as not being a REAL expert, at least when they recognize that the title was self-given... you see it's easy to identify a self-proclaimed expert when the person actually calls themself an expert, but it can much harder to identify them when they simply act like they're experts... one tell tale sign of an implicit self-proclaimed expert is making claims and then failing to back them up in a reasonable and logical way... it's not always so clear, however, so the line between the implicit self-proclaimed expert and the person who is just confident that s/he is right can become quite blurred... that's one of the reasons why i occasionally take it upon myself to explicitly state that i am not an expert, so that people won't mistake me for a self-proclaimed (or even real) expert...
another way the title of expert can lose it's meaning is when it's applied through the 'friend of a friend' approach... this is where person A says person B is an expert and instead of taking that declaration with a grain of salt (as one should) and determining for yourself if person B really deserves to be called an expert, you simply take person A's word for it for whatever reason... this effectively gives person B respect (your respect) that person B hasn't earned - and respect is something that should definitely be earned, not just given away...
back to index
Tuesday, May 30, 2006
flame on dick morrell
dick morrell has been having a little email argument with someone via his blog here and here over mr. morrell's views on okopipi...
in the first one, rather than address points made by the emailer, morrell laughs at the emailer for not being able to figure out how to jump through the necessary hoops in order to leave an actual comment on the blog... the hoops are there to prevent blog spam, i can understand why a so-called anti-spam expert would want to prevent blog spam, but the hoops are non-obvious as i soon found out... it's not enough to enter your name, email address, webpage, comment, and captcha code in the comment entry webform like you would for most other blogs - no, for this one you have to hunt down the login link, create a user account, check your email for the password, go back and log on, and then enter your name, email address, webpage, comment and captcha code... i went through all of those steps and then left a comment to the effect that perhaps the emailer failed to figure out the comment process because the comment process was non-obvious... nothing particularly unfriendly in pointing out the user experience of his blog could use some work - heck, just putting a login link in the comment webform area would have probably made a huge improvement...
in the second one morrell pulls the old who does he think he's talking to routine, again instead of addressing the emailer's points... for this one i didn't pull any punchs - i plainly stated that the emailer was talking to someone who was clearly too full of their own self-importance to do anything other than say "i'm an expert and i say it's like this"... i pointed out that just because he was supposedly an expert that it doesn't mean his claims don't need to be backed up, and then i called him on his support of gadi evron's FUD and his own smearing of the principals involved in okopipi...
and he deleted my comments... both of them as i turns out... and what's more he sent me email - not to the anonymous email address i entered (to avoid spam) in the comment webform but rather to the disposable email address i had to use (to avoid spam) instead when creating a user account in order to keep the password secret (i wouldn't want someone reading the email to the anonymous email address and posing as me)... the email went something like (but not exactly like, since unlike mr. morrell i follow the letter of rfc1855 so i'm paraphrasing here) this:
ok, first of all respect is something you earn, not something that's given to you and certainly not something you take as an entitlement for being a so-called expert... second, who do you think you're talking to, dick? "my team"? what team? i'm not part of okopipi, i'm just someone who thinks you and gadi need to explain yourselves and support the claims you've made with logically valid arguments - just being an 'expert' isn't enough...
but wait, there's more... not long after he sent a second email that went a little like this:
[sarcasm]no... deleting my comments doesn't breach freedom of speech at all...[/sarcasm]
if you really supported freedom of speech you wouldn't delete comments that were 'undesirable' to you... clearly if i want freedom of speech i'm going to have to take it thusly... and as for knocking my use of a disposable email address - are you for real? stand up and be counted my ass, it's a farking anti-spam measure and a real anti-spam expert should have respected that...
then again, a real anti-spam expert should probably have also thought twice about sending me unwanted email in the first place... i don't appreciate the out-of-band communication, dick - if you wanted to engage me in discussion you should have responded to my comments where i left them... i didn't enter an address into your blog's anti-spam system so that you could send me patronizing email that i don't want, i entered it because i was forced to, because it was the only way to leave a comment... you abused that information... it's a good thing i anticipated that and used a disposable address - consider that address disposed of...
in the first one, rather than address points made by the emailer, morrell laughs at the emailer for not being able to figure out how to jump through the necessary hoops in order to leave an actual comment on the blog... the hoops are there to prevent blog spam, i can understand why a so-called anti-spam expert would want to prevent blog spam, but the hoops are non-obvious as i soon found out... it's not enough to enter your name, email address, webpage, comment, and captcha code in the comment entry webform like you would for most other blogs - no, for this one you have to hunt down the login link, create a user account, check your email for the password, go back and log on, and then enter your name, email address, webpage, comment and captcha code... i went through all of those steps and then left a comment to the effect that perhaps the emailer failed to figure out the comment process because the comment process was non-obvious... nothing particularly unfriendly in pointing out the user experience of his blog could use some work - heck, just putting a login link in the comment webform area would have probably made a huge improvement...
in the second one morrell pulls the old who does he think he's talking to routine, again instead of addressing the emailer's points... for this one i didn't pull any punchs - i plainly stated that the emailer was talking to someone who was clearly too full of their own self-importance to do anything other than say "i'm an expert and i say it's like this"... i pointed out that just because he was supposedly an expert that it doesn't mean his claims don't need to be backed up, and then i called him on his support of gadi evron's FUD and his own smearing of the principals involved in okopipi...
and he deleted my comments... both of them as i turns out... and what's more he sent me email - not to the anonymous email address i entered (to avoid spam) in the comment webform but rather to the disposable email address i had to use (to avoid spam) instead when creating a user account in order to keep the password secret (i wouldn't want someone reading the email to the anonymous email address and posing as me)... the email went something like (but not exactly like, since unlike mr. morrell i follow the letter of rfc1855 so i'm paraphrasing here) this:
i've deleted your comments because you don't show the proper respect for me or gadi or any of the other people who work really hard to stop spammers the correct way.
i have a lot more experience than you or any of your team on . . .
ok, first of all respect is something you earn, not something that's given to you and certainly not something you take as an entitlement for being a so-called expert... second, who do you think you're talking to, dick? "my team"? what team? i'm not part of okopipi, i'm just someone who thinks you and gadi need to explain yourselves and support the claims you've made with logically valid arguments - just being an 'expert' isn't enough...
but wait, there's more... not long after he sent a second email that went a little like this:
i hope you don't think my deleting your comments breaches the freedom of speech i support.
the email address you use [place disposable email address here] says it all.
stand and be counted and have a reasonable discussion instead of acting like some guy sitting in his darkened room in front of a glowing computer monitor.
[sarcasm]no... deleting my comments doesn't breach freedom of speech at all...[/sarcasm]
if you really supported freedom of speech you wouldn't delete comments that were 'undesirable' to you... clearly if i want freedom of speech i'm going to have to take it thusly... and as for knocking my use of a disposable email address - are you for real? stand up and be counted my ass, it's a farking anti-spam measure and a real anti-spam expert should have respected that...
then again, a real anti-spam expert should probably have also thought twice about sending me unwanted email in the first place... i don't appreciate the out-of-band communication, dick - if you wanted to engage me in discussion you should have responded to my comments where i left them... i didn't enter an address into your blog's anti-spam system so that you could send me patronizing email that i don't want, i entered it because i was forced to, because it was the only way to leave a comment... you abused that information... it's a good thing i anticipated that and used a disposable address - consider that address disposed of...
Sunday, May 28, 2006
the merits of the blue security anti-spam approach
if you hire someone to send a million messages on your behalf, you better be prepared for a million responses...
that was the gist of blue security's blue frog anti-spam technology, and it's the approach that okopipi hopes to build upon... i posted about blue security going down for the count previously and i predicted that a group like okopipi would try and fill blue security's shoes (not through any sort of precience, mind you, but rather just because it would have fit an established pattern of human behaviour), but it seems okopipi have stirred up a hornet's nest of controversy in the process...
let's look at the criticisms... the one with the most technical merit concerns the anti-spam registry that the blue security approach had... essentially it was a list of hashes of email addresses that the spammers could use to remove blue frog users from their spam lists... the fact that email addresses were hashed (a non-reversible transformation) prevented spammers from finding any new addresses directly from the registry, however it did allow them to identify which addresses in their own spam lists were blue frog users and that allowed them to retaliate against those users... however there is no way to tell spammers which email addresses to remove without identifying those email addresses - the only alternative is to not offer the spammers any kind of remediation process at all and say "sucks to be you", which clearly would have had much worse chances of a productive outcome... a zero tolerance approach may be safer for the users, but it can't get their names removed from the spammers' lists - it's predicated on getting the spammers to give up their business entirely instead of simply adjusting their approach and i suspect that nobody is that persuasive...
another criticism is that the blue security approach could be used against innocent merchants... the idea was that if one sent out spam advertising a competitor, that competitor would then have to deal with a deluge of complaints they could do nothing about.... this rose out of the more general concern about whether it's possible for blue frog to target the wrong site and what happens then... the thing is, blue frog could only send complaints to sites that blue security enabled it to and blue security took pains to confirm that those sites were appropriate places to lodge complaints... the process they followed can be reviewed here...
[edited to add this paragraph] still another criticism is that sites are hosted on hacked machines and just move around from one hacked machine to another... that kind of thing can be detected, however, since blue security contacted the isp as well as the merchant site... also, a fly-by-night operation wouldn't have gone unnoticed with an examination period exceeding 10 days... if the site was one that didn't stick around for at least a couple days blue security would have had no reason to develop a script to send complaints to it...
there's also a criticism that sending opt-out requests to the merchant sites constituted a DDoS... this is a rather ridiculous thing to say - each person who receives a spam has a right to complain about it, and since the spammer was merely acting as an agent of the merchant when s/he sent out the spam (and since the spammers go to great lengths to not be reachable themselves) the merchant is the appropriate entity to address one's complaints to... at most one opt-out would be sent per spam the blue frog user received and each opt-out was a response to an incomming spam message... while that may result in service disruptions for the merchant, it's no different than if each spam recipient manually went to the merchant's site and complained (and lets face it, the spam invites each recipient to visit the merchant's site)... the blue frog cleint automated the process of filing a complaint initiated by the user, nothing more...
an even more outlandish claim is that the blue frog clients installed on user machines constituted a botnet... a botnet is ultimately controlled by a central controller, a bot master... the blue frog clients were operated by the blue frog users themselves, not blue security - blue security just sent out updates to those clients (which included instructions on how to send the complaints but not instructions to actually send them)... these kinds of claims by so-called security experts are pure FUD... those spreading the FUD appear to be parroting the opinions of others and simply claim there is universal agreement rather than actually backing up their claims - that kind of argumentation is fallacious and hopefully more people will be able to see that now...
blue security's approach was designed in such a way that the easiest way to resolve the problem was to remove the specified addresses from their spam lists (and they had safeguards in place to prevent their system from being abused to hurt legitimate merchants) - unfortunately while we as humans often take the easiest way out sometimes we don't and that manifested itself in this case in a significant DDoS attack against blue security (bringing down their website and service) and it's users (sending them orders of magnitude more junk mail than usual)... some spammers didn't like being told what to do and and had the means to retaliate and now blue security is no more... okopipi hopes to develop a similar system but one that is less prone to attack (though nothing is invulnerable)... i hope they employ equivalent safeguards against abuse and if so, more power to them...
that was the gist of blue security's blue frog anti-spam technology, and it's the approach that okopipi hopes to build upon... i posted about blue security going down for the count previously and i predicted that a group like okopipi would try and fill blue security's shoes (not through any sort of precience, mind you, but rather just because it would have fit an established pattern of human behaviour), but it seems okopipi have stirred up a hornet's nest of controversy in the process...
let's look at the criticisms... the one with the most technical merit concerns the anti-spam registry that the blue security approach had... essentially it was a list of hashes of email addresses that the spammers could use to remove blue frog users from their spam lists... the fact that email addresses were hashed (a non-reversible transformation) prevented spammers from finding any new addresses directly from the registry, however it did allow them to identify which addresses in their own spam lists were blue frog users and that allowed them to retaliate against those users... however there is no way to tell spammers which email addresses to remove without identifying those email addresses - the only alternative is to not offer the spammers any kind of remediation process at all and say "sucks to be you", which clearly would have had much worse chances of a productive outcome... a zero tolerance approach may be safer for the users, but it can't get their names removed from the spammers' lists - it's predicated on getting the spammers to give up their business entirely instead of simply adjusting their approach and i suspect that nobody is that persuasive...
another criticism is that the blue security approach could be used against innocent merchants... the idea was that if one sent out spam advertising a competitor, that competitor would then have to deal with a deluge of complaints they could do nothing about.... this rose out of the more general concern about whether it's possible for blue frog to target the wrong site and what happens then... the thing is, blue frog could only send complaints to sites that blue security enabled it to and blue security took pains to confirm that those sites were appropriate places to lodge complaints... the process they followed can be reviewed here...
[edited to add this paragraph] still another criticism is that sites are hosted on hacked machines and just move around from one hacked machine to another... that kind of thing can be detected, however, since blue security contacted the isp as well as the merchant site... also, a fly-by-night operation wouldn't have gone unnoticed with an examination period exceeding 10 days... if the site was one that didn't stick around for at least a couple days blue security would have had no reason to develop a script to send complaints to it...
there's also a criticism that sending opt-out requests to the merchant sites constituted a DDoS... this is a rather ridiculous thing to say - each person who receives a spam has a right to complain about it, and since the spammer was merely acting as an agent of the merchant when s/he sent out the spam (and since the spammers go to great lengths to not be reachable themselves) the merchant is the appropriate entity to address one's complaints to... at most one opt-out would be sent per spam the blue frog user received and each opt-out was a response to an incomming spam message... while that may result in service disruptions for the merchant, it's no different than if each spam recipient manually went to the merchant's site and complained (and lets face it, the spam invites each recipient to visit the merchant's site)... the blue frog cleint automated the process of filing a complaint initiated by the user, nothing more...
an even more outlandish claim is that the blue frog clients installed on user machines constituted a botnet... a botnet is ultimately controlled by a central controller, a bot master... the blue frog clients were operated by the blue frog users themselves, not blue security - blue security just sent out updates to those clients (which included instructions on how to send the complaints but not instructions to actually send them)... these kinds of claims by so-called security experts are pure FUD... those spreading the FUD appear to be parroting the opinions of others and simply claim there is universal agreement rather than actually backing up their claims - that kind of argumentation is fallacious and hopefully more people will be able to see that now...
blue security's approach was designed in such a way that the easiest way to resolve the problem was to remove the specified addresses from their spam lists (and they had safeguards in place to prevent their system from being abused to hurt legitimate merchants) - unfortunately while we as humans often take the easiest way out sometimes we don't and that manifested itself in this case in a significant DDoS attack against blue security (bringing down their website and service) and it's users (sending them orders of magnitude more junk mail than usual)... some spammers didn't like being told what to do and and had the means to retaliate and now blue security is no more... okopipi hopes to develop a similar system but one that is less prone to attack (though nothing is invulnerable)... i hope they employ equivalent safeguards against abuse and if so, more power to them...
Friday, May 26, 2006
does µTorrent contain adware / spyware?
i recently became aware some controversy over the possibility that the popular bittorrent client µTorrent contains adware and/or spyware...
there are a number of threads on the µTorrent forums about so i thought i'd use this an an object lesson in how to make these determinations for yourself - and as an added bonus, we're going to do it without even downloading the software...
we can do that by looking at what the software's author had to say about the issue here...
the interesting thing (at least to me) is that there is no 3rd party adware client software - the ad-serving functionality is built by the same person(s) who built the µTorrent client... it's an option i didn't cover in my post about software developers who go the adware route but it's an important one none-the-less... if a software developer finds s/he needs ad revenue, creating the ad serving engine in-house is an excellent way to avoid the pitfalls of potentially nefarious behaviour from 3rd party adware clients... a software developer has the potential to offer users a far more benign adware client if they go this route than if they just accept whatever some 3rd party hands them...
unfortunately that potential seems to be lost in this case... for one thing, the ad-supported nature is not disclosed on the front page of the site nor on the download page - probably because the author doesn't want to admit that it's adware (just because you make it yourself doesn't mean it's not adware)... potential users need to be informed about this sort of thing, they need to be able to make an informed decision about whether they want to install software that displays ads before they download and install it... not disclosing it (whether one is in denial or for some other reason) is a breach of good faith...
the other thing that negates it's potential to be benign is the spyware issue...
there are a number of threads on the µTorrent forums about so i thought i'd use this an an object lesson in how to make these determinations for yourself - and as an added bonus, we're going to do it without even downloading the software...
we can do that by looking at what the software's author had to say about the issue here...
“Nothing is placed on the user's machine [when the NanoTorrent browser opens,]” Ludvid explains. “It's an advertisement inside the web browser only, the ad comes from a webserver owned by me, and it's removed when the window is closed. No cookies at all are installed, not even my own…The ads are generated by the script on the webserver. The µTorrent client as such does not contain any ads. They are generated by the webserver and shown through a php script to the webbrowser when the user searches.”so it does in fact display ads - and not just by accident, the browser is directed to his own site to display ads hosted there... the fact that the ads are not contained in the bittorrent client is not really an issue - adware doesn't need to contain the ads it displays, it just needs to display ads... the fact that the client isn't actually displaying the ads in a window that's part of the client itself but instead uses a browser window is also not really an issue, plenty of adware uses browser windows to display their ads (it saves them from having to reinvent the wheel)...
the interesting thing (at least to me) is that there is no 3rd party adware client software - the ad-serving functionality is built by the same person(s) who built the µTorrent client... it's an option i didn't cover in my post about software developers who go the adware route but it's an important one none-the-less... if a software developer finds s/he needs ad revenue, creating the ad serving engine in-house is an excellent way to avoid the pitfalls of potentially nefarious behaviour from 3rd party adware clients... a software developer has the potential to offer users a far more benign adware client if they go this route than if they just accept whatever some 3rd party hands them...
unfortunately that potential seems to be lost in this case... for one thing, the ad-supported nature is not disclosed on the front page of the site nor on the download page - probably because the author doesn't want to admit that it's adware (just because you make it yourself doesn't mean it's not adware)... potential users need to be informed about this sort of thing, they need to be able to make an informed decision about whether they want to install software that displays ads before they download and install it... not disclosing it (whether one is in denial or for some other reason) is a breach of good faith...
the other thing that negates it's potential to be benign is the spyware issue...
The latest version of µTorrent, version 1.5, contains an integrated search feature. The end user can opt to search several of the major search engines, such as Mininova, ThePirateBay, TorrentSpy, and isoHunt. Once the search is conducted, an independent browser window is opened. Instead of going to the Mininova.org domain however, the browser is directed to NanoTorrent.com.that basically tells me that my search queries are being sent somewhere other than the search engine they were intended for... oh, they get to their intended destination eventually, but not before going through a middle-man first... we're assured that the information is not collected or used in any way, but that's not the point (nor is it something we can verify)... spyware isn't spyware because the information it gives a 3rd party is abused, it's spyware because it gives a 3rd party (in this case nanotorrent.com, owned and operated by the same guy) your information (in this case your search queries)... personally, i would rather my search queries not go through middle-men - not because i search for things that i'd be ashamed to let others know about but rather purely on the basis of principle - what i search for is between me and my search engine of choice...
Wednesday, May 17, 2006
the future of blue security
i know it sounds like a strange subject to blog about, now that blue security has given up... the thing is, this is the internet - and i've been on the internet long enough to know that neither good ideas nor bad ideas ever happen just once... everything gets repeated - over and over and over and over and over again...
so the spammers knocked the company off the face of the web with a DDoS (distributed denial of service) attack... the very fact that they mounted such a counter attack is an indication that the technique blue security was using was working... lashing out the way they did is a sign of weakness, not strength...
unfortunately (for the spammers) the spammers are apparently unfamiliar with the streisand effect... their actions have served to advertise their vulnerability and all the people who thought blue security's idea was a good one and a bunch of new people who hadn't even heard of it before are now going to recognize that vulnerability for what it is and put that information to use...
you see, you might be able to kill a commercial venture like blue security through force and intimidation, but you can't kill an idea quite so easily... you remember what happened when the original napster went down? hundreds of knock-offs popped up in it's place and peer-to-peer filesharing has been an unstoppable hydra ever since...
it's likely that something similar will happen here with the same analysis of past efforts, identification of points of weakness, and innovation to overcome those weaknesses that continues to take place on the p2p front to this very day...
and what about that one russian spammer threatening to take down the entire internet if he can't send his spam? well let's just say that there are all kinds on the internet, and i'm not naive enough to think that there aren't some people out there that are so fed up with spam as to be willing to endure the internet version of a scorched earth in order to affect a final solution to the spam problem...
blue security may be gone, but i don't think the story is over... not by a long shot... the spammers clearly won this battle, but they may have just lost the war...
so the spammers knocked the company off the face of the web with a DDoS (distributed denial of service) attack... the very fact that they mounted such a counter attack is an indication that the technique blue security was using was working... lashing out the way they did is a sign of weakness, not strength...
unfortunately (for the spammers) the spammers are apparently unfamiliar with the streisand effect... their actions have served to advertise their vulnerability and all the people who thought blue security's idea was a good one and a bunch of new people who hadn't even heard of it before are now going to recognize that vulnerability for what it is and put that information to use...
you see, you might be able to kill a commercial venture like blue security through force and intimidation, but you can't kill an idea quite so easily... you remember what happened when the original napster went down? hundreds of knock-offs popped up in it's place and peer-to-peer filesharing has been an unstoppable hydra ever since...
it's likely that something similar will happen here with the same analysis of past efforts, identification of points of weakness, and innovation to overcome those weaknesses that continues to take place on the p2p front to this very day...
and what about that one russian spammer threatening to take down the entire internet if he can't send his spam? well let's just say that there are all kinds on the internet, and i'm not naive enough to think that there aren't some people out there that are so fed up with spam as to be willing to endure the internet version of a scorched earth in order to affect a final solution to the spam problem...
blue security may be gone, but i don't think the story is over... not by a long shot... the spammers clearly won this battle, but they may have just lost the war...
Tuesday, May 16, 2006
mcafee-siteadvisor says what about search engine results?
perhaps you've heard - search engines lead users to dangerous content... actually, that's what siteadvisor (a company and technology recently purchased by mcafee) is saying...
siteadvisor, as you may or may not know, provides technology to tell you which of the search engine results on the result page are safe and which ones aren't... they've basically come up with a list of known bad sites and they mark up the search engine results to show you what's bad and what isn't... why they only do this for search engine results i don't know, search engine result pages are not the only pages that link to other pages - it should be possible to mark up all web pages to indicate link safety...
at any rate, singling out search engines this way is FUD... the implication is (and this is born out by all the alarmist revisionist headlines on articles talking about this siteadvisor study) that search engines aren't safe... search engines just point to web pages, just like other web pages point to web pages... it's not search engines that are unsafe it's the web in general - the same malware infested pages you can encounter using a search engine you can also encounter by following links on other pages (which is necessarily true in order for the unsafe pages to get a high enough page rank to be in the first 5 pages of google results)... search engines just point to the rest of the web - their results are an organized reflection of the web pages that exist...
but what is the siteadvisor study really saying? well, that their technology for detecting unsafe results returned from search engines is detecting unsafe results being returned from search engines... thanks, siteadvisor, for something very close to a tautology, and congratulation on validating your raison d'etre... but y'know - it's not unlike when experts on internet addiction do studies that show internet addiction is a growing problem - whether it's true or not, it's completely self-serving...
mcafee-siteadvisor are basically tooting their own horn trying to get attention, and i think i know what kind of attention they're hoping for... you see, back in the day it used to be a pretty big deal to be the anti-virus company that microsoft used in-house... it was a badge of honour, a matter of prestige and great PR... in today's world the internet (rather than the PC) is becoming the new platform - the web represents the file system, the search engine index represents the file allocation table, and the search engine itself is analogous to the OS... how prestigious would it be to be the scanning technology licensed by google or yahoo or msn to clear the bad pages out of their indices? mcafee-siteadvisor doesn't even have to try hard, they're the only game in town, they just have to hype things up a bit and raise some awareness so as to generate market pressure on the search engines to bite (thus the focus on search engines being unsafe)...
3.1% of organic search results and 8.5% of sponsored search results are bad - yup, that should work... not too outrageous, not too easy to ignore, it sounds 'just right'...
siteadvisor, as you may or may not know, provides technology to tell you which of the search engine results on the result page are safe and which ones aren't... they've basically come up with a list of known bad sites and they mark up the search engine results to show you what's bad and what isn't... why they only do this for search engine results i don't know, search engine result pages are not the only pages that link to other pages - it should be possible to mark up all web pages to indicate link safety...
at any rate, singling out search engines this way is FUD... the implication is (and this is born out by all the alarmist revisionist headlines on articles talking about this siteadvisor study) that search engines aren't safe... search engines just point to web pages, just like other web pages point to web pages... it's not search engines that are unsafe it's the web in general - the same malware infested pages you can encounter using a search engine you can also encounter by following links on other pages (which is necessarily true in order for the unsafe pages to get a high enough page rank to be in the first 5 pages of google results)... search engines just point to the rest of the web - their results are an organized reflection of the web pages that exist...
but what is the siteadvisor study really saying? well, that their technology for detecting unsafe results returned from search engines is detecting unsafe results being returned from search engines... thanks, siteadvisor, for something very close to a tautology, and congratulation on validating your raison d'etre... but y'know - it's not unlike when experts on internet addiction do studies that show internet addiction is a growing problem - whether it's true or not, it's completely self-serving...
mcafee-siteadvisor are basically tooting their own horn trying to get attention, and i think i know what kind of attention they're hoping for... you see, back in the day it used to be a pretty big deal to be the anti-virus company that microsoft used in-house... it was a badge of honour, a matter of prestige and great PR... in today's world the internet (rather than the PC) is becoming the new platform - the web represents the file system, the search engine index represents the file allocation table, and the search engine itself is analogous to the OS... how prestigious would it be to be the scanning technology licensed by google or yahoo or msn to clear the bad pages out of their indices? mcafee-siteadvisor doesn't even have to try hard, they're the only game in town, they just have to hype things up a bit and raise some awareness so as to generate market pressure on the search engines to bite (thus the focus on search engines being unsafe)...
3.1% of organic search results and 8.5% of sponsored search results are bad - yup, that should work... not too outrageous, not too easy to ignore, it sounds 'just right'...
Monday, May 15, 2006
pro-active vs. reactive technologies and techniques
we've all heard the rhetoric... known virus/malware scanning is reactive rather than pro-active - it's essentially a dead technology... we need pro-active technologies to deal with todays threats... pro-active technologies that look for virus/malware-like behaviour...
if you're like most security lemmings you're probably nodding your head in agreement at this point so i'm going to have to debunk some myths...
is known virus/malware scanning (more generally, blacklisting) reactive? developing known virus/malware scanners is certainly reactive since you have to wait for the virus or malware to actually exist before you can write a routine to identify it - so it's reactive in the scope of developing a technology for global consumption... at the local scope, the end user's machine, the application of a blacklist is a preventative measure - it stops the malware it's able to stop before the malware can activate, before the virus can infect anything, before sensitive data is compromized... that is the very definition of pro-active...
is behavioural virus/malware detection pro-active? developing the technology is certainly pro-active since you can write a routine to detect anything that performs behaviour X before most of the things that actually do perform behaviour X are even written - so it's pro-active in the global scope... at the local scope, however, the application of behavioural monitoring software is reactive by definition - think about it; the malware has to run, it has to become active, it has to try something naughty before the behavioural monitor can do anything... it reacts to bad behaviour from software... it's not prevention if it kicks in after...
let's look at some other technologies... take the application whitelist, the other preventative technology... it's development is pro-active since it can address malware before the malware is ever written... it's use is also pro-active as it stops the execution of any software that isn't known to be good... maybe this is the real champion of pro-active technologies - but wait: cataloging all good things is even more unmanagable than cataloging all bad things (blacklist) so a vendor supplied whitelist isn't such a great option... that means the real work, deciding what goes on the list and what doesn't, is left to the end user - that's a recipe for failure... oh, don't get me wrong, it's still a valuable tool, and software firewalls (implementing network connection whitelists) have shown us that it can work pretty well, but deciding what to trust and what not to trust (and thus what to add to the whitelist and what not to add) is a problem we already know end users aren't good at so some failures are going to happen...
how about change detection? it's development is pro-active too, all malware changes something, so long as your change detector can monitor that particular something for changes you can detect those changes even if they're made by malware that wasn't even thought of when the change detector was developed... unfortunately, in use change detection is reactive - it detects the changes after they have been made... then too, the work of deciding what changes are ok and what changes represent malware activity is largely left up to the end user...
now, i don't think anyone would argue that prevention isn't the preferred outcome... with prevention there is no clean-up, with prevention there is no lost data, with prevention there are no bank account passwords or credit card numbers to change - the alternatives to prevention are much messier... does prevention happen at the global scope of things? does simply making the technology stop the malware? no of course not... prevention happens at the end points, at the local scope, where the techniques actually get put to use... it is in that scope where 'pro-active or reactive' should be determined - the conventional wisdom on this matter is entirely backwards...
further, it needs to be realized that the more you can push the difficult task of figuring out what is trustworthy and what isn't back on the developers the better... security works best when decisions are made by informed users so the more relevant information the security software can give them the better, and the vendors are in a much better position to come up with and disseminate that information...
so is known virus/malware scanning really dead? no... in fact it is the cleanest and most cost effective technique that exists for dealing with malware... it does fail, but all preventative measures fail, that's the nature of things... that's why reactive techniques like behaviour monitoring and change detection exist, to help detect when preventative measures fail... the idea that scanning should be scrapped in favour of behaviour based detection systems is entirely wrong-headed; they should be used in conjunction with each other, they complement each other, they constitute defense in-depth... all of the above mentioned techniques have their place in a multi-layered anti-virus/anti-malware strategy...
if you're like most security lemmings you're probably nodding your head in agreement at this point so i'm going to have to debunk some myths...
is known virus/malware scanning (more generally, blacklisting) reactive? developing known virus/malware scanners is certainly reactive since you have to wait for the virus or malware to actually exist before you can write a routine to identify it - so it's reactive in the scope of developing a technology for global consumption... at the local scope, the end user's machine, the application of a blacklist is a preventative measure - it stops the malware it's able to stop before the malware can activate, before the virus can infect anything, before sensitive data is compromized... that is the very definition of pro-active...
is behavioural virus/malware detection pro-active? developing the technology is certainly pro-active since you can write a routine to detect anything that performs behaviour X before most of the things that actually do perform behaviour X are even written - so it's pro-active in the global scope... at the local scope, however, the application of behavioural monitoring software is reactive by definition - think about it; the malware has to run, it has to become active, it has to try something naughty before the behavioural monitor can do anything... it reacts to bad behaviour from software... it's not prevention if it kicks in after...
let's look at some other technologies... take the application whitelist, the other preventative technology... it's development is pro-active since it can address malware before the malware is ever written... it's use is also pro-active as it stops the execution of any software that isn't known to be good... maybe this is the real champion of pro-active technologies - but wait: cataloging all good things is even more unmanagable than cataloging all bad things (blacklist) so a vendor supplied whitelist isn't such a great option... that means the real work, deciding what goes on the list and what doesn't, is left to the end user - that's a recipe for failure... oh, don't get me wrong, it's still a valuable tool, and software firewalls (implementing network connection whitelists) have shown us that it can work pretty well, but deciding what to trust and what not to trust (and thus what to add to the whitelist and what not to add) is a problem we already know end users aren't good at so some failures are going to happen...
how about change detection? it's development is pro-active too, all malware changes something, so long as your change detector can monitor that particular something for changes you can detect those changes even if they're made by malware that wasn't even thought of when the change detector was developed... unfortunately, in use change detection is reactive - it detects the changes after they have been made... then too, the work of deciding what changes are ok and what changes represent malware activity is largely left up to the end user...
now, i don't think anyone would argue that prevention isn't the preferred outcome... with prevention there is no clean-up, with prevention there is no lost data, with prevention there are no bank account passwords or credit card numbers to change - the alternatives to prevention are much messier... does prevention happen at the global scope of things? does simply making the technology stop the malware? no of course not... prevention happens at the end points, at the local scope, where the techniques actually get put to use... it is in that scope where 'pro-active or reactive' should be determined - the conventional wisdom on this matter is entirely backwards...
further, it needs to be realized that the more you can push the difficult task of figuring out what is trustworthy and what isn't back on the developers the better... security works best when decisions are made by informed users so the more relevant information the security software can give them the better, and the vendors are in a much better position to come up with and disseminate that information...
so is known virus/malware scanning really dead? no... in fact it is the cleanest and most cost effective technique that exists for dealing with malware... it does fail, but all preventative measures fail, that's the nature of things... that's why reactive techniques like behaviour monitoring and change detection exist, to help detect when preventative measures fail... the idea that scanning should be scrapped in favour of behaviour based detection systems is entirely wrong-headed; they should be used in conjunction with each other, they complement each other, they constitute defense in-depth... all of the above mentioned techniques have their place in a multi-layered anti-virus/anti-malware strategy...
Sunday, May 14, 2006
what is a hybrid / blended threat?
a malware hybrid is a combination of 2 or more types of malware... for example, osx/leap.a is an instant messaging worm and a type of executable file infecting virus known as an overwriting infector...
although it isn't generally well known, a piece of malware can be a virus and a worm and a rat and a rootkit and any number of other malware types all at the same time - the various malware types are not mutually exclusive in any way... anti-malware vendors (anti-virus vendors in particular) don't generally do a great deal to make this obvious to the general computer using public, often preferring to treat one type as taking precedence over the others... occasionally one may see a write-up that lists something as a "spyware worm" or something like that but generally not...
this may be one of the more detrimental things that the industry practices because it misrepresents the breadth and scope of the threat that a particular pigeon-holed piece of malware poses... no malware type is an island unto itself, they can all be combined with one another and that is an important point to remember when dealing with the issue of what type of malware something is...
another (better known) term for this, at least the way some people (like kaspersky) use it, is "blended threat"... symantec, on the other hand, reserve the term blended threat for those hybrids that include exploit code as one of the malware types in the combination... according to nick fitzgerald, symantec coined the term to mean just that so that is the more formal meaning - however i can see no reason why exploit code should be so special as to deserve a special term for it's hybrids and clearly others agree...
back to index
although it isn't generally well known, a piece of malware can be a virus and a worm and a rat and a rootkit and any number of other malware types all at the same time - the various malware types are not mutually exclusive in any way... anti-malware vendors (anti-virus vendors in particular) don't generally do a great deal to make this obvious to the general computer using public, often preferring to treat one type as taking precedence over the others... occasionally one may see a write-up that lists something as a "spyware worm" or something like that but generally not...
this may be one of the more detrimental things that the industry practices because it misrepresents the breadth and scope of the threat that a particular pigeon-holed piece of malware poses... no malware type is an island unto itself, they can all be combined with one another and that is an important point to remember when dealing with the issue of what type of malware something is...
another (better known) term for this, at least the way some people (like kaspersky) use it, is "blended threat"... symantec, on the other hand, reserve the term blended threat for those hybrids that include exploit code as one of the malware types in the combination... according to nick fitzgerald, symantec coined the term to mean just that so that is the more formal meaning - however i can see no reason why exploit code should be so special as to deserve a special term for it's hybrids and clearly others agree...
back to index
Saturday, May 13, 2006
what is an exploit?
an exploit is something that takes advantage of (or exploits) a defect or vulnerability in either an existing piece of software or hardware.
unlike most forms of malware, an exploit is not necessarily a program in the traditional sense. while it can be used to refer to a program specially written to communicate bad input to a vulnerable piece of software, it can also be just the bad input itself. any bad input (or even valid input that the developer just failed to anticipate) can cause the vulnerable application to behave improperly. in the sense that all data is code and all inputs form languages, however, an exploit can be thought of as a program written in the input language of the vulnerable software.
because exploits may simply be bad input rather than an application, they may act in the context of an exploited application without first being saved to disk. this is a problem for conventional anti-malware apps that focus on scanning for malware on disk hopefully before it has a chance to execute (often just before they execute if you're using an on-access scanner). in the case of an exploit it can be a legitimate but vulnerable application that is running and performing the malware functions so a known malware scanner would have to scan the vulnerable application's input in order to address this case.
although malware is generally not based on exploiting software vulnerabilities and therefore not inherently dependent on them, it is possible to make malware in part or completely out of exploit code. such malware would then depend on vulnerabilities by definition.
if the malware is completely dependent on vulnerabilities it can be an exception to the general rule about disclosing malware not leading to the closure of any window of exposure, since it's disclosure would make the affected vendor(s) and community aware of the vulnerability and place pressure on the vendor(s) to get it fixed. however disclosing a working exploit still arms the bad guys - it should be possible to disclose the vulnerability that the malware exploits without giving out the actual malware (thereby helping to close the window of exposure without arming the bad guys as they'd have to come up with their own exploit), so disclosure of exploit based malware is still a bad thing to do.
like adware, exploits aren't necessarily always malware. a non-weaponized exploit can be used to test for the presence of a known vulnerability after a patch for the vulnerability has been made available so that people can determine if they need the patch and/or if the patch installed properly and/or if the patch is effective. this kind of exploit disclosure actually facilitates the closure of the window of exposure for the vulnerability in question.
(updated to integrate a somewhat language-theoretic view of exploits)
back to index
unlike most forms of malware, an exploit is not necessarily a program in the traditional sense. while it can be used to refer to a program specially written to communicate bad input to a vulnerable piece of software, it can also be just the bad input itself. any bad input (or even valid input that the developer just failed to anticipate) can cause the vulnerable application to behave improperly. in the sense that all data is code and all inputs form languages, however, an exploit can be thought of as a program written in the input language of the vulnerable software.
because exploits may simply be bad input rather than an application, they may act in the context of an exploited application without first being saved to disk. this is a problem for conventional anti-malware apps that focus on scanning for malware on disk hopefully before it has a chance to execute (often just before they execute if you're using an on-access scanner). in the case of an exploit it can be a legitimate but vulnerable application that is running and performing the malware functions so a known malware scanner would have to scan the vulnerable application's input in order to address this case.
although malware is generally not based on exploiting software vulnerabilities and therefore not inherently dependent on them, it is possible to make malware in part or completely out of exploit code. such malware would then depend on vulnerabilities by definition.
if the malware is completely dependent on vulnerabilities it can be an exception to the general rule about disclosing malware not leading to the closure of any window of exposure, since it's disclosure would make the affected vendor(s) and community aware of the vulnerability and place pressure on the vendor(s) to get it fixed. however disclosing a working exploit still arms the bad guys - it should be possible to disclose the vulnerability that the malware exploits without giving out the actual malware (thereby helping to close the window of exposure without arming the bad guys as they'd have to come up with their own exploit), so disclosure of exploit based malware is still a bad thing to do.
like adware, exploits aren't necessarily always malware. a non-weaponized exploit can be used to test for the presence of a known vulnerability after a patch for the vulnerability has been made available so that people can determine if they need the patch and/or if the patch installed properly and/or if the patch is effective. this kind of exploit disclosure actually facilitates the closure of the window of exposure for the vulnerability in question.
(updated to integrate a somewhat language-theoretic view of exploits)
back to index
Friday, May 05, 2006
socketshield hope and hype
i recently heard about an anti-malware app called socketshield that, like most new apps, is being hyped as being the best thing since sliced bread so i decided to look a little deeper...
essentially the product is a known-malware scanner (specifically a known-exploit scanner) that operates at the socket level, meaning that anything that connects to the internet would have it's traffic filtered by this scanner... that's not hugely interesting, though it does fill a niche as other somewhat comparable products i've heard of restrict themselves to specific protocols like smtp or http, so they play up their intelligence gathering efforts hoping (probably correctly) that most prospective users won't realize that much of those things are entirely analogous to methods used by more conventional anti-malware vendors... for example:
they're just trying to differentiate themselves from the countless other security vendors on the market, and i can understand that but it seems like some people misunderstand both the originality and application of the technology... it's not an anti-rootkit technology (or an anti-stealthkit technology) per se, it's just a known malware scanner operating on network traffic and focusing on exploit code that would otherwise be used to download/install/execute more conventional malware (which i suppose makes it anti-exploit technology - which is fitting since it comes from a company called exploit prevention labs)... they're also not doing anything wildly unique when it comes to gathering information about new exploits - they're just playing it up more because the average consumer doesn't understand or appreciate the implications of what is really noteworthy about the technology - it scans for malware on the wire rather than on the disk, so it has an opportunity to stop exploits for your browser, email client, or other internet-facing software from reaching their intended targets... conventional scanners often have difficulty with this because they focus on scanning files on the local hard disk and more and more frequently systems are being initially compromized by code that never reaches the hard disk or reaches it after it's already been run...
on that matter, they do have a claim on their product information page that i must take issue with... they claim "Anti-virus and anti-spyware programs only detect exploits after the damage has been done." which is technically false - these programs detect malware on disk... sometimes that winds up being after the damage has been done, but historically they've dealt with the kind of malware that has to be a file on your hard disk before it can run and so that window of opportunity allowed their products to be used for prevention as well as cleanup...
that said, as the internet becomes increasingly ubiquitous and feature-rich, we're moving closer and closer to a network computing platform and this technology represents the network computing analog of on-access scanning - we need anti-malware vendors to make this kind of technology more ubiquitous as well... malware that runs in the browser or in a plug-in or some other network-related application is not as vulnerable to being scanned on disk before execution and the anti-malware world needs to catch up..
essentially the product is a known-malware scanner (specifically a known-exploit scanner) that operates at the socket level, meaning that anything that connects to the internet would have it's traffic filtered by this scanner... that's not hugely interesting, though it does fill a niche as other somewhat comparable products i've heard of restrict themselves to specific protocols like smtp or http, so they play up their intelligence gathering efforts hoping (probably correctly) that most prospective users won't realize that much of those things are entirely analogous to methods used by more conventional anti-malware vendors... for example:
- an extended network of human researchers exists in the anti-virus industry, one need only look at the list of contributors to the wildlist to see this...
- honey pots and search bots and the like are used routinely in the anti-malware domain... just look here, here, and here for a few examples...
- a "technology that creates a filter for known and suspected exploit distributor sites" sounds an aweful lot like automatic signature extraction... i know they're not exactly the same thing but they both boil down to technologies to generate matching criteria algorithmically...
- a "community of ... users who allow information about attempted exploitation of their computers to be transferred back to..." is very much like the statistics gathered by many online virus scanners...
- a "correlation engine" that collects all the intelligence gathered by various means and distributes it back to the users sounds suspiciously like an auto-update facility... theirs is real-time instead of periodically polled - big whoop...
they're just trying to differentiate themselves from the countless other security vendors on the market, and i can understand that but it seems like some people misunderstand both the originality and application of the technology... it's not an anti-rootkit technology (or an anti-stealthkit technology) per se, it's just a known malware scanner operating on network traffic and focusing on exploit code that would otherwise be used to download/install/execute more conventional malware (which i suppose makes it anti-exploit technology - which is fitting since it comes from a company called exploit prevention labs)... they're also not doing anything wildly unique when it comes to gathering information about new exploits - they're just playing it up more because the average consumer doesn't understand or appreciate the implications of what is really noteworthy about the technology - it scans for malware on the wire rather than on the disk, so it has an opportunity to stop exploits for your browser, email client, or other internet-facing software from reaching their intended targets... conventional scanners often have difficulty with this because they focus on scanning files on the local hard disk and more and more frequently systems are being initially compromized by code that never reaches the hard disk or reaches it after it's already been run...
on that matter, they do have a claim on their product information page that i must take issue with... they claim "Anti-virus and anti-spyware programs only detect exploits after the damage has been done." which is technically false - these programs detect malware on disk... sometimes that winds up being after the damage has been done, but historically they've dealt with the kind of malware that has to be a file on your hard disk before it can run and so that window of opportunity allowed their products to be used for prevention as well as cleanup...
that said, as the internet becomes increasingly ubiquitous and feature-rich, we're moving closer and closer to a network computing platform and this technology represents the network computing analog of on-access scanning - we need anti-malware vendors to make this kind of technology more ubiquitous as well... malware that runs in the browser or in a plug-in or some other network-related application is not as vulnerable to being scanned on disk before execution and the anti-malware world needs to catch up..
Subscribe to:
Posts (Atom)