a little egg on alwil's face

thanks to luke tan for once again drawing my attention to a compromised website, only this time it was not a blogger blog, it was the avast web forum serving up malware with an exploit to get it automagically installed...

wilders security has some good initial details details and it seems to the forum admin's credit (as well as those who reported the problem in the first place) it was caught fast and the forum shut down for maintenance to limit the damage that could be done to the public at large...

the forum is back up now and apparently free from the malware that was previously being served and apparently breaking core functionality of the forum... let's hope it stays that way - but for those who visited while it was behaving strangely, you might want to do a formal scan of your entire system just to be on the safe side (although since avast itself, along with a number of other anti-malware products, was able to detect and block the malware i suspect most of the forum's users would not be affected)...

threat centric reality check

readers of richard bejtlich's tao security blog are no doubt familiar with a concept he frequently promotes called threat centric security... this is a security paradigm that tries to eliminate threats as opposed to vulnerability centric security which aims to eliminate vulnerabilities...

he's mentioned it in a number of posts and i've often gotten the feeling that there was something that wasn't quite right but i could never really put my finger on it until i read this article on bad guys last week where he said:

It's important to remember that we're fighting people, not code. We can take away their sticks but they will find another to beat us senseless. An exploit or malware is a tool; a person is a threat.

when i read that it suddenly became crystal clear to me, the underlying problem i had with what he was saying about threat centric security was rooted in his classifications....

on the one hand i can see where he's coming from; just about every negative security consequence we can think of can be traced back to a person or group of people... whatever the attack, there's always a person who initiated it and as the saying goes kill the head and the body dies... this is why one would say malware is just at tool, because one sees it as nothing more than an extension of the attacker and hypothesizes that if you take the attacker out of the equation the malware will become irrelevant...

there are a number of problems with this and the first is that malware is more than just a tool... a hammer is a tool and a person has to physically swing it each and every time s/he wants to strike a nail... malware, on the other hand, is an agent and has the ability to be far more autonomous... the most fundamental benefit an attacker receives by employing malware is automation; s/he may only need to press a button to start the malware doing a complex and time consuming set of tasks and it's not going to stop just because the attacker has been put in jail, it doesn't need the attacker at that point, it will just keep going until either it's programming or it's controller tell it to stop...

generally speaking viruses and worms have neither a built-in stop condition nor a controller interface that would allow someone to tell them to stop, so putting the person responsible in jail isn't going to have any affect on the spread of that virus or worm... this is part of the reason why old viruses never die and why there are still people out there trying to remove 15 year old boot sector viruses... once a virus or worm starts self-replicating in the wild, the person responsible is already out of the picture...

in spite of the fact that old viruses never die, some would likely argue that viruses aren't really a big issue anymore... fine, then let's talk about what has replaced them as the scourge of the internet - botnets... botnets do have a controller interface, but what good is that if the person doing the controlling is put in jail? maybe part of his/her sentence could be to instruct the bot software to uninstall itself from all the victim machines but that assumes that someone else hasn't already taken control of the botnet... just as thugs employed by a crime boss find a new crime boss to work for when the existing one is busted by the cops, so too can an existing botnet be used by a new crook when the old one is taken out of the picture... in this case it's not kill the head and the body dies, it's kill the head and a new head will come along and take it's place... ultimately the same is true of virtually all non-replicative malware in some sense - take one attacker out of action and another one steps in and continues using the malware... this is why it's important to consider malware as more than just a tool or extension of the attacker, it's an agent operating on behalf of an attacker and once it's been put into action taking the person responsible out of action doesn't change what it can do...

that leads us to the second problem - the conceit that fighting people can replace fighting code... at the end of the day the threat centric security that focuses on people is called law enforcement because the people in question are criminals... we all know how effective law enforcement has been at eliminating crime in the physical world so it shouldn't be too much of a surprise to realize that it will probably be no more effective at eliminating cyber-crime... a sword on the battlefield stops being able to cause you harm only when there's no one left to wield it; and so too with non-replicative malware, it only stops being able to cause harm when there are no more cyber-criminals left to employ it - and since there's a seemingly endless supply of criminals the malware will continue to be capable of causing harm in spite of our effects to put the criminals behind bars...

finally, on a historical note, in case anyone is thinking that the threat centric security that richard bejtlich talks about is something we need to start doing, it's actually been going on for rather a long time now... remember christopher pile aka the black baron? how about david l. smith aka vicodines? then there's mike calce aka mafiaboy and kim vanvaeck aka gigabyte... even robert morris jr. faced legal repercussions for the morris worm... that's going back nearly 20 years and it's just the tip of the iceberg as far as sheer numbers go...

don't get me wrong, i'm not knocking threat centric security, i think it's important, but there's more to it than just fighting people... malware in general has nothing to do with vulnerabilities so anti-malware security can't be said to fall under the umbrella of vulnerability centric security... even encarta says that things can be threats too... malware is a threat agent (or threat as those who prefer more ambiguous terms would say), it may not be in charge but it is a thing that acts to cause harm, and taking out those instances that come your way qualifies as a type of threat centric security...

who doesn't love bacn?

seems a new meme was born recently involving an email classification called bacn... it seems it's become important to classify notification and other emails that you actually want to receive but don't have time to look at right now...

it also seems that some people see a problem here... frankly, i don't... bacn isn't spam, it isn't anything like spam... it's sent by cooperative parties more or less at your request - if you don't want to receive it anymore you can ask for it to stop and it should actually stop... and since it isn't being sent maliciously it's not going to mutate and evolve rapidly in order to avoid filters that move it into folders specifically made to hold it and organize it and keep it from making your inbox unmanagable...

basically, everything we learned not to do with spam actually works on bacn because bacners (got a better term for bacn senders?) are cooperative rather than malicious...

what is a script kiddie?

script kiddies were people whose ability to attack digital resources came entirely from the pre-made scripts they found and shared with each other...

they were considered one of the lowest forms of attacker (even amongst other attackers) due to the fact that they showed no real aptitude for anything except clicking, copying, and pasting... as such the term 'script kiddie' was universally considered an insult...

before scripting became widely adopted as a way to create malware this class of attacker would have been the type to hex edit (with difficulty, i'm sure) other people's viruses in order to change text strings inside and pretend like they'd made something new or later to use virus creation kits to pretend basically the same thing...

scripting made editing existing malware easy because the malware didn't need to be compiled/assembled into hard to read machine code in order to run; it remained in source code form and could be opened and modified using nothing more than notepad... some of the more creative script kiddies could even cobble together something sort of new by cut-n-pasting parts of other malware scripts together... if any were to rise rise above this stage they might be recognized as being more than just a script kiddie, but most were too clueless to realize that they were regarded derisively even by their would-be peers...

back to index

the beneficiaries of malware kits

this is a little on the stale side (sometimes things just take a while to get done) but i was reading an article on dancho danchev's blog about the shark 2 diy malware kit and something struck me...

it's clear that malware kits benefit the less technically sophisticated attackers by making easy to for many people to create many new pieces of malware that no one has ever seen before (assuming no one else chose exactly the same options, which actually seems unlikely)... it's also clear that enabling these profit driven versions of script kiddies can serve to draw attention away from the activities of the more sophisticated cyber criminals but would you believe anti-malware companies can benefit too?

if you look at how well malware creation kits have fared in the past it becomes clear that malware produced by a kit doesn't provide much of a challenge... this isn't because the malware doesn't have great features that would serve conventional malware well in the wild, it's because it came from a kit and the kit itself became known... as an example, back in the day i spent some time (a couple weeks maybe?) observing a group of self-proclaimed virus writers whose entire stock of viruses were created using the nrlg virus creation kit - each and every one of them detectable, but not as distinct and individual viruses like you might expect, rather as nrlg generated viruses... the thing about generated malware is once you know the generator you can predict and recognize all of it's output so that even if some twit goes to the trouble of creating 5,000 vcl/nrlg/whatever variants it poses no real problem for the av vendors...

now the newer kits like this shark 2 diy kit are professionally made and updated frequently and you may think that would make things harder for the anti-malware vendors, what with there being multiple versions of the kit to have to deal with... consider how many different pieces of malware could be generated with all those different versions of the kit, however, and you'll soon see that adding detection for the output of the different versions of the kit is faster/easier than analyzing each piece of output and adding detection for it individually...

so not only do kits optimize ease of malware creation, they optimize ease of mitigation as well... let this be a lesson to all you less skilled malware profiteers out there - if you can't make malware yourself then go find something else to do because all the stealth and anti-debugging tricks in the world aren't going to help a piece of malware generated by a known algorithm... in the end you're probably just being used as a smokescreen by people with more technical expertise than you...

what is comment spam?

comment spam is spam that appears in blog comments instead of in email...

traditionally the idea behind comment spam was to add links a spamvertised (advertised by spam) site to various other sites so that a) people would follow those links and visit the spamvertised site and b) search engines like google would rank the spamvertised site higher since there were more links to it and so it would be more likely to show up on the first page of search results (basically a kind of search engine optimization scheme)...

different blogs have different means of coping with comment spam: some have a CAPTCHA, some require a moderator to approve the comment before it can appear on the blog, some use moderation after the fact (so that for a while the spam will actually appear there), some require the commenter to create an account, and some even have advanced content or IP-based filtering... not all blog owners implement anti-spam functionality for their comments, however, and no anti-spam technique is perfect so in some cases the spam still gets through...

to combat the SEO effect some (possibly most) blog platforms implemented a technique by which links in comments would be marked in such a way that search engines wouldn't count them regardless of whether they were good links or bad links...

that didn't stop comment spam either, of course - people can still follow the links and not all comment spam even has links anymore... as such blog owners still often need to use techniques like those described above to combat comment spam...

back to index

what are splogs?

a splog is a form of web-based spam in the form of a blog...

unlike comment spam, in the case of splogs the entire blog in question is spam, not just a small part of it... because blogs are so easy to setup and publish content on it's become a popular way of spamvertising a site...

to combat this type of abuse of service, blogging service providers typically employ anti-spam techniques like CAPTCHAs to prevent the automated creation of splogs but CAPTCHAs are becoming less effective as techniques for defeating them are developed... on top of that, CAPTCHAs don't prevent real live humans from setting up splogs... because of this, blogging service providers try to prune out splogs manually when they become aware of them...

back to index

when is the infosec sellout blog not the infosec sellout blog?

when it's pwned by someone else...

it fell into someone else's hands just last month but at least that time the new registrar seemed cooperative and gave it back to the rightful owners...

now, unfortunately, the current content seems to indicate that the blog has turned into a splog or worse considering how these things tend to go...

as such it looks like the infosec sellout blog is unsafe again... guess they just can't catch a break...

what is server-side polymorphism?

server-side polymorphism is a type of polymorphism where the polymorphic engine (the transformation function responsible for producing the malware's many forms) doesn't reside within the malware itself...

just as conventional polymorphism was constrained to housing the polymorphic engine within the virus its meant to operate on (because the code doing the copying has to have access to the transformation function), server-side polymorphism requires the polymorphic engine to be part of the system (generally a website) that serves (hands out) copies of the non-replicative malware it's used on instead of being in the malware itself...

this has proven to be very effective and very hard to counter from a conventional known-malware perspective... the reason is because with the polymorphic engine staying on the server instead of residing within the malware itself the transformation function can remain unknown to the malware analysts... although the analysts can try to perform black-box analysis of the transformation function, without knowing all the variables the function takes into account it's not possible to model the entire algorithm and predict all possible outputs... further, the transformation function can be arbitrarily complex, it could involve actually recompiling the malware with different parameters, or it might not even be an algorithm at all (someone might literally be manually changing the malware that the server is handing out)...

given this, it's not really possible in the general case for signature-based known-malware detection technology to reliably detect all instances of a piece of malware that employs server-side polymorphism but there are some facts that anti-malware vendors can use to their advantage... first, while signatures probably won't work, heuristics should be able to have some success against the various instances of such malware (assuming the polymorphism isn't too complex)... second, polymorphism has never been easy to develop and so the use (and sale) of kits may be helpful since the kits should contain the polymorphic engine and therefore give the analysts access to the transformation function... finally, there are detection and prevention technologies (behaviour-based detectors, whitelists, etc) that can often stop malware without needing to know what the malware looks like and vendors are increasingly including such technology in their suites...

back to index

what is metamorphism?

metamorphism can be thought of as a kind of polymorphism that doesn't use decryptors... in fact many of the techniques that polymorphic viruses used to vary their decryptors metamorphic viruses have used to vary their entire bodies...

metamorphism, like polymorphism, was a type of camouflage that was meant to fool anti-virus technology of the day... one of the successful solutions to polymorphism was to use a polymorphic virus' decryptor against it generically... by allowing it to run in an emulated environment so that the decryptor would reverse the obfuscation that had been performed on the main body of the virus, the de-obfuscated static virus body could then easily be matched against signatures...

rather than encrypt the virus' body and decrypt it when needed as a conventional polymorphic virus would, a metamorphic virus would vary it's entire body the way a polymorphic virus varied it's decryptor... since the transformation function used didn't need to be reversed in order for the code to run (otherwise decryptors in polymorphic viruses would have needed additional decryptors of their own), this meant that the virus' main body was generally never returned to an untransformed state during the normal operation of the virus and so would foil the previously mentioned tactic used against conventional polymorphism...

that said, the metamorphic engine (like the polymorphic engine) still must reside within the virus (in order for copies to have a different form the code doing the copying must have access to the transformation function) and that in itself was a weakness as it gave anti-virus vendors knowledge of the transformation function and therefore the ability to know (or at least derive) all forms a metamorphic virus could take...

back to index

what is polymorphism?

in the malware context, polymorphism refers to a property of self-replicating malware (viruses and worms, *although self-modifying non-replicative programs take on different forms by virtue of modifying themselves so the term polymorphism can technically apply to them also) whereby the offspring (the copies) potentially take on a different form than the parent (the original)...

typically polymorphism works by encrypting the main virus body (which was actually unchanging) using a variable key (in order to make the ciphertext actually be different from one instance to the next a different key is needed each time, otherwise it would simply be considered *encrypted) and using a decryptor (a stub that decrypts the main body of the virus in order for it to execute) that is also variable (otherwise the decryptor itself could be easily used to detect the virus)...

polymorphism is a type of camouflage that was originally developed back when anti-virus products were just using simple scan strings to compare against samples in the process of looking for viruses... a virus that changed it's contents could easily fool such a simple scanner because there would be no single sequence of bytes that would match all instances of the virus... as a result anti-virus companies developed technology that would use the virus' decryptor against it by allowing it to decrypt the main body of the virus so that that could then be used to identify the virus...

the term polymorph, in the malware context, arose out of a long telephone conversation between frisk (fridrik skulason) and alan solomon as a way to describe viruses that mutated or garbled themselves (according to dr. solly's retelling anyways) but over the years it has been narrowed to exclude cases where the decryptor didn't change (variably encrypted), or only changed into relatively few alternate forms (oligomorphs), or cases that didn't use a decryptor at all...

back to index

(*updates/improvements thanks to vesselin's comments)

the first rule of anti-virus fight club is don't let that kurt guy find out about it

awww, randy beat me to it, darn my self-imposed no-blog-posting-at-work rule... more than a few potential posts have wound up indefinitely stalled because of that rule but oh well... i'll post the thoughts i took down earlier anyways since there's a thing or two i can say that someone who's actually in the industry probably can't (or shouldn't)...

so i stumbled across this itblogwatch article about a group called untangle untangling av's mysteries and i was stunned... testing with 35 viruses? half of which submitted by the audience so we don't even know if they're really viruses? and clamav won? there are so many things wrong with this picture it's not even funny...

first, 35 viruses - 17 controlled (for lack of a better word), 17 submitted by the audience, and 1 test file - isn't enough to do anything except mislead people... this is the kind of test pc magazines used to do that were so laughably bad people were told to ignore them...

next, using samples submitted by the audience - can you see the audience sitting quietly for hours while the integrity of the samples they submitted was verified? no? me neither... ergo their integrity probably wasn't verified and so the results of that part of the test are next to useless...

further, who are the people submitting these samples? where do they come from and what company(ies) or organization(s) are they associated with? do they have ties of any kind with any of the products being tested? there's a potential for some significant sample selection bias here (magnified considerably by the ridiculously small sample size)...

and clamav? i generally don't bash actual products, but clamav? while some people may argue that anti-virus products are a commodity now, that doesn't mean that absolutely all of them are created equal - even if they are a commodity there are still going to be products on the fringes for which such general statements don't apply and unfortunately clamav is just such a product... the reason for this is that while av products may be a commodity, the expertise involved in creating virus scanning engines is not... it's highly specialized and few people have those skills - those that do are employed commercially and bound under various employment contracts in such a way as to not be able to contribute to the clamav open source project... and that's just the engine development, there's also considerable expertise involved in processing malware samples to add to a product's database and the people with those skills are also generally employed employed commercially... why do you think the number of entries in clamav's database has only ever been a fraction (generally about 1/3) of what commercial products have... there are all sorts projects for which open source works, but in order for it to work the knowledge required has to be fairly common and widely available in the community - something which just isn't true for av scanning engine/signature development...

at first blush it seemed to me that this av fight-club is a publicity stunt more than a reliable comparative review... then i dug a little deeper and found a few things:

1. the organization (untangle) conducting the fight-club uses clamav in their own product and so cannot be trusted not to cook the results in that engine's favour in some way or another (ex. sample selection, test design, etc.)...
2. the organization that conducted the test is distributing live viruses to the public, which is totally unacceptable - the center for disease control doesn't hand out free samples and neither should people dealing with computer viruses...

the untangle documentation on their av fight club spins an interesting yarn about their dealings with other testing bodies and how they don't want to test clamav... though i can't speak for the more well regarded testing organizations, if you want to know why they don't bother testing clamav i wouldn't bother looking any further than the paltry 144,368 entries in their database (at the time of writing)... many products have passed 300,000 and some are as high as 500,000 (all figures include non-viral malware, obviously)... i'm sure they probably recheck clamav every once in a while to see if it's significantly improved or not (ie. can it reliably detect polymorphic viruses yet?) but so long as it's only detecting a fraction of what the other products detect it's not worth the time required to test it regularly...

and before anyone starts jumping up and down about how clam is only missing the 'old' malware that shouldn't be a problem anymore, let me first reiterate that old viruses never die (people are still looking for stoned.empire.monkey removal help 15 years after it was released), and let me also point out that considering the growth rate of malware, the 'old' stuff should be a minority fraction not a majority...

lastly, and this is not something i thought to mention originally but randy made a good point, including the eicar test file in this sort of test shows just how serious (or rather not serious) you should take these test results... it's sort of like giving the competitors marks for getting their names right... not only is detection of the test file almost guaranteed for all products, it's detection has no bearing on a product's ability to detect viruses because the test file isn't a virus or even virus-like in any way...

Update: it seems the composition of the test set may be different than i thought... mcafee are reporting that there are actually 6 eicar samples... they may be right, i don't know, none of the documentation says exactly how many of their samples came from eicar and since eicar really only has the one test file i assumed it only contributed that much to the test... the mcafee folks (in an effort to replicate the results) downloaded and examined the actual test set, something i refused to do (i wasn't going to denounce the distribution of viruses in one breath and then greedily gobble them up in the next, it's just not me), so they're probably right about how many of the samples are the eicar file... i can't imagine how they got 6 eicar samples, though, since eicar only provides the one test file in 3 different forms (4 if you think changing the file extension qualifies)... at any rate, sextuple counting the eicar test file is just weird...

the blue pill - once more, with feeling

i kinda hoped to never again darken my blog with those two words again... i even resisted the temptation to point to the response to the matasano challenge and say 'nyah, nyah, i told you so'...

and frankly, i'm not even interested in debunking the hogwash about it being 100% undetectable anymore - i know that perfect protection from detectors is impossible, joanna knows it's impossible, and i know that joanna knows that it's impossible...

if it were any of that stuff i've already posted about before i wouldn't be posting again because i've already said my peace about that... no, despite all the faults, all the criticisms i've made, the one good thing i was able to say was that at least she didn't release it - at least she was being responsible...

now even that is gone... maybe i should write viruses, slap a research sticker on them, release them and call it good... does that work? no? i didn't think so...

was there a compelling reason to make the stealthkit available to the public? was someone feeling the heat over some ridiculous claims and rather than eat crow decided to let those detractors test it for themselves with the cop-out caveat that it's not finished?... seems a plausible explanation - at any rate, congratulations joanna on becoming part of the problem, i'm sure that black hat you've made yourself will go over well at that conference by the same name...