poking holes in trojans

it seems like only days ago when this blog's longest comment thread in recent memory drew to a close after a heated discussion on the definition of trojan and now it seems that not long after both chet wisniewski and david harley posted blog entries featuring that very classification.

not only that but chet's usage of the word as an umbrella term for all non-replicative malware doesn't seem to match david's usage - nor does it agree with my definition (which i imagine probably doesn't exactly match david's either). all of which just goes to show that there really isn't a universally agreed upon definition of trojan. no matter which definition you use there are always some problems with it.

that being said, there are some ideas in chet's post that mirror topics brought up in the aforementioned comment thread and that i think should be brought out front and center.

starting with the low-hanging fruit, let's look chet's example of a trojan that you don't have to execute in order to become a victim of - that being the drive-by download. now i realize that my computer science background has allowed me to develop some rather transcendent notions of what execution means (even going beyond this), but i really don't think one needs to go that far to get the concept that when you open a web page you're executing it's contents. a web page is a container for data and a wide variety of executable content (from javascript to flash to activex to silverlight, etc) and, rather than bog down the user experience with endless prompts to execute this, that, and the other thing, browser developers decided that opening a webpage should result in the execution of whatever executable content it contains. this is something that doesn't get nearly as much attention as it probably should and as a result most people aren't aware of this rather significant detail (otherwise more people would be using noscript) and consequently make bad decisions about how to use the web. i expect that chet himself is all too aware of the executable potential of web content but he's not passing that knowledge on to the reader when he tells them that drive-by downloads don't require any user interaction. the user opened the page in the first place (or opened another page that lead to the drive-by download page being opened) so they did interact in the sense of executing something. clicking a link in your web browser isn't that much different than clicking an *.exe in your file browser, and if more people understood that they might be more careful online.

more generally, the notion that something can be a trojan without requiring the user to execute something seems very odd to me. it seems to me that a piece of malware that doesn't need the user to execute it, that doesn't need the victim to let it in past the defenses, simply doesn't bare much similarity to the legendary strategem from which the name trojan horse program is derived.

i realize that analogies shouldn't be carried too far but to say that all malware that doesn't self-replicate (basically everything that's left over once you remove viruses and worms) is a trojan horse makes me wonder why on earth they chose the term trojan horse in the first place. the definition and the name seem to have no obvious connection. perhaps at the time they simply hadn't conceived of any malware that didn't conform to the paradigm used by the ancient greeks, but is that still true today or could i conjure up some malware examples that just don't seem like they should be called trojans at all? for example, when we think about malicious software we often think about that which runs on the victim's computer, but what about malicious software that runs on the attacker's computer? a participatory DoS tool, for example, would certainly seem to belong to the malware set since it's malicious software, and it certainly doesn't belong to the self-replicating set, but can you imagine something whose malicious functions are both known and advertised being called a trojan horse? should we call every implement of war a trojan horse instead of just the actual hollow wooden horses? catapults will henceforth be known as trojan horses, trenches also, swords and guns and chemical weapons, all of it. while we're being absurd let's call everyone bruce in order to avoid confusion. g'day bruce.

how about an example that does execute on the victim's machine? now remember i'm trying to steer clear of anything the victim user would let in past his/her defenses so the question you might be asking yourself (after taking into account just how liberal my concept of execution really is) how on earth such malware would get onto the victim's system? the answer, of course, is that it's planted there by an attacker who has already gained access to the system. back in the early 90's (perhaps even earlier) there was this attack technique whereby an unsecured system would be used to sniff out enough information (generally login credentials) to compromise a more secure system (because users of the unsecured system might on occasion access resources on another system), which in turn would then be used to sniff out information to compromise an even more secure system and so on and so forth until the attacker reached his/her goal. the attacker would use a collection of tools, often including some sort of back door in the form of a modified system binary as well as a password sniffing program, that were at least in the beginning known as toolkits (eventually one of these toolkits got named "rootkit" and the rest, as they say, is history). now i'll admit that the modified system binary that provides a back door does seem to bare at least a passing similarity to what we'd think of as a trojan horse program even if the victim didn't let it in him/herself (it's something that the victim could have easily let through the gates if given the chance), but in this context, rather than baring a similarity to the trojan horse of old, this bares more similarity to converting an existing agent into a double-agent. additionally a password sniffer in and of itself doesn't necessarily strike me as being particularly trojan-like. it's a packet sniffer that filters what it captures. it's not even clear that it's malicious until you take the context of it's use into account.

that sort of context sensitivity is often cited as a property of the trojan set but i believe it is a property of the malware set (of which the trojan set is a proper subset). in fact i think the trojan set inherits that property from the malware set. i also think that at the end of the day it's that property which makes the question of how to define such a set pointless. the term "trojan horse program" should probably go down in infamy as one of the anti-malware community's great failures because in it's unqualified form it has been one of the most singularly unhelpful classifications. back when there were only 3 major subclassifications for malware (virus, worm, and trojan, as chet mentioned in his post) we had quite a successful anti-virus industry that handily took care of viruses and worms, but not really trojans. both viruses and worms have functional definitions and trojans (whether you consider them the complement of the self-replicative set within the malware set or something more specific) do not. it wasn't until we started carving out functionally defined subsets of the trojan set (such as spyware and adware) that we started to actually get a handle on trojans. problems need to be well-defined before we can hope to address them.

so maybe we should all just forget about trojan as an unqualified term and only use it when we're talking about things like remote access trojans or downloader trojans. while we're at it, let's make sure we continue to carve out new functionally defined subsets of the malware set when fundamentally new behaviour comes along so that we don't sit around gazing at our navels and lamenting how difficult it is to classify things as belonging to an ill-defined set. we've already had an anti-spyware industry, an anti-trojan industry, an anti-rootkit industry, etc. due to slow response by anti-malware incumbents - we don't need to keep doing that.