confessions of a twitter worm victim

as some of you may know, this past wednesday someone released a self-retweeting worm on twitter that exploited an XSS vulnerability in the popular twitter client tweetdeck. i happen to be a tweetdeck user and i got hit by the worm, not once but twice. since i believe in owning up to my mistakes in order to serve as an example to others, i figured it was important for me to write this post.

this isn't the first time i've had to do this. four years ago it was discovered that there had been a RAT bundled with the software for a USB battery charger sold by the energizer battery company (it had gone undetected by the community for years) and i wrote about my experience then as well.

this was the first time getting hit with something that could spread to others, and spread it did. i know this because i got email notifications from twitter when other people's tweetdeck clients automatically retweeted the tweet that that my client automatically retweeted. that's actually one of the things i think i did right - i have twitter setup to send me notifications for as much of that kind of activity as i possibly can. the result is that i get what is essentially an activity log sent to my email in near real-time and that alerted me to the problem within minutes of it occurring.

that quick notification allowed me to undo the retweet before it propagated from my account again. that limited the extent to which i contributed to the spread of the worm. acting quickly to neutralize the threat in my twitter stream is another thing i believe i did right.

unfortunately i also did a number of things wrong. for example, i knew about the XSS vulnerability before i encountered the worm, i saw excellent preventative advice and even retweeted that, but i failed to follow it exactly. the advice was to sign out of tweetdeck and then de-authorize the app in twitter. what i did instead was close the tweetdeck tab in my browser and de-authorize the app. i took a shortcut because i didn't believe anyone i followed would actually tweet anything malicious. i didn't anticipate that they might do so involuntarily - the possibility of something like the samy worm from years past never occurred to me. and so when news spread that the vulnerability had been fix and that users needed to log out and back in again to apply the fix i re-opened the tab, re-authorized the app (because that was the first prompt i was presented with) and then went hunting for the logout button. that's when i got the email notification that another user had retweeted one of my retweets.

however, i did not see the alert popup that was supposed to indicate the worm had executed. i didn't realize it at the time but that was important because it meant there was more going on than i realized. it meant that the worm had not executed in the client i was sitting in front of. what i had forgotten was that i had another tweetdeck client open on a computer at work and when i re-authorized the app the worm executed on the work computer rather than my home computer. it wasn't until i was on a bus to see an old friend that the significance of what had (and had not) happened clicked and then it wasn't for another several hours before i could get access to that work computer (where the alert popup was still patiently waiting for me) in order to log out and back into tweetdeck again, which i did without de-authorizing the app beforehand so the un-retweeted tweet got re-retweeted.

in short it was a comedy of errors.

what i've taken away from this is a number of things:

1. i am once again humbled by the clear demonstration that i am not perfect. while i certainly knew conceptually that i wasn't perfect, i have had a surprisingly good track record with malware. having my ass handed to me made the appreciation of my imperfection much more visceral.
2. i've gained a better appreciation for the value of de-authorizing apps in twitter. to a certain extent it can seem kind of abstract but what it's actually doing is isolating a vulnerable component from the rest of the network not unlike pulling the network cable out of an infected computer did back when worms that enumerated network shares or sent mass emails were prevalent.
3. i've identified my failure to log out of things (not just tweetdeck but all sorts of sites) as a bad habit. it's pure laziness and it's not even rational laziness because there's almost no effort involved in logging in when you use a password manager. part of the reason i didn't post this sooner is because i wanted to see if breaking this habit was a reasonable expectation or whether saying i was going to improve was just wishful thinking. so far this improvement seems like an entirely reasonable expectation - i've had no problems logging out of things when i don't need the session open any longer.

at the end of the day, improvement is what sets an incident apart from a failure. the only real failure is a failure to learn from your mistakes and do better the next time. i'm not perfect (no one is) but each time i screw up i make sure i get better.

numbers, context, and background

one of the things i've come across while reading various sources is an attempt to pin down an intended target nation for the stuxnet worm based on prevalence data. the theory goes something like 'since nation X is where most instances of stuxnet are found, therefore nation X was the intended target (because obviously more work was put into spreading it there)'.

this theory has some problems, however. first and foremost is that not all the numbers agree. while we have symantec saying that ~60% is in Iran, we also have eset saying that ~60 are in the US just 3 days earlier. they can't both be right - or can they? and if they are, what are the implications for the targeted nation theory?

as is always the case when there are contradictory numbers, we have to look at how those numbers were arrived at. in fact, even when there aren't contradictory numbers, we should still be paying close attention to how those numbers were arrived at.

close examination of vikram thakur's post on the symantec site suggests that there number represents actual infected machines trying to connect to their C&C server (on top of everything else, stuxnet is also a botnet) during a 3 day period between july 19 and july 22. they were able to gather this data because they redirected the domains hosting the C&C servers to themselves so it seems like it would be a pretty accurate snapshot of the pool of infected machines at a particular point in time.

eset's numbers in david harley's post came from their installed clients throughout the world. their cloud-based technology reported the instances - however, since stuxnet employs stealth it's more likely that rather than reporting infected machines (where it would be active and hidden) it's actually reporting infected USB drives. it could also be reporting both if eset's products can see through the stealth, but the key point is that eset's numbers almost certainly include infected USB drives while symantec's do not. the USB numbers are important because that's how this worm spreads and if one were going to work on targeting a particular nation, spreading infected USB drives in that nation would be the way to do it.

furthermore eset's numbers appear to be from the time detection for the worm was added until the time the statistic was reported, rather than just the 3 day period covered by symatec's figures. this means that eset's figures represent a measurement of how many instances of the worm there were over it's detected lifetime to that point, while symantec's figures represent a measurement of how many infected machines remained at that point. this is important because by the time symatec started collecting it's data, negative population controls had already been in effect for some time.

controls which, like worms they intend to control, are not necessarily uniformly effective across the entire globe. some products have greater market share in some regions that they do in others, and the dominant product in certain regions might be poor at controlling particular worms and thus allow those worms greater reproductive advantages in those regions than they might find in others. the presence of population controls like anti-malware software affects both the death and birth rates of worm instances and as anyone who's heard johnny long discuss hackers for charity knows, such controls are not uniformly present or effective across all regions.

there are a actually a variety of other factors, in addition to such controls, that contribute to how well and in what way a worm or virus spreads, as discussed in some detail by jeff kephart, david chess, and steve white in "Computers and Epidemiology". some of these factors, like the degree of connectedness of susceptible hosts (and how often adequate contact between such hosts happens), can be influenced by computing culture, which in turn can be influenced by culture in the more general sense, geopolitical climate, and even socioeconomic considerations. hypothetically speaking, a nation that is cut off from US technologies due to trade sanctions (as metioned by by brian krebs) could well exhibit a higher rate of software sharing as part of 'alternative' procurement techniques and in so doing raise the region above the epidemic threshold for some unspecified worm.


ultimately both symantec and eset could be right since they were measuring different things over different periods of time. what that means for the targeted nation theory is that things aren't as clear-cut as either set of numbers would suggest on their own. what we do know is that stuxnet appeared to enjoy more reproductive success in Iran than elsewhere. whether that's down to purely epidemiological factors or intentional injection of the worm into the local computing population by a malicious actor is unclear, but eset's data would support an argument against the latter option as the effort seems to have been expended elsewhere. on the other hand, if we were to entertain the notion that the US was the target based on the amount of infected materials floating around the computing population, then we are left once again with the conclusion that stuxnet was a failure since in spite of all that effort the prevalence of actual infected machines in the US was minuscule.

i don't think much can be read into the fact that there were more infected machines in Iran than elsewhere since such pockets of infection are actually normal - especially for self-replicating malware that must be spread by physical media. some region had to draw the short straw and this time it was Iran.

why the stuxnet worm is an abject failure

in a previous post i called the stuxnet worm an abject failure, and intimated that it was because it was a worm. some might wonder why i said that when there have been a number of worms in recent memory (conficker, for example) that have spread far and wide and were considered successful, not just in spite of becoming widespread, but rather because of it. why should the stuxnet worm be subjected to an apparent double standard?

to understand why you have to look who the intended pool of victims are for the malware in question. for most common worms or viruses the goal is to infect or infest as many machines as possible. there is no special subset that is being targeted, they're just looking to add computing resources to their attack platform; where that attack platform can be used for anything from simply infecting/infesting still more machines to something as complex as building a botnet. anything where more is better.

in this kind of scenario there is a rather large number of machines for which public knowledge of the attack makes little or no difference with respect to whether the attack succeeds. the virus or worm will be able to thrive within this population because the machines are poorly administered, have misconfigured anti-malware software (assuming it's present and enabled at all), and no special mitigating steps have been taken to deal with the possibility of getting infected by the virus or worm (like disabling autorun, for example). if you guessed these were home user machines you'd be right (although there are a significant number of these in other environments as well). these are generally considered low value targets so the people charged with taking care of them generally don't do all that good a job.

the stuxnet worm, in contrast to this, was targeting machines that controlled industrial processes like manufacturing, power generation, water treatment, etc. these are, quite clearly, near the opposite end of the spectrum of valuable targets. as a result the people tasked with taking care of these machines are generally trained professionals who, in all likelihood, will take special steps to mitigate the threat of a new attack that specifically targets those machines once that attack becomes public knowledge.

and therein lies the rub. self-replicating malware does not stay below the radar. malware that makes copies of itself always winds up drawing attention to itself. each copy it makes increases the chance that someone will catch on, and when someone does that's the first step in the inevitable process of the attack becoming public knowledge.

consider the difference between plant eating animals and meat eating animals. plants don't generally react to protect themselves when they sense a plant eater coming near them, but prey animals definitely do react to protect themselves so meat eaters have to behave in a way that prevents their prey from knowing they're coming. if meat eaters bumbled along like plant eaters they'd never catch anything and eventually starve. they'd be abject failures just as the stuxnet worm is.

man 'infects' self with computer virus?

that's pretty much what the story says (read it here) and if it were true (or even possible) then it would be a pretty boneheaded thing to do. and they call this guy "doctor".

but if you haven't figured it out by now, the whole thing is complete rubbish. over 4 years ago a bunch of researchers came up with some less than amazing research that showed that certain RFID tagging systems could be susceptible to compromise by malware stored on RFID tags themselves (which i wrote about here). specifically, the data on the tags could exploit programming flaws in the back-end database the system runs off of. in essence you could write malware (even viruses or worms) that operates in the context of the database, and you could use RFID tags as a storage and distribution medium.

4 years later and another bunch of researchers (including a one dr. mark gasson)  have the (not so) bright idea to stick one of those RFID tags in a person. yeah, that really is all that happened here. that and some effective huckstering get into the media spotlight (if even only for a short while).

it really is quite unspectacular though. dr. gasson took something that supposedly contained a computer virus and then put that inside yet another container (his own body) and then called that container 'infected' as if that's all it took. by the same token i could put one of those tags in a tupperware container and call that 'infected' - and wouldn't that be something; not only 'infecting' something that's inanimate but well and truly inert. what's more, i could take one of these specially prepared RFID tags and put it between two slices of bread and make an 'infected' sandwich. i could even put one in a hole in the ground and 'infect' the planet. clearly this notion of 'infection' by containment is absurd.

but it gets a little more absurd, because dr. gasson claims to be the first. now a very clever commenter over at boingboing pointed out (here) that you get basically the same effect by sticking an infected USB thumb drive in your rectum. while you may consider that to be a juvenile observation to make, his assertion that it constitutes prior art has merit. USB thumb drives are small and portable and easily inserted into a variety of bodily cavities for the purposes of hiding or smuggling data. furthermore, USB thumb drives are notorious for hosting things like autorun worms. as such, with the bizarre "containment == 'infection'" logic being used, it's almost a certainty that dr. gasson was actually not the first human to be 'infected' by a computer virus in this (non)sense, he's simply the first to make a media spectacle of himself over the issue. (one might argue that unlike an RFID tag, a USB thumb drive wouldn't be able to pass on the infection once in your rectum - but it was never specified that the business end couldn't be left sticking out)

i can't discuss this topic without touching upon what i think is (at least partially) to blame for the ridiculous and rather scary statement being made by dr. gasson, though. it's one of my long-standing pet peeves: terminology misuse. you may have noticed my persistent decoration of words related to the word "infect". that's because it's been used in a sense that is so far from an reasonable meaning of the word infect that it doesn't deserve to be treated as a normal word. terminology misuse has become de rigeur to such an extent that even well known anti-malware personalities such as graham cluley and mikko hypponen endorse it for some terms. you can argue about natural semantic drift of words over time until you're blue in the face but technical jargon is not (and should not be) subject to the whim and whimsy of the unwashed masses (even when it comes to subjects that affect them). this particular instance of sensational absurdity is a consequence of and an argument against unfettered semantic drift in the realm of technical jargon. in no reasonable sense of the word was this person ever infected by a computer virus. absurd statements like the one the researcher is making are only possible because of slightly less absurd statements made before it that haven't been corrected yet, which in turn can eventually be traced back to basic terminology misuse.

does conficker have a silver lining?

don weber posted an intriguing thought about the massive conficker worm actually making the internet more secure...

he's got some sound logic - it does shine the spotlight on the problem and give people who know what to do an opportunity to convince decision makers to do the right thing and that could certainly make people more secure...

trouble is i made the mistake of saying something similar in the previous decade... technically it was more along the lines of 'it would be good if X were bigger/more damaging because then people would sit up and take notice'... as you can imagine then along came something that was bigger/more damaging and people did sit up and take notice... where's the trouble with that you say? i got what i wanted, right?

wrong... a lot of people were negatively affected for what turned out to be a temporary lesson... i'm sorry to say but one of the observations i've made over the past 19 years of following the malware problem is that people largely do not retain the lessons of the past and thus wind up repeating history over and over again...

this case is likely not going to be any different - while don suggests that the efforts put forth as a result of this mass infestation are going to make future mass infestations harder he neglects to mention that there have been plenty of mass infestations in the past whose cumulative effects should have made mass infestation darn near impossible by now if the effect had any kind of staying power...

but the effect doesn't have staying power, it's short lived... there certainly is a window of opportunity for people to push through smart policy/technology changes, but the window is not large - take advantage of it now while it's still open...

viruses on the international space station

this past week there was a lot of buzz surrounding the news that an autorun worm had infected 2 laptops aboard the international space station... i wasn't sure i was going to bother saying anything about it at first but then i decided it might serve as an interesting object lesson so let's look at what we can learn from this event and what could have been done differently....

my first reaction when reading of the event was that this just goes to show how pernicious and autonomous self-replicating malware truly is... that notion (that viruses/worms are somehow worse or more autonomous than other forms of malware) has been scoffed at in the past but viruses in space stand as a testament to their ability to get into places no one intended or would have imagined... no other form of malware besides self-replicators would have been able to find new victims in that sort of environment...

another thing we can learn from this is to stop clinging to the fantasy that the only kind of malware we need to worry about anymore is the new stuff, that old-style viruses and worms aren't worth worrying about anymore... this wasn't brand new malware, it wasn't state of the art, and it wasn't something researchers on the bleeding edge would have taken notice of even when it was new... the malware threat landscape isn't composed exclusively of novelties, there's a heck of a lot of banality out there as well...

yet another lesson is that can be learned is that for all the whining about how AV is failing, at least some of the evidence used to support that argument (in other words, some of the failures) is actually a result of not using AV in the first place, not keeping it up to date, or not following the various other best practices for AV...

actually using an AV program is the first thing the astronauts and/or NASA could have done differently... while i'm sure there are plenty of arguments for why one might not want an anti-virus program on them, such as highly critical real-time processing of experimental data, these were laptops running windows and so were already unsuitable for real-time processing ('what do you mean the OS must have been busy don't something else during that time period?')... i assume someone up there must have had AV or else we wouldn't have a name for the malware...

failing that, they could have used some other sort of anti-malware technology like application whitelisting... in fact, considering the environment that might even be a more appropriate approach since it's unlikely that astronauts need to introduce new software to those machines very often... that is unless part of their job requires them to rewrite or apply patches to software being used in the experiments to collect/analyze data... come to think of it, that might actually be the case - it's not like the folks designing the experimental payloads have a lot of chances to test and debug their software under real-world conditions when the real-world in question is actually out of this world...

the astronauts could have operated the machines under non-administrative accounts - actually there isn't really anything to suggest they didn't, nor is there anything specific to an autorun worm's replication technique that should require administrative access... despite a previous post i made highlighting the ways in which least privilege can fail to stop malware, it still is fairly effective against a lot of existing malware...

they could have disabled autorun on those machines - in fact, they probably still should disable it... autorun is purely a convenience feature for the technologically inept; hopefully that's not the sort of folks NASA is sending into space (then again, they did get infected by somewhat old malware)...

finally, they could have used something other than windows machines... although technically not immune to malware, macs and linux machines have a far smaller pool of threat agents to worry about and the lower population density means that they are less connected to other similar endpoints that could pass on something they'd be susceptible to... of course, once again this is likely subject to what the machines are being used for - if they're running or monitoring experiments with them then they may be stuck with whatever the people who designed those experiments wrote their software for (and considering the cost of doing anything in space, cutting corners on the ground and using cheap windows developers is pretty likely)...

according to NASA this is not the first time they've had a virus infection in space... let's hope they also look at these sorts of events as learning experiences and figure out how to do things better in future...

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

follow-up on the ethical conflict in the webappsec domain

well, it's been several days now and there have been a number of reactions (such as the comment thread for the article i originally linked to or christofer hoff's reaction to my previous post on the subject)...

i wanted to post a follow-up to address robert hansen's reaction to my post and i was actually planning on posting it sooner but now i'm glad i didn't because i get to throw in material from mike rothman as well...

i'm going to start with mike, actually, since i can at least link to what he wrote (though past experience trying to comment on his blog has been less than stellar - ie. the comments seem to get lost)... mike posted his reaction in today's daily incite and although he thinks he knows what my argument is about he actually gets it rather spectacularly wrong...

Kurt thinks that this is going to uncover an attack that wouldn't have been discovered otherwise and that's a bad thing.

no, i think that the contest is going to a) create new threat agents (ie. worms - that is the point of the contest after all) and b) popularize this class of threat...

creating threats, increasing the total number of threats out there is not something white hats are supposed to be doing... that contributes to the problem, not the solution...

popularizing the threat means that the bad guys' adoption of this class of threat agent will speed up, in other words the arrival of xss worms and other web-based malware (which are probably an inevitability given our current trend towards web-based computing) happen sooner...

both of which ultimately benefit mr. hansen...

That we shouldn't trust these researchers because they think like hackers.

no, we shouldn't trust them because they act like bad guys... creating malware and/or requesting the creation of malware is fundamentally not a white hat activity because it contributes to the malware problem (the way dropping litter on a littered street contributes to the litter problem)...

My point is that in all likelihood they are working on smaller footprint and more innovative XSS attacks and they are going to figure stuff out.

indeed they may well do so, but they sure as hell shouldn't receive help from us in order to get there...

So we need to engage in similar tactics to understand the attack surface and protect our stuff.

similar tactics? defense is not the same as attack, they don't use the same tactics - and even if it were appropriate to use tactics similar to the bad guys (and there's a serious question of how we differentiate ourselves from the bad guys if we do), the bad guys are NOT doing their research in the public sphere... they at least have the good sense to use darknet channels to avoid helping us... that is the tactic we should be copying...

How will we defend ourselves if we aren't doing similar research?

by analyzing threats rather than creating new ones... there is no real reason to expect the malware we write and the malware they write will be similar enough for defenses against our own malware to automatically work against theirs as well...

Kurt's entire argument is based on the assumption that the bad guys aren't going to figure the stuff out anyway.

and once again, spectacularly wrong... my argument is based on the principle of not being part of the problem... it doesn't matter if they figure this stuff out on their own or not, we shouldn't be helping them...

But playing the ostrich game and hoping the problem goes away doesn't work very well.

playing dumb and ignoring the unintended consequences of your own actions doesn't work very well either...

moving right along to robert hansen's reaction (which, for previously described reasons, i'm not comfortable linking to so the quotes will just have to be good enough):

Clearly, and admittedly most of these people have no background in the issue and have never read this site

and then there's me who both has a familiarity with worms and reads the site...

as there is lots of samples of existing worm code in lots of places on the Internet now. Just because they don’t know about it doesn’t mean it’s not there.

and just because it's out there doesn't mean you should add to it...

I’ve always said, you don’t understand a problem until you see it and play with it.

playing with malware and creating new malware are not on the same level...

If working to help the understanding of worm propagation makes me evil, so be it.

understanding may be the ends but those ends don't justify the means... not everything done under the banner of a laudable goal is alright...

I’d rather be evil and be able to help solve problems than be good and be useless at solving the problem

though i've never personally referred to mr. hansen as evil, his current path will make the problem worse, not better, and it most certainly won't solve the problem... worms are not a solvable problem...

Will this empower bad guys? I’d be nieve to say there’s no chance of that.

in truth some of the bad guys will gain at least as much knowledge from this experiment as the good guys will... further, the knowledge this produces will be directly usable by them, not us... the contest is advancing the art of xss worm creation (creating new threat agents is the job of the attacker, not the defender), with the intention that the results will be usable in a second stage of research into xss worm mitigation...

For people who liken me to an anti-virus company writing viruses,

i think the closest anyone came to making that comparison was me, but what i actually compared mr. hansen to to was an anti-virus vendor motivating others to create malware that would ultimately benefit that vendor... and i made that comparison because, with the exception that mr. hansen isn't an anti-virus vendor, that's exactly what's going on...

I’d like to point out the fact of the matter which is that I don’t get paid to consult with browser companies on browser security

fine, the browser companies don't pay him, but the companies hoping to avoid getting hit by xss worms (among other things) do... the more popular that threat becomes, the greater the chance such companies will get hit and therefore the greater the demand for his services...

To date I also have never been paid by any company who has ever been hit by an XSS worm.

yeah "to date"... that's because the number is still relatively low... but as i said, he does get paid by companies hoping to avoid that fate...

Also, unlike an anti-virus company, I don’t have a security product in development.

instead he has services and a brand and who knows what he'll be able to leverage that into in the future... jamie butler wasn't part of an anti-stealthkit company when he was writing and popularizing stealthkits - it wasn't until later that he became the CTO of a government funded anti-stealthkit startup aiming to solve the problem he helped create...

Think the bad guys are going to stop their own research if we stop talking about it?

no, i just think they won't get a helping hand anymore... or has the idea of not being part of the problem gone out of fashion?

But through it all, I’m 100% confident that this will lead to previously non-published/understood results about worm propagation

and i'm 100% confident that he will hasten the onset of the web-based malware problem by popularizing it as he does...

Time to start working on solutions, rather than trying to keep the research quiet.

said as if those two things were mutually exclusive... they aren't...

and of course there were numerous comments in support of mr. hansen's actions... from christofer hoff:

I found it rather interesting that Kurt took the tact that he did. I think his point regarding the potential for misuse of code generated as a result of the contest is plausible but unlikely.

it was also the lesser of the two issues i was bringing up... however, since the bad guys have shown that they are in fact willing to use proof of concept code written by the good guys (see: bootroot) it's still something one should take seriously...

Honestly, PoC code for any sort of exploitable vulnerability has the potential for misuse, so I’m not convinced this is a corner case that deserves the flambe treatment it’s getting.

apparently i'm going to have to get used to saying 'except these are worms, not just exploits' (because i already said it a couple times on hoff's own blog)...

However, I found it a bit of a reach to accuse you of ethical violations and seeding the world with Malware so you could profit from the results as part of a giant conspiracy theory.

i didn't say he was seeding the world with malware, i said he was increasing the xss worm's mindshare... this contest does increase the raw number of xss worms, but it's worst impact is that it captures the imagination of more bad guys and makes them more apt to jump into this problem space sooner...

It’s clear that many of those posting their opinions fail to recognize which side of the fence you sit and the contributions toward making the world “better” you have made.

the side of the fence on which he intends to sit and the one he winds up on are not necessarily the same thing... the road to hell is said to be paved with good intentions after all... whatever contributions he may have made, they have to be taken in context of how they were made...

from digi7al64:

Also in response to this from Dr. Vesselin Bontchev who stated “Respectable security researchers don’t encourage the creation of malware by running contests for it!”. Sir, I don’t believe that a single entity of peers should be solely those with the knowledge to determine who and when the general public should be “allowed” this type of information.

and the reason s/he (sorry, but the pseudonym does not convey a definite gender) believes that is because s/he is either naive, believes malware research is the same as vulnerability research, or is ignorant of malware research/creation history...

malware materials belong in the hands of the public about as much as infectious biological disease samples do...

from someone calling themselves spyware:

Hiding the problem instead of stopping it? What are we, scared? Afraid for the consequences? Act NOW and you are safe.

this person is obviously someone who believes xss worms can be stopped once and for all (thereby making one 'safe')... that's not going to happen unless xss itself can be wiped out (which doesn't require worm research much less worm creation) or unless the entire web regresses to purely static content...

the ability to support malware such as worms and viruses an inherent property (rather than a flaw that can be corrected) of any system where sharing is allowed, where that sharing is transitive (what i share with you, you can share with others), and where data can be interpreted as program code... nothing in the particular implementations or even in larger patterns one sees in groups of implementations of xss worms is ultimately going to be able to stop xss worms once and for all - only stopping xss itself or all active content stops those things which allow xss worms to be...

from the very briefly named xs:

Education should never be considered unethical.

education at the expense of others may well be unethical depending on the nature of that expense...

and from robert (presumably a different robert than mr. hansen who prefers to go by the pseudonym rsnake):

Security Through Obscurity has never been a good approach,

relying on obscurity for your security is not a good approach, but there are plenty of things for which removing obscurity does not help you...

for example, you would not benefit if your personal details (full name, mailing address, telephone number, financial information, etc) became less obscure...

and that's where things stood the last time i checked... nobody (and i mean nobody) seems to get the argument about the contest leading to the threat class entering the mainstream sooner... mr. hansen came closest when he disingenuously tried to refute the argument that he stood to gain from the problem becoming worse... but the real head scratcher, the thing that i've found most frustrating of all is how people like to apply vulnerability research logic to malware research issues... i'm actually tempted to write a new post specifically about just that...

what is an email worm?

an email worm is, predictably, a type of worm that spreads over email...

email worms are perhaps the most well known type of worm since most people have seen more than a few of them in their email... in fact, during the peak of an email worm's population growth, some people have been known to see thousands of samples of a single worm in their email...

often email worms send themselves as email attachments to their victims, leading to a general rule of thumb that instructs users to be cautious with unexpected email attachments (as well as technology to strip out email attachments if they conform to one of a list of known executable file types)... there have been some email worms (such as vbs/bubbleboy), however, that have been able to spread inside the body of the email instead of as an attachment, so just looking out for email attachments isn't necessarily enough when it comes to email worms....

email worms, like all computer worms, are just programs and as such need to be executed before they can do anything... at one point email worms used any number of exploits to get themselves executed automatically as soon as the email was opened in a vulnerable email client (such as outlook or outlook express) or sometimes even as soon as you simply selected the email in the list (if you had the preview pane turned on)... many such vulnerabilities have been fixed and the option to view emails as plain text instead of html (since html rendering of email was often required for the exploits to work) has grown in popularity, but so to has the use of social engineering in order to trick the user into executing the attachment - and that still remains effective to this day...

back to index

grey goo strikes again

looks like one of the more interesting things in security blog land today was a service outage over the weekend in second life caused by the infamous grey goo (virtual virus hits second life, grey goo hits second life, worms in second life, security, a human problem)... i'm not sure why they all chose this particular time to take notice of the grey goo in a malware context but at least now i know i'm not the only one who thought it was an interesting instance of game-related malware...

this particular case was pretty unremarkable, though, unless you take the golden rings (from sonic the hedgehog) into account... otherwise it really wasn't a big deal - it's not the first time and it's not the worst time... presumably the first time was the worst time because linden labs hadn't yet developed tools to cope with the problem of self-replicating code in the game, but now they have and this latest case saw new logins blocked (if you were already in the game you could generally stay in) for less than half an hour while they cleaned up the mess (as opposed to the head scratching and long-delayed resolution they went through when the problem first came up in october of last year)...

of course there's more to the story of grey goo than most seem to be reporting... last month i wrote about it, about it's classification, and about the counter measures linden labs developed - essentially behaviour blocking technology... the fact that grey goo continues to pop up from time to time illustrates the broader principle that behaviour blocking can't completely solve the virus problem... i suspect that the quick cleanup this time points to what essentially boils down to a signature based removal technique as well (which, for the time being at least, is a perfectly reasonable way to recover from the special cases that get around the primary defense), so linden labs continues to be an interesting example of anti-malware techniques and technology developing in the apparent absence of but parallel to the anti-virus industry...

second life's 'grey goo'

i don't play second life myself (i don't know how people find the time) but i caught wind of an interesting story last week by way of boingboing.net about self-replicating objects inside the second life game...

pat yourself on the back if you think this is going to wind up with me labelling them viruses - but not too hard (you might break your spine) since this is a virus related blog...

yup, it appears that users can make their own objects in second life and code behaviours into those objects with a scripting language... that makes them, essentially, programs... and those second life objects that self-replicate? well they're self-replicating programs, which fits the academic definition of virus like a glove... apparently there are a number of different grey goo incarnations (since counter measures were developed and deployed) but i haven't found any descriptions yet that could be interpreted as a program infecting another program, so i would probably classify the grey goo as a kind of worm (more specifically i suspect it might qualify as a rabbit)...

one of the things about this that is interesting to me is that this is a departure from the other stories one often hears about regarding internet gaming malware... generally the malware one hears about is a password stealer or some other kind of spyware meant to enable the attacker to steal something of value... they're held up as examples of how malware today has become financially motivated (so-called crimeware)... as near as i can figure, however, there's no direct financial benefits to grey goo attacks - if anything they seem more like the vandalism stage of malware we used to have and perhaps it's good to remember that technically that hasn't really gone away yet (obviously)...

some folks may disagree with the vandalism charactization - after all, in the real world grey goo would qualify as a weapon of mass destruction... second life isn't the real world, however... the grey goo in second life doesn't consume other in-game resources like real world grey goo would (which makes it both more benign and in some senses harder to control) - the only resources second life grey goo consumes are the computing resources of the game servers, effectively executing a DoS attack on the game... nobody dies and nobody's in-game character dies; at most it really just brings the servers down and interferes with in-game commerce (which has apparently branched out into real-world commerce but interfering with that wouldn't really qualify as mass destruction)...

another interesting aspect are the counter measures that have been developed to combat the grey goo, particularly because they were developed in-house at linden labs (creators of second life) rather than by the anti-virus community and because they seemed have come up with familiar solutions in spite of not being part of the anti-virus industry and probably not even thinking of it as a viral problem... one blog commentor shudders at the thought of writing an anti-virus to address the problem and yet that's exactly what linden labs did with their grey goo fence... of course it's not what the average person would consider an anti-virus, it's not a signature based known virus scanner (perhaps because the anti-virus industry has done such a poor job of image control that the idea of creating a conventional scanner for this problem was anathema to the developers), it's a behaviour based system that triggers on excessive instantiation (rezzing) within a family of objects (too many children in too short a time is bad)...

one key thing to point out is that behaviour based systems (like all preventative measures) are not perfect and the grey goo fence is no exception... apparently second life requires objects to be able to instantiate other objects so some level of self-replication is always going to be able to get in under the grey goo fence's threshold... additionally it might be possible fool family membership evaluation (perhaps by socially engineered player intervention)... at any rate, the grey goo fence has failed and a new counter measure being suggested is limiting some of the scripting functionality required for self-replication so that only trusted individuals can make use of it - which is essentially a kind of whitelist... whitelists won't be a silver bullet either, of course, because there is a limit to the accuracy and scope to which one can objectively define trust...

it'll be interesting to me to see where this kind of in-game malware proceeds - whether truely infectious self-replication emerges, whether other types of malware-related techniques are employed... it almost makes me want to play the game and see it first hand... almost...

symantec, viruses, and the mac

i've written about viruses and the mac before but of course people don't read what i write or don't listen to what i say or maybe just don't think i'm right and so continue to make silly gaffes... sometimes those people are even in a position where you'd expect them to know what they're talking about...

take for example the recent pronouncement from symantec that there are no file infecting viruses for the mac osx platform... todd woodward is a symantec employee so of course people are going to assume what he says about viruses and the mac must be true... he makes a pretty convincing argument too, except for one tiny problem - in trying to convince us that osx/leap.a wasn't a file infecting virus he points to a symantec virus analyst's write-up that actually says osx/leap.a does infect files...

ooops...

but lets not be too hard on poor todd, after all he's not a virus analyst himself, rather he's a product support analyst for symantec... still, that embarrassing gaffe could have been avoided if he'd simply read the page he was linking to...

so just to clear up the confusion (and to repeat something i've said a bunch of times already) osx/leap.a is an overwriting file infector (that would have been a companion infector if not for a bug in the code) and an instant messaging worm at the same time... that's right, is a worm/virus hybrid and therefore there IS a virus for the mac osx platform... i get the feeling that perhaps todd is not aware that something can be both a virus and worm at the same time but it can and there are plenty of examples in the windows world so that part of his post about the differences between worms and viruses is poorly conceived..

a little clarity on the RFID virus issue

you may have read recently about the newly discovered possibility of using RFID tags as a vector for viruses and worms... there seems to be some confusion about this and to be honest that's not unexpected when even the researchers who came up with this are unclear on the matter of viruses and worms (they use the old erroneous distinction between worms and viruses where worms don't require interaction from the user even though neither their worms nor their viruses require interaction)...

first off, the RFID tags are a storage medium (not unlike a floppy disk or USB flash drive) with a very small capacity (1024 bits or 128 bytes)... they don't get infected, per se, they just hold the code and nothing more...

second, the data stored on the RFID tag can be malformed in such a way as to exploit a vulnerability in the system that reads and stores the data, such as an SQL injection attack that executes a self-replicating query...

third, although the main example given in the source material doesn't infect any host programs it's not inconceivable that an actual infector could be written (for example an SQL query that infects stored procedures)...

fourth, this isn't a concern for regular folks, only for warehouses and shipping centers and other similar places that would be actively using RFID tags and entering their data into some sort of system... the 'virus' can't magically jump out of the RFID tag and infect your computer, nor can it hop from one RFID tag to another (although once the 'virus' copies itself over other tag data in the database it may get written back to other RFID tags by the system)...

this really isn't as technologically ground breaking as it might first seem... viruses and worms exploit vulnerabilities in order to self-replicate on a frequent enough basis - the only addition here is using RFID tags as a storage and distribution medium...

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...

what is a worm?

a worm is a self-replicating program that is able to make (possibly evolved) copies of itself that are not attached to (via infection) other host programs...

that is not to say that worms can't infect host programs, there are already many examples of virus/worm hybrids that are able to self-replicate using both strategies - later variants of klez, for example... there are also examples of virus/worm hybrids that must infect a host program in order to self-replicate (like w32/ska, which needs to infect wsock32.dll in order to email itself*)...

also since it must self-replicate, a worm meets the requirements of the mathematical definition of virus and can therefore be thought of a kind of virus, but only in more academic/scientific contexts...

while there are schools of thought that would include such further constraints as being able to spread over a network or even being network-aware, these constraints are arbitrary and in some cases just wrongheaded... for example - a program that copies itself to all logical drives provided by the operating system is actually still able to spread over implicit networks like sneakernet, as well as being able to spread over more conventional windows networks in the presence of mapped drives... the requirement for network-awareness, on the other hand, is actually an attempt to narrow the network spreading constraint by introducing intent into the equation (network-awareness becomes an indicator of intent to spread over networks and thereby weed out the supposed accidental network spreading in the previous example) while completely ignoring the fact that intent is an entirely subjective quantity (especially when judging it from code) and causes the definition to no longer be functional for no apparent reason or benefit...

(* thanks to peter szor's book for reminding me of that)
back to index

false authority syndrome finds it's way to The Register

in reference to the following artice:
Beastie Boys CD installs virus | The Register

the author of this article is Thomas C. Greene... consider the byline:

[quote]
Thomas C Greene is the author of Computer Security for the Home and Small Office, a comprehensive guide to system hardening, malware protection, online anonymity, encryption, and data hygiene for Windows and Linux.
[/quote]

there seems to be every reason to take his word as gospel, doesn't there... one problem, the article he wrote for The Register indicates that he clearly has no idea what viruses, worms, or trojan horse programs (3 major classes of malware) are...

the DRM software installed by the new Beastie Boys album is not a virus for 2 reasons... most importantly, it does not self-replicate - it does not make copies of itself, copies aren't placed on your existing music CD's, the installer is not (as far as i can tell) get placed on any new CDR's you happen to burn - the most fundamental requirement for classifying something as a virus is that that something has to self-replicate (this has been true ever since the invention of computer viruses by Fred Cohen in 1983, and you can refer to his numerous works on the subject if you don't believe me)... second, it does not infect any host program - by which i mean that it does not attach itself to any program in such a way that when an attempt is made to execute the host program the DRM software does not get executed as well as or instead of the host program... infection of host programs is generally regarded as a requirement for calling a self-replicating program a virus instead of a worm (another kind of self-replicating malware) or something else...

so it's not a virus because it doesn't self-replicate and it doesn't infect host programs...

Mr. Greene makes further errors in his justification of calling it a virus rather than a worm... there is an argument (that is not particularly well thought out) that says that viruses require user intervention and worms do not - however that argument is meant to be applied to the way the virus or worm gets executed, not how it gets copied (as Mr. Greene seems to think)... clearly, as the DRM software autoexecutes, the DRM software in question better suits the classification of worm under this (dubious) argument...

what the DRM software in question actually is, is the payload of a trojan horse - a trojan horse being something that advertizes itself as performing some desirable function but does something bad in addition to or instead of that desirable function... even a passing familiarity with the field of malware should have made this readily apparent to Mr. Greene....

the legal implications are pretty much the same, though... that much he got right...