i've seen a couple of articles now about this being the 25th anniversary of the computer virus known as brain.
brain was the first PC virus in the wild. it was the first bootsector infector. it was the first stealth virus.
supposedly it was created in the (somewhat hypocritical) hopes of attacking software piracy, so the history of intellectual property maximalism has a particularly odious chapter to add.
the thought occurred to me, however (and i'm probably not the first but i haven't seen this said anywhere that i can remember), that if the stated motivation behind the virus is correct then brain is, on top of everything else, the first commercially motivated malware. before zeus, before gpcode, before adware, before the porn dialers there was the brain virus intended to get people to contact the virus' manufacturer for support.
Showing posts with label stealth. Show all posts
Showing posts with label stealth. Show all posts
Thursday, January 20, 2011
Saturday, May 15, 2010
understanding KHOBE
there's been quite a lot of press given to the research surrounding KHOBE this week, and while the coverage on the normal anti-malware blogs i follow was quite good, coverage outside that community left something to be desired (accuracy? comprehension?).
to start with, KHOBE is not so much an attack as it is a technology. KHOBE stands for Kernel HOok Bypassing Engine. it's technology developed by matousec to do exactly what that name suggests - bypass kernel hooks. it does this with a technique that matousec calls argument switching but which has in the past been called a time-of-check-to-time-of-use attack (or TOCTTOU attack; see this post on the eset threatblog).
this sort of attack is an active countermeasure, meaning a piece of malware implementing this attack has to be active in memory in order for attack to be performed. this means, first and foremost, that in order to mount this sort of attack the malware already has to be able to get past traditional scanning technologies without using argument-switching, since they examine the program before it's allowed to execute and become active.
as such, the anti-malware techniques that argument-switching is a countermeasure for are behavioural techniques (including, but not limited to certain self-defense techniques that anti-malware products use to prevent being shut down by malware that becomes active). by switching the contents of memory after a chunk of code has been checked for potentially malicious intent but before it's passed to the system to execute, this attack manages to prevent behavioural detection/prevention techniques from seeing the code that is actually going to be executed and in that way constitutes a kind of stealth that works against behavioural techniques (though it only works against behavioural techniques that are implemented in a particular way - using the particular kernel hooks that KHOBE was designed to bypass).
behavioural stealth is interesting at least so far as it demonstrates some of the limits of behavioural techniques to protect systems from attack (all techniques have limitations). from a strategic point of view, once a piece of malware is able to execute it's already passed every opportunity you had to prevent compromise outright - at that stage the only thing left is to contain the damage using behavioural techniques and/or sandboxing. behavioural stealth could clearly render containment by behavioural blocks ineffective (again, if it's implemented using the kernel hooks in question) and might even bypass the sandboxing technology, depending on how it's implemented.
although the attack has apparently been known about for some time (much longer, it seems, than the folks at matousec realized), it hasn't yet been used. however, that may now change as the current threat ecosystem is much different from when TOCTTOU was originally discussed. matousec has raised the attack back out of the depths of obscurity and there are now any number of computer criminals out there who would be more than willing to take matousec's research and use it for their own gains (much like what happened to eEye's bootroot research). this is the risk one takes when publishing attack research for the world to see, so you have to weigh your options very carefully to see if it's really worth arming the bad guys. and of course don't just follow full disclosure dogmatically simply because it seems like that's what everybody else does - as emerson said "a foolish consistency is the hobgoblin of little minds".
to start with, KHOBE is not so much an attack as it is a technology. KHOBE stands for Kernel HOok Bypassing Engine. it's technology developed by matousec to do exactly what that name suggests - bypass kernel hooks. it does this with a technique that matousec calls argument switching but which has in the past been called a time-of-check-to-time-of-use attack (or TOCTTOU attack; see this post on the eset threatblog).
this sort of attack is an active countermeasure, meaning a piece of malware implementing this attack has to be active in memory in order for attack to be performed. this means, first and foremost, that in order to mount this sort of attack the malware already has to be able to get past traditional scanning technologies without using argument-switching, since they examine the program before it's allowed to execute and become active.
as such, the anti-malware techniques that argument-switching is a countermeasure for are behavioural techniques (including, but not limited to certain self-defense techniques that anti-malware products use to prevent being shut down by malware that becomes active). by switching the contents of memory after a chunk of code has been checked for potentially malicious intent but before it's passed to the system to execute, this attack manages to prevent behavioural detection/prevention techniques from seeing the code that is actually going to be executed and in that way constitutes a kind of stealth that works against behavioural techniques (though it only works against behavioural techniques that are implemented in a particular way - using the particular kernel hooks that KHOBE was designed to bypass).
behavioural stealth is interesting at least so far as it demonstrates some of the limits of behavioural techniques to protect systems from attack (all techniques have limitations). from a strategic point of view, once a piece of malware is able to execute it's already passed every opportunity you had to prevent compromise outright - at that stage the only thing left is to contain the damage using behavioural techniques and/or sandboxing. behavioural stealth could clearly render containment by behavioural blocks ineffective (again, if it's implemented using the kernel hooks in question) and might even bypass the sandboxing technology, depending on how it's implemented.
although the attack has apparently been known about for some time (much longer, it seems, than the folks at matousec realized), it hasn't yet been used. however, that may now change as the current threat ecosystem is much different from when TOCTTOU was originally discussed. matousec has raised the attack back out of the depths of obscurity and there are now any number of computer criminals out there who would be more than willing to take matousec's research and use it for their own gains (much like what happened to eEye's bootroot research). this is the risk one takes when publishing attack research for the world to see, so you have to weigh your options very carefully to see if it's really worth arming the bad guys. and of course don't just follow full disclosure dogmatically simply because it seems like that's what everybody else does - as emerson said "a foolish consistency is the hobgoblin of little minds".
Monday, May 19, 2008
the decline of anti-malware protocols
if you've read this blog for any amount of time you've probably encountered posts where i try to debunk the idea that anti-virus is dead or falling behind or something similar... those generally have to do with anti-virus technology or the anti-virus industry, but there is one aspect of av that seems to be doing more than a little poorly these days and that is the application of proper anti-malware protocols - in other words, the practice of AV...
my interest in malware has lead me along many seemingly tangential paths in security over the years, and although i won't pretend to have any great insight in most of them i did pick up a few gems along the way... one of the gems i picked up as a result of following sci.crypt for a decade or so was the idea that no matter how secure an encryption algorithm is a cryptosystem that uses it is not secure unless it uses the algorithm in the proper way... in part that means using best practices for the algorithm (such as not using a one-time pad more than one time, or sanitizing an rc4 keystream), but it also means following a secure cryptographic protocol...
i propose that a similar principle is true for anti-virus or more generally anti-malware: you cannot gain the full benefits from a particular anti-malware technology unless you use it properly... again, sometimes this means best practices like keeping all your software up-to-date, and sometimes it means following correct procedures (implementing an anti-malware protocol)... this is one of the things i had in mind way back when when i wrote my anti-virus cook book but unfortunately protocols have seen little if any attention in the intervening years (and my cook book is way out of date these days, though some of the underlying principles remain unchanged)...
i understand why there hasn't been much focus on it... there is a pervasive opinion that anti-malware technology should stand on it's own, it shouldn't need informed users to act in a particular way because you can't depend on users in general to be informed or act the way you think they should... this has lead to the unfortunate consequence of making people think there is a purely technological solution to the malware problem when there isn't... it also ignores the fact that not only are some people actually capable of following proper anti-malware protocols, the population in general is at least capable of improving even if we'll never see complete uniform adherence to a particular code of conduct...
with that in mind, however, i was disappointed to discover that not only have protocols not advanced much in their adoption outside the anti-malware community but they're even being dropped within the anti-malware community... 10 years ago you would not have encountered a well respected 3rd party tester testing known-malware scanners against active stealth-capable malware so imagine my dismay at discovering that av-test.org did precisely that as described in a paper linked to by this darkreading article... the paper describes 2 separate tests, one on XP using anti-malware suites that claim some measure of stealthkit detection, and one on vista using so-called "pure anti-virus" products (ie. known-malware scanners only)...
the issue here is primarily the second test... known-malware scanning is primarily a preventative technological control... it is quite effective at filtering known-malware out of incoming materials... to their credit, anti-malware vendors have also made their scanner products useful in the contexts of detection and correction as well, but with the caveat that the user should use them from a clean environment (by booting from known-clean bootable non-writable media or by slaving the suspect drive in a known clean computer)... outside-the-box analysis is the only reliable countermeasure to whatever active offensive and defensive capabilities a particular piece of malware might have - it is a well known principle that you cannot trust a compromised system to accurately report it's state...
while there are technological shortcuts that can prove moderately successful (as demonstrated by av-test.org's XP test), those shortcuts are not reliable enough to completely obviate the need for the formal outside-the-box analysis... the benefits of shortcuts is that they allow one to extend the time between performing otherwise costly formal methods like outside-the-box analysis (up to a point) without increasing the risk of something getting through... in that respect, the XP test wasn't so bad since the products tested actually claimed to perform such shortcuts, but the vista test was methodologically unsound because it misused the technology it purported to test by testing it in a compromised environment...
now there have long been proponents of this sort of testing... they would often cite such methodologies as reflecting actual usage conditions because that's the way people use the products in real life... but the fact of the matter is that that's the way most people misuse the products in real life... when you're developing a benchmark the metric that is more interesting is the one that shows what a product is capable of when used properly, not the one that shows what happens when people don't know what they're doing...
when a respected testing body performs tests like this it reinforces worst-practices and the mismatched expectation that anti-malware software should just protect us automagically... i can't accept as valid any testing methodology that misuses the technology it purports to test and i can't believe andreas marx didn't know better since he referenced 2 of his own previous papers on the use of recovery disks and made a feeble mention in his conclusion that maybe their use is a better way to go... they are absolutely the better way to go when you suspect a system might be compromised and this has been known in the anti-malware community for a long, long time... when the anti-malware community itself starts dropping best practices and proper protocols, the practice of AV doesn't just fall behind, it regresses...
my interest in malware has lead me along many seemingly tangential paths in security over the years, and although i won't pretend to have any great insight in most of them i did pick up a few gems along the way... one of the gems i picked up as a result of following sci.crypt for a decade or so was the idea that no matter how secure an encryption algorithm is a cryptosystem that uses it is not secure unless it uses the algorithm in the proper way... in part that means using best practices for the algorithm (such as not using a one-time pad more than one time, or sanitizing an rc4 keystream), but it also means following a secure cryptographic protocol...
i propose that a similar principle is true for anti-virus or more generally anti-malware: you cannot gain the full benefits from a particular anti-malware technology unless you use it properly... again, sometimes this means best practices like keeping all your software up-to-date, and sometimes it means following correct procedures (implementing an anti-malware protocol)... this is one of the things i had in mind way back when when i wrote my anti-virus cook book but unfortunately protocols have seen little if any attention in the intervening years (and my cook book is way out of date these days, though some of the underlying principles remain unchanged)...
i understand why there hasn't been much focus on it... there is a pervasive opinion that anti-malware technology should stand on it's own, it shouldn't need informed users to act in a particular way because you can't depend on users in general to be informed or act the way you think they should... this has lead to the unfortunate consequence of making people think there is a purely technological solution to the malware problem when there isn't... it also ignores the fact that not only are some people actually capable of following proper anti-malware protocols, the population in general is at least capable of improving even if we'll never see complete uniform adherence to a particular code of conduct...
with that in mind, however, i was disappointed to discover that not only have protocols not advanced much in their adoption outside the anti-malware community but they're even being dropped within the anti-malware community... 10 years ago you would not have encountered a well respected 3rd party tester testing known-malware scanners against active stealth-capable malware so imagine my dismay at discovering that av-test.org did precisely that as described in a paper linked to by this darkreading article... the paper describes 2 separate tests, one on XP using anti-malware suites that claim some measure of stealthkit detection, and one on vista using so-called "pure anti-virus" products (ie. known-malware scanners only)...
the issue here is primarily the second test... known-malware scanning is primarily a preventative technological control... it is quite effective at filtering known-malware out of incoming materials... to their credit, anti-malware vendors have also made their scanner products useful in the contexts of detection and correction as well, but with the caveat that the user should use them from a clean environment (by booting from known-clean bootable non-writable media or by slaving the suspect drive in a known clean computer)... outside-the-box analysis is the only reliable countermeasure to whatever active offensive and defensive capabilities a particular piece of malware might have - it is a well known principle that you cannot trust a compromised system to accurately report it's state...
while there are technological shortcuts that can prove moderately successful (as demonstrated by av-test.org's XP test), those shortcuts are not reliable enough to completely obviate the need for the formal outside-the-box analysis... the benefits of shortcuts is that they allow one to extend the time between performing otherwise costly formal methods like outside-the-box analysis (up to a point) without increasing the risk of something getting through... in that respect, the XP test wasn't so bad since the products tested actually claimed to perform such shortcuts, but the vista test was methodologically unsound because it misused the technology it purported to test by testing it in a compromised environment...
now there have long been proponents of this sort of testing... they would often cite such methodologies as reflecting actual usage conditions because that's the way people use the products in real life... but the fact of the matter is that that's the way most people misuse the products in real life... when you're developing a benchmark the metric that is more interesting is the one that shows what a product is capable of when used properly, not the one that shows what happens when people don't know what they're doing...
when a respected testing body performs tests like this it reinforces worst-practices and the mismatched expectation that anti-malware software should just protect us automagically... i can't accept as valid any testing methodology that misuses the technology it purports to test and i can't believe andreas marx didn't know better since he referenced 2 of his own previous papers on the use of recovery disks and made a feeble mention in his conclusion that maybe their use is a better way to go... they are absolutely the better way to go when you suspect a system might be compromised and this has been known in the anti-malware community for a long, long time... when the anti-malware community itself starts dropping best practices and proper protocols, the practice of AV doesn't just fall behind, it regresses...
Saturday, February 02, 2008
when is a PUP not a PUP?
when it hides itself...
i came across a post on the mcafee avert labs blog the other day talking about potentially unwanted programs adding 'rootkit' functionality and i was struck by the absurdity of it...
if a PUP is using stealth and taking steps to avoid detection, why are we bothering with the euphemistic classification of 'possibly unwanted program'?
that a program is possibly unwanted implies that there is also the possibly that it is wanted, but taking steps to avoid detection implies that the program's creators don't care if the user wants the program or not and are in fact anticipating that the user won't want it...
if the creators of the software don't genuinely believe people want their software, why are we giving them the benefit of the doubt? i can see some legitimate reasons for software to hide other things on a system (to protect them from uninformed alteration, for example) but i can't see any legitimate reason for a program to hide it's own presence...
i'm not going to call a spade a spade, i'm going to call it a god damned shovel - if what used to be called a potentially unwanted program has added stealthkit functionality then it's no longer a potentially unwanted program, it's fully fledged malware... not all spyware/adware/what-have-you qualified as potentially unwanted programs in the first place, it was always a very special and very tenuous distinction that applied only to the most benign instances... actively avoiding detection isn't the mark of something benign...
i came across a post on the mcafee avert labs blog the other day talking about potentially unwanted programs adding 'rootkit' functionality and i was struck by the absurdity of it...
if a PUP is using stealth and taking steps to avoid detection, why are we bothering with the euphemistic classification of 'possibly unwanted program'?
that a program is possibly unwanted implies that there is also the possibly that it is wanted, but taking steps to avoid detection implies that the program's creators don't care if the user wants the program or not and are in fact anticipating that the user won't want it...
if the creators of the software don't genuinely believe people want their software, why are we giving them the benefit of the doubt? i can see some legitimate reasons for software to hide other things on a system (to protect them from uninformed alteration, for example) but i can't see any legitimate reason for a program to hide it's own presence...
i'm not going to call a spade a spade, i'm going to call it a god damned shovel - if what used to be called a potentially unwanted program has added stealthkit functionality then it's no longer a potentially unwanted program, it's fully fledged malware... not all spyware/adware/what-have-you qualified as potentially unwanted programs in the first place, it was always a very special and very tenuous distinction that applied only to the most benign instances... actively avoiding detection isn't the mark of something benign...
Thursday, January 18, 2007
where do stealthkit detectors belong
mike rothman brought up an interesting point today in a section of his daily incite - where does stealthkit (rootkit to those of you drinking the revisionist rootkit koolaid) belong? inside a larger security application suite (or perhaps a larger security application period) or on it's own as a separate tool? although they're often separate right now, mike thinks they probably shouldn't be...
but given how they operate and how best the fundamental technique they employ can be used, is merging them into larger products really reasonable?
most stealthkit detectors employ a generic detection technique known as a cross-view diff or cross-view analysis where essentially you look at some area of the computer in 2 or more different ways and see if there are any discrepancies between them... although most stealthkit detectors are trying to cut this particular corner, outside-the-box analysis is ultimately necessary to truly see through persistent stealthed malware... the av industry knew this back in the 90's (it was called clean booting back then, though microsoft has since recycled that term) but got microsoft's boot up their ass when NTFS became mainstream without any robust method to perform outside-the-box analysis on that type of file system so they've been squeaking by with safe-mode ever since... anti-spyware and other anti-malware apps that grew up in the interim have never even dealt with this methodology because active stealth went out of fashion for a number of years but for an anti-malware that deals specifically with stealth in a generic sort of way at least part of it's operation really should be done outside-the-box and that is going to set it apart from other anti-malware functionality...
as yet the only detector i know of that does an outside-the-box cross-view diff is the WinPE implementation of microsoft's strider ghostbuster rootkit detection technology but that's still just a research project... no one else does it because as yet microsoft have not made WinPE easily available to the public (though i've heard rumors this may change with vista) and the alternative, BartPE, must be generated by the user (due to copyright and licensing restrictions from microsoft) rather than distributed with the stealthkit detector, which is a not-so-simple task from the perspective of average-joe computer users...
but if the anti-stealthkit folks were to do things right, how well would the resulting product (that runs off a bootable cd) fit in with existing security apps? not very well would be my guess... it would be nice if anti-virus and other anti-malware apps could operate in a similar outside-the-box environment since stealth is just a means to hide what eventually becomes known-malware, but that defies centralized management consoles and scheduled scans and a variety of other convenience features (bloat) that they've accumulated over the years... outside-the-box is fundamentally at odds with convenience but it's necessary for reliable generic detection of stealthed objects so how can you reconcile stealth malware detection with the increasingly convenient unified anti-malware product?
but given how they operate and how best the fundamental technique they employ can be used, is merging them into larger products really reasonable?
most stealthkit detectors employ a generic detection technique known as a cross-view diff or cross-view analysis where essentially you look at some area of the computer in 2 or more different ways and see if there are any discrepancies between them... although most stealthkit detectors are trying to cut this particular corner, outside-the-box analysis is ultimately necessary to truly see through persistent stealthed malware... the av industry knew this back in the 90's (it was called clean booting back then, though microsoft has since recycled that term) but got microsoft's boot up their ass when NTFS became mainstream without any robust method to perform outside-the-box analysis on that type of file system so they've been squeaking by with safe-mode ever since... anti-spyware and other anti-malware apps that grew up in the interim have never even dealt with this methodology because active stealth went out of fashion for a number of years but for an anti-malware that deals specifically with stealth in a generic sort of way at least part of it's operation really should be done outside-the-box and that is going to set it apart from other anti-malware functionality...
as yet the only detector i know of that does an outside-the-box cross-view diff is the WinPE implementation of microsoft's strider ghostbuster rootkit detection technology but that's still just a research project... no one else does it because as yet microsoft have not made WinPE easily available to the public (though i've heard rumors this may change with vista) and the alternative, BartPE, must be generated by the user (due to copyright and licensing restrictions from microsoft) rather than distributed with the stealthkit detector, which is a not-so-simple task from the perspective of average-joe computer users...
but if the anti-stealthkit folks were to do things right, how well would the resulting product (that runs off a bootable cd) fit in with existing security apps? not very well would be my guess... it would be nice if anti-virus and other anti-malware apps could operate in a similar outside-the-box environment since stealth is just a means to hide what eventually becomes known-malware, but that defies centralized management consoles and scheduled scans and a variety of other convenience features (bloat) that they've accumulated over the years... outside-the-box is fundamentally at odds with convenience but it's necessary for reliable generic detection of stealthed objects so how can you reconcile stealth malware detection with the increasingly convenient unified anti-malware product?
Saturday, September 23, 2006
blue pill 2.0
have you heard the news about a new version of the blue pill?
there have been a number of nails in the coffin of the blue pill that i never bothered commenting on, mostly because i felt i'd already said enough... the final nail in the coffin, i think, should be the fact that joanna rutkowska herself is now working on the next version which is supposed to be even stealthier (stealthier than 100% undetectable?)... clearly then, the blue pill was not 100% undetectable and all those people who said so were proven right...
but this is not an i told you so...
see, version 2.0 is supposed to be truely 100% undetectable (at least that's the goal)... 1.0 fell victim to certain technical issues that joanna hopes to address in the next version...
what she won't be addressing (because it can't be addressed) are the theoretical issues that make 100% undetectable malware impossible... stealth is a protective measure and 100% effective stealth implies that perfect protection is possible when in fact we know this is axiomatically false... blue pill 2.0 won't meet the 100% undetectable snake oil goal joanna has set for it anymore than v1.0 did, nor will version 3 or 4 or 65...
see, this isn't an i told you so, it's an i'm telling you so again because somebody wasn't listening the first time...
there have been a number of nails in the coffin of the blue pill that i never bothered commenting on, mostly because i felt i'd already said enough... the final nail in the coffin, i think, should be the fact that joanna rutkowska herself is now working on the next version which is supposed to be even stealthier (stealthier than 100% undetectable?)... clearly then, the blue pill was not 100% undetectable and all those people who said so were proven right...
but this is not an i told you so...
see, version 2.0 is supposed to be truely 100% undetectable (at least that's the goal)... 1.0 fell victim to certain technical issues that joanna hopes to address in the next version...
what she won't be addressing (because it can't be addressed) are the theoretical issues that make 100% undetectable malware impossible... stealth is a protective measure and 100% effective stealth implies that perfect protection is possible when in fact we know this is axiomatically false... blue pill 2.0 won't meet the 100% undetectable snake oil goal joanna has set for it anymore than v1.0 did, nor will version 3 or 4 or 65...
see, this isn't an i told you so, it's an i'm telling you so again because somebody wasn't listening the first time...
Thursday, June 29, 2006
the blue pill is NOT 100% undetectable
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]
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]
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...
Saturday, April 22, 2006
mcafee's rootkit report: an alternative interpretation
the internet has been relatively a-buzz this week over a report (well, part of a report, actually - don't ask me why they couldn't release the whole thing) out of mcafee on the growth of the 'rootkit' threat... a lot of attention has been paid to mcafee's rather poor choice of words when the key findings blamed the "open source environment" for the increased proliferation and complexity of rootkits...
first, yes it really has nothing to do with "open source"... the concept that the author was probably struggling for when he settled on "open source" was public or full disclosure... a software licensing paradigm has nothing to do with 'rootkits' getting more complex or being deployed more frequently, but public disclosure is an enabling practice... coming out against full disclosure or anything like it isn't a popular thing to do in security circles these days, though, which may be why the author tried to find some other term...
also, mcafee named and shamed rootkitDOTcom as a possible leading cause of the worsening 'rootkit' problem... a lot of people took issue with this, mostly they're the folks who feel rootkitDOTcom is doing nothing more than practicing full disclosure and that full disclosure can do no wrong... some even try to quote bruce schneier with the old "security by obscurity is no security at all" line and to those people i'll direct you to what bruce schneier has actually written about full disclosure, particularly about irresponsible (and perhaps even criminal) disclosure...
now mcafee has it partially right, the public disclosure taking place on rootkitDOTcom and various collaboration sites and blogs IS at least partially responsible for the increase in complexity of 'rootkits'... by sharing malware source code and even compiled binaries with literally everyone (as rootkitDOTcom does) the supposed good guys are adding their voices, their knowledge, and their skills to the collaborative efforts of the bad guys...
that said, mcafee's figures show something in the growth patterns that availability of information cannot explain... collaboration sites in general and rootkitDOTcom in particular have been around for years so why then does the growth rate change so dramatically when it gets to 2005? availability of source and binaries are enabling factors, not causative ones - they don't drive the innovation or deployment of this type of malware...
something changed, something happened in 2005 that made 'rootkits' a whole lot more popular - i'll give you 3 guesses as to what that was and the first 2 don't count... that's right, sony bmg / first4internet / xcp... the media circus surrounding that debacle kept 'rootkits' in the public eye for a long time... it made them mainstream, not only in the eyes of the general internet public but in the malware creators' eyes as well... the attackers interest was piqued, their imagination was sparked, the tools they needed were easy to find and so now we are witnessing something not that unlike the slashdot effect except in malware development... throngs of people who weren't making 'rootkits' before, who probably weren't even aware of the kind of stealth technology that was available or how it could be used to their advantage, now are and that's what mcafee's numbers represent...
does that mean the media is to blame for building all this interest in 'rootkits'? maybe - i'd certainly like to blame some of the ills of the world on their sensationalism... the bad guys are still the ones responsible for doing bad things, but the media pointed a whole bunch of them in a new direction... that doesn't mean that greg hoglund and co. of rootkitDOTcom are off the hook, though... for all protestations of helping people learn about threats, learning for the sake of learning doesn't improve security - they aren't helping to close the window of exposure for this class of threat but they are helping to arm the bad guys... that's called being part of the problem rather than part of the solution...
first, yes it really has nothing to do with "open source"... the concept that the author was probably struggling for when he settled on "open source" was public or full disclosure... a software licensing paradigm has nothing to do with 'rootkits' getting more complex or being deployed more frequently, but public disclosure is an enabling practice... coming out against full disclosure or anything like it isn't a popular thing to do in security circles these days, though, which may be why the author tried to find some other term...
also, mcafee named and shamed rootkitDOTcom as a possible leading cause of the worsening 'rootkit' problem... a lot of people took issue with this, mostly they're the folks who feel rootkitDOTcom is doing nothing more than practicing full disclosure and that full disclosure can do no wrong... some even try to quote bruce schneier with the old "security by obscurity is no security at all" line and to those people i'll direct you to what bruce schneier has actually written about full disclosure, particularly about irresponsible (and perhaps even criminal) disclosure...
now mcafee has it partially right, the public disclosure taking place on rootkitDOTcom and various collaboration sites and blogs IS at least partially responsible for the increase in complexity of 'rootkits'... by sharing malware source code and even compiled binaries with literally everyone (as rootkitDOTcom does) the supposed good guys are adding their voices, their knowledge, and their skills to the collaborative efforts of the bad guys...
that said, mcafee's figures show something in the growth patterns that availability of information cannot explain... collaboration sites in general and rootkitDOTcom in particular have been around for years so why then does the growth rate change so dramatically when it gets to 2005? availability of source and binaries are enabling factors, not causative ones - they don't drive the innovation or deployment of this type of malware...
something changed, something happened in 2005 that made 'rootkits' a whole lot more popular - i'll give you 3 guesses as to what that was and the first 2 don't count... that's right, sony bmg / first4internet / xcp... the media circus surrounding that debacle kept 'rootkits' in the public eye for a long time... it made them mainstream, not only in the eyes of the general internet public but in the malware creators' eyes as well... the attackers interest was piqued, their imagination was sparked, the tools they needed were easy to find and so now we are witnessing something not that unlike the slashdot effect except in malware development... throngs of people who weren't making 'rootkits' before, who probably weren't even aware of the kind of stealth technology that was available or how it could be used to their advantage, now are and that's what mcafee's numbers represent...
does that mean the media is to blame for building all this interest in 'rootkits'? maybe - i'd certainly like to blame some of the ills of the world on their sensationalism... the bad guys are still the ones responsible for doing bad things, but the media pointed a whole bunch of them in a new direction... that doesn't mean that greg hoglund and co. of rootkitDOTcom are off the hook, though... for all protestations of helping people learn about threats, learning for the sake of learning doesn't improve security - they aren't helping to close the window of exposure for this class of threat but they are helping to arm the bad guys... that's called being part of the problem rather than part of the solution...
Tuesday, April 04, 2006
microsoft says escape from wet paper bag becoming impossible
holy crap, have you heard the news? microsoft has proclaimed that it's becoming impossible to recover from malware..
yeah, of course you've heard the news... everyone and their grandmother seems to think it's a big deal that microsoft is saying security is too hard...
microsoft is basically citing windows rootkits, advanced spyware, and anything else that might hook the kernal as the reason why recovery from malware is going to supposedly become impossible... in the malware world those things all boil down to stealth techniques, and as i've already said - we solved the stealth problem over a decade ago... microsoft, being deaf, blind, and monumentally stupid, made that solution basically unusable by foisting NTFS on us without giving us a solution for booting from a known clean removable medium and parsing NTFS partitions (before NTFS we could just boot from a write protected, bootable floppy disk and access the drive from DOS without triggering any malware self-defense mechanisms and without allowing the malware's stealth capabilities to be activated)...
the really weird thing is that microsoft does have the technology... it's called a PE (Preinstalled Environment) disk and not only does microsoft not want to give it away for free or bundle it with the operating system to aid in maintenance and disaster recovery, but they actually got on the case of the maker(s) of the BartPE disk (a free alternative to microsoft's own PE disk) a couple years ago, forcing the product temporarily offline...
lots of folks are taking microsoft's proclaimation seriously - don't buy into their cop-out... the handful of years they've spent trying to catch up in the security field are apparently just not enough for them to realize they have the solution in their own grubby little hands... the malware problem is not as bad as those morons in redmond make it out to be...
yeah, of course you've heard the news... everyone and their grandmother seems to think it's a big deal that microsoft is saying security is too hard...
microsoft is basically citing windows rootkits, advanced spyware, and anything else that might hook the kernal as the reason why recovery from malware is going to supposedly become impossible... in the malware world those things all boil down to stealth techniques, and as i've already said - we solved the stealth problem over a decade ago... microsoft, being deaf, blind, and monumentally stupid, made that solution basically unusable by foisting NTFS on us without giving us a solution for booting from a known clean removable medium and parsing NTFS partitions (before NTFS we could just boot from a write protected, bootable floppy disk and access the drive from DOS without triggering any malware self-defense mechanisms and without allowing the malware's stealth capabilities to be activated)...
the really weird thing is that microsoft does have the technology... it's called a PE (Preinstalled Environment) disk and not only does microsoft not want to give it away for free or bundle it with the operating system to aid in maintenance and disaster recovery, but they actually got on the case of the maker(s) of the BartPE disk (a free alternative to microsoft's own PE disk) a couple years ago, forcing the product temporarily offline...
lots of folks are taking microsoft's proclaimation seriously - don't buy into their cop-out... the handful of years they've spent trying to catch up in the security field are apparently just not enough for them to realize they have the solution in their own grubby little hands... the malware problem is not as bad as those morons in redmond make it out to be...
Saturday, March 25, 2006
what is a dropper?
a dropper is a program that carries an (often hidden) instance of some already known malware within itself and drops (extracts and runs) the malware it carries when it itself gets executed...
droppers are a means of getting malicious content past gateway security checking practices such as scanning downloads and email... they're generally easy to create by performing some arbitrary transformation (like run-time compression or encryption or some other type of encoding) on the malware it carries (which is then reversed when the malware gets dropped) but not necessarily easy for a scanner to see through programmatically unless it has prior knowledge of the transformation algorithm... in it's transformed state the malware may not be recognizable to the security applications that checked the dropper as it entered the machine and if that happens then the malware may go undetected when it gets dropped unless additional measures such as real-time monitoring or sandboxing are used...
the dropper represents a kind of (usually) temporary camoflage and as such is a distant relative of the more conventional stealth techniques... because they secretly introduce malware into a system they are also a type of trojan horse program in their own right...
back to index
droppers are a means of getting malicious content past gateway security checking practices such as scanning downloads and email... they're generally easy to create by performing some arbitrary transformation (like run-time compression or encryption or some other type of encoding) on the malware it carries (which is then reversed when the malware gets dropped) but not necessarily easy for a scanner to see through programmatically unless it has prior knowledge of the transformation algorithm... in it's transformed state the malware may not be recognizable to the security applications that checked the dropper as it entered the machine and if that happens then the malware may go undetected when it gets dropped unless additional measures such as real-time monitoring or sandboxing are used...
the dropper represents a kind of (usually) temporary camoflage and as such is a distant relative of the more conventional stealth techniques... because they secretly introduce malware into a system they are also a type of trojan horse program in their own right...
back to index
Tuesday, March 14, 2006
why virtual machine based 'rootkits' won't be the next big problem
ok, ignoring the issue of what rootkits really are for the moment, let's examine this idea of rootkits that are so low level they're even below the OS...
first, as greg hoglund points out you're pretty much guaranteed to notice the performance hit when your entire OS gets dropped into a virtual machine...
second, as pointed out on the f-secure blog it's actually been done before over a decade ago, back when stealth was still called stealth...
but really, i think i'm going to go them both one better (at least) and say that we solved the full stealth problem over a decade ago... that solution was called booting from a known clean bootable floppy disk and scanning with a known virus scanner...
"but kurt, how are we supposed to use our generic rootkit detection technology if the rootkit isn't active?" - simple, you aren't... those sorts of generics require the malware to be active, which gives it a tactical advantage (it's able to actively defend itself then)... it also allows the malware to know more about the security application than the security application knows about the malware, which is another tactical advantage for the malware... if you're unfamiliar with what sun tsu had to say about engaging the enemy when you're at a disadvantage then i suggest you go do your homework right now... you can't rely solely on generics that way - known-malware techniques (know your enemy) must be employed in an environment and under conditions of your choosing in order to maximize your tactical advantage, and the generics are then used in a supporting role to partially cover what that strategy can't...
now, those of you who've been following things for a few years now you probably know that microsoft screwed that option up with the advent of NTFS... no version of MSDOS is capable of parsing an NTFS partition natively and microsoft seems unwilling to do much about that - probably because so far there really hasn't been that great a need these days... however, should the need arise a fair amount of effort has gone into correcting microsoft's oversight... things like bart's pe disk, NTFS4DOS, or any one of the many recovery oriented live-cd linux distributions can give you access to an NTFS partition after booting from a known clean bootable medium...
all in all, the majority of what's being said out there about microsoft's subvirt and the technology it represents is just hype... in the very unlikely event that anyone ever actually bothers trying to deploy it in the wild, it's an old problem that we've had a solution for for some time now...
[obligatory terminology rant]
of course all of this is one of the consequences of the rootkit redefinition... it clouds the issues in both the rootkit problem-space and the stealth problem-space... we wouldn't be forgetting this history if stealth was still called stealth, and then maybe the brain-trust at microsoft wouldn't have to spend untold millions reinventing the wheel that we already know how to deal with...
[/obligatory terminology rant]
first, as greg hoglund points out you're pretty much guaranteed to notice the performance hit when your entire OS gets dropped into a virtual machine...
second, as pointed out on the f-secure blog it's actually been done before over a decade ago, back when stealth was still called stealth...
but really, i think i'm going to go them both one better (at least) and say that we solved the full stealth problem over a decade ago... that solution was called booting from a known clean bootable floppy disk and scanning with a known virus scanner...
"but kurt, how are we supposed to use our generic rootkit detection technology if the rootkit isn't active?" - simple, you aren't... those sorts of generics require the malware to be active, which gives it a tactical advantage (it's able to actively defend itself then)... it also allows the malware to know more about the security application than the security application knows about the malware, which is another tactical advantage for the malware... if you're unfamiliar with what sun tsu had to say about engaging the enemy when you're at a disadvantage then i suggest you go do your homework right now... you can't rely solely on generics that way - known-malware techniques (know your enemy) must be employed in an environment and under conditions of your choosing in order to maximize your tactical advantage, and the generics are then used in a supporting role to partially cover what that strategy can't...
now, those of you who've been following things for a few years now you probably know that microsoft screwed that option up with the advent of NTFS... no version of MSDOS is capable of parsing an NTFS partition natively and microsoft seems unwilling to do much about that - probably because so far there really hasn't been that great a need these days... however, should the need arise a fair amount of effort has gone into correcting microsoft's oversight... things like bart's pe disk, NTFS4DOS, or any one of the many recovery oriented live-cd linux distributions can give you access to an NTFS partition after booting from a known clean bootable medium...
all in all, the majority of what's being said out there about microsoft's subvirt and the technology it represents is just hype... in the very unlikely event that anyone ever actually bothers trying to deploy it in the wild, it's an old problem that we've had a solution for for some time now...
[obligatory terminology rant]
of course all of this is one of the consequences of the rootkit redefinition... it clouds the issues in both the rootkit problem-space and the stealth problem-space... we wouldn't be forgetting this history if stealth was still called stealth, and then maybe the brain-trust at microsoft wouldn't have to spend untold millions reinventing the wheel that we already know how to deal with...
[/obligatory terminology rant]
Monday, February 20, 2006
the descent of rootkits
i think it's about time to get to the root of the rootkit terminology shift...
i've blogged before about what i think a rootkit is, and about how the anti-spyware coalition's definition is basically in line with my own...
and yet somehow the definition currently in use is all about hiding processes and/or activities from the user rather than about root/administrative privileges...
as i observed before; f-secure, despite acknowledging that the original unix meaning was basically in line with the one i use in this little blurb:
but my first clue about where this new definition came from was in mark russinovich's blog entry where he gives his definition:
a rootkit developer community? well, a community of developers of cloaking technology at any rate... but lets think about this for a sec... by and large, these developers are not going to be a malicious bunch (there are far more good people in the world than there are bad) so when they look at rootkits, even the original unix-style rootkits, they aren't going to really be all that interested in the more blatantly malware type features - the thing that's going to interest them is the cloaking because it has applications outside of malware...
it has been suggested that terminology changes with frequent misuse and that is most likely what happened here... the developer community in question, lacking any significant influence from malware experts (since malware issues were outside the scope of their interests, and because malware expertise is a lot harder to come by than you might think), used and reused the term rootkit (since rootkits represented examples of the kinds of sophisticated stealth techniques they were interested in) so much outside of it's original meaning that they gave it a new meaning...
so what? you might well think that language changes in just this way so there's nothing wrong here, but consider this:
while upcoming concepts like 'stealth by design' indicate that the current terminological misstep may be in the process of correcting itself, there will be purists who will resist the change in terminology on the basis that the proposed new definition of rootkit is not what a rootkit was supposed to be... they'll simply have to be reminded that their rootkit definition was not the original one either and if the correction does take place it will simply be a reversion to the original state of things...
i've blogged before about what i think a rootkit is, and about how the anti-spyware coalition's definition is basically in line with my own...
and yet somehow the definition currently in use is all about hiding processes and/or activities from the user rather than about root/administrative privileges...
as i observed before; f-secure, despite acknowledging that the original unix meaning was basically in line with the one i use in this little blurb:
The term rootkit is very old and is dated back to the days when UNIX ruled the world. Rootkits for the UNIX operating system were typically used to elevate the privileges of a user to the root level (=administrator). This explains the name of this category of tools.still insists on using the new hiding-related definition...
but my first clue about where this new definition came from was in mark russinovich's blog entry where he gives his definition:
Software that hides itself or other objects, such as files, processes, and Registry keys, from view of standard diagnostic, administrative, and security software.which he says he derived from what the rootkit developer community was using as a definition and which happens to basically mirror the definition proposed by greg hoglund, founder of rootkit.com (a hub of the aforementioned developer community) and author of a book on these so-called rootkits (not that registering a domain and/or writing a book actually makes anyone a credible authority, but for the sake of argument lets say he is one), which states:
A rootkit is a tool that is designed to hide itself and other processes, data, and/or activity on a system.
a rootkit developer community? well, a community of developers of cloaking technology at any rate... but lets think about this for a sec... by and large, these developers are not going to be a malicious bunch (there are far more good people in the world than there are bad) so when they look at rootkits, even the original unix-style rootkits, they aren't going to really be all that interested in the more blatantly malware type features - the thing that's going to interest them is the cloaking because it has applications outside of malware...
it has been suggested that terminology changes with frequent misuse and that is most likely what happened here... the developer community in question, lacking any significant influence from malware experts (since malware issues were outside the scope of their interests, and because malware expertise is a lot harder to come by than you might think), used and reused the term rootkit (since rootkits represented examples of the kinds of sophisticated stealth techniques they were interested in) so much outside of it's original meaning that they gave it a new meaning...
so what? you might well think that language changes in just this way so there's nothing wrong here, but consider this:
- technical jargon does not evolve the same way that conversational language does... imagine if people started using the term 'telescope' to refer to something completely different...
- hoglund's definition describes what is more properly known as stealth in the malware field... the concept of stealth has enjoyed wide use in the malware field for at least the past 20 years (back in 1986, the brain virus wasn't just the first pc virus in the wild, it was the first stealth virus) and has been applied to virtually all forms of malware, not just rootkits
- stealth is actually a more natural and intuitive label for what hoglund's definition describes; so much so that the term is creeping back into the vocabulary of the rootkit community at rootkit.com to cover new types of cloaking that 'rootkit' is no longer felt to encompass
- under hoglund's definition, the term 'rootkit' has no etymological basis - that is the word doesn't appear to come from anywhere or be rooted in any underlying details... by comparison, a collection of programs (-> a collection of software tools -> a toolkit -> a kit) that aids in gaining or maintaining root/administator (administrator is called 'root' in unix) access is fairly clear about where the term 'rootkit' comes from
while upcoming concepts like 'stealth by design' indicate that the current terminological misstep may be in the process of correcting itself, there will be purists who will resist the change in terminology on the basis that the proposed new definition of rootkit is not what a rootkit was supposed to be... they'll simply have to be reminded that their rootkit definition was not the original one either and if the correction does take place it will simply be a reversion to the original state of things...
Sunday, February 12, 2006
this has got to stop
ok, so it was bad enough when sony's digital rights malware got labelled a rootkit, at least it really was malware... but now anti-virus products and other legitimate programs are being called rootkits too...
this is basically a witch-hunt, everything that hides anything is getting called a rootkit and it clearly isn't serving the public's interests... at what point in the process of calling legitimate apps and even anti-virus products rootkits does one wake up and realized they've made a tremendous error? at what point does one own up to that mistake and admit it? before or after you become a media darling?
cloaking of any kind is bad and microsoft agrees? windows cloaks things... "Hidden files and folders", "Hide extensions of known file types", "Hide protected operating system files (Recommended)"... and don't get me started on "NeverShowExt"
there are some circumstances where hiding things is clearly bad, such as hiding them from the administrator... however hiding things from ordinary users can reduce confusion and the potential for user initiated disasters... hiding things that can help to detect the presence of malware from that malware can reduce the malware's viability in the real world... so long as the administrator has the ability to disable beneficial cloaking there should be no problem...
this is basically a witch-hunt, everything that hides anything is getting called a rootkit and it clearly isn't serving the public's interests... at what point in the process of calling legitimate apps and even anti-virus products rootkits does one wake up and realized they've made a tremendous error? at what point does one own up to that mistake and admit it? before or after you become a media darling?
cloaking of any kind is bad and microsoft agrees? windows cloaks things... "Hidden files and folders", "Hide extensions of known file types", "Hide protected operating system files (Recommended)"... and don't get me started on "NeverShowExt"
there are some circumstances where hiding things is clearly bad, such as hiding them from the administrator... however hiding things from ordinary users can reduce confusion and the potential for user initiated disasters... hiding things that can help to detect the presence of malware from that malware can reduce the malware's viability in the real world... so long as the administrator has the ability to disable beneficial cloaking there should be no problem...
what is stealth?
stealth is a property held by instances of malware that employ stealth techniques... stealth techniques are any techniques which serve to hide something (usually malware) from something else (usually the user or security software employed by the user)...
in malware, stealth is not an attack in and of itself but rather it is an adaptive strategy applied to other attack techniques in order to increase their likelihood of success... by keeping evidence of the attack hidden, the window of opportunity for the attack to succeed remains open longer and therefore the number of opportunities encountered that could lead to success tends to increase...
virtually all classes of malware have employed stealth techniques at one time or another, however not all instances of malware employ stealth techniques... further, stealth techniques are not exclusively the domain of malware - stealth has been employed in legitimate applications too... in fact there are some cases where stealth is used to hide information used by anti-malware applications from the very malware they're trying to protect against...
back to index
in malware, stealth is not an attack in and of itself but rather it is an adaptive strategy applied to other attack techniques in order to increase their likelihood of success... by keeping evidence of the attack hidden, the window of opportunity for the attack to succeed remains open longer and therefore the number of opportunities encountered that could lead to success tends to increase...
virtually all classes of malware have employed stealth techniques at one time or another, however not all instances of malware employ stealth techniques... further, stealth techniques are not exclusively the domain of malware - stealth has been employed in legitimate applications too... in fact there are some cases where stealth is used to hide information used by anti-malware applications from the very malware they're trying to protect against...
back to index
what is a rootkit?
a rootkit is a collection of one or more programs that aid in gaining and/or regaining (sometimes expressed as maintaining) root/administrative access on a system....
by gaining access i mean that they provide an attacker with credentials for a user with administrative privileges or a user whose privileges can be escalated (by use of some additional exploit) to administrative priviledges... usually this is performed with network sniffing from other compromized machines or some other password stealing technique...
by regaining access i mean that they provide an attacker with an easy means of re-entering the system with their administrative priviledges at a later date... usually this is done with a backdoor of some kind...
rootkits originated in the unix domain but have since been brought into the windows fold with an unfortunate twist - many in the industry have taken to redefining rootkits under windows to be basically anything that hides files, registry keys, alternate datastreams, etc... they ignore the concept of root/administrative privilege entirely (that's where the root in rootkit comes from - root is the administrative user account under unix/linux), instead focusing exclusively on what might otherwise be called stealth...
stealth is not an attack in it's own right but rather it is a technique for keeping the window of opportunity open longer, thereby improving the likelihood of success of the actual attack... virtually all classes of malware have employed stealth techniques (as they used to be called before the year 2000) at some point or another, not just rootkits - rootkits are not special in that regard... the application of stealth techniques helps to hide the programs that comprise the rootkit, allowing the rootkit more time to steal passwords and other sensitive information, and allowing the attacker more time to use the compromized system...
stealth became such an important part of rootkits (especially under unix where security-aware admins monitor system integrity carefully) that the stealth techniques themselves became the means by which the presence of a rootkit could be detected... perfect stealth, it turns out, is hard if not impossible to acheive and by using multiple techniques to examine system resources and comparing the results it is often possible to detect when something is being actively hidden from sight... unfortunately this a generic detection technique and as such is prone to alert on anything that hides things whether they're rootkits or something else, so the choice to categorize all things detected this way as rootkits is curious and a little troubling... and considering there are also software products out there that hide things in order to protect them from malware (instead of being malware) it can lead to a great deal of fear, uncertainty, and doubt among users...
in short - stealth isn't what makes a rootkit a rootkit, it's what makes a rootkit a successful rootkit... that's why virtually all of them use it...
(see these two usenet articles for additional analysis of what a rootkit is, and thanks to roger wilco for the debate)
back to index
by gaining access i mean that they provide an attacker with credentials for a user with administrative privileges or a user whose privileges can be escalated (by use of some additional exploit) to administrative priviledges... usually this is performed with network sniffing from other compromized machines or some other password stealing technique...
by regaining access i mean that they provide an attacker with an easy means of re-entering the system with their administrative priviledges at a later date... usually this is done with a backdoor of some kind...
rootkits originated in the unix domain but have since been brought into the windows fold with an unfortunate twist - many in the industry have taken to redefining rootkits under windows to be basically anything that hides files, registry keys, alternate datastreams, etc... they ignore the concept of root/administrative privilege entirely (that's where the root in rootkit comes from - root is the administrative user account under unix/linux), instead focusing exclusively on what might otherwise be called stealth...
stealth is not an attack in it's own right but rather it is a technique for keeping the window of opportunity open longer, thereby improving the likelihood of success of the actual attack... virtually all classes of malware have employed stealth techniques (as they used to be called before the year 2000) at some point or another, not just rootkits - rootkits are not special in that regard... the application of stealth techniques helps to hide the programs that comprise the rootkit, allowing the rootkit more time to steal passwords and other sensitive information, and allowing the attacker more time to use the compromized system...
stealth became such an important part of rootkits (especially under unix where security-aware admins monitor system integrity carefully) that the stealth techniques themselves became the means by which the presence of a rootkit could be detected... perfect stealth, it turns out, is hard if not impossible to acheive and by using multiple techniques to examine system resources and comparing the results it is often possible to detect when something is being actively hidden from sight... unfortunately this a generic detection technique and as such is prone to alert on anything that hides things whether they're rootkits or something else, so the choice to categorize all things detected this way as rootkits is curious and a little troubling... and considering there are also software products out there that hide things in order to protect them from malware (instead of being malware) it can lead to a great deal of fear, uncertainty, and doubt among users...
in short - stealth isn't what makes a rootkit a rootkit, it's what makes a rootkit a successful rootkit... that's why virtually all of them use it...
(see these two usenet articles for additional analysis of what a rootkit is, and thanks to roger wilco for the debate)
back to index
Sunday, March 13, 2005
rootkits for windows
this page tries to explain what rootkits are and the emerging threat they pose for the windows platform...
that's all well and good but there's something that just doesn't sit well with me... let's take a closer look:
i like this explanation... it's simple, it's consistent, it makes sense.... a rootkit is a tool used to gain root (*nix speak for administrator) privileges...
now this is not so good... apparently rootkits for windows don't really have anything to do with giving a principle administrative privileges... it does a bunch of the other things it's unix counterpart does (i.e. it uses sophisticated techniques to hide) but no elevation of privilege...
does that make sense to you?
if i take the self-replication out of a virus, regardless of the fact that it can still do all the other things it used to be able to do, it is no longer a virus...
why then if i take the root granting functionality out of a rootkit does it remain a rootkit?
it doesn't seem to make a lot of sense, it is not logically consistent... by rights, what they're calling rootkits for windows should be called (in keeping with the spirit of the rootkit name) stealthkits...
now, this was an f-secure description so you may well be thinking that maybe those f-secure folks are a little confused... but no, if that were the case then why does sophos also seem to think that rootkits are more about hiding than they are about privilege elevation (which they don't even mention)... and then there's sysinternal's explanation of rootkits which also focuses on hiding rather than privilege elevation...
this seems like it might actually be industry wide, in which case i can just site here in awe and wonder because the industry appears to be from a completely different planet than you and me...
that's all well and good but there's something that just doesn't sit well with me... let's take a closer look:
The term rootkit is very old and is dated back to the days when UNIX ruled the world. Rootkits for the UNIX operating system were typically used to elevate the privileges of a user to the root level (=administrator). This explains the name of this category of tools.
i like this explanation... it's simple, it's consistent, it makes sense.... a rootkit is a tool used to gain root (*nix speak for administrator) privileges...
Rootkits for Windows work in a different way and are typically used to hide malicious software from for example an antivirus scanner. Rootkits are typically not malicious by themselves but are used for malicious purposes by viruses, worms, backdoors and spyware. A virus combined with a rootkit produces what was known as full stealth viruses in the MS-DOS environment.
now this is not so good... apparently rootkits for windows don't really have anything to do with giving a principle administrative privileges... it does a bunch of the other things it's unix counterpart does (i.e. it uses sophisticated techniques to hide) but no elevation of privilege...
does that make sense to you?
if i take the self-replication out of a virus, regardless of the fact that it can still do all the other things it used to be able to do, it is no longer a virus...
why then if i take the root granting functionality out of a rootkit does it remain a rootkit?
it doesn't seem to make a lot of sense, it is not logically consistent... by rights, what they're calling rootkits for windows should be called (in keeping with the spirit of the rootkit name) stealthkits...
now, this was an f-secure description so you may well be thinking that maybe those f-secure folks are a little confused... but no, if that were the case then why does sophos also seem to think that rootkits are more about hiding than they are about privilege elevation (which they don't even mention)... and then there's sysinternal's explanation of rootkits which also focuses on hiding rather than privilege elevation...
this seems like it might actually be industry wide, in which case i can just site here in awe and wonder because the industry appears to be from a completely different planet than you and me...
Subscribe to:
Posts (Atom)