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.
34 comments:
I kinda disagree with one of your arguments. I think that anti-virus programs should detect exploits - and should prefer detection of the exploit itself to the malware that uses it, precisely because this way it will catch the infinite number of possible malicious programs that rely on the said exploit. After all, exploit detection is a kind of generic malware detection. Saying that "patching is the proper way to protect from exploits" is like saying that "backup is the proper way to protect from malware" - true in theory but meaningless in practice.
Sadly, very few anti-virus programs try to detect exploits as opposed to the malware (shellcode, payload) that uses them. I try to do that whenever possible in our scanner (F-PROT) - but nevertheless it too detects too few of them. (One of the problems is that the information provided by Microsoft about the known exploits in their products is often late, incomplete, plain wrong and/or causes false positives - but let's not get into that.) Nevertheless, when our scanner reports an exploit (it uses the CVE nomenclature), it is precisely the exploit that has been detected and I guarantee you that we'll detect all possible malware that uses this particular exploit.
well, i don't really disagree with the sentiment that the more bad things a scanner detects the better - so in that sense i'm not saying scanners shouldn't detect exploits, BUT clearly when scanners do so it creates other problems. it creates a state where anti-virus interferes with the legitimate usage of exploits so that in order to use them the AV has to be turned off (and that's not really a good thing to do in general).
i definitely don't agree with the notion that the preference for an optimal solution is meaningless in practice, however. it is far better to make a system invulnerable to a particular thing than to set up a guard well versed in catching a particular thing.
nor do i agree with the comparison between the protective capabilities of patching and the protective capabilities of backups, as backups aren't a preventative strategy but instead a restorative strategy.
on the other hand, it's good to hear f-prot has such complete detection of the exploits you've handled. presumably at some point you'll be able to reach 100% detection of metasploit output files and then the script kiddies who make use of metasploit won't be able to get anything past you.
The issue with AV is that as a technology, its fatally flawed. Most real-world zero day is not detected by AV until it reaches critical mass. The encoding methods within Metasploit allow the good guys to verify this behavior, but at the end of the day its actually easier to do with purpose-built tools (binders, packers, etc). Penetration testers need the ability to create attacks without an existing signature; this is a hard fact, as the goal is to emulate what a real world attack looks like. My personal beef with AV is unrelated to this issue entirely; most AV products don't just flag the Metasploit installation as a Potentially Unwanted Program, they go further and corrupt the directory structure and mark various exploit modules as "Trojans" of various sorts. This leads to a major support headache on my end for no additional security for the user.
@hdm:
with all due respect, the issue with your argument is that it's fatally flawed.
zero-days? seriously?
limitations are not flaws, true zero-days are outside the scope of what scanners are good at, and they also represent only a portion of the threat landscape. if you're using anti-virus scanners expecting them to stop zero-day threats you might as well use a hammer to drive screws while you're at it. there are other tools better suited to that particular job. i would have thought you of all people would know that.
as for the corruption and flagging things as trojans - who do you think is responsible for that? who do you think created the demand for av to look at metasploit at all? the people engaged in the very behaviour i'm trying to prompt you folks to discourage. if you condone, or worse encourage, such behaviour then increasing problems co-existing with av is the reward you can expect to reap.
No argument about the positive uses for Metasploit.
But I believe the argument that Metasploit output should not be detected by AV is misguided. The positive use of exploits, whether through Metasploit or otherwise, is an exception. If present anywhere but on equipment set up for the purpose, by those with the necessary rights, authorization and competence, exploit code has no legitimate function except as part of malware (or it's creation).
Therefore, the legitimate presence of Metasploit output must be an exception, and all other uses should be considered a potential threat and caught in the same manner as malware.
@itinsecurity:
that sets up an unfortunate situation where only metasploit is allowed to legitimately use exploits and no one can be allowed to compete with the project.
that seems like it would be a bad thing.
"If present anywhere but on equipment set up for the purpose, by those with the necessary rights, authorization and competence, exploit code has no legitimate function"
the same can be true of any number of administrative tools. even FORMAT.COM has an exceptionally narrow set of legitimate use cases. this is why i suggested that exploit code be classified as a potentially unwanted program.
if you use the term "zero-day" to be more broad rather than strictly a colloquial term for unreported exploits, HDM's argument absolutely applies. signature-based anti-virus died a long time ago, and it's hilariously simple to circumvent current anti-virus heuristics. in fact, sometimes you don't even have to try to circumvent said heuristics even when you've written a simplified, well-worn-path of malware. this is not to say that anti-virus programs are poorly written-- this is an extremely difficult problem to solve.
this goes right to the heart of HDM's main argument-- it's horrendously flawed for this reason. undetected malware threats are a real issue, and transforming your malware to avoid programmatic detection is not difficult in the least. with the constant rise we're seeing in targeted attacks, HDM is absolutely correct.
"that sets up an unfortunate situation where only metasploit is allowed to legitimately use exploits and no one can be allowed to compete with the project."
Yes, if you assume a general exception for it. I agree, that would be bad. I was picturing more of a case-by-case exception, even if that means turning off your AV for the run.
As for classifying it.. even if classified as 'potential', I will have my AV block anything 'potential' unless explicitly allowed anyway.
@itinsecurity:
i too would have my AV block it when possible. i wouldn't expect for it to be possible, though. when it's possible i consider it an added bonus, but there are better ways to deal with vulnerable software and the associated exploits. AV should not be your only layer and i would not rely on it for this.
@anonymous:
i used the term "zero-day" in my response to HDM to refer to anything new, not strictly to unreported exploits.
as such you may want to reread my response to him in that new light because the only horrendous flaw here is in the logic of using a tool meant for known things against unknown things. that's not a problem with the tool but with the person using it.
stop using a hammer to drive screws.
What do you have against capital letters?
@anonymous:
"What do you have against capital letters?"
absolutely nothing. i even use them in formal communications or occasionally for acronyms.
Given the new comments on this post, let me clarify my view. I disagree with this post because penetration testers are running into AV issues and we, as the Metasploit development team, view this as an obstacle to our application working as intended. We can argue all day about how customers shouldn't be using AV to block exploits and social-engineering attacks, but the fact is they do, and because of this, products like Metasploit need to be aware of it and provide workarounds.
If a legitimate tester's attack is blocked *because* the AV has a signature for the tool they used, this leads to a false sense of security for the end customer and frustration for the tester. The fact that AV vendors feel they need to compete for non-malware signatures is a real problem, but it is their problem, not ours.
As long as AV vendors block legitimate testing tools, we will continue to develop new ways to evade them. This is an arms race, but we don't have to win the race, we just have to stay slightly ahead, most of the time.
@hdm:
i don't think we're in as much disagreement as you seem to think we are.
this post was mean to highlight 3 things:
1) that AV detection of metasploit output is a problem for people legitimately trying to use the framework (which you seem to be agreeing with).
2) that people who go around saying there's something wrong with AV because it doesn't detect metasploit output actually contributes to the problem outlined in (1) by creating market pressure the AV vendors can't reasonably be expected to ignore.
3) since (1) is a consequence of (2), discouraging (2) should help minimize (1).
my open letter offers a practical suggestion on how you can combat the very problem you're describing.
Hi Kurt! We agree on the main points, my confusion relates to this line:
"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"
I think what you are saying is that publishing a video trouncing an AV product for coverage is bad. I read your statement to mean that using services like VirusTotal before a penetration test is bad, which I disagree with. Thanks for clarifying!
Embedding an MSF payload into an executable turns that executable into a Trojan. When that Trojan is executed, there is no exploit of a vulnerability taking place, as code is just being executed directly by the user or system. How can you seriously argue that a Trojan is not malware and therefore out of scope for an AV product to detect?
@hdm:
it looks like we're getting onto the same page. you're right that my statement was more about trouncing an AV than the practice of using virustotal before a pentest.
however, now that you mention it, running custom malware through virustotal prior to a pentest may be sub-optimal. the bad guys don't do this anymore because virustotal auto-submits to vendors. instead the bad guys now have their own multi-scanner services to use. if you're going to simulate the actions of a bad guy, that particular detail might work in your favour.
i only make this suggestion, of course, with the understanding that legitimate pentesters' custom malware will not see the light of day and will only ever be used in controlled environments.
@druid:
try checking out what i've written about how problematic trojan classification can be due to the context sensitivity of it's NON-functional definition (defined by things other than function).
metasploit output generally is greyware, not malware, precisely because of the context of it's use.
From reading your "Malware Classification Fail" post, I'm not sure you understand what a Trojan is. It's definition is quite specific and generally unrelated to the context in which it's employed, and as you incorrectly indicate in that post has nothing to do with whether or not a user is tricked into executing it. How it ends up executing is irrelevant; the term describes properties and behaviors of a particular class of malware. While I agree with your point in that post that AV vendors over-classify things as Trojans, you seem to be making a similar mistake in assigning intent or execution vector to the term, which is inappropriate.
However, playing by your rules, the context that Metasploit is used in the video that you posted, as an example of what you are talking about, was with the intent to create a classic Trojan, i.e., a non-replicating executable that appears to perform one benign or desired function while simultaneously providing access to an unauthorized entity. It's most definitely malware, not grayware, as it's obviously malicious due to the particular payload that was embedded. Had he embedded calc.exe, I'd agree that it would be grayware as then it would both fail the providing access requirement as well as being non-malicious.
I also think a problem you're running into is that you're trying to group everything that Metasploit can possibly produce into one big "Metasploit output" bucket. Metasploit is many things to many people, and this is grossly over-generalizing. Again, in the video you posted, Metasploit was being used as a malware (specifically, Trojan) creation tool.
Finally, people say there's something wrong with AV because its a fundamentally flawed technology, not because it specifically can't detect malware that is created by Metasploit. This was the point that I took away from the video, and from reading your "Open Letter Revisited" post, you seem to agree. It's flawed because it's a reactive technology, and cannot be expected to catch new and unknown malware. My point was that once malware has been created with Metasploit, that particular piece of malware is then well within scope for AV detection. Just be glad that he's uploading his malware to VirusTotal so that it gets indexed (:
Hi Kurt,
Thanks for the article. As a metasploit user and pentester i appreciate it.
I do however have a problem with your pitch.
If anti-virus is not responsible for catching zero days, encoded malware, or stand alone payloads, why do they (the anti-virus companies) use it as a selling point?
Look at every enterprise anti-virus/anti-malware web page and there is a two sentence blurb outlining "protection from zero-day attacks." or other such garbage.
Maybe re-defining the categories of malware is necessary, but if you sell me an "all purpose screwdriver" im going to expect it to screw anything even a really obscure screw ;)
Of course "we" as a security community know what AV/AM does/doesn't do, but we dont write the product descriptions.
We are responsible for testing the environments they are deployed in and highlighting their effectiveness vs real attacks. If they say they combat these types of attacks, and they don't, i consider that a fail.
Even worse if they claim to combat these attacks and an out-in-the-open encoder/tool can bypass them, i'd hate to see the skiddie (or god forbid APT ;) with some real underground stuff.
much respect,
-Jason
@druid:
i'm sorry but on this we disagree - deception is the defining characteristic of a trojan, not construction (it doesn't matter if something is made the same way a trojan would be). i don't know what half-baked jargon file your definition comes from, but if it doesn't hinge on deception then it doesn't agree with what the anti-malware community has been using for the past couple decades.
as for the argument that the files pen-testers use meeting the basic qualifications for my definition of trojan, i again point out the context. legitimate pen-testers have authorization do perform their tests, so although the person at the keyboard may not agree with what the program is doing, the people in charge have authorized it.
finally - if you took away from my open letter revisited post that i agree that AV is fundamentally flawed then you need to reread my closing paragraph as it contradicts that interpretation in a fairly unambiguous way.
@jason:
i have 2 words for you "marketing lies".
you don't believe drinking a certain brand of beer will cause you to be mobbed by beautiful women, right? well if you're smart enough to know not to believe beer advertising what's stopping you from making the same connection with technology?
that's just one aspect of things, of course - another is that AV vendors have additional technologies that actually are fairly effective against new/unknown malware, but those technologies are not part of the scanner and cannot be demonstrated by poorly executed tests (mis)using virustotal.
Please re-read my response. I said nothing of construction when speaking to the definition of a Trojan. It doesn't matter if it was constructed with Metasploit, some other toolkit, or even by hand. I agree that deception is a defining characteristic, but it is deception in FUNCTION (when it appears benign when executed but is allowing unauthorized access in the background), not in how it ends up being executed. Deception used to get it executed in the first place is considered social engineering, commonly of the phishing variety.
Again, the context is irrelevant. Whether the Trojan is used maliciously or as part of an authorized pen-test, it's still a Trojan. The term defines function, not construction or motive.
@druid:
my apologies, when i mentioned construction it was in reference to your first comment here, not your most recent one. it implied that following constructive process X results in trojans.
however, we are still in disagreement over what is an isn't a trojan. since i have a post specifically about the definition of trojan (here) i'm going to simply have to refer you to that and if we still don't see eye to eye then i suspect a resolution will not be forthcoming regardless of how long we drag this comment thread on.
After reading the post on the definition of a Trojan that you referred me to, I have two thoughts:
Your first paragraph is *almost* a correct, accepted definition of a Trojan, and you should have stopped right there. The bit that doesn't fit with your definition is the user's "belief" that you mention. The program either does or does not perform a benign or expected function in addition to the covert malicious function; it has nothing to do with whether or not the user believes it will. The classic definition also had the requirement that the malicious bit provided unauthorized ACCESS, hence the namesake, but for the sake of this argument we'll use the more modern definition that you used in the post that you referred me to.
The entire rest of that post is completely misguided. Of particular concern is your example of renaming format.com to best-blowjob-ever.com thus turning it into a "potential trojan", which is then only determinable by assessing the intent of the person that renamed it or the belief of the person that is executing it. This executable is not a Trojan. Simply renaming an executable, regardless of intent, does not make it a Trojan. Primarily it fails the "does something expected/benign while also covertly doing something else malicious" requirement. Had the renamed executable ACTUALLY given the user a blowjob, or shown a video of a blowjob, or did pretty much anything else to do with a blowjob, while ALSO covertly formatting their drive, THEN it would be a Trojan. format.com, renamed, is still just an executable who's primary function is to format a disk.
I overheard this earlier today, which demonstrates the fallacy of your definition:
dude1: "hey, you should take a look at this Trojan"
dude2: "that's not a Trojan"
dude1: "why is that?"
dude2: "because you told me it's a Trojan"
Anyhow, it's clear that you have a much broader (and in my opinion, incorrect) definition of the term Trojan than what is found in the accepted nomenclature. I suggest that you do some reading regarding the term and it should become quickly obvious that the term "Trojan" is indeed a functional definition describing the malware's behavior, contrary to what you claim.
http://lmgtfy.com/?q=definition+of+Trojan+horse+malware
At this point we'll agree to disagree.
google has just farked up a comment that i accepted. i'm going to try and repost it for the commenter.
After reading the post on the definition of a Trojan that you referred me to, I have two thoughts:
Your first paragraph is *almost* a correct, accepted definition of a Trojan, and you should have stopped right there. The bit that doesn't fit with your definition is the user's "belief" that you mention. The program either does or does not perform a benign or expected function in addition to the covert malicious function; it has nothing to do with whether or not the user believes it will. The classic definition also had the requirement that the malicious bit provided unauthorized ACCESS, hence the namesake, but for the sake of this argument we'll use the more modern definition that you used in the post that you referred me to.
The entire rest of that post is completely misguided. Of particular concern is your example of renaming format.com to best-blowjob-ever.com thus turning it into a "potential trojan", which is then only determinable by assessing the intent of the person that renamed it or the belief of the person that is executing it. This executable is not a Trojan. Simply renaming an executable, regardless of intent, does not make it a Trojan. Primarily it fails the "does something expected/benign while also covertly doing something else malicious" requirement. Had the renamed executable ACTUALLY given the user a blowjob, or shown a video of a blowjob, or did pretty much anything else to do with a blowjob, while ALSO covertly formatting their drive, THEN it would be a Trojan. format.com, renamed, is still just an executable who's primary function is to format a disk.
I overheard this earlier today, which demonstrates the fallacy of your definition:
dude1: "hey, you should take a look at this Trojan"
dude2: "that's not a Trojan"
dude1: "why is that?"
dude2: "because you told me it's a Trojan"
Anyhow, it's clear that you have a much broader (and in my opinion, incorrect) definition of the term Trojan than what is found in the accepted nomenclature. I suggest that you do some reading regarding the term and it should become quickly obvious that the term "Trojan" is indeed a functional definition describing the malware's behavior, contrary to what you claim.
http://lmgtfy.com/?q=definition+of+Trojan+horse+malware
At this point we'll agree to disagree.
@druid:
thanks for showing me jmgtfy.com, i can see how that would come in handy.
in return let me show you something
http://www.faqs.org/faqs/computer-virus/faq/
your mention of an "accepted definition of a Trojan" followed by referencing a random google search made me think that perhaps you'd like see something a little more authoritative with respect to what the anti-malware community accepts (as opposed to what the unwashed masses of the internet accept). you'll note that the document has dozens of contributors, all of whom were arguably part of the anti-malware community when it was drafted, since they were participating in an anti-virus forum, and many of whom are recognizably still part of that community today.
for the sake of context, the virus-l mailing list/comp.virus newsgroup combo was, in it's day, one of the preeminent avenues for intelligent discussion on the topic of malware.
i should also note that there isn't really a universally accepted definition of trojan in the anti-malware community, but the one in that document probably comes closest to meeting that criteria.
Quoting, from the FAQ you referenced, section "B3) What is a Trojan Horse?":
"A TROJAN HORSE is a program that does something undocumented that the programmer intended, but that some users would not approve of if they knew about it."
The section then goes on to differentiate Trojans from viruses and other malware based on further functional behavioral characteristics, not the victim's belief or method of its construction.
This is pretty much the same definition I gave you, and the primary characteristic that the FAQ uses to define the term is that it has to *DO* something malicious and covert in addition to it's overt function. I fail to see how this document supports your argument, as there is no mention of the victim's belief or construction technique anywhere in it. The only intent mentioned is the intent of the malware author, which is obvious.
Further, aside from the definition in this particular section, all further mentions of Trojans in the FAQ also fail to support your argument.
@druid:
i believe we have entered into the realm of 'reading into things that which is not there'.
a) the definition from that FAQ does not specify that a trojan must do something malicious in addition to it's overt function. it makes no mention of doing one thing and something else. in fact the primary author of that document corrected me multiple times on that very issue by saying that a trojan performs the unwanted function as well or instead of the purported function.
b) the definition in the FAQ also does not specify that the function a trojan performs need be universally considered malicious, only that it is unwanted by the user (or more exactly, that the user wouldn't approve of it). that being said, the very notion of malice introduces the intent of the creator into the equation and eliminates the possibility of the definition being functional.
c) i'm really kind of surprised that you would agree that deception is a defining characteristic but then turn around and say belief is not part of the equation - you cannot have deception without belief. deception is the act of making someone believe that which is not true.
d) where belief comes into play is in getting the malware executed in the first place. trojans are, necessarily, programs that are run by the user. if they didn't require the user to run them then the approval mentioned in the definition would be a non-sequitur. a user must believe the program is good or at the very least benign, otherwise s/he will not run it.
btw - thanks for the chance to debate this topic. i used to argue these sorts of points in usenet (and fidonet before it) and i've missed this sort of thing.
a) It does not explicitly specify it, but it most certainly implies it; "Doing something undocumented" and "that the user would not approve of if they knew about it" both imply that the application does something expected or benign as well, which jives with pretty much every other definition of Trojan that you will find in any other resource.
b) I would argue that if it is unwanted by the user, it is malicious. If it's unwanted, it is acting against the wishes of the user. Further, as specifically a classification of MALware (i.e., *malicious* software), it is malicious by definition.
c) I spoke of functional deception. The user doesn't necessarily have to *believe* that nothing malicious is happening, they just have to be unaware of it. Awareness and belief are two completely different things. In this context, I guess "covert operation" would be more appropriate than "deception". I suggest the scenario where a human is not even involved; HackerJoe identifies a binary on a system that he can modify that is regularly executed by a privileged scheduler. He embeds back-door code into it so that when it is executed by the system, it's normal function takes place, but the back-door is also activated, thus turning the executable into a Trojan. Does the system *believe* that the file is benign? No, it just executes it because it always has. Perhaps you can make a case about trust here. But it's still a Trojan, and belief isn't even part of the equation.
d) See c) regarding your requirement that Trojans must be run by users. Users/Administrators would likely still not approve of the back-door being opened if they knew about it, but in the scenario I suggested, the user or administrator wasn't even involved in the direct execution of the Trojan. But it's still a Trojan. I still think that the belief you speak of is squarely situated in the social engineering that is needed to get users to execute Trojans, which is not applicable to *all* Trojans, and therefore not a property of a Trojan.
@druid:
a) i'm sorry but that simply does not follow. just because a trojan performs an unapproved of function does not imply that it must also perform an approved function. that is only a requirement if the trojan needs to maintain the illusion past initial execution so that the user will execute it again in the future. given the various persistence strategies malware can employ, such a requirement is almost never actually present. on a side note, i wonder how you reconcile your view with the existence of such things as droppers and downloader trojans which usually only perform the unwanted function.
b) i agree that if it is unwanted it can generally be considered malicious in that particular context but the function itself isn't malicious. if it formats your drive when you didn't want it to, that is clearly malicious, but if it formats your drive when you did want it to then it is not malicious.
c) at this point you've strayed too far from what i or the anti-malware community would consider a trojan. a program that is not executed by the user isn't a trojan. the issue of approval (or disapproval) specified in the definition is a non-sequitur when humans are taken out of the picture. machines do not disapprove of any program's function. therefore when humans are taken out of the picture we're no longer talking about trojan horse programs. if there had been a way for the greeks to get into troy without the aid of the tojans, they wouldn't have needed or built the horse.
d) see c). something that happens automatically without user intervention on some level is not the work of a trojan but of some other form of malware.
a) If it *only* performs the unwanted function, it's not a Trojan. The entire point of the Trojan is to maintain the illusion so that the victim is unaware, regardless of whether or not it is executed once or multiple times. I have always defined a dropper as a Trojan who's payload is a virus or some other persistent malware, i.e., the Trojan "drops" something else onto the system. I don't really need to reconcile anything about droppers as it's essentially a particular type of Trojan. Your FAQ also defines droppers as a class of Trojan, which would thus have them inherit the definition of a Trojan, which is what we are debating. The only place I found a definition of a dropper that did not define them specifically as a class of Trojan was Wikipedia, and I don't want to get into debating the validity of referencing Wikipedia as we all know where that dark path leads.
b) If it formats your drive when you did want it to, that's it's overt function, and therefore isn't a Trojan. This was the problem with your executable renaming example. If you rename the executable that formats, formatting is still its overt function.
c) Please speak for yourself, not what the anti-malware community considers a Trojan unless you can reference additional documentation other than one FAQ from 1995 (which, happens to disagree with your definition that a dropper can be something other than a Trojan). I am entirely speaking for myself, even though many friends and colleagues I've spoken to over the past couple of days who work in the AV/malware industry have agreed with my understanding of what a Trojan is (I frequently peer-review to make sure I'm not crazy). The only reference I've made other than my own personal opinion was to collected examples of the nomenclature via the Google search I referenced. Anyhow, I didn't take humans completely out of the equation, just out of the execution of the Trojan, which is where this "belief during execution" notion is coming from as well as your requirement that "a Trojan must be executed by a user", which is also nowhere in the B3 definition from your FAQ. In my scenario, the admin of the system, who I would hope is human, would still disapprove of the backdoor being started, the back-door is still malicious and unwanted, but the administrator or a user had no hand in actually executing it or believing anything while doing so. He is probably aware of what scheduled executions happen on his systems, but he's *unaware* that malicious code has also now been executed via the Trojan, as the overt function still taking place maintains the illusion. He doesn't have to believe anything one way or the other; he's just completely unaware.
d) I never claimed the automated bit was the work of the Trojan or any other malware. In my scenario, the Trojan is just sitting there waiting to be executed. The system scheduler, which is not a human, eventually executes it. The executable is still a Trojan, as it performs the overt function when the scheduler executes it, however now that it is a Trojan it also opens the back-door. No humans or belief involved in the execution.
Anyhow, I've made my case, we just disagree, and I have quite a few other things on my plate that this discussion is now distracting from (: Feel free to make a final counterpoint as it's your blog, hopefully I'll be able to get back here and read it.
@druid:
1) considering the number and pedigree of the contributors to that faq, i consider it a fair representation of what kind of definition for trojan the anti-malware community will accept.
2) i don't think the fact that it's 15 years old is important. while we've come up with a variety of functionally specified subsets of the trojan set, even with a compelling reason to redefine the overall set it wouldn't happen (i tried to make it happen).
3) that being said i think you're misinterpreting the definition in the faq so i dug up some additional material from the same author:
"By definition, Trojans require a judgment call -- what exactly is "undesirable" program behaviour? -- there are clearly "situational" aspects, but how can a scanner make those calls at run-time? It can't, so it becomes a build-time decision. This probably (hopefully!) seems very straightforward to those reading this message, but the reality is that way too many users of AV software do not understand that one person's Trojan can be another's most useful utility. "
this precludes a functional definition (there are no judgment calls in determining if something meets a functional definition). this also defends the position of a far more broad definition of trojan than you're open to as the "one person's trojan can be another's most useful utility" cannot fit into your dual overt+covert functional requirement.
4) the idea that a trojan doesn't need to be executed by the user is one of the stranger notions i've come across. if the victim doesn't have to open the door for it, if the user doesn't have to give it access to CPU cycles by executing it, then it stops bearing any similarity to the legendary stratagem from which it derives it's name - with the possible exception of a tenuous link in the form of stealth (or functional deception or covert behaviour if you prefer). however, since the modern security community has glommed onto stealth as the defining characteristic of rootkits, we can't very well let it also be the defining characteristic of trojans or we approach the obviously false expression rootkit == trojan.
And yet, semantics and the dicing thereof are the fodder of so much employment in the ITSEC industry. Yay.
Post a Comment