the disclosure debate is the wrong argument

prompted by an exchange on twitter this morning i began spending mental resources on an old favourite that everyone loves (hates) to go over again and again - the disclosure debate.

the disclosure debate is a debate over what the right answer is to the question  "i found a problem, now what do i do with it?". it's a natural place to come from for many in the security community and the question surely needs an answer. but the disclosure debate tries to raise the answer into a principle and each side of the debate believes that their side is more principled, more virtuous than the other. you have to pick a side and in so doing you also pick a tribe and signal your allegiance.

the disclosure debate has been raging in the security community for a long time and the two major sides right now are full disclosure which is generally favoured by security researchers, and responsible disclosure which is generally favoured by vendors. when you pick a side you're choosing to align with one of these groups.

but is that really it? is it just a choice between researchers and vendors? are they the only ones with real skin in the game? hell no.

so then let's catalog the groups of people involved:

1. vendors of vulnerable products/systems/services. these are the people who, when faced with discovery of a security vulnerability in their product, are expected to act quickly and create a fix for their product to eliminate the risk posed by by that vulnerability
2. security researchers. these are the people who find the vulnerabilities. often a great deal of work goes into finding vulnerabilities and consequently researchers often want and even deserve some kind of reward, whether simply adding to their reputation which they can parlay into better paying job or a more direct financial reward like a bug bounty.
3. attackers. these are the people who would actually exploit the vulnerability to victimize people, whether for money, ideology, or a laundry list of other reasons
4. users of vulnerable products/systems/services, be they businesses, institutions, individuals, etc. these are the people who are actually affected by vulnerabilities and arguably should be the most important consideration

now attackers and users don't figure all that much in the disclosure debate. sure the ostensible reason we have the debate is because we say we want to help the users, and the reason for doing the vulnerability research and disclosing the results at all is supposed to be to thwart attackers, but when arguing over which side of the disclosure debate is best attackers and users are treated as constants, as monolithic homogeneous groups that always present the same issues in every case and that's just not an accurate reflection of reality. 

not all attackers would be able to find the vulnerabilities on their own. those that can are just as much a minority as the security researchers themselves are. not all attackers are interested in any given vulnerability. those that target foreign states may be more interested in PLC vulnerabilities than VLC vulnerabilities. some may not have the connections or resources to exploit a particular vulnerability. some may specialize in attacks against a completely different kind of technology. some are simply not motivated enough to add a new exploit to their arsenal.

meanwhile, not all users pay attention to the channels where disclosures are communicated, in large part because most users can't understand or meaningfully act on the information in a disclosure. filtering out attack traffic, using IOCs, deploying mitigations, etc. are all the domain of a very select group. additionally not all users are aware of all patches when they become available, or are willing or able to apply them.

these are only a fraction of the variations among the two groups that can affect if/how they'll use a vulnerability and if/how they might be affected by the vulnerability. the reason we keep having the disclosure debate is because that debate has never adequately addressed these variables, because they have the potential to make the answer change depending on the vulnerability, which would mean there is no single right answer or right side in the debate. the debate focuses on principles to the exclusion of nuance, only paying lip service to the people who would use the vulnerabilities and the people those vulnerabilities would be used against. 

those who find a problem in some kind of technology want an easy answer to the question of what they should do with it - that's why the disclosure debate exists, to try and arrive at an easy answer so people can just follow the one right principle for handling the situation and be done with it. it follows a trend that has become all too common in the technology sector of trying to abstract people out of the equation because people are messy and complicated. but people are part of the equation whether we like it or not so the argument shouldn't be about which principle is right, but rather whether our actions should be governed by principle or by considerations for people.

in the watchmen, the character rorschach was governed by principles to the exclusion of virtually everything else ("never compromise. not even in the face of armageddon"). defending truth and justice so stridently made him arguably the most heroic, in the comic book sense of the word. but the more realistic portrayal of individuals and circumstances and society as a whole in the watchmen highlighted how ill-fitting such unwavering adherence to principles can be in the real world.

we need to stop talking about the disclosure debate, not because it should be settled already, but because it can never be settled, because it's parameters don't fit the real world. it's the wrong argument. if we really want to help protect one group of people from another group of people then we need to spend a lot more time thinking about those people each and every time the subject comes up. there are no shortcuts when it comes to doing the right thing.

there's a quality problem in the anti-malware industry

if you follow infosec news sources at all, by now you've probably heard about the claim made by an anonymous pair of ex-kaspersky employees that kaspersky labs weaponized false positives.

more specifically, the claim is that engineers at kaspersky labs were directed to reverse engineer competing products and use that knowledge to alter legitimate system files by inserting malicious looking code into them so that they would both seem like files that should be detected and be similar enough to the original file that the competing product will also act on the legitimate file and in so doing cause problems for users of those competing products.

i've heard this described as fake malware, but for the life of me i can't see why it should be called fake. the altered files may not do anything malicious when executed, but they're clearly designed to exploit those competing products. furthermore, there is clearly a damaging payload. this isn't fake malware, it's real malware. it may launch it's malicious payload in an unorthodox and admittedly indirect manner, but this is essentially an exploit.

some consider the detection of these altered files to be false positives because the files don't actually do anything themselves, but since they have malicious intent and indirectly harmful consequences, i think the only real false positives in play here are the original system files that are being mistaken for these modified files.

by all accounts, this type of attack on anti-malware products actually happened. what's new here is the claim that kaspersky labs was responsible at the direction of eugene kaspersky himself. there's a lot of room for doubt. the only data we have to go by so far, besides the historical fact of the attack's existence, is the word of anonymous sources (who potentially have an ax to grind) and some emails that, quite frankly, are easily forged. circumstantially there's also an experiment kaspersky participated in around the same time frame that has similar earmarks to what is being claimed except for the part about tricking competing products into detecting legitimate files as malware.

i don't expect we'll ever know for sure if kaspersky was behind the attacks. doubts have been expressed by members of the industry, but frankly i've seen too many things whitewashed or completely ignored (like partnerships with government malware writers) to take their publicly expressed statements at face value. there are certainly vendors i'd have a harder time believing capable of this but there just doesn't seem to be sufficient evidence that the claims are true. the problem is that i can't imagine any kind of evidence the anonymous sources are likely to have that isn't easy to repudiate. had they taken a stand at the time (like someone with actual scruples would have done) they would have been able to put their names behind their claims - they may have lost their jobs but they surely would have been able to find employment with a different vendor because hiring a whistle-blower would have been good PR.

however, as it stands now, the anonymous sources have to remain anonymous. if they're telling the truth then they are complicit in kaspersky's wrong-doing, and if they're lying they are throwing the entire industry under the bus for no good reason (because this claim fans the fires of that old conspiracy theory about AV vendors being the ones who write the viruses). Either way, to have this claim linked to their real identities now would make them radioactive in the industry. no one would touch them, and for good reason.

long ago it used to be that the industry only employed the highest calibre of researchers. people who were beyond reproach. naturally, in order to grow, the industry has had to hire ever increasing numbers of people and old safeguards against undesirable individuals joining the ranks don't scale very well. increasingly people who aren't beyond reproach are being found amongst the industry's ranks and there appears to be no scenario where these two anonymous sources don't fall into that category. the inclusivity that the general security community embraces (and that the anti-malware industry is increasingly mimicking) has the consequence that blackhats are included. the anti-malware industry is going to have to either figure out if they're ok with that or figure out a way to avoid what the general security community could not.

on exploit detection

data is code and code is data. i know that people like to think of data and code as being inherently different and separate from each other but in the end it's all just symbols in various languages on a real-world analog to the turing machine's infinite tape. fetching the next instruction, decoding it, and performing an operation based on what resulted from that decoding is not intrinsically different from fetching the next chunk of data, parsing it, and performing an operation based on what came out of that parsing. the ability to treat code as data is what allows us to distribute software, and the ability to treat data as code is what allows us to add new functionality to our general purpose computers that they weren't able to do before.

the distinction between programming languages and other input languages is simply that a programming language is intended to be used by programmers to create programs that are used by other people and other input languages are intended to be used by everybody else for (ostensibly) less complex purposes. it's really a matter of complexity, more than anything else, but it turns out that there are many input languages that aren't thought of as programming languages but are turing-complete and so are just as complex as any programming language. further, it's not just that there are two groups of languages (trivial and complex), but rather an entire spectrum.

with that in mind it's little wonder that data in the form of exploits can be just as bad as more traditional malware, but the implications go beyond just that. since data and code are not intrinsically different, since exploits are essentially malicious programs written in the input language for a vulnerable piece of software or hardware, some of the things we know to be true about malware should also hold for exploits.

specifically, the problem of deciding if an arbitrary input exploits a vulnerability seems like it should be reducible to the halting problem. i can certainly imagine trivial input languages where the presence or absence of an exploit is easily decidable, such as one where there are only 2 possible inputs, a legitimate one and one that triggers a vulnerability. however, in general, and certainly in no small part due to the existence of turing-complete languages, i'm fairly confident in saying that this problem is analogous to the virus detection problem. and THAT means that the problem of exploit detection, regardless of how it's approached in practice, is ultimately subject to the same limitations as the problem of virus detection.

to that end, testing exploit detection can run into the same methodological problems that testing virus detection can. for example, creating one's own exploits and testing against those instead of drawing exploit samples from the wild presents the same kind of problem that creating one's own viruses and testing against those would. namely that what is created in the lab does not necessarily correspond to what exists in the wild and so a product's ability to detect what was created in the lab doesn't necessarily correspond to it's ability to detect what's in the wild. certainly it's trivial to see how that would be true for products that detect known exploits using a method similar to known-malware scanning, but even for products that attempt to parse suspected exploits exactly the same as a vulnerable application would this would be the equivalent of emulating suspected viral code which we already know can't work all the time either (otherwise the virus problem would be decidable and we could then use it to solve the halting problem) so there could be exploits in the wild that elude such detection. as such we really should be regarding exploit detection testing that uses in-house exploits on equal footing as virus detection testing that uses lab-made viruses.

sample this

i seem to be getting a lot of mileage out of the NSS folks lately. one might think it's because i have some sort of grudge or maybe that i'm one of the av industry's 'pets' and just defending my master (like i did back when i accused a big chuck of the av industry of being snake oil peddlars, i'm sure). the truth is, however, that NSS Labs have simply given me a wealth of material to work with. please rick or vikram, talk some more.

in a previous post i linked to this video taken at the source boston conference this year. it's a panel discussion with vikram phatak, peter stelzhammer, and mario vuksan, with andrew jaquith acting as moderator. i'm going to be referring to it again in this post - specifically at about 25:00 minutes into the video where vikram talks about exploits.

now i'm going to be generous and overlook the fact that he confuses exploits with vulnerabilities at one point. it's vulnerabilities that are the flaws, exploits are what takes advantage of the flaws. the truth is public speaking isn't necessarily easy and things can come out wrong (or not come out at all), as i found out not too long ago, so it seems reasonable enough to me that he actually meant vulnerability when he said "it's an exploit, it's a flaw in IE or in Firefox or..."

what doesn't seem reasonable to me, however, is the idea he was actually talking about vulnerabilities rather than exploits for that entire part of the discussion. i'm fairly certain he was talking about exploits for the most part, so when he trotted out this idea that there are no samples when it comes to exploits my immediate reaction was "that's bullshit".

we exist in a universe of cause and effect. well, ok, determinism breaks down at the quantum level but at the macroscopic level determinism is the overriding trend - and even more so when we're talking about digital computers because they are deterministic finite state machines. the exploitation of a vulnerability doesn't just happen by magic, this isn't some sort of cyber-voodoo, there is a causal agent, an actor, some chunk of data that the computer receives which, when the computer operates on it, results in the vulnerability being exploited.

and guess what that chunk of data is - that's right, it's the supposedly fictional exploit sample. it doesn't matter that it's not an *.exe or that it may not even be saved to disk, that just makes collecting it more challenging. when asked for a sample, that chunk of data (along with a way to replay it's delivery to the vulnerable system/subsystem) is what is being requested - an example of the agent which causes the vulnerability to be exploited.

at this point some of you might be thinking about the fact that an exploit for a particular vulnerability can take many different forms and might even be thinking that that would make the previously described sample worthless. 'many forms' is not a new concept in the anti-malware field. the fact that an exploit can come in many forms is just another aspect of polymorphism. that's probably not a word that gets associated with exploits very much, in part because of a rather arbitrary convention of differentiating between 'code' and data. code is data, however, and any data the computer bases a decision on is for all intents and purposes the same as an instruction (the data dictates what the computer will do next) and can be considered a kind of code. so while exploits may not superficially resemble other polymorphic things from the past like polymorphic viruses or server-side polymorphic trojans, exploits are programs of a sort and multiple different exploits for the same vulnerability are functionally equivalent programs - which, when considered in that light, actually does bear some conceptual similarity to server-side polymorphic trojans. as such an exploit sample doesn't become worthless just because there are other forms it could take, it just means that detecting that one form represented by the sample is only the beginning.

metasploit open letter revisited

"what we have here is a failure to communicate"

at least, that's what it feels like after fielding a bunch of comments on my last metasploit related post. hd moore specifically felt the need to clarify his view and since it seems that my position could stand some clarification itself i'd like to reiterate my response to him here.

my open letter to the metasploit community was meant to drive home 3 points:

1. AV detection of metasploit output is a problem for anyone trying to use metasploit legitimately and not necessarily appropriate.
2. when people go around saying there's something wrong with AV because it fails to detect metasploit output (in other words, there's something wrong with AV because it fails to do something we've already established would be a problem if it did do) then that actually contributes to the problem by generating market pressure on the AV vendors to correct this supposed problem and add detection.
3. since (1) is a consequence of (2), therefore discouraging (2) should help minimize (1).

(2) is what i saw when i watched john strand's video, but as it happens i've also had a chance to communicate with john and gain a better understanding of where he was coming from (i'd like to think he also gained a better understanding of where i was coming from but that's immaterial for this discussion). i won't divulge the contents of a private communication but i will say that i came away with the impression that he was more interested in showing that there is something wrong with defenses that rely too heavily on what is traditionally considered AV.

if my interpretation is correct then i am in complete agreement with him and i think you'd be hard-pressed to find anyone in the anti-malware community or industry who would disagree. i'd even go so far as to say that his video was an appropriate way of demonstrating that point if that point had been presented in such an unambiguous manner. unfortunately that's not what i took away from it when i first viewed it, and as some of the comments on the 'open letter' post show there are those with a far less nuanced understanding of the topic. i just watched the video again and although i found the phrase that triggered my previous response, in light of my new found understanding i no longer see it the same way.

there isn't anything wrong with AV technology per se (and there are certainly some vendors with more non-signature-related bells and whistles than others), but rather the way people use it (as their one and only defense). it's a poor craftsman who blames his tools, so stop trying to drive screws with a hammer and stop trying to block new/unknown threats with a known-malware scanner.

open letter to the metasploit community

dear metasploit community,

first, please direct your attention to the following video as it demonstrates the very thing i'd like to speak to you about:


as members of the metasploit community, you are no doubt aware of the various legitimate uses for metasploit and the exploits it generates. validating the efficacy of a patch, testing patch deployments, maybe even some penetration testing.

i imagine that you're also aware that some in your ranks have embarked on a wholly misguided ideological quest to highlight the supposed shortcomings of the anti-virus industry using metasploit and it's output.

now let's be clear about something here; we are all in agreement that there are legitimate uses for metasploit's output, therefore that output in general can only be classified as potentially unwanted programs. let's also be clear that the only proper way to address the vulnerabilities that metasploit's output exploits is by patching the vulnerable software. as such, the argument put forward that there's something wrong with anti-virus products that don't detect metasploit output is fallacious on 2 counts: 1) the output isn't necessarily malware (usually only greyware), and 2) anti-virus products are not the proper defense against known exploits (patching is).

there are some concepts in the anti-malware community that some members of the metasploit community may be less aware of than others. one is that there is a countably infinite number of possible programs, and of those a countably infinite number that can do bad things. it is beyond the realm of possibility to detect an infinite number of things so the anti-malware industry has wisely limited it's focus to those that actually exist, to threats that are real, at least as far as malware scanning goes.

another concept which may not be all that apparent is that, while we've faced users of malware creation toolkits for a long time, we have generally lumped them in with the script kiddies due to the complete lack of skill requirements for using such toolkits.

now, even though metasploit isn't a malware creation toolkit (since it's output generally can't be considered malware), it's being used like one in the above video (with the concomitant implication for the user in question). furthermore, this non-malware is being uploaded to virustotal, effectively abusing the service by wasting it's bandwidth on known non-malware, in order to test scanners in a manner that the people who run virustotal themselves say is invalid.

this in turn is putting pressure on av vendors to add detection for metasploit's output, even though that output isn't technically malware, and you know what? as vendors add better and better detection for metasploit's output files, metasploit becomes less and less capable a tool for the legitimate purposes we already identified because anti-virus products will interfere with it's use. how can you use output files from metasploit to validate patch efficacy, test patch deployment, or perform pen-tests if the anti-virus is blocking them? the argument could be made, i suppose, that anti-virus impeding pen-tests is actually a good thing, but it's clear that anti-virus is a fragile defense against exploits when compared to the proper defense of actually patching the vulnerabilities and if AV is interfering with your ability to test if the proper defenses are in place, that really can't be considered a good thing.

with all of this in mind, i would like to ask the metasploit community to do whatever you can to help discourage people from engaging in the behaviour demonstrated in this video. it's arguably worse for the metasploit community than it is for the anti-malware community, but it is definitely bad for both communities and, i think, bad for security in general. no one is helped when people burn one perfectly good tool in order to shame another simply because the tool they're targeting doesn't behave the way they naively think it should.

is secunia the new consumer reports?

(well, looks like i'm going to add to the noise about the secunia test... it's already been discussed on the security fix blog, eset's threatblog, the register, the sunbelt software blog, the panda security blog, and the zero day blog)

so secunia did a test with exploits they developed in the lab and found that av products sucked...

well gee, doesn't that sound an awful lot like the consumer reports test? if you don't make the distinction that exploits are a special case of malware then there would really be no difference between this and that terrible consumer reports test where they paid to have 5000 new pieces of malware created...

but exploit code is a special case, we need to create benign exploits, we need to be able to use them in order to determine whether our systems are vulnerable, whether the patches that supposedly fix the vulnerability have been applied properly, whether they truly fix the vulnerability, etc...

so then this test was alright then, right? nope, not by a long shot... first and foremost is the idea that anti-virus/anti-malware products should detect these lab-grown exploits in the first place... the issue is not so much that av is only in the business of detecting malicious software, it's that there are very good reasons why av can't and shouldn't be detecting benign exploits... as i just got finished saying, we need those exploits, we need to be able to use them, but how are you supposed to do that if your anti-virus is blocking access to them? it's one thing to use a benign exploit to test the vulnerable surface area of your systems, it's another thing altogether to turn off your security software to do so... there are a variety of technical, logistical, and legal reasons why anti-malware must be constrained to detecting only those things with a proven malicious pedigree, and if people don't like that it's just too bad - get over it, those reasons aren't going away just because they don't mesh with your ideology... either exploits are legitimate and necessary, in which case anti-malware apps shouldn't be alarming on them because it interferes with the proper use of exploits, or they aren't, in which case secunia acted in bad faith by creating new malware - secunia can't have their cake and eat it too...

the next problem was this notion of detecting exploitation... read that carefully - "detecting exploitation"... is exploitation a thing? no, it's a behaviour, and despite certain claims from various companies about dynamic behaviour-based heuristics, known-malware scanners (and by all indications that's the only part of the security suites secunia actually tested, begging the question why they bothered with the suites at all - incompetence maybe?) are built to detect bad actors not bad actions... that's not to say anti-malware companies don't have offerings to detect and even block bad or unauthorized behaviour, they do have HIPS offerings, but it's fundamentally different technology from what people are accustomed to with anti-malware and it's not always simple to setup/maintain properly so they don't necessarily bundle it with their anti-malware products or even in their internet security suites...

speaking of the distinction between actors and actions, that confusion seemed to be rooted in the use of the term "threat"... i have in the past remarked that "threat" is a bit of an ambiguous term where all kinds of things with "threat" in their name get called simply threats... in this case in particular, anti-malware apps use the term "threat" as a short form of "threat agent" (which is actually one of the more common things that "threat" is used to represent)... exploitation isn't an agent by any stretch of the imagination but because everything gets called simply a "threat" those who don't really understand what's going on (which surprisingly seems to include the folks at secunia) will treat all usages of the term the same and not realize that anti-malware scanners are only designed to catch some of the things that get called "threat"...

of course, a post on this site wouldn't be complete without pointing out the conflict of interest that is also present in this test... secunia's business is about vulnerabilities and exploits - they have a paid product for detecting vulnerable software (a different approach to the same ends as trying to catch/block the exploits) so it's in their financial best interests to publish a test that makes the anti-malware industry look bad (aka FUD) and the exploit problem look important (in other words, hyping up the problem)... it's a classic self-serving study and one wonders if the people responsible think the rest of us were born yesterday...

no such thing as non-executable files

i happened to notice a post by benny ketelslegers presenting a digested view of a symantec post by andrea lelli on file format vulnerabilities... i didn't give the symantec post much thought when i first encountered it, but when i read benny's post i realized that i (and perhaps many others) have been taking the issue of executable files for granted and that the word choices being made could lead to an altogether wrong concept of what a program is and by extension what sorts of things can effectively be malicious agents on a computer...

perhaps my first exposure to the idea that there are no non-executable files came when i was still a teenager learning that for every sequence of bytes there exists a turing machine for which that sequence of bytes is a virus... i didn't even really know that much about turing machines at the time (other than they were a way to model computers) but i understood what it meant - for every sequence of bytes there exists a possible computing environment where those bytes are interpretable as a self-replicating program...

it's an interesting statement, but it's awfully narrowly focused on viruses... it turns out that the focus on viruses was just because of the context... in reality, for every sequence of bytes there exists a possible computing environment where those bytes are interpretable as a program...

that probably still sounds pretty formal to the average person, but not as formal as fred cohen's reference to the generality of interpretation... the simplest way i can express this is that there is no fundamental difference between data and code, that program code basically is data but that it's data for which there happens to be some part of the computer (some other program or subsystem) that will treat it as a collection of one or more instructions... any piece of data you can imagine can potentially be interpreted (or even misinterpreted) as program code, although it may not have much meaning or do anything useful as a program...

this ability to treat arbitrary data as code is what allows us to add new, previously unimagined capabilities to our computers in the form of new software... it's what makes our general purpose computers 'general purpose', but there's still more to the story... the ability to treat a particular chunk of data as code in practice may not even be intentional, it can be an emergent property resulting from excessive complexity and/or poor implementation... this leads to what i often refer to as exotic execution and data that makes use of such a property is generally referred to as an exploit...

all this is to say that all data may also be considered by the computer to be program code under the right conditions, and determining if those conditions have or have not been met can be very hard... as such, to say something is not program code, to say that it is non-executable is an oversimplification that can (especially when uttered by authoritative sourced like symantec) promulgate an idea that there are safe, non-executable file types which in turn gives people a false sense of security when handling those types of files...

indeed, the majority of the file types referenced by the symantec post explicitly support the ability to contain code that their respective reader applications are intended to execute (whether that be javascript in pdf documents or visual basic in microsoft office documents)... the fact that those file types can also carry known exploits should have little bearing and the very fact that people need to be corrected about the safety of such files points to a more endemic false sense of security about data in general... there are in fact no safe file types and no such thing as non-executable files...

vulnerability research vs. malware research

well, i said i was tempted to write a post on this topic, and even though it turns out i've written about it several times in the past (viruses and disclosure, malware and disclosure, full disclosure to name but a few) i'm going to try it again in hopes that after this one i won't ever have to repeat myself on this subject again (yeah, as if)...

as always, the most interesting debates wind up being about meaning, so lets define some terms for the sake of this discussion... a vulnerability is in essence a mistake that allows a component or service of a system to behave in an unexpected and unintended way that has a negative impact on the security of the system (i know not everyone ascribes to the mistake definition, but it's useful to draw a distinction between those vulnerabilities which can be fixed and those that can't - rest assured i will cover the alternative later)... vulnerability research, then, is the process of discovering these mistakes; sometimes by looking at source code, sometimes by reverse engineering the vulnerable system, sometimes even by accidentally or intentionally triggering the unintended behaviour... now there's a pretty broad consensus (with the exception of the bad guys) that vulnerabilities are bad so naturally we want to get rid of them, and because they're mistakes they can be fixed... however, because vulnerability research is often performed by people other than those who made the vulnerable system in the first place, it becomes necessary to find a way to demonstrate the existence of the vulnerability to others... further, those tasked with fixing the vulnerability require a reliable means of triggering the unintended behaviour in order to determine why that behaviour occurs and in order to ensure that whatever fix they put in place actually fixes the vulnerability... therefore we need an exploit to trigger the unintended behaviour so that the vulnerability can be demonstrated to others to convince them that a fix is needed, and also to test for the presence of the vulnerability when developing (or even applying) a fix...

of course with those uses in mind it's important to make the distinction that what we want in the way of exploits are actually benign exploits (as opposed to malicious/weaponized ones)... for example, when dealing with an arbitrary code execution vulnerability, an exploit that launches notepad is preferable to one that launches tftp with command line parameters to download something malicious from the internet and then subsequently launch that... you see exploits can be used for malicious purposes as well as the positive ones already described, and the less benign the exploit is the easier it is for a bad guy to do something bad with it...

now so far i've described exploits as things that are able to demonstrate the existence of a mistake that we want to fix... clearly when that mistake isn't present the exploit shouldn't work so we can say that the exploit depends on the existence of the mistake/vulnerability...

malware is a different beast entirely because it doesn't (in general) depend on the existence of a mistake or vulnerability... what does it depend on? well, from one of the seminal pieces of research on viruses we know that self-replicating malware depends on 3 things: the ability to share data (necessary for the attacker to get his malicious software from his own machine to the victim's machine), the ability to pass data that's been shared with you along to others (sharing transitivity - necessary for self-replicating malware to spread or pass itself along), and the ability to interpret data that's been shared with you as program code (ie. the ability to add to or change the set of things the computer is willing to execute - the generality of interpretation - necessary for the computer to be able to execute the new incoming malware)... none of these things can really be considered flaws or mistakes, in fact it's hard to imagine computers being as useful as they are without them... without sharing there would be no internet, no floppy/cd/dvd drives or printers (they would allow sharing over the sneakernet), no store-bought software (you'd have to make all the software, including the operating system, yourself), etc... not being able to pass anything along would be equally bizarre (though that's the world that hollywood envisions and tries to make real through the use of DRM), it would also make the division of labour very hard to manage because hierarchies would be impossible (your boss wouldn't be able to pass along to you anything his boss had given him, nor would he be able to pass along to his boss anything you had produced)... not being able to interpret data as program code would be the most profound change of all as it is this property that makes the general purpose computer a general purpose computer rather than a pocket calculator - it allows a single computer to be flexible enough to be used for many changing purposes and without that flexibility we'd need a different piece of hardware specially designed for each and every new task that came our way... it should be clear that these are things we neither can nor want to 'fix' and so self-replicating malware will always be possible... it turns out that all sharing transitivity does for self-replicating malware is allow it to spread, so we can therefore say that in general non-replicative malware doesn't need it (though that doesn't necessarily mean some specific instances won't use it, such as for the command and control of more sophisticated botnets)... there are no additional dependencies worth mentioning for non-replicative malware in general (the exception being exploits, which can be considered a type of malware and obviously depend on vulnerabilities) because the underlying functionality they use is the same functionality used by normal software, it's just that that functionality is used to perform actions we don't want performed... communicating with a remote site the way RATs, botnets, and spyware does is just sharing of messages, and we've already covered sharing... writing to the hard disk is pretty fundamental and can even be considered a kind of sharing between sessions or a prerequisite of media-based sharing... outputting to the screen (something adware necessarily has to do) is necessary in order for the user to properly interact with the computer (and really all input and output can be considered as falling under the umbrella of sharing)... since there are no dependencies in general that can be 'fixed', this case therefore covers the alternative of the vulnerability that isn't a mistake...

now a clever reader at this point would be asking him/herself how much sense it makes to perform the previously described type of vulnerability research on a vulnerability that can't be fixed... a knowledgeable reader would know the answer: it doesn't make sense to perform that sort of research... an argumentative reader might point out that such malware can exploit fixable vulnerabilities too, but the answer to that is to research the fixable vulnerability and look at the exploit for that on its own rather than connected to more general malware...

so how does that change the nature of research around malware? well for one thing the previously discussed benefits of creating benign exploits don't apply in malware research because they were all predicated on the idea that what allowed the thing to exist could be fixed... we know that's not generally true for malware and in the cases where it is true it's because the malware contains an exploit that can exist separate from the malware and be used that way instead of connected to the malware (which only serves to make the exploit less benign)... additionally, because malware in general depends on non-fixable properties of a system (not to mention they're less benign), the benefits that society reaps from sharing benign exploits with the public at large also don't apply to malware for essentially the same reason...

another, more intrinsic difference between the two research fields is that in vulnerability research we create a special kind of malware called exploits as indicators of the presence of the vulnerability but in malware research we do not create any kind of malware as an indicator of the presence of malware (that just wouldn't make sense)... creating malware in the course of doing malware research would actually be analogous to creating vulnerabilities in the course of doing vulnerability research... the reason we create indicators for vulnerabilities is that the vulnerabilities themselves are not exactly visible or shareable, they aren't distinct entities in and of themselves, whereas if i want to show you a piece of malware i give you the actual malware...

a third difference between the two research fields is that there is (according to popular informed opinion) a discrete, finite number of vulnerabilities while the number of possible malware is, theoretically, countably infinite - limited in practice only by the available storage space... so while it may make a certain kind of sense to enumerate vulnerabilities, making an exploit for each one so that the vulnerability can be mitigated (hopefully before it gets used by the bad guys), it's a very different idea to try and enumerate all possible malware in hopes of being able to mitigate all of them (because there's just too many of them and because there are so many, most will actually never actually be made by either the good guys or the bad guys)... furthermore, while it might seem feasible (or at least within the realm of hope) to stay ahead of the bad guys with regards to vulnerabilities, no matter how many pieces of malware we preemptively make in order to mitigate them the chances that we will block a bad guy by beating him to the creation of a particular piece of malware is essentially zero... the malware we might make is practically guaranteed to be different from the malware the bad guys will make...

by now you should be starting to see how different malware research is from vulnerability research and how pointless creating malware for the purposes of malware research is compared to creating benign exploits for the purposes of vulnerability research... instead, malware research focuses on malware that has already been made and classes of malware that already exist... rather than creating malware and hoping in vain that the bad guys malware will have the same properties, malware researchers share data with each other about new malware trends while they're still in their early stages and make educated guesses about what the next step will be... sometimes their predictions are right (such as storm botnet nodes being used in phishing, which was predicted when it was observed that the botnet was becoming segmented) and sometimes they aren't (or at least aren't yet, like some of the more ambitious predictions about mobile malware)... as such, malware researchers also look at the human attackers creating/using the malware - trying to guess their motivations, gaging their skill level, determining their connections with others, etc, because all those things are important in predicting what they might do next... enumerating possible future malware is not nearly as useful or accurate as a predictive tool in malware research as it's counterpart is in vulnerability research...

given these profound differences, it really makes very little sense to treat malware research the same as vulnerability research or malware in general the same as a benign exploit...

what is a drive-by download?

a drive-by download is a form of exploitation where simply visiting a particular malicious website using a vulnerable system can cause a piece of malware to be downloaded and possibly even executed on that system...

in other words it's a way for a system to be compromised just by visiting a website...

the vulnerability(s) exploited in order to cause a drive-by download can be in the web browser itself or possibly in some other component involved in rendering the content of the malicious page (such as a multimedia plug-in or a scripting engine)...

drive-by downloads are particularly pernicious for two reasons... the first is that it can be hard to avoid being vulnerable and still maintain the functionality people have come to expect from the web... all software has vulnerabilities at least some of the time and there may be quite a few pieces of software on a given system that deal with web content (such as real player, quicktime, flash, adobe acrobat reader, etc) that may have vulnerabilities... add to that the fact that vulnerabilities aren't always fixed right away and that many users don't apply patches or updates as soon as they're available and you wind up with a fairly large pool of potential victims...

the second reason they are so pernicious is that it can be hard to avoid being exposed to an exploit leading to a drive-by download... the exploit can be delivered through legitimate, high profile, mainstream sites by way of the advertising (or other 3rd party) content on the site... if the ad network that supplies the advertising content is infiltrated by cyber-criminals (which has been known to happen) then they can sneak a malicious ad into the network's ad rotation and get it inserted into otherwise trusted and trustworthy sites... for this reason the old advice of only visiting trusted sites can't really protect you from this type of threat...

back to index

the stupidity of exploit wednesday

exploit wednesday is the day after patch tuesday, so named because apparently exploits get released on that day supposedly so as to maximize the length of time the exploit can be used against systems...

but who says the day after patch tuesday is the best day to release exploits? does it really maximize the window of exposure? if an exploit were released one day earlier (ie. the same day as patch tuesday) would there really be time for microsoft to create and test a patch to be included in patch tuesday? how about 2 days earlier (as in today, the day before patch tuesday)? how about 3?

if we look at history, what is the shortest time microsoft has ever needed for researching, addressing, testing, and deploying a patch? an exploit should be releasable before patch tuesday so long as there isn't enough time for the patch to be included... right now there are currently 2 unpatched microsoft word vulnerabilities (one of which has been known about for a week or more) with exploits being used in the wild and they aren't getting included in tomorrow's patch roll-out because there wasn't time to go through the extensive development and testing process that microsoft puts patches through before deploying them...

if the exploit is serious enough to warrant an out of cycle patch then it doesn't matter when you release it because you won't be able to manipulate the size of the window of exposure through timing the release... otherwise the maximum window of exposure is achieved by releasing {minimum microsoft patch time} - 1 days before patch tuesday...

if the bad guys who make and sell the exploits don't know this yet then they're morons... if the bad guys who buy the exploits haven't figured this out yet and agree to an exploit wednesday release date then they're also morons... if the good guys are expecting the bad guys not to figure this out, if they genuinely don't expect to see many exploits until exploit wednesday then they are naive and they're eventually going to get caught with their pants down...

what is a zero-day exploit?

a zero-day exploit is exploit code that is in the wild (being used on computers in the real world rather than just a lab) on the same day (or even earlier) that the vulnerability it exploits is discovered by the good guys...

often the vulnerability is discovered by virtue of discovering the exploit code (ie. the exploit code reveals the presence of the vulnerability)...

the zero-day adjective dates back at least to the early warez days where releasing a pirated copy of something while it was still zero days old was something that was handsomely rewarded by others in the scene...

back to index

what is an exploit?

an exploit is something that takes advantage of (or exploits) a defect or vulnerability in either an existing piece of software or hardware.

unlike most forms of malware, an exploit is not necessarily a program in the traditional sense. while it can be used to refer to a program specially written to communicate bad input to a vulnerable piece of software, it can also be just the bad input itself. any bad input (or even valid input that the developer just failed to anticipate) can cause the vulnerable application to behave improperly. in the sense that all data is code and all inputs form languages, however, an exploit can be thought of as a program written in the input language of the vulnerable software.

because exploits may simply be bad input rather than an application, they may act in the context of an exploited application without first being saved to disk. this is a problem for conventional anti-malware apps that focus on scanning for malware on disk hopefully before it has a chance to execute (often just before they execute if you're using an on-access scanner). in the case of an exploit it can be a legitimate but vulnerable application that is running and performing the malware functions so a known malware scanner would have to scan the vulnerable application's input in order to address this case.

although malware is generally not based on exploiting software vulnerabilities and therefore not inherently dependent on them, it is possible to make malware in part or completely out of exploit code. such malware would then depend on vulnerabilities by definition.

if the malware is completely dependent on vulnerabilities it can be an exception to the general rule about disclosing malware not leading to the closure of any window of exposure, since it's disclosure would make the affected vendor(s) and community aware of the vulnerability and place pressure on the vendor(s) to get it fixed. however disclosing a working exploit still arms the bad guys - it should be possible to disclose the vulnerability that the malware exploits without giving out the actual malware (thereby helping to close the window of exposure without arming the bad guys as they'd have to come up with their own exploit), so disclosure of exploit based malware is still a bad thing to do.

like adware, exploits aren't necessarily always malware. a non-weaponized exploit can be used to test for the presence of a known vulnerability after a patch for the vulnerability has been made available so that people can determine if they need the patch and/or if the patch installed properly and/or if the patch is effective. this kind of exploit disclosure actually facilitates the closure of the window of exposure for the vulnerability in question.

(updated to integrate a somewhat language-theoretic view of exploits)

back to index

socketshield hope and hype

i recently heard about an anti-malware app called socketshield that, like most new apps, is being hyped as being the best thing since sliced bread so i decided to look a little deeper...

essentially the product is a known-malware scanner (specifically a known-exploit scanner) that operates at the socket level, meaning that anything that connects to the internet would have it's traffic filtered by this scanner... that's not hugely interesting, though it does fill a niche as other somewhat comparable products i've heard of restrict themselves to specific protocols like smtp or http, so they play up their intelligence gathering efforts hoping (probably correctly) that most prospective users won't realize that much of those things are entirely analogous to methods used by more conventional anti-malware vendors... for example:

• an extended network of human researchers exists in the anti-virus industry, one need only look at the list of contributors to the wildlist to see this...
• honey pots and search bots and the like are used routinely in the anti-malware domain... just look here, here, and here for a few examples...
• a "technology that creates a filter for known and suspected exploit distributor sites" sounds an aweful lot like automatic signature extraction... i know they're not exactly the same thing but they both boil down to technologies to generate matching criteria algorithmically...
• a "community of ... users who allow information about attempted exploitation of their computers to be transferred back to..." is very much like the statistics gathered by many online virus scanners...
• a "correlation engine" that collects all the intelligence gathered by various means and distributes it back to the users sounds suspiciously like an auto-update facility... theirs is real-time instead of periodically polled - big whoop...

i think you'll agree that it's all pretty bland when you really think about the meaning of what they're saying...

they're just trying to differentiate themselves from the countless other security vendors on the market, and i can understand that but it seems like some people misunderstand both the originality and application of the technology... it's not an anti-rootkit technology (or an anti-stealthkit technology) per se, it's just a known malware scanner operating on network traffic and focusing on exploit code that would otherwise be used to download/install/execute more conventional malware (which i suppose makes it anti-exploit technology - which is fitting since it comes from a company called exploit prevention labs)... they're also not doing anything wildly unique when it comes to gathering information about new exploits - they're just playing it up more because the average consumer doesn't understand or appreciate the implications of what is really noteworthy about the technology - it scans for malware on the wire rather than on the disk, so it has an opportunity to stop exploits for your browser, email client, or other internet-facing software from reaching their intended targets... conventional scanners often have difficulty with this because they focus on scanning files on the local hard disk and more and more frequently systems are being initially compromized by code that never reaches the hard disk or reaches it after it's already been run...

on that matter, they do have a claim on their product information page that i must take issue with... they claim "Anti-virus and anti-spyware programs only detect exploits after the damage has been done." which is technically false - these programs detect malware on disk... sometimes that winds up being after the damage has been done, but historically they've dealt with the kind of malware that has to be a file on your hard disk before it can run and so that window of opportunity allowed their products to be used for prevention as well as cleanup...

that said, as the internet becomes increasingly ubiquitous and feature-rich, we're moving closer and closer to a network computing platform and this technology represents the network computing analog of on-access scanning - we need anti-malware vendors to make this kind of technology more ubiquitous as well... malware that runs in the browser or in a plug-in or some other network-related application is not as vulnerable to being scanned on disk before execution and the anti-malware world needs to catch up..

update from crazyworld

so guess what - Publishing exploit code ruled illegal in France...

guillermito will have to pay 5,000 euros if he publishes security vulnerabilities again... that's right, security research is basically illegal in france now so don't you be making fun of any of those french products that really, really suck...

but wait, there's more (there always is with this case)... if you read this article you'll see that tegam is defending it's actions by saying that guillermito's claims are false and his motives questionable... ooops! if his claims are false then the exploits he supposedly published must not actually exploit weaknesses in the product - in which case he didn't publish exploits, only defamatory material, in which case tegam's current claims against him are baseless... but since a court of law agreed with tegam's claims they must not be baseless, in which case the exploits are real, in which case his claims are true rather than false... you can't have your cake and eat it too, tegam...

i swear this company must be run by untrained monkeys...