file infecting viruses vs digital signatures

vesselin's comments to my previous article inspired me to consider actual attack scenarios rather than just weaknesses in a proposed system so i've turned the title of this entry around to indicate more focus on the threats rather than the vulnerabilities...

in one of the responses to the comments i posited a scenario where a malicious entity compromises a legitimate software vendor and infects their software in such a way that they distribute infected programs with valid digital signatures and which can in turn sign executables they infect... today nishad herath posted a similar scenario over at the mcafee avert blog so at least i'm not the only one who thought of this possibility...

but you know what, that's actually a rather complicated scenario so i got to thinking maybe there's a simpler one... then it dawned on me; the premise for this protective technique is to manage the integrity of files and the assumption is that you can't infect files without changing them and thus affecting their integrity... it turns out that this assumption is wrong - certain types of companion viruses can infect a host program without modifying it at all... so if a malicious entity were to get a certificate they could easily sign their companion virus with it and so long as no one figured out the entity was signing malicious code their certificate would never be revoked and the virus could spread unhindered... and in joanna's world where digital signatures replace all the tricks that are used to detect the presence of viruses there would be nothing to alert the general public that the code was malicious and the certificate should be revoked...

ouch, that seems pretty damning, doesn't it... but you know what, companion viruses were always pretty obscure... it wasn't a particularly popular strategy in part because the extra files gave it away to those who were looking for extra files (oh, another one of those nasty virus detection tricks joanna thinks we can do without)... ok, so then how about a virus that inserts the host program into a copy of itself, rather than itself into the host program (the so-called amoeba infection technique) and then signs this new copy with the aforementioned maliciously obtained certificate? once again, a digital signature based whitelist isn't going to stop this from happening...

now that takes care of one of the aspects that kept companion viruses obscure but it doesn't really improve on the obscurity itself as this technique is even more obscure that companion infection... if you've followed me to this stage perhaps something else has dawned on you - if a virus can sign a copy of itself with a host program inside of it, why shouldn't it be able to sign a host program that it had inserted a copy of itself into using a completely conventional infection technique and the malicious entity's certificate? the answer is there is no reason it can't...

so it would seem that a digital signature based whitelist where vendors sign their own programs (effectively vouching for the safety of their own code) wouldn't really prevent file infecting viruses at all if that were the only thing the world were using... you still need all sorts of tricks to figure out when a vendor's certificate can't be trusted anymore, which points back to a fundamental problem with this kind of self-signing system - it correlates identity (which is the only thing a certificate authority can test) with trustworthiness in spite of the fact that they don't actually have anything to do with each other... just because the vendor's front man is who he says he is and hasn't done anything bad in the past (that anyone knows of) doesn't mean the vendor itself isn't a malicious entity... currently, standard certificates (like the ones used for websites) have become so easy for anyone to get that they've become meaningless and this lead to the creation of extended validation certificates which simply involves more in-depth investigation of the entity and which in turn has no bearing on what the entity will do after getting the certificate... i can see no way for a digital signature system for code to work any different than the one used for websites so the same problem will apply; and then even if we somehow figure out that the entity cannot be trusted, their virus(es) will continue to spread until a revocation is issued for their certificate and that information trickls down to all the affected systems...

trusting the vendor (or whatever else you want to call the software provider) to attest to the trustworthiness of their own software just seems far too naive from a security standpoint, which is why i originally didn't even consider it to be the model joanna had been talking about... a system where independent reviewers checked programs for malicious code before signing them (essentially certifying programs rather than program providers) seemed to be a safer solution, though it's got the same scaling problems that conventional centrally managed whitelists have... a system that certifies programs rather than program providers would be less vulnerable to the scenarios mentioned here (i think only a variation on the first one should be able to allow viruses to still spread) but either way, both options still allow viruses to operate if used on their own... at best (and by now this should sound familiar) digital signature based whitelists should be something we use with the more conventional tricks we're used to, not instead of them as joanna rutkowska would like you to believe...

digital signatures vs file infecting viruses

so joanna rutkowska actually talks about things other than so-called rootkits... this time (i won't link to the article for known reasons) it's file infecting viruses...

from the article:

But could the industry have solved the problem of file infectors in an elegant, definite way? The answer is yes and we all know the solution – digital signatures for executable files. Right now, most of the executables (but unfortunately still not all) on the laptop I’m writing this text on are digitally signed. This includes programs from Microsoft, Adobe, Mozilla and even some open source ones like e.g. True Crypt.

With digital signatures we can "detect" any kind of executable modifications, starting form the simplest and ending with those most complex, metamorphic EPO infectors as presented e.g. by Z0mbie. All we need to do (or more precisely the OS needs to do) is to verify the signature of an executable before executing it.

I hear all the counter arguments: that many programs out there are still not digitally signed, that users are too stupid to decide which certificates to trust, that sometimes the bad guys might be able to obtain a legitimate certificate, etc...

But all those minor problems can be solved and probably will eventually be solved in the coming years. Moreover, solving all those problems will probably cost much less then all the research on file infectors cost over the last 20 year. But that also means no money for the A/V vendors.

first things first - this is essentially a whitelist technique (with the added bonus that the cryptographic component allows the proof of whitelist membership to be shipped with the file instead of requiring a lookup in a very big list) with all associated fundamental problems... think the problem of signing all good programs is small and will probably be solved? maybe for suitably large values of small... if you're going to focus on identifying good files instead of bad ones you have to keep in mind that the good files outnumber the bad by orders of magnitude and grows at an even faster rate... conceptually signing all good programs is simple, but in practice it's very, very hard...

but let's assume we do solve that problem... so if the file isn't signed then it doesn't run and if the file's signature is invalid then it doesn't run... the presence of a valid signature is assumed to mean that the file is a) not bad and b) hasn't had anything bad put into it after signing, but is that a valid assumption? given that mobile spyware can get digitally signed by symbian, i think not, at least not for the first part of the assumption... currently digital signatures like the ones joanna holds up as examples are meant to prove authenticity, not safety... putting the onus on the signatories to determine whether the code they're signing is safe doesn't solve any malware problem, it just offloads it onto the signatory... this is also not a small problem: distinguishing good from bad is and always has been the problem and offloading it onto someone else doesn't make it any easier to solve...

the second part of the assumption, that verified signature implies nothing bad has been put into the file, may well be true, assuming that the verification system itself hasn't been compromised... the digital signature proves authenticity and one of the prerequisites for authenticity is integrity and that's really the underlying ingredient here - managing system integrity... any application whitelist worth it's salt already keeps track of the integrity of the executables on the whitelist, otherwise it would be trivial to fool it by simply replacing a whitelisted application with a piece of malware with the same filename... but as yisreal radai showed in his paper "integrity checking for anti-viral purposes: theory and practice" (sorry, no suitable non-vx links at this time), systems that detect changes to the integrity of files are subject to attack and one based on digital signatures is no different... the signing key could be stolen (there's been malware designed to steal cryptographic keys in the past) and then generating valid signatures for infected files would be trivial, the key used to verify the signatures could be altered (either on disk or dynamically in memory) by a malicious process that has already been signed, or if the system allows adding new keys then one could be added maliciously that would allow the files to be modified (infected) and then resigned with the new key to trick the system into thinking the file's integrity is intact... in fact, taking a cue from the developers of stealth technology under windows, one could simply change the result returned by the signature verification function... in order to be immune from attack, an integrity checking system has to be offline and out of reach of the attacker, and that's not compatible with a system that checks integrity in real-time to prevent modified files from running...

of course there are other problems too... it's not just deciding what to sign, ensuring the signatures are themselves trustworthy, and finding the resources to sign every good program in existence... there's also the classic whitelist problem of deciding what to do in an environment where programs are being created (or even what's a program in the first place)... are we going to digitally sign word documents? yes? ok, and will that stop macro virus infection? no of course not... there are plenty of macro viruses that infect a document when the document is saved - a point at which a new digital signature would have to be created anyways... then when the person we send the document to opens it the virus runs and then proceeds to infect documents that person creates or modifies (and then signs) and so on and so on...

again, from the article:

So, do I want to say that all those years of A/V research on detecting file infections was a waste time? I’m afraid that is exactly what I want to say here. This is an example of how the security industry took a wrong path, the path that never could lead to an effective and elegant solution. This is an example of how people decided to employ tricks, instead looking for generic, simple and robust solutions.

unfortunately a digital signature based whitelist is no elegant solution either... whitelisting for anti-viral purposes dates back at least as far as thunderbyte anti-virus and there have always been ways to manually check the integrity of transfered files to make sure they haven't been altered from what original vendor was distributing by using crc's, hashes, and even digital signatures... a digital signature based whitelist makes certain aspects of usage a little more convenient, but it doesn't mitigate the inherent problems of a whitelist...

joanna may have wanted to use this to demonstrate the way security solutions ought to be in an ideal world, but the world is not ideal, and the virus problem as well as the many varied ways of addressing it are not as simple as she portrays them... thus her example of security gone wrong has no legs... in the real world there is a counter-measure for every protective measure, and elegance (subjective as it is) cannot be the basis upon which the measures we take are judged...

the blue pill - once more, with feeling

i kinda hoped to never again darken my blog with those two words again... i even resisted the temptation to point to the response to the matasano challenge and say 'nyah, nyah, i told you so'...

and frankly, i'm not even interested in debunking the hogwash about it being 100% undetectable anymore - i know that perfect protection from detectors is impossible, joanna knows it's impossible, and i know that joanna knows that it's impossible...

if it were any of that stuff i've already posted about before i wouldn't be posting again because i've already said my peace about that... no, despite all the faults, all the criticisms i've made, the one good thing i was able to say was that at least she didn't release it - at least she was being responsible...

now even that is gone... maybe i should write viruses, slap a research sticker on them, release them and call it good... does that work? no? i didn't think so...

was there a compelling reason to make the stealthkit available to the public? was someone feeling the heat over some ridiculous claims and rather than eat crow decided to let those detractors test it for themselves with the cop-out caveat that it's not finished?... seems a plausible explanation - at any rate, congratulations joanna on becoming part of the problem, i'm sure that black hat you've made yourself will go over well at that conference by the same name...

there's more to security than just prevention

thanks to richard bejtlich for drawing my attention to this (because i find dark reading to be impenetrably dull)...

it appears that joanna rutkowska is trying to get the message across that there's more to security than prevention, that there's always some way around preventative measures and so you have to worry about detection as well... i can't pass up the two-fold irony here... first, joanna became a household name in security precisely because of her claim of making 100% undetectable malware, which should mean that focusing on detection is wasted effort... second and regarding the same claim, her undetectable malware is implicitly preventing detection... if she wants to bang the drum of no perfect prevention then more power to her, but she's going to need to eat her own dog food, as the saying goes...

richard echoes her sentiments though, and although there's a really good reason for all the focus on prevention (come on, say it with me now, an ounce of prevention is worth a pound of cure) i'll chime in with my own support for them too... security doesn't start and end with prevention (well, it might start there, but it definitely doesn't end there)... all preventative measures fail under some circumstances so it becomes important to try and detect preventative failures... i've written about the limits of prevention in an anti-virus context before (what i wrote applies equally well outside of the malware field) and when i did i made it clear that security doesn't end with detection either... it's all well and fine to detect a preventative failure, but then what?... after detection comes remediation - when you've discovered that your attempts to prevent bad things from happening have failed then you need to remedy the situation... in security one often will hear of the CIA triad; confidentiality, integrity, and availability are all things that security aims to maintain... well prevention, detection, and remediation form a triad too - they're the stages one goes through in the process of trying to protect something...

at this point you might be thinking that if security doesn't end with prevention and it doesn't end with detection then it must end with remediation because there aren't any elements left is this triad... one would be wrong for thinking that, however... remediation feeds back into prevention - since you don't want to have to keep applying the remedy over and over again you need to augment the preventative measures to help prevent what you failed to prevent before... prevention, detection, and remediation are a 3 stage cycle; they keep going indefinitely and each pass through the cycle makes security a little bit better/stronger....

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...

the blue pill leaves a foul aftertaste

yes, i know i've blogged about it before a couple of times already but time has passed and events have unfolded...

black hat is over, joanna rutkowska's presentation is complete and the media just lapped it up... microsoft expressed interest (and why wouldn't they when it bypassed protection mechanisms in their latest and greatest and most secure OS ever?) and probably others too...

in fact, at least one (perhaps more) anti-virus vendor has expressed interest in obtaining more information and that's when everything changed...

see, it was made clear way back in june that the blue pill wouldn't be available for download by the public and i thought to myself well gee that's a good thing... i mean it's clear that if it were freely (as in speech) available that the bad guys would adapt it and use it for their own purposes (if/when 64bit amd platforms become a significant hardware base)... it sounded very promising ethically, it seemed like the people holding the cards (coseinc) were going to be responsible (a stark contrast with so much of what goes on in the stealthkit/rootkit domain)...

so imagine my surprise and disappointment to read that in order for anti-virus companies to get additional information they'll have to pay money... yes, that's right, av companies are expected to pay for access to malware... as if malware creators don't already have enough of a financial incentive these days... by paying for malware, anti-virus companies would be giving malware creators (academic or otherwise) more reasons to create even more malware... that is not something av companies should ever be contributing to as it makes them part of the problem rather than part of the solution...

it's not like the malware creators were simply discovering an existing flaw, the potential for malware doesn't depend on flaws and joanna rutkowska made it clear that the blue pill doesn't depend on any flaws so the growing (and contraversial) practice of paying vulnerability researchers for vulnerability information (on the basis that they've done useful work for the vendor whose product they found flaws in by finding those flaws so they can be fixed) doesn't apply...

thankfully the folks at authentium did the right thing... i hope more do the same and come out publicly against the practice of paying for malware... and for those that don't, just remember what happened to the reputation of a certain someone who bought virus collections way back when...

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...