what is a vulnerability

a vulnerability is generally considered to be a mistake or oversight that allows the vulnerable program or system to behave in an unintended and undesirable way in response to a particular input.

alternatively, in the sense that the inputs a program accepts represent a language, a vulnerability is a condition where unanticipated functionality is exposed and can be called like a programming API by 'programs' written in the input language in question (otherwise known as exploits).

the occasional exposure of unwanted functionality is unfortunately pretty much an inevitability because the complexity of modern systems makes it next to impossible to anticipate all possible outcomes for all possible inputs. only the most trivial of programs can be made proof against this problem.

although vulnerabilities generally do occur as a result of a mistake or failure to anticipate something, it's also possible for undesirable functionality to be exposed intentionally. these are sometimes considered to be a kind of backdoor. however the vulnerability came about, the exposure of that functionality is unintended and undesirable to someone - be they the software vendor or the software consumer.

back to index

what is whole product testing?

whole product testing is a form of anti-malware testing that aims to measure the effectiveness of entire anti-malware products rather than just testing the known malware scanner or the heuristic engine within the product.

whole product testing came about in answer to the problem where testing individual parts of an anti-malware product in isolation didn't give an accurate view of how well the product as a whole could perform (for example a threat might slip by the known malware scanner but be picked up by a behavioural technique that wouldn't show on a scanner test) and there was no way to combine the results of tests of the various parts to represent the effectiveness of the whole product. only by giving every part of a product the opportunity to stop a threat can we have an idea of whether that threat would have been stopped on a end user's machine.

because of the wide array of passive and active defenses anti-malware products provide, whole product testing requires each malware sample in the test set to be launched and then the system checked for indications of how well or poorly the anti-malware product stopped the malware sample from compromising the system. after this the system has to be returned to a known-clean state (generally by restoring an image of the drive). this is quite a bit more time and labour intensive than simply running a scanner against a directory full of malware and as a result often requires the size of the test bed to be more modest due to practical considerations (not enough hardware, manpower, etc). while a smaller test bed size may potentially raise questions about statistical significance (depending on how small it is) the ability of the results to map more directly to what an end user can expect makes this type of testing more ideal than earlier testing of a product's individual parts.

back to index

what is anti-malware testing

anti-malware testing is a means by which a qualified organization measures various properties of anti-malware software, such as speed, memory footprint, malware prevention effectiveness, or even malware removal effectiveness.

in theory, anti-malware testing should be straight-forward. we want the test results to tell us what we would experience if we used the anti-malware ourselves in the real world in order that we can make better decisions about what product to use, so it stands to reason that a test should simulate real world usage. in practice such simulation can actually be very difficult and a variety of shortcuts have been introduced over the years to make anti-malware testing more practical.

unfortunately, as we have found out, even small deviations from the real world can often have a big impact on the actual meaning of the test results such that they can't actually be interpreted the way we intended. one of the challenges that the community faces is understanding how these shortcuts affect the meaning of the results, determining if the new meaning is still useful in some way, and developing new testing methodologies that have fewer and/or less impactful shortcuts so that the tests can come ever closer to approaching the ideal state where their results will actually have the meaning we intend for them to have.

back to index

what is scareware?

scareware (also called rogueware, fake AV, rogue AV, and a host of other names) is a type of malware that pretends to be legitimate security software, often for the purposes of extorting money from the user.

the traditional method of operation for scareware once it runs on the victim's machine is that it will pretend to have found security threats on the system but inform the user that in order to remove them the user must pay to register the fake security software first. the security threats that it claims to find are used to scare the user into complying with the request for registration, but they are generally either non-existent or they were purposefully planted there by the scareware.

scareware can be introduced into a system by any number of means, including drive-by downloads, installation by other malware such as bots, droppers, or downloaders, or they could even do their fake initial  scan directly from the web page that sells the scareware (sometimes with hilarious inconsistencies like scanning windows folders when you're browsing from a mac computers).

because scareware pretends to be something which it is not in order to socially engineer the user into paying the malware writers who created it, it qualifies as a type of trojan horse program. it doesn't have to try to hard in order to trick the user as users are very willing to believe anything claiming to be security, especially when it says the user is unsafe, in large part because legitimate security vendors have long trained users to trust them without question.

back to index

what is an alias companion virus?

an alias companion virus is a type of companion virus that takes advantage of the command aliasing functionality of operating systems that support it in order to get executed instead of the program the user intended to execute.

command aliasing is a feature whereby long, complex commands can be given simple, easy to type aliases in order to enhance the usability of the system. MS-DOS didn't support this functionality, nor is there much demand for it in the face of graphical user interfaces, but some alternative DOS command shells did, and various flavours of *nix (including linux) do as well.

if a viral program creates an alias that points to itself but gives that alias the same name as some other program (the so-called host program), and if the operating system in question gives execution precedence to aliases (which they often do), then alias (or more specifically the viral program it points to) will get executed instead of the host program the alias got it's name from.

back to index

what is a renaming companion virus?

a renaming companion virus is a type of companion virus that uses the 'rename file' functionality of the operating system to assume the identity of the host program it infects.

a renaming companion virus will rename the host program it's infecting (often to something with the same name but a different file extension so that it's easy to find later) and then rename itself so that it has it's host's original name. this way, when people attempt to execute the host program they will be executing the virus instead and the virus can then locate the renamed host and execute it so that the user doesn't suspect anything is wrong.

back to index

what is a path precedence companion virus?

a path precedence companion virus is a type of companion virus that takes advantage of the precedence or order in which DOS traverses the PATH variable (a delimited list of directories) to find a partially specified executable file when attempting to execute it.

as a simple example, suppose the PATH variable holds just two directory names. if we issue a command to execute a file that happens to be in the second directory but we don't specify which directory it's in, DOS will search the first directory and then the second directory in order to find and execute the file. if another executable with the same name as our intended command happens to exist in the first directory then it will get executed instead of the one we intended.

regardless of where the program we intend to run is, if a companion program exists in a directory closer to the beginning of the PATH, that program will get executed instead.

back to index

what is an execution precedence companion virus?

an execution precedence companion virus is a type of companion virus that takes advantage of the precedence or order in which DOS tried to find a partially specified executable file when attempting to execute it.

the canonical example is one where a DOS command is issued that would normally execute a file with an *.EXE file extension - should there be a file with the same name but a *.COM extension in the same directory, the *.COM file will be executed instead. in order to hide the fact that there was something unusual going on, the *.COM file would generally then explicitly execute the *.EXE file so that the program the user intended to execute actually gets executed.

whenever there are multiple executables with the same name but different file extension in the same directory, the system will always use a set rule to decide which takes precedence over the others. *.COM files take precedence over *.EXE files, which in turn take precedence over *.BAT files, and so on...

back to index

what is a malware writer?

like a virus writer, a malware writer is someone who writes/programs malware. nothing more, nothing less.

the term malware writer is essentially the same as virus writer, only more general to include those who write non-viral malware.

back to index

what is a crimeware kit?

a crimeware kit is a product and/or service that allows a prospective online criminal to carry out his/her criminal enterprise without needing the technical know-how to build that enterprise in the first place.

the technical aspects of an online criminal enterprise that a crimeware kit might typically provide for the criminal/customer include the malware itself which is often some sort of bot, a command and control interface, and potentially a facility for spreading the bot to new victims and thereby increase the size of the botnet.

by taking all the technically challenging parts of the online criminal enterprise out of the criminal's hands a malware kit could be said to create a turn-key system for online criminal enterprise. it's users could likewise be considered the professional criminal equivalent of script kiddies.

back to index

what is APT?

APT is an acronym that stands for advanced persistent threat. it is a classification for attackers that fall outside the normal attacker bell curve. advanced persistent threats are highly skilled (advanced) and well funded so that they can spend a great deal of time and effort (persistent) trying to compromise a single organization.

unlike conventional cybercriminals who will go after as many victims as possible in order to achieve their goal of financial profit, advanced persistent threats have relatively few targets because what they're after isn't so widely available that everyone has it. APT is well suited to espionage (including industrial espionage) and sabotage, especially (in the case of so-called cyberwar offensives) sabotage of infrastructural operations such as power generation or water pumping stations.

back to index

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.

what is credentialed malware?

credentialed malware is essentially (and perhaps more aptly described as) multi-user malware. not multi-victim malware, mind you, but multi-attacker - it is designed to be used by multiple attackers with differing levels of access to the malware's collection of functionality.

credentialed malware really only makes sense in the context of a criminal organization where different members of that organization have different roles and different levels of trust.

it also only make sense (from a tactical perspective) in cases where attackers would need to physically access the compromised machine(s) (ie. a public kiosk) in order to pull of a successful attack. if the machine could be accessed remotely or if the machine could send data out to remote destinations then there would be no need to employ multiple human agents to mask the maneuvers required to make the attack work.

back to index

(thanks go to nicholas percoco and jibran ilyas for introducing me to this concept)

what is autoplay social engineering?

autoplay social engineering is a subset of social engineering tricks that specifically utilize the autoplay dialog that windows normally presents when certain types of storage media are inserted into the computer...

related to autorun malware, autoplay social engineering assists in getting the malware executed in situations where autorun doesn't automatically launch the malware as soon as the storage media is inserted into the machine... when the autoplay dialog is displayed it presents the user with a list of options for how the user can view the data on the storage media (such as viewing a slide show if the media contains pictures, viewing a video on the media, opening the drive in explorer, etc) and can also include an option, specified in the autorun.inf file in the root directory on the media, that can literally be anything (including launching of malware processes)... this optional entry would appear at the top of the list and be selected by default when the autoplay dialog opens...

should the option specified in the autorun.inf file present itself as something it's not, such as showing the icon and description identical to that for opening the drive in explorer when it actually runs malware, then that represents a form of social engineering as it's tricking the user into doing something s/he doesn't really want to do...

back to index

what are dynamic heuristics?

dynamic heuristics are a branch of heuristic techniques that try to determine if a suspect program is malicious by running the program in a simulated environment and trying to detect the active (dynamic) malicious behaviour(s)...

there are a number of ways to accomplish this, whether it be emulating the program until it reveals the de-obfuscated (and, ideally, previously known) version of itself, or running it in some some sort of sandbox to catalog a broader range of it's behaviours looking for signs of malicious intent...

one of dynamic heuristics' strengths lies in being able to bypass many of the obfuscatory techniques that malware writers use to stymie static heuristic analysis as obfuscation has traditionally needed to be undone at run-time for the malware to operate... unfortunately a number of tricks have been developed by malware writers to try and combat these techniques and they generally exploit a more natural and general weakness involving the fact that for any non-trivial program there are multiple paths that program execution can take but any single invocation of the program will follow only one of those paths... program execution can take different paths (and thus produce different behaviours) depending on any number of different conditions present at run-time so the malicious behaviour a dynamic heuristic engine is looking for may not show up (either by chance or by design) during analysis...

back to index

what are static heuristics?

static heuristics are a branch of heuristic techniques that try to determine if a suspect program is malicious by examining the structure and contents of the program in an inactive (static) state and trying to find (for example) code fragments that have been commonly used for malicious ends in the past...

this type of technique is especially dependent on having detailed knowledge not only of the contents past malware but also of the contents of legitimate programs so as to avoid alerting on the presence of code that, though heavily used by malware, is also common in legitimate software...

one of the strengths of static heuristics is that, unlike dynamic heuristics, it is able to examine multiple possible program execution paths due to the fact that it's looking at all the contents of the program instead of just the code that would get executed during one particular invocation of the program... unfortunately, malware writers have developed a number of techniques to obfuscate their code in such a way as to prevent a heuristic engine from being able to see the actual code and thus preventing it from performing static analysis on that code...

back to index

what is an autorun worm?

an autorun worm is a type of worm that is carried (literally) from one machine to another on removable media (such as CDs, DVDs, or USB flash drives) and uses the autorun feature of windows to either automate or at the very least facilitate it's execution when the media is put into the next computer...

this type of worm makes use of the autorun facility by copying not only itself to removable media but also placing an autorun.inf file on the media that contains the instructions necessary to run the worm's program when the media is inserted into a machine that has the autorun facility enabled...

although the autorun facility works by default for CDs and DVDs (as you've no doubt noticed when inserting some of them into your computer), it doesn't work by default for standard USB flash drives - something called autoplay (which shows the user a menu of convenient actions s/he can take such as playing audio/video, opening the drive in explorer, etc) is initiated instead...

that said, there are changes one can make to a computer to make it initiate autorun instead of autoplay, there are specially designed USB flash drives that lie to windows about what kind of device they are in order to make use of autorun, and other USB devices can't reasonably be expected to identify themselves as standard USB flash drives when that's not what they are and so pose the potential of initiating autorun when used... also, even if autorun doesn't automatically initiate as soon as the media is inserted into the computer, it may initiate when you double-click on the drive in explorer... additionally, for contexts where autoplay is initiated, the autorun.inf file can specify actions (such as executing the worm) to be added to the top of the menu that the user is presented with and which can be presented in a deceptive manner so as to trick the user into choosing the malicious action added by autorun.inf file...

back to index

what is a variant?

a malware variant is a modified version of a previously existing piece of malware where the modification was performed by something other than the malware itself...

any modification that results in something that isn't a byte-for-byte match with the original is enough to classify the result as a new variant so long as the modification wasn't made entirely by the malware itself... that means flipping a single bit by hand creates a new variant while traditional polymorphism does not...

the reason traditional polymorphism isn't considered to produce new variants is because every possible form the malware can take as a result of the polymorphism is knowable by analyzing the code of that malware... the transformation is known and fixed, while modifications performed by forces beyond the malware itself are unknown and unpredictable...

perhaps confusingly, server-side polymorphism can arguably be considered to produce new variants... this is because the modification is not performed by the malware itself but by a server-side component that the malware analysts may not have access to and as a result cannot predict all possible forms a given malware may take when transformed by it... if the server-side component becomes known (and assuming it's entirely algorithmic) then it becomes possible to detect all possible instances of a piece of server-side polymorphic malware, but it's difficult in general to justify saying that they magically stop being different variants once the transformation function becomes known...

back to index

(thanks to vesselin for the previous discussions on the objective definition of variant)

what is malware qa?

malware quality assurance is a process in which malware writers test their malware in order to determine whether the malware meets the degree of effectiveness they had hoped for (and obviously one where they throw out those instances that don't meet the grade)...

malware quality assurance indicates a level of maturity and professionalism on the malware writer's part, and although the term could be used to describe a variety of things (some as banal as running a virus to see if it reproduces), it is generally used to refer to the practice of running a large number of anti-malware scanners on a given sample to determine how likely that sample is to go undetected when used in the wild (which may thereby establish an objective measure of the malware sample's monetary worth)...

it is sometimes incorrectly suggested that anti-detection malware qa underscores a weakness in traditional signature-based known-malware scanning... in reality, any new piece of malware will bypass a good known-malware scanner (because the good ones are so exacting so as to eliminate false alarms) so long as it's not a byte-for-byte match with a previously known piece of malware - this is by definition, and there's no need to perform any quality assurance tests to prove it... malware qa is actually an attack against heuristics, because it is the heuristic engines that would be detecting these new/unknown malware samples the malware writers are testing, not the known-malware scanning engines...

back to index

what are heuristics?

in anti-malware, heuristics refer to a family of techniques/technologies meant to determine if a given program is malware based on a collection of rules (heuristic can be considered to be a fancy word for "rule of thumb") derived from past experience with malware...

heuristic analysis looks for structures/routines/behaviours/etc (depending on the implementation) commonly found in malware rather than looking for actual specific instances of malware... one could think of this as being a measure of similarity, not necessarily to a specific malware sample (though there are heuristic engines capable of reporting that X is a new or modified variant of Y), but rather to malware in general... this gives it the potential to detect new/unknown malware but also carries with it the potential to raise false alarms as there is nothing done by malware that is unique to just malware (rules of thumb aren't an exact science)... in order to prevent an unacceptable number of false alarms the heuristic detection typically gets watered down (by requiring more heuristic conditions to be met, or by requiring a higher heuristic score if the conditions aren't weighted equally, before the heuristic engine decides to raise an alarm), but this also has the effect of lowering the true alarm rate as well...

heuristics ability to detect unknown malware is meant to compensate for known-malware scanning's complete inability to do so, however it cannot detect all unknown malware and with the constraints placed on it to avoid false alarms that ability is reduced to an even lower level of effectiveness... as the instantaneous population of unknown malware increases, this shortfall in effectiveness becomes an increasingly troublesome problem...

back to index