user education is working

there is a fairly prevalent opinion in security circles that user education doesn't work... no matter how much you try to teach users, they never learn...

my retort to this is generally along the lines of "ok, give me your name, address, telephone number and credit card information and i'll prove you wrong"... obviously no one is going to give me that information and that proves them wrong - users of credit cards learned not to give that information out to every tom, dick, and harry a long time ago (we know they learned it because it's not knowledge they were born with)...

but sometimes that fails to convince, so here's a personal anecdote... i was out having a meal with some people not too long ago and the conversation briefly turned to email and the woman beside me (whom i had never met before and never coached in any way) said she tends to delete anything with an attachment... she was the first and only person to mention attachments during the brief discussion of email...

we're not talking about a security person or even necessarily a computer person here either - she's a school teacher and she's adopted a behaviour that was unheard of in the general populace 10 or even 5 years ago...

people never stop learning things, and netizens learn to adapt to the threats present in the environment they inhabit - how could they not? staying safe online is a competitive advantage and successful strategies will be discovered and adopted and spread like memes through the computer user population... they don't need to know the internals of how various threats operate or why certain safe-hex behaviours work, only that they do work...

how to spot snake oil using the halting problem

i blogged previously about how the halting problem is good for separating the possible from the impossible in the malware field, but i suspect it's still a little over most people's heads... art kopp came up with the term "snake oil spotter guidelines" and it inspired me to try and distill what i said earlier into a (hopefully) simpler heuristic that anyone can use...

let's say you have a sequence of one or more bits or bytes... let's further say that it's of finite length (in practice we never deal with anything that goes on for ever) and that it is well defined (we know the exact sequence)... this might sound familiar, it might even sound like a virus signature, but i'm talking in a much more general sense here so we'll just call it a pattern...

1. any system that claims to find all instances of something that is equal to or contains such a pattern (ie. finding all instances of the character 'a' or the string "dog") does not run into difficulties with the halting problem and is not snake oil (at least not as far as that particular claim is concerned)...


2. any system that claims to find all instances of something that is not equal to or does not contain such a pattern (ie. finding all instances of a characters that aren't 'a' or all words that don't contain the substring "dog") does not run into difficulties with the halting problem and is not snake oil (as far as that claim is concerned)...


3. any system that claims to find all instances of something using the equal/not equal or contains/not contains comparison to any one of a finite list of such patterns (ie. finding all instances of the characters 'a' and 'b' or all words that don't contain the substring "dog" or "shoe") does not run into difficulties with the halting problem and is therefore not snake oil as far as that claim is concerned...


4. any system that claims to find all instances of something less trivial than what has been described so far, something that can't be represented as a well defined finite set of such patterns (viruses, for example, cannot be represented that way as there are an infinite number of possible viruses - so too with any function, since there are an infinite number of ways to implement any given function - also any class of bug or vulnerability has an infinite number of ways in which it can occur in practice), or by using a less trivial method of comparison (certain types of preprocessing, like decryption or decompression notwithstanding) generally does run into difficulties with the halting problem and therefore probably is snake oil...


5. any system that claims to prevent or avoid all instances of something must use a technique that is equally capable of finding all instances of that something and so the previous rules apply...


6. any system that only claims to find/prevent some instances of something doesn't run into difficulties with the halting problem and is therefore probably not snake oil as far as that claim is concerned...

wow, that's actually pretty big... let's condense it...

any system that claims to find all instances of something and that something is non-trivial and/or is to be found using a non-trivial comparison method will generally run into difficulties with the halting problem and therefore be snake oil...

as a corollary to the above, all real world threats and vulnerabilities wouldn't be problems if they were trivial... therefore any system that claims to find or prevent all instances of a particular kind of threat or vulnerability is snake oil unless the particular kind in question is specified narrowly enough that it applies only to a specific, well defined, finite set of items that can themselves be represented by one or more of a finite number of the above mentioned patterns... for example, all known viruses represents just such a set of items and can therefore be detected and/or prevented without running into problems with the halting problem...

the descent of rootkits

i think it's about time to get to the root of the rootkit terminology shift...

i've blogged before about what i think a rootkit is, and about how the anti-spyware coalition's definition is basically in line with my own...

and yet somehow the definition currently in use is all about hiding processes and/or activities from the user rather than about root/administrative privileges...

as i observed before; f-secure, despite acknowledging that the original unix meaning was basically in line with the one i use in this little blurb:

The term rootkit is very old and is dated back to the days when UNIX ruled the world. Rootkits for the UNIX operating system were typically used to elevate the privileges of a user to the root level (=administrator). This explains the name of this category of tools.

still insists on using the new hiding-related definition...

but my first clue about where this new definition came from was in mark russinovich's blog entry where he gives his definition:

Software that hides itself or other objects, such as files, processes, and Registry keys, from view of standard diagnostic, administrative, and security software.

which he says he derived from what the rootkit developer community was using as a definition and which happens to basically mirror the definition proposed by greg hoglund, founder of rootkit.com (a hub of the aforementioned developer community) and author of a book on these so-called rootkits (not that registering a domain and/or writing a book actually makes anyone a credible authority, but for the sake of argument lets say he is one), which states:

A rootkit is a tool that is designed to hide itself and other processes, data, and/or activity on a system.

a rootkit developer community? well, a community of developers of cloaking technology at any rate... but lets think about this for a sec... by and large, these developers are not going to be a malicious bunch (there are far more good people in the world than there are bad) so when they look at rootkits, even the original unix-style rootkits, they aren't going to really be all that interested in the more blatantly malware type features - the thing that's going to interest them is the cloaking because it has applications outside of malware...

it has been suggested that terminology changes with frequent misuse and that is most likely what happened here... the developer community in question, lacking any significant influence from malware experts (since malware issues were outside the scope of their interests, and because malware expertise is a lot harder to come by than you might think), used and reused the term rootkit (since rootkits represented examples of the kinds of sophisticated stealth techniques they were interested in) so much outside of it's original meaning that they gave it a new meaning...

so what? you might well think that language changes in just this way so there's nothing wrong here, but consider this:

• technical jargon does not evolve the same way that conversational language does... imagine if people started using the term 'telescope' to refer to something completely different...
  
• hoglund's definition describes what is more properly known as stealth in the malware field... the concept of stealth has enjoyed wide use in the malware field for at least the past 20 years (back in 1986, the brain virus wasn't just the first pc virus in the wild, it was the first stealth virus) and has been applied to virtually all forms of malware, not just rootkits
• stealth is actually a more natural and intuitive label for what hoglund's definition describes; so much so that the term is creeping back into the vocabulary of the rootkit community at rootkit.com to cover new types of cloaking that 'rootkit' is no longer felt to encompass
• under hoglund's definition, the term 'rootkit' has no etymological basis - that is the word doesn't appear to come from anywhere or be rooted in any underlying details... by comparison, a collection of programs (-> a collection of software tools -> a toolkit -> a kit) that aids in gaining or maintaining root/administator (administrator is called 'root' in unix) access is fairly clear about where the term 'rootkit' comes from

while upcoming concepts like 'stealth by design' indicate that the current terminological misstep may be in the process of correcting itself, there will be purists who will resist the change in terminology on the basis that the proposed new definition of rootkit is not what a rootkit was supposed to be... they'll simply have to be reminded that their rootkit definition was not the original one either and if the correction does take place it will simply be a reversion to the original state of things...

feedback

this post is a little towards the administrivia side but it's been something i've been thinking about for a while...

you'll probably notice that there is no way to post comments about my blog articles - that's intentional and there are a couple of good reasons for it...

the first is that by and large most of my posts here are rants - they're posted in order to get something off my chest, not necessarily strike up a discussion...

the second, perhaps the more important, is that i don't feel like providing yet another malware forum, much less have to maintain yet another malware forum (i'm already the moderator on a couple of malware discussion forums and frankly, i don't need to add to that list)...

and lastly, i just like having the last word, and rather that fiddling around with comments or arguing 'til i'm blue in the face, i just leave comments off... (i also don't have to deal with comment spam this way)

that said, i suspect people would find my blog more fulfilling if they had some means of interacting with me and maybe even changing my mind or holding me accountable for whatever errors they think i've made... i still don't want to create any new forum for discussion so i've decided to do something a little unorthodox - i'm going to direct people to existing unmoderated (so that there's no chance of me manipulating conversations) forums in the form of 2 usenet newsgroups - alt.comp.virus and alt.comp.anti-virus... i've also created a disposable email address specifically for feedback so you can email me here [edit: mailto link removed]...

[edit: adding new contact feature]
ok, i was using sneakemail.com to provide a disposable email address that i could use on this site, but mailnull.com has an even better service... the idea was always to prevent spammers from getting my real email address by having their bots parse my blog looking for anything that looked like an email address... the disposable email address allowed me to be contacted without revealing my real email address but the spammers could still send email to that address... mailnull.com offers a web contact form to go along with their disposable email service and that effectively removes all email addresses from the web page - so now you can contact me here...

[jan 1, 2007 - edit: this is probably the most changed page on the whole blog]
guess i'm growing soft in my old age, i've just enabled comments... so much for all my arguments against them...

what is DRM?

digital rights malware (or digital rights management software if you prefer) is any program bundled with media (text, graphics, audio, video, or some combination thereof) that takes some measure of control over the user's electronic device(s) in order to limit what the user can do with the media, often in contradiction to some extent with what applicable laws say the user should be allowed to do with it...

the user is often unaware of the presence of the digital rights malware his/her media purchase has been crippled with or how it invariably works against his/her interests, so it therefore qualifies as a kind of trojan...

in recent months there has been a trend to label any form of digital rights malware that uses stealth to hide itself (and in order to be effective against any user with half a brain they have to use stealth) as a rootkit... this is part of a larger and rather misguided trend to call anything that uses stealth a rootkit... while DRM is malware, it is not necessarily a rootkit...

there is an older trend (and some well known examples of success) of trying to get protection of digital rights malware enshrined in the law... this moves the creation and maintenance of copyright policy out of the hands of the government and into the hands of various corporate interests and has sometimes been called paracopyright... in places where this has taken place many of those corporate interests have proven themselves uninterested in the user's rights many times over...

(see my previous posting on digital rights malware here)

back to index

SANS - strike 2

i posted previously about SANS hosting and distributing malware and what i thought of it... well here's strike 2 against them...

apparently now they're asking the general public to send them samples of some worm...

now, under my ideals of responsible handling of self-replicating materials i'm willing to accept that some people might actually feel like there's a good reason to trust them - after all, it's SANS...

but think about it for a minute... they have to resort to asking the general public for a sample? that tells me that either no one in the anti-virus research community or industry trusts them enough to give them a sample, or the people at SANS involved in this aren't even bothering to develop the contacts needed to get these types of materials through the right channels...

either way, it isn't good...

this has got to stop

ok, so it was bad enough when sony's digital rights malware got labelled a rootkit, at least it really was malware... but now anti-virus products and other legitimate programs are being called rootkits too...

this is basically a witch-hunt, everything that hides anything is getting called a rootkit and it clearly isn't serving the public's interests... at what point in the process of calling legitimate apps and even anti-virus products rootkits does one wake up and realized they've made a tremendous error? at what point does one own up to that mistake and admit it? before or after you become a media darling?

cloaking of any kind is bad and microsoft agrees? windows cloaks things... "Hidden files and folders", "Hide extensions of known file types", "Hide protected operating system files (Recommended)"... and don't get me started on "NeverShowExt"

there are some circumstances where hiding things is clearly bad, such as hiding them from the administrator... however hiding things from ordinary users can reduce confusion and the potential for user initiated disasters... hiding things that can help to detect the presence of malware from that malware can reduce the malware's viability in the real world... so long as the administrator has the ability to disable beneficial cloaking there should be no problem...

what is stealth?

stealth is a property held by instances of malware that employ stealth techniques... stealth techniques are any techniques which serve to hide something (usually malware) from something else (usually the user or security software employed by the user)...

in malware, stealth is not an attack in and of itself but rather it is an adaptive strategy applied to other attack techniques in order to increase their likelihood of success... by keeping evidence of the attack hidden, the window of opportunity for the attack to succeed remains open longer and therefore the number of opportunities encountered that could lead to success tends to increase...

virtually all classes of malware have employed stealth techniques at one time or another, however not all instances of malware employ stealth techniques... further, stealth techniques are not exclusively the domain of malware - stealth has been employed in legitimate applications too... in fact there are some cases where stealth is used to hide information used by anti-malware applications from the very malware they're trying to protect against...

back to index

what is a rootkit?

a rootkit is a collection of one or more programs that aid in gaining and/or regaining (sometimes expressed as maintaining) root/administrative access on a system....

by gaining access i mean that they provide an attacker with credentials for a user with administrative privileges or a user whose privileges can be escalated (by use of some additional exploit) to administrative priviledges... usually this is performed with network sniffing from other compromized machines or some other password stealing technique...

by regaining access i mean that they provide an attacker with an easy means of re-entering the system with their administrative priviledges at a later date... usually this is done with a backdoor of some kind...

rootkits originated in the unix domain but have since been brought into the windows fold with an unfortunate twist - many in the industry have taken to redefining rootkits under windows to be basically anything that hides files, registry keys, alternate datastreams, etc... they ignore the concept of root/administrative privilege entirely (that's where the root in rootkit comes from - root is the administrative user account under unix/linux), instead focusing exclusively on what might otherwise be called stealth...

stealth is not an attack in it's own right but rather it is a technique for keeping the window of opportunity open longer, thereby improving the likelihood of success of the actual attack... virtually all classes of malware have employed stealth techniques (as they used to be called before the year 2000) at some point or another, not just rootkits - rootkits are not special in that regard... the application of stealth techniques helps to hide the programs that comprise the rootkit, allowing the rootkit more time to steal passwords and other sensitive information, and allowing the attacker more time to use the compromized system...

stealth became such an important part of rootkits (especially under unix where security-aware admins monitor system integrity carefully) that the stealth techniques themselves became the means by which the presence of a rootkit could be detected... perfect stealth, it turns out, is hard if not impossible to acheive and by using multiple techniques to examine system resources and comparing the results it is often possible to detect when something is being actively hidden from sight... unfortunately this a generic detection technique and as such is prone to alert on anything that hides things whether they're rootkits or something else, so the choice to categorize all things detected this way as rootkits is curious and a little troubling... and considering there are also software products out there that hide things in order to protect them from malware (instead of being malware) it can lead to a great deal of fear, uncertainty, and doubt among users...

in short - stealth isn't what makes a rootkit a rootkit, it's what makes a rootkit a successful rootkit... that's why virtually all of them use it...

(see these two usenet articles for additional analysis of what a rootkit is, and thanks to roger wilco for the debate)

back to index

what is a functional definition?

in the malware field the ideal kind of definition for a class of malware is the functional definition... essentially it is a definition that defines the class of things by what function all things in that class must perform...

for example a web browser must be able to browse the web, and anything that can't browse the web cannot be a web browser...

the reason this is the ideal kind of definition in the malware field is because it depends only on things that can be determined by examining a malware sample itself... this makes it the most objective type of definition...

by contrast some definitions depend on speculation about the intent of the malware author or about the perceptions of the user... such dependencies make for very subjective definitions, and such subjectivity leads to disagreements over whether a particular peice of malware actually belongs to the subjectively defined malware class in question...

back to index

what is a trojan?

a trojan horse program is a program which the user believes performs good (or at least benign) function but which also or instead performs a function the user would not approve of if s/he knew about it...

there are those who think trojan horse programs are synonymous with back doors, however that is only one of the many different types of trojans known...

the most striking thing about this is that it is not a functional definition... we cannot determine if program X belongs in the trojan horse class just by examining it, we must also look at how it gets presented to the user and make guesses as to how an average user might reasonably interpret that presentation...

for example, format.com (the utility used to format disks) is certainly not a bad program - if you need to format a disk then this is the program you want to use... however, if someone were to rename it to best-blowjob-ever.com (an example of social engineering) then someone else could be in for a nasty surprise when they tried to run it...

this may seem like nothing more than a mental exercise so far, but now imagine you were going to write an anti-trojan program to help protect people from trojans - how could your product alarm on best-blowjob-ever.com and not on format.com when their contents are identical? in general it can't be done and so deciding whether or not to detect program X as a trojan becomes a balancing act... one has to try to decide whether it's more important to warn people of the potential trojan or to not create fear among those who happen to have a legitimate program that gets maliciously misused in some circumstances...

these kinds of problems innevitably stymie efforts to help protect people from malware and is why non-functional definitions are such a bad thing... unfortunately, in the case of trojans, that's the kind of definition we're stuck with...

back to index

what is social engineering?

social engineering is the process by which an attacker exploits the social needs and/or desires of people and their behaviours in response to those needs and/or desires in order to engineer an outcome that is favourable to him/her...

basically it's tricking people into doing what you want them to do... a perfect example of this is the vbs/loveletter email worm... it exploited people's need to feel wanted and loved in order to get them to execute the worm... by trying to open what they thought was a message from a secret admirer, they would inadvertently execute the worm which would then send it's false promise of love to others...

this is used a great deal in malware - so much so that these days a piece of malware's success in the wild could be considered to depend more on how good it's author is at social engineering than on how good it's author is at programming...

back to index