Monday, March 29, 2010

metasploit open letter revisited

"what we have here is a failure to communicate"

at least, that's what it feels like after fielding a bunch of comments on my last metasploit related post. hd moore specifically felt the need to clarify his view and since it seems that my position could stand some clarification itself i'd like to reiterate my response to him here.

my open letter to the metasploit community was meant to drive home 3 points:
  1. AV detection of metasploit output is a problem for anyone trying to use metasploit legitimately and not necessarily appropriate.
  2. when people go around saying there's something wrong with AV because it fails to detect metasploit output (in other words, there's something wrong with AV because it fails to do something we've already established would be a problem if it did do) then that actually contributes to the problem by generating market pressure on the AV vendors to correct this supposed problem and add detection.
  3. since (1) is a consequence of (2), therefore discouraging (2) should help minimize (1).
(2) is what i saw when i watched john strand's video, but as it happens i've also had a chance to communicate with john and gain a better understanding of where he was coming from (i'd like to think he also gained a better understanding of where i was coming from but that's immaterial for this discussion). i won't divulge the contents of a private communication but i will say that i came away with the impression that he was more interested in showing that there is something wrong with defenses that rely too heavily on what is traditionally considered AV.

if my interpretation is correct then i am in complete agreement with him and i think you'd be hard-pressed to find anyone in the anti-malware community or industry who would disagree. i'd even go so far as to say that his video was an appropriate way of demonstrating that point if that point had been presented in such an unambiguous manner. unfortunately that's not what i took away from it when i first viewed it, and as some of the comments on the 'open letter' post show there are those with a far less nuanced understanding of the topic. i just watched the video again and although i found the phrase that triggered my previous response, in light of my new found understanding i no longer see it the same way.

there isn't anything wrong with AV technology per se (and there are certainly some vendors with more non-signature-related bells and whistles than others), but rather the way people use it (as their one and only defense). it's a poor craftsman who blames his tools, so stop trying to drive screws with a hammer and stop trying to block new/unknown threats with a known-malware scanner.

Wednesday, March 24, 2010

bad advice: disable your av

i'm sure you can probably think back and remember at least one example of a piece of software you've installed in the past that came with directions suggesting you disable your anti-virus before you install.

that little pearl of anti-wisdom has been with us a long, long time and has always irked me. the software industry, whether too lazy, too hurried, or to ignorant to know any better, decided that rather than resolve whatever conflict they may encounter with security software it would be better to train users to drop their defenses.

what could possibly go wrong?

plenty could go wrong, of course, not the least of which being that once the users are effectively trained to drop their defenses when told it would be trivial for malware authors to distribute their wares with instructions telling people to disable their av. who needs to develop technical measures to bypass anti-virus when you can simply tell users to turn it off for you and have them do it like good little trained monkeys.

well, nowadays more and more applications are being delivered to users over the internet, specifically over the web, and along with that, anti-malware products are focusing increasingly on web-borne threats. as such you can probably guess this was bound to happen eventually:


































yeah, this WTF moment was brought to you by a facebook application development company called chainn who thought it would be a good idea to tell users to disable (or even remove) norton anti-virus. hey, it worked well enough back in the days of desktop applications, right? why not facebook applications too? i mean, really, what's more important, online safety or finding out how you fit in amongst your friends?

apparently they also have some problems with adblock plus - i wonder why?

Saturday, March 20, 2010

fooled by spam

march has really not been my month. first i find out that not only have i finally had my very first malware incident but that it had also been present for nearly a year, and then i get fooled into approving a comment that is in actuality spam.

cdman83 has a writeup on the spam campaign, and gunter ollmann got the final word from sophos that it really was someone loosely associated with them (an employee of a company they hired) who was responsible and who they intend to take to task over the fiasco.

perhaps i'm losing my touch in my old age and becoming too trusting, too willing to give the benefit of the doubt. then again, if i'd had the multiple comments that gunter ollmann had i would have had a far less ambiguous dataset from which to draw conclusions from. i guess i shouldn't feel too bad about being fooled, after all i was only fooled into approving a relatively benign comment - sophos was fooled into hiring the company in question in the first place and giving them money.

Monday, March 08, 2010

the energizer bunny looks more like a RAT

that's RAT as in remote access trojan, for the uninitiated.

by now i'm sure most security folks have heard about this but if you haven't yet, here's the US-CERT advisory, symantec's blog entry by liam murchu, a sophos blog post by graham cluley, a blog post at cybercrime & doing time by gary warner, a sunbelt blog post by tom kelchner, a zero day security blog post by ryan naraine, and that's just the tip of the iceberg.

now the reason i'm writing about this story that so many other people have written about when i normally eschew over-reported news events is because i have a personal stake in this - i actually have the offending device. worse still, i had the software in question installed on one of my computers since late march of last year. ouch! thanks to a tweet by mikko hypponen i found out about this early saturday morning (thanks mikko, that's just the way i wanted to start off my weekend) and proceeded to cuss up a storm because this is the first time in my 20+ years of computing that i have legitimately been been hit with malware - my perfect record is over.

oh well, enough of that. there are 2 things about this that i think deserve closer scrutiny. the first is that question of whether the malware shipped with the hardware device itself as many have stated, or whether the symantec blog is right and the software was only available as a download from the energizer website. i can't say conclusively one way or the other but i can offer some evidence that the software was only ever available from the energizer website.
  1. the device has no memory capacity. no drive appears in windows explorer when you plug the device in.
  2. when you plug it into a computer it asks to install drivers but can find no drivers to install.
  3. the package i got did not contain any separate media, and when i searched for the device on ebay, none of the packages there seemed to either.
  4. the instruction sheet (yes, i still have that too) informs you that you can see the charging status on your computer with free software from the energizer website
  5. the software is entirely optional. the device works without it (though the software does offer improved usability over the indicator LED). the device even ships with an AC->USB converter (which is what actually drew my attention in the first place) so that you can plug the device into the wall and bypass the computer (and thus any monitoring software) entirely.
  6. not only does the instruction sheet instruct you to get the software from the energizer website, but when you plug the device in, the device identifier displayed in both the new hardware notification bubble and driver installation wizard includes not just the product name but also the URL for downloading the software from energizer.
perhaps there was alternate packaging that included the compromised software, but when even the hardware tells you to download the software from the web then it hardly seems necessary for there to ever have been software packaged with it.

the second thing i think deserves examining is the question of what went wrong. as i said, i got hit with this, but could it reasonably have been avoided? that's a question i've been mulling over since saturday. let's go through the various failures and see if i acted unreasonably wrecklessly:
  • anti-virus products didn't detect it back then. i scan everything and the software came up 'clean'. av failed to save me here.
  • application whitelisting also failed me. it asked if i wanted to allow the software to run but this is software i intentionally installed - why wouldn't i allow it to run?
  • of course there are reasons to disallow software you just installed - i did my due diligence and googled the file and everything told me that it was associated with the charger and nothing said there was anything untoward about it. as such the community intelligence, the nascent reputation system of the internet let me down also.
  • the software firewall is an interesting case - in theory i could have made the connection and asked why battery charger software needs to open a port and listen for connections. on the other hand, i did research the file and found nothing to indicate it wasn't legitimately part of the software and therefore no reason not to trust that whatever it was trying to do was something it was supposed to do. maybe i could have been more suspicious, maybe i even was - the compromised system was a 10 year old clunker that isn't particular responsive to input at the best of times which, when combined with the occasional popup overload from the firewall/whitelist combo, has resulted in at least one instance of my clicking the accept button without seeing what i was accepting.
  • could i have saved myself some headache (and saved a bit of face) by using sandboxing? given the particulars of the system there's no way i would use a full virtual machine on it, and besides that would have been overkill for this application. it also would have interfered with the rather desirable behaviour of automatically launching the monitor UI (application virtualization wouldn't have been much better in that regard). that sounds like a strange thing for me to say, but the PC is so old that launching anything on it is painfully slow so the automated behaviour was welcome at the time. i suppose the fact that i never had any intention of hooking it up to my main PC (which actually has power running through it far more often) means that at some level i actually was using a sandbox of sorts - a physical sandbox machine if you will - but really, i trusted the software and had no reason to think i needed to run it in a sandbox.
trust seems to be the recurring theme here. i trusted the software. maybe i shouldn't have trusted it, but you can't get very far in computing without trusting at least some software, and there wasn't a compelling reason not to trust this software.

one thing to take away from this (or at least something that i'm taking away from it) is that a number of my security behaviours only help to protect me against the unknown. if i trust something, even though i'm wrong, there isn't much my defenses can do to help me. i will certainly be thinking about ways to overcome that weakness in the future.

of course, since i was behind a NAT-enabled router and wasn't forwarding port 7777 to the compromised machine, some of my defenses did work - but i was lucky. if it had been some other, more aggressive type of malware things might not have turned out so well for me. or, on the other hand, anything more than the passive listening for commands might have actually tipped me off to the presence of something malicious.

we can play "what if" until we're blue in the face - i've identified both the fact that my defenses have room for improvement and the nature that improvement must take. i've also been reminded that what they say really is true - it happens to everyone eventually. it took more than 20 years for me which is longer than most and i've been a little cocky about that, but in the end there's always some weakness, some way in, and if it hadn't been for my monitoring of security-related events i'd probably still be compromised right now. in the end the thing that helped me the most was my interest in security itself.

Friday, March 05, 2010

open letter to the metasploit community

dear metasploit community,

first, please direct your attention to the following video as it demonstrates the very thing i'd like to speak to you about:


as members of the metasploit community, you are no doubt aware of the various legitimate uses for metasploit and the exploits it generates. validating the efficacy of a patch, testing patch deployments, maybe even some penetration testing.

i imagine that you're also aware that some in your ranks have embarked on a wholly misguided ideological quest to highlight the supposed shortcomings of the anti-virus industry using metasploit and it's output.

now let's be clear about something here; we are all in agreement that there are legitimate uses for metasploit's output, therefore that output in general can only be classified as potentially unwanted programs. let's also be clear that the only proper way to address the vulnerabilities that metasploit's output exploits is by patching the vulnerable software. as such, the argument put forward that there's something wrong with anti-virus products that don't detect metasploit output is fallacious on 2 counts: 1) the output isn't necessarily malware (usually only greyware), and 2) anti-virus products are not the proper defense against known exploits (patching is).

there are some concepts in the anti-malware community that some members of the metasploit community may be less aware of than others. one is that there is a countably infinite number of possible programs, and of those a countably infinite number that can do bad things. it is beyond the realm of possibility to detect an infinite number of things so the anti-malware industry has wisely limited it's focus to those that actually exist, to threats that are real, at least as far as malware scanning goes.

another concept which may not be all that apparent is that, while we've faced users of malware creation toolkits for a long time, we have generally lumped them in with the script kiddies due to the complete lack of skill requirements for using such toolkits.

now, even though metasploit isn't a malware creation toolkit (since it's output generally can't be considered malware), it's being used like one in the above video (with the concomitant implication for the user in question). furthermore, this non-malware is being uploaded to virustotal, effectively abusing the service by wasting it's bandwidth on known non-malware, in order to test scanners in a manner that the people who run virustotal themselves say is invalid.

this in turn is putting pressure on av vendors to add detection for metasploit's output, even though that output isn't technically malware, and you know what? as vendors add better and better detection for metasploit's output files, metasploit becomes less and less capable a tool for the legitimate purposes we already identified because anti-virus products will interfere with it's use. how can you use output files from metasploit to validate patch efficacy, test patch deployment, or perform pen-tests if the anti-virus is blocking them? the argument could be made, i suppose, that anti-virus impeding pen-tests is actually a good thing, but it's clear that anti-virus is a fragile defense against exploits when compared to the proper defense of actually patching the vulnerabilities and if AV is interfering with your ability to test if the proper defenses are in place, that really can't be considered a good thing.

with all of this in mind, i would like to ask the metasploit community to do whatever you can to help discourage people from engaging in the behaviour demonstrated in this video. it's arguably worse for the metasploit community than it is for the anti-malware community, but it is definitely bad for both communities and, i think, bad for security in general. no one is helped when people burn one perfectly good tool in order to shame another simply because the tool they're targeting doesn't behave the way they naively think it should.

Monday, February 15, 2010

the true nature of security

what is security

security can mean many things to many different people. have you ever wondered why that is? do we examine what security is and what the nature of it's relationship is to other supposedly related topics or do we simply build upon a foundation of an instinctual gut level feeling about what is and isn't secure? for me (and others like me) it has traditionally been the latter, but i'm about to do the former and take you, the reader, with me.

i'm going to try and lead the thinking a little bit. try to complete these sentences:
i don't feel _________ online without an anti-virus.
i don't feel _________ online without a firewall.
i don't feel _________ doing online banking without SSL.
now if you're reading this blog there's a good chance you see the world through security-coloured glasses and likely answered "secure" for all 3 questions. unfortunately, while seeing the world through security-coloured glasses has no doubt served you well over the years (i know it certainly has for me) the fact is that it's still a distortion of reality (regardless of how useful it may be). i want you to think about basic human needs. i want you to think about someone who isn't as security conscious as you are - in fact someone who isn't even technologically sophisticated. think about someone who's afraid to go online and tell me how you think they would complete this sentence:
i don't feel ________ online.
if you guessed safe then you get a gold star.

so to start things off, security is related to safety. this is demonstrated by what i consider to be the best answer to the "are mac's more secure" question - that being they're safer but not necessarily more secure. clearly we're expecting security to help us meet our basic need for safety. there is a school of thought that says everything we do represents a strategy for meeting our basic needs (even altruism is said to come from a need to contribute). therefore it can be said that security is a set of strategies for meeting our basic human need for safety. notice, however, that i did not say it was the set of strategies for meeting that need - as the answer to the "are mac's more secure" question indicates there is more than one path to safety.

i'm going to make an aside here and address something that may be a sticking point for some people. when i talk of strategy here, i'm not talking about the kind of stuff sun tzu would dream up. there's an entire spectrum of strategies, going from the primitive all the way up to the complex. the kinds of strategies people employ day to day are often not arrived at through deep thought, but through trial and error, growing organically as the need arises. that being said, sun tzu does have a lot of wisdom that can be applied to the analysis and formulation of strategies once one undertakes to purposefully modify their strategies.

regulation vs. privacy

two other topics that seem to often be associated with security are regulations and privacy. in fact i recently came across the unusual juxtaposition of "regulation vs. privacy". why do i think that's unusual? well look at it this way - both seem to be related to security so it stands to reason that they are both approaches to meeting our need for safety - so why should 2 things that are meant for the same purpose be at odds with one another? to understand that i think we need to delve deeper into what they are and how they fit together with security.

regulation

at a basic level, what are regulations? they're really just rules that individuals or groups are expected to follow. they don't really do much for us all by themselves, though, do they. i could make a rule that says everyone must wear a green shirt but it would be meaningless. i have no way to enforce it. even if i found a way to enforce it, i wouldn't have the moral authority to do so. there we have the key to understanding regulation. it's one part of a bigger whole. you can't just have rule makers, you need enforcement as well, and the authority to do so or society will rebel against you. the most straight forward examples of rules and enforcement are laws and police. together we generally consider the lawmakers and police to be the authorities and as such we can say that in security circles when we talk of regulation what we're really talking about is a class of strategies for meeting our need for safety called authority.

privacy

so is privacy also part of a duality like the regulation/enforcement example above? if it is i can't really see it, but i can see how it represents something more general. in fact, using a mac (or any other alternative platform) for improved safety is also an example of the same thing. think about what you're doing when you're keeping something private - you're hiding it from the public, you're obscuring it from vision. now think about what you're doing when you use an alternative platform like the mac, or alternative browsers or other software - rather than using the most popular thing, you're using something that's more obscure. thus it can be said that obscurity is another class of strategies for meeting our need for safety.

putting the pieces together

now that we have a few pieces, let's see if we can put them together into something coherent. coming from a strategic point of view, when we're trying to maintain our safety while dealing with an opponent there are a few broad categories of things we can do.
  1. first and foremost we can neutralize the opponent before s/he can attack us. this is the role that authority plays. we make rules of conduct (either formal or informal) intended to maintain our safety, identify those who violate those rules (to determine who our opponent is), and then try to sanction them in some way to keep them from violating those rules in the future (neutralize them before they can attack again).
  2. next we can harden ourselves against attack, make ourselves invulnerable or at least minimize the impact of an attack that is launched against us. this is the role that security plays. we set up roadblocks, we try to identify where our vulnerabilities are and fix or cover them, and generally try to shield ourselves.
  3. finally we can run and hide. as much as we may dislike the notion, sometimes our other efforts aren't good/effective enough. this is the role that obscurity plays. by making ourselves more difficult to target we in effect make ourselves less likely to be attacked.
at this point it seems that not only do authority, security, and obscurity fit together rather nicely, there also doesn't appear to be room for anything more; with the exception, perhaps, of recovery for when everything else fails. but recovery doesn't preserve safety, it doesn't keep you safe from harm and so is not really related in that sense.

for the 6 year olds

a quote often attributed to einstein goes as follows:
if you can't explain it to a six year old, you don't understand it yourself.
i happen to think that's a pretty good yardstick for measuring understanding so how can we explain this in terms a six year old can understand? my tendency is to relate it back to antiquity, to a fanciful time that most children (in the western world at least) are familiar with and probably fantasize about to some extent. i would say that authority is like the sword we use to strike down our opponents with before they can strike us down, security is like the shield or armour that keeps us from harm when our opponent does strike us, and obscurity is like the hiding place we use when the sword isn't sharp enough and the shield isn't strong enough.

one other thing i would do, of course, is use pictures.


regulation vs. privacy revisited

getting back to that question of why these two different things that are supposed to be for the same goal are at odds with one another, i think there are two main reasons for this. the first is the obvious; our opponents have the same basic human need for safety as we do so our respective efforts will certainly clash to some extent. the second reason is more subtle. notice that when we speak of regulation we're addressing only one half of authority - rule making. i think we take enforcement for granted. i think we focus too much on the making of rules and so when authority fails we think we need to make new rules (not unlike the old saying "when all you have is a hammer, everything looks like a nail"). what happens next is that those new rules often confer greater powers onto enforcers, and that opens the door to abuse. this single-minded focus on regulation over application is dysfunctional and can hurt us just as easily as it can help us. greater powers, like the sword of damocles, loom over all our heads not just those of our opponents.

information security

if you've had a growing sense that something was wrong, that all of this seems to not quite fit with the notion of information security somehow, then you'd be right. after all, information is just ones and zeros, bits and bytes. you can hide a bit you can't harden a bit against attack - and for that matter, attackers don't generally attack information, they steal it.

so what's going on? well, what do attackers attack in order to steal information? the systems which store, transmit, and control access to that information. in other words, information systems. what these systems do is obscure information, but the systems themselves can be secured in their own right. strategies need not be used in isolation from one another and this is an example where both obscurity and security are combined. indeed, both are generally considered to be within the realm of self-defense and so can be practiced by the widest array of individuals and organizations. we call it information security, i suspect, for much the same reason you likely answered "secure, secure, secure" to the questions at the beginning of this post - because we look at the world through security-coloured glasses. data security is a further bastardized version of this.

security folks don't like obscurity very much, they often say that there's no security through obscurity and even in this framework they'd be correct - but there is safety through obscurity. we can tag data, make it self-describing, etc. but it can never defend itself because data is not an actor. systems through which it is accessed may defend it based on whatever protection-specific information is present, but that's the system doing the defending, not the data itself. encryption probably comes closest to securing data in the sense of hardening it (because it does seem like we're doing something to the information itself), but still the data is just inside an encrypted envelope and the only security present is in keeping the decryption key secret (hidden/obscured).

the true nature

so it seems that i've gone through all this just to say that security is one of 3 different classes of strategies (along with authority and obscurity) for meeting our basic human need for safety in some fashion or another. that presents us with an interesting opportunity to talk about the state of security because in this context what we'd really be talking about is how effective our strategies are. if we find them wanting, that further begs the question how can we improve them, and then we're in the realm of purposefully modifying our strategies to achieve something closer to the optimum state. we should also be better able to recognize now the roles of authority and obscurity and how those strategies too can be put to use for our real goal of safety.

Thursday, February 11, 2010

update on possible user database breach at instructables

i have good news for instructables.com users. i've been in contact with Eric Wilhelm, CEO of Instructables, who was able to get to the bottom of the issue i previously blogged about in short order and it turns out to have not been a breach of their database after all.

Instructables uses a 3rd party service to handle their newsletters. in the past they used a company called iContact, but they switched to Streamsend 2 years ago. it appears that iContact recently had a breach of their systems which you can read more about on the iContact blog.

as such it seems likely that it was only email addresses (not other, potentially more sensitive information like credentials) that were leaked since that's the data iContact would have needed access to. further, anyone who joined Instructables after the switchover to Streamsend would not have had their email address compromised by this event. this should still serve as a reminder, however, of how important it is not to re-use your passwords as, had it actually been a breach of the Instructables user database, it wouldn't have just been your Instructables account that the attackers got access to, but also every other account where you used the same username and password.

finally, there will undoubtedly be those who question why iContact still had Instructables data after 2 years. while Mr. Wilhelm expressed regret for not insisting that data be purged, i can only imagine why iContact was holding onto data it couldn't (or rather shouldn't) use for such a long time.

user database breach at instructables?

many have at least heard the advice to use unique passwords at every site they visit. well i go a few steps beyond that. not only do i use unique randomly generated passwords at every site, i use unique randomly generated email addresses at each site too.

that probably sounds like overkill, but consequence for me (besides knowing exactly which sites are spammy) is that the older identities collectively form a kind of honeypot for detecting user database breaches.

it was as a result of my address for ethicalhacker.net receiving spam that i realized (and later verified) that something untoward had happened there and so it is that today i'm going to come out and say that something fishy is going on over at instructables.com.

a unique, randomly generated email address (basically a secret shared between only myself and instructables) that is unguessable (there are approximately 4.7x10^18 possible values so the chance of them guessing one of my 200 or so addresses is so small that if they guessed 1 million times a second it would still take on average 375 years before they got one) should only be usable by those who know it, so the fact that i'm receiving drug spam at this email address tells me that somehow the user information they had in their database for my account has been leaked.

*update*: it appears i miscounted the number of characters in the email address and thus my probability calculations are off. there's only 1x10^14 combinations, which means that at a million guesses a second someone could get expect to guess one of mine in (on average) about 3 days. i'm not convinced that sort of brute forcing operation is going on, however (it seems like it would be too much work for too little benefit).

Tuesday, February 09, 2010

2nd annual security blogger summit

last week i attended the 2nd annual security blogger summit put on by panda security in madrid, spain and i figure i ought to share my experience for the benefit of those who may wind up going next year. a handful of people may be aware that this is not the first time a vendor has offered to fly me somewhere for some event they're putting on, and some might wonder why i agreed this time when the last time i refused on the grounds of maintaining my rabid independence. the answer is pretty straight-forward - at the security blogger summit you are actively chastised for mentioning any vendor by name, and nobody would argue that the attendees of the previous one (such as bruce schneier or andy willingham, for example) are in any way in panda's pocket. also, opportunity rarely knocks twice. at any rate, on with my story.

my flight was to leave pearson international airport in toronto at around 7pm on tuesday, february 2, so i arrived at the airport at 4pm (i like to arrive early because you never know what's going to happen). at the very entrance of the passage way to the gates (before getting to security at all) there was a guy basically reminding people of security restrictions and asking everyone who passed whether they were carrying any liquids, gels, or pastes. i had toothpaste with me and apparently this was a problem because in spite of the fact that the tube was nearly empty and obviously flattened all the way down to the cap this security guard was more interested in the original capacity of the container because he thought it might be too big. thankfully he found the label that said 90ml and that was an acceptable size, but i still needed to put it in a clear plastic bag.

next up was the actual security checkpoint. i learned some valuable lessons here, like taking off my boots before going through the metal detector. unfortunately my boots weren't the only thing to set off the metal detector, the zipper of my pants did too. even the security guard's wand was set off by my zipper (just a standard zipper on a normal pair of jeans by the way, nothing fancy or unusual). this was the only airport i went through on the entire trip where the equipment was so sensitive that it was set off by my zipper so (thankfully) it was the only time i got a pat-down on the front of my pants (yes, i'm aware that sounds a lot like i got groped by airport security - perhaps it even qualifies as precisely that).

following that was the big wait, because in spite of the trouble i had getting through security, my early arrival meant i still had plenty of time. more time than i had even banked on, apparently, because the plane was 15 minutes late. that shouldn't be a problem except i don't have a direct flight to my final destination. it still shouldn't be a problem because there's supposed to be an hour between the arrival of the first plane and the departure of the second, and even with that 15 minutes removed that still leaves 45 minutes so i wasn't worried and i enjoyed watching movies on the 7 hour flight to paris. as an aside, this had been the first time in 7 years that i'd been on a plane so the tiny screens in the back of the seats was quite a novelty. unfortunately, when we landed, i was informed by the flight crew that i had missed my connection and would have to see customer support to get the next flight. so i wait in line, and wait, and wait some more, only to be told that no, the flight hadn't left yet and if i hurried i might catch it (this is 2-3am my time by the way). so i hurried along until i was stopped at an access control point and asked what flight i was trying to get to and then informed that it really had left and so i went to the customer service desk conveniently located right there and got my boarding pass for the next flight.

that next flight was to be 3 hours later, a little after 12 noon, paris time (which made it after 6am my time). the gate, however, was a bus terminal - i'm now familiar with boarding a plane by bus, but that was the first time i'd heard about such things so in my sleep deprived mind i was rather confused. at any rate, i struggled to stay awake so that i wouldn't miss my bus and eventually it arrived and took us to our plane where we waited for takeoff. and we waited, and waited, and waited some more until the voice over the intercom informed us that the flight wouldn't be leaving as planned because the brakes were broken (of all the things that could break, it was the brakes). so we waited and waited and waited some more when the voice apologized for the delay and said they were still trying to figure out where the bus was to take us to another plane. eventually that bus arrived and we boarded it and headed off to the next plane but what struck me as curious was that that bus was being followed by another bus that displayed the flight information not for the flight i was on but for the subsequent flight to the same destination. that's right, i missed not one but two flights to spain and now they were going to try to squeeze 2 flights onto the same plane. thankfully that worked and i finally arrived in madrid, spain 5 hours later than my originally scheduled arrival time.

with that out of the way, i got offered a cab ride to my hotel (or what i thought was a cab, but not having seen spanish taxis yet i didn't realize that it was a more expensive option - and if their are any spanish cab drivers reading this, please make sure to print the cost clearly on the receipt rather than scribbling it so that i can actually read it and avoid you trying to explain that it's 79 euros without being able to say 79 in my language). once there i checked in, familiarized myself with the room, cleaned myself up and waited for the scheduled 9pm dinner with the others (there wasn't time for sleeping, at least not the kind of sleeping i needed after being awake for nearly 2 days). at 9 i wandered down to the lobby and had a nice meal with luis corrons, brian krebs, sean-paul correll and his girlfriend (whose name i can't recall - sorry), and josu franco; and we stayed in the hotel restaurant eating and talking until long after all the other hotel guests had left. i have no idea what time it was when that ended but i do know that when i finally got to bed i fell asleep immediately.

as hard as it was to pull that all-nighter, though, it worked perfectly because i had no trouble adjusting to the 6 hour time difference the following day. that's a good thing too, because that was the day of the main event, as well as a press conference in the morning. now those of you who are going to subsequent security blogger summits and who like to be surprised, you may want to skip the rest of this paragraph and the one following it because i'm going to share some of the surprises i experienced as the agenda for the event was a little vague about certain things. first the press conference: we had been told it was really more of a breakfast with journalists - well, ok, i've never been to either a press conference or a breakfast with journalists so from my perspective it was more a case of 3 of the english speaking panelists (brian krebs, joseph menn, and myself) presenting a synopsis of what we intended to talk about at the main event, while eating cookies and pastries. everything we said was then translated by our excellent translator matilda (sp?) and then the journalists asked questions which we answered and those answers were also translated back for the journalists. following that was a filmed Q&A with each of the 3 of us individually. following that was long lunch (they seem to like late, long lunches in spain) with most of the english and spanish panelists and after that was the main event, the summit itself.

i'm going to be brutally honest about this part - i was disappointed in my performance at the summit. i was too quiet. i have to admit, i was actually holding my tongue, even though i knew i should have been speaking more, but let me explain why. what neither the agenda for the event, nor the videos from last year's event hinted at was that the panel discussion was to be a 3 minute explanation of each panelists view of the state of security (i was thinking of going with the true nature of security and the security user conversion problem, but 3 minutes? oh, and hey i haven't even settled on a solution to the conversion problem yet) followed by a debate where each panelist with something to say had to get in line and wait their turn. and what a debate that turned out to be. everyone had their own opinion, the queue of people waiting to say their peace was never wanting for more bodies, and every time someone opened their mouth the direction of the discussion changed. that was a completely new experience for me and i'm afraid i was not able to adapt quickly enough. every time someone said something i thought i could comment on, my instincts told me i couldn't because by the time my turn in the queue would come the direction of the debate would have changed 3, 4, or even 5 times. in retrospect i realize that i should have ignored that instinct, that i wouldn't be doing anything worse to the continuity of the discussion than everyone else was already doing. unfortunately i realized that too late and i feel bad that i wound up not contributing as much to the discussion as i could have.

if you're at all curious how a discussion with people speaking different languages works from a logistical point of view, panda had apparently hired a team of translators to translate in (near) real-time over some headphones that were provided. there were translators for both languages so everyone got the full content of the discussion (though there were subtle things like "final user" instead of "end user" that make me wonder if, had engaged in a semantic debate over some point, i might be arguing over a minor mistranslation). it worked really well, although when yago jesus (who sat on my left) was speaking i found myself wishing the volume on my headphones went up to 11. following the debate was a Q&A with the audience, but that was pretty straight-forward, as was the networking following that.

the following day (friday) was a day-trip to bilbao to visit panda's lab. luis corrons and pedro bustamante gave brian krebs, joseph menn, and i 2 brief presentations about malware and cybercrime and then showed us around the lab, giving us brief demos of the internal tools and techniques used in the lab. now this was my first time in a virus lab (my first reaction was, wow this looks just like work only bigger) but after seeing what goes on there (there were a lot of familiar concepts in play) and thinking back to some of the things i written on my blog about what av vendors do, i can see how someone might get the impression that i've spent time in such a lab before. i haven't, of course - most of what i know is gathered from years of interacting with various anti-malware luminaries and the rest actually from university (for example, classifying something based on it's similarity to other already classified things - a malware lab does this with malware samples, but in school we did it with natural language text). because we weren't the normal sorts of people they do presentations for in the lab and actually already knew a fair bit about the subject the visit was much shorter than it might otherwise be and we had time to see some sights in bilbao with luis corrons, sean-paul correll, and javier merchan, and finally to have a late lunch on what was without question the best steak i've ever had. one of the others said that steak was ruined for them now but i take it as more of a challenge, i have something to aim for now. at any rate, once we flew back to madrid and i was back in my room i decided to do a bit of brainstorming and apparently lost all track of time because the next thing i knew it was after 11pm and i had been pacing my room for several hours (still trying to solve the security user conversion problem). i think the others had planned on doing something that evening but i missed it - oops.

saturday was a free day, nothing was planned, nobody was coming around to check up on us or anything like that. we were free do as we pleased, and so i wandered around madrid for 5 hours, getting lost then found then lost again in the big city. i would have stayed out longer but after the walking from the previous day, the pacing the previous night, and then 5 more hours of walking my legs were getting sore. i rested up a bit, let my legs start approaching normal again and then headed out to the prado national museum (of fine art, apparently). i had passed by it earlier in the day and someone told me it would be free from 6-8pm so i figured i should take a look inside. well, it turns out what i'd always figured was true - i'm a philistine. nothing really grabbed my attention for more than a few moments so i wound up seeing quite a bit of the inside of the place, zipping around from room to room, until i realized i was bored and headed back to the hotel early. there i called it quits because my legs were well and truly done by that point.

finally, sunday was the day to head back home. i opted for the subway as my transportation to the airport and i'm glad i did - 2 euros to go back as opposed to the 79 to get to the hotel in the first place. the trip home was basically uneventful, but i realized that in the 5-6 days i'd been traveling for the security blogger summit i had doubled the number of planes i'd ever been on in my entire life. i had a great time though, and panda showed us some amazing hospitality and took really good care of us. if i had it all to do over again i would. there's a couple of things i'd do differently, of course, but i'd definitely go.

Wednesday, January 20, 2010

the myth of in-the-wild prevalence

upon reading this article at ghacks.net about scanning linux systems for viruses i became aware that there are some misunderstandings over the meaning of the term 'in the wild'.

the article in question is not the only place i've seen these misunderstandings and i don't want to knock it too hard because it does advise scanning your linux systems, but the statement that
Linux is immune to viruses right? Well…mostly. Even though a proof of concept virus has been discussed, and nothing has actually made it into the wild…you still have email on your system.
fairly clearly indicates both a lack of awareness of the threat linux faces as well as a lack of understanding of what constitutes as 'in the wild'.

so let's get this out of the way early in the discussion. 'In the wild' means literally that the malware in question is active and victimizing someone or some group, somewhere in the real world. that seems like an obvious and natural definition but what isn't obvious is the implication that that has for most people. you see many people equate 'in the wild' with epidemic. they think that if something were really in the wild it would have affected a lot of people and they would have seen it personally or known someone who had seen it. they think that they can use their own experience as a measure of whether something is 'in the wild' or not. the reality is that something being 'in the wild' does not mean that that something is common enough for you to have stumbled across it - there is a wide spectrum of prevalence possibilities for 'in the wild' malware.

to that end, there have of course been linux viruses in the wild. are there still some in the wild? well given that old viruses never really die, i'm going to have to say yes. remember, rare and 'in the wild' are not mutually exclusive concepts - something can be both at the same time. once something goes into the wild it's subsequently very difficult to conclusively show it has left the wild. in fact you could say it's equivalent to proving a negative (which, as we all know, is impossible).

(note: just to be clear, i'm not talking about the wildlist from wildlist.org. things that are on the wildlist are definitely 'in the wild' but not everything 'in the wild' gets to go on the wildlist. the wildlist is a much more narrowly defined set than what's 'in the wild')

Sunday, January 10, 2010

what's in a malware name

...that which we call conficker by any other name would taste as sour.

david harley, tom kelchner, and mary landesman have all posted their responses to an infosecurity article questioning the apparent lack of consistency in malware naming.

they all say more or less the same thing about the deluge of modern malware making harmonization of names impossible and to a certain extent they're right, but to a certain extent they're also wrong - not so much in the technical details of their answer but more in the way they're framing the problem that the infosecurity article was underlining.

now the truth is i had actually planned on writing about malware naming some time ago in response to another of david harley's articles in which he basically says malware names are irrelevant. i can see where he's coming from with that, and probably you can too. a malware detector doesn't care what the name of the malware is, only whether it's there or not - and the consumer of the malware detector generally won't care that much about the name either (certainly not whether it's the same name that all the other vendors use). in the consumer's worst case scenario all they really need is some sort of unique identifier, be it a number, a GUID, or some made up nonsense word (oh, wait, that's what they get now) in the event that they need to call up the vendor for support.

but there's a problem with this line of thinking and i'll demonstrate it with a little thought experiment. let's take all the bones in the human body and replace their current identifiers (such as scapula, ulna, radius, etc) with numbers, or GUIDs, or made up nonsense words. now try having an intelligible discussion about bones you've broken over your lifetime with someone. can you imagine how much more difficult that would be? obviously replacing their current names with the made up nonsense words would just pose difficulty in adjusting to new names but GUIDs would be far too unwieldy for people to use, and numbers would have numerical relationship baggage that would confuse the issues. let's take one more step in this thought experiment, however. let's say there are 50 different people, each with their own different set of replacement identifiers for the bones in the human body, and let's say that they collectively are trying to advise people on bone health. how well is that really going to work? not very well, obviously.

while it is true that malware today is far too numerous to harmonize the naming for each and every instance, we can't let the great become the enemy of the good. if the anti-malware world revolved exclusively around the production and consumption of malware detectors then names really would be unimportant and irrelevant, but the fact is in such a world people like david harley and tom kelchner and mary landesman wouldn't be blogging about such things because those blogs would also be irrelevant.

the thought experiment above demonstrates when names are important and why consistent names are important. names are important when you're dealing with people rather than just technology. they are important when you are trying to communicate information about threats, trends, etc. to people. people need names for things, and frankly they need to be fairly simple names - that's why storm, loveletter, and code red catch on while waledac, virut, and sality wallow in obscurity, and why people keep misspelling conficker. heck, it's why meteorologists name significant weather formations like hurricanes using human given names like harry or katrina. people also need for multiple authorities to agree on the names for things or else they can't integrate data from multiple sources and are left disoriented and confused.

again, we can't let the great (harmonizing the naming of all malware instances) become the enemy of the good (harmonizing the naming of the relative handful of malware instances the industry considers significant enough to write about in things like year-end threat reports). it may be impossible to coordinate names for each malware instance in existence and entirely pointless even if it were possible, but the same does not hold true for the small set of malware that vendors write about by name. just so we're clear, i'm not suggesting that such coordination need take place before releasing detection for the aforementioned malware. what i have in mind is something not unlike the now defunct common malware enumeration with the exception of using names instead of numbers - a post hoc harmonized second name (a common name or layman's name) for those few pieces of malware that the industry feels they need to communicate to the masses about.

of course, after all that is said and done, even if naming were consistent i fully realize that different vendors reports would list different sets of malware and to that end people still need to understand that such reports reflect not the actual threat landscape but what the vendor has seen of the threat landscape. to that end there should still be overlap between the sets of malware used by different vendors in their reports, and if there isn't that suggests sampling bias pronounced enough to render those models of the threat landscape irrelevant.

Friday, December 18, 2009

20 years in av

i knew time was coming, i even thought about marking the occasion here, but my attention was elsewhere at the time so there weren't any posts on the subject.

then eddy willems posted about his 20th anniversary in anti-malware and i thought maybe i should post about this after all - so it entered my to-do list and languished there for a while.

and then today david harley posted about his upcoming 20th anniversary in anti-malware so i figure it's time to pop that task off the to-do stack and actually write something.

you see, i also had my 20th year in the anti-malware field this year - though not in the professional sense that eddy and david did. i don't recall the exact date but i know it was in late november of 1989 that i started down the path i'm on today (i gave a basic run down of how it happened in my about me post 3 years ago).

it's interesting to me to discover that some of the other names i know in this field also got started the same year. it didn't really seem like '89 was all that significant a year or anything, but i guess that's about when awareness of the malware problem (or rather the virus problem at the time since that was the principle form of malware being created) was reaching the critical mass necessary to entrench itself firmly in the general public's consciousness - first as an obscure curiosity, but as an increasingly real and oftentimes personal annoyance for people as they had their own run-ins with the problem. as such i'm sure there's quite a few more who got their start that year.

at any rate, happy anniversary eddy and david. i hope it's been as stimulating for you as it has been for me.

Saturday, December 12, 2009

why mac fanatics still believe they're virus free

(another post form the draft pile)

i stumbled across this article about why macs are still virus free and it occurred to me that there were a number of false premises that deserved highlighting to illustrate why mac users still think their beloved platform is so safe.

  • the first thing i noticed was an ill-conceived notions of what a virus is (eg. "When I say virus I'm referring to a program which self-propagates and self-installs either by exploiting a back door in the operating system or another legitimate application"). by this definition most PC viruses (and i'm not using virus as a catch-all umbrella term here) are not actually viruses.
  • next thing i noticed was the comparison of apples to fruit (eg. "So why don't Macs get viruses while Windows PC's seem to be facing a constant tsunami of malware, spyware, worms, trojans and botnets?"). compare mac viruses to pc viruses please, not mac viruses to pc viruses, worms, spyware, trojans, botnets, etc. either that or compare the gamut of mac malware to the gamut of pc malware.
  • next on the list of wrong-headed thinking i picked up from that post was thinking malware authors are still just attention seekers (eg. " There are a lot of theories regarding install base and attention-seeking virus writers") when it has been demonstrated over and over again for the past several years that they're financially motivated now - the current trend is to follow the money.
  • another bit of nonsense i noticed (which in fairness is bandied around by a lot of otherwise intelligent people) is thinking that going after the biggest group limits them to going after just one group (eg. "wanting to target the biggest market") when it has been demonstrated that professional malware gangs are targeting both platforms at the same time (see zlob gang).
  • yet another wrong thought in the article was thinking that unix makes the difference (eg. "The real answer is UNIX") when in fact the first academic treatment of the virus problem (back when the term 'computer virus' was originally coined) had viruses successfully replicating across a user population in a professionally administered unix environment without cooperation from the admin.
  • the most damning, however, is thinking in yesterdays terms. the very fact that they're still focusing on viruses rather than malware in general shows just how outdated the thinking really is. most of the malware currently attacking pc's these days is NOT viral (either by normal pc definitions, incorrect mac definitions, or formal definitions). furthermore viral malware isn't really the biggest malware problem these days. huge numbers of non-viral malware are the biggest problem facing pc's and the malware gangs have been targeting both pc's and macs for years now.


mac users have largely ignored the malware problem, which is probably why what little they know of the problem is generally either wrong or out of date. the malware problem isn't ignoring them, however. they have an opportunity to get ahead of the problem, but if they keep living in the past that opportunity will be squandered.

Sunday, December 06, 2009

sneakemail is no longer free

well, y'know what they say, all good things must come to an end and the free ride at sneakemail.com appears to be one of those things. as of sometime earlier this month sneakemail.com moved to a paid service and existing accounts were switched over to the one month trial setup.

if you're using sneakemail then this is probably something you want to know about (i found out quite by accident) because when the trial is over your emails won't get forwarded to your real email address anymore.

i've been using sneakemail for years now, and directing others their way. it's a great service and it's helped me keep spam in check so i don't want to say that their service isn't worth the $2 a month fee, but recurring charges are the bane of my existence so i'm not sure what i'm going to do. this is complicated by the fact that i have so many addresses with them (most of which get no traffic, but still). switching to another service would be a pain due to a several years long habit of using sneakemail as well as all the existing addresses i'd have to switch over. plus there's no guarantee that the next one will turn out any better in the long run. paying the fee would also be a pain, and an ongoing one at that.

but enough of my griping - you're now forewarned, go do something about your account if you're a sneakemail user. you have less than 30 days.

malware classification fail

here's one from the drafts pile, hopefully it's not too stale


i'm wondering what the anti-malware world is coming to when the leading vendor classifies something as a trojan even though it clearly discloses what damage it does.

by this logic, every copy of every operating system also ships with a trojan horse program, either in the form of the delete command or the format command.

one of the basic requirements of a trojan is that it tricks the user into executing it - the original trojan horse wouldn't have gotten very far if there was a warning sign on the outside that said it contained enemy soldiers that would sack the city when night fell. so too would suspected malware not get very far if it plainly disclosed what it does.

this game is at worst a potentially unwanted program - in other words, grayware. we can't just go around calling every bad program (or even just every bad non-viral program) a trojan anymore than we can go around calling all malware viruses. not using the proper terminology is a great way to confuse everyone and confusion is something we don't want to sow, right?!?

Friday, November 27, 2009

av vendors are not like drug pushers

one of the erroneous ideas i sometimes come across is that av vendors are a little like drug pushers - that they want to keep you the user addicted or otherwise dependent on signature updates because charging you for regular signature updates is the only way they can make money.

this notion is complete, uninformed bullshit.

the first problem with this idea is the money aspect - if you haven't noticed, the major av vendors come out with a new version of their products (not just new signature updates) every year, not unlike microsoft comes out with a new version of ms office every few years. you have to pay microsoft to upgrade your ms office installation so it shouldn't take a rocket scientist to realize that av vendors make money the same way. they also make money from those who just renew at the end of the year instead of buying the new version because the signature and engine updates cost money to develop.

now you might think that just plays into a more fundamental issue, that they're purposefully adhering to a technology that requires updates/upgrades so that you need to pay each year but that's also nonsense. both the threat landscape and the operating environment itself are constantly changing, there's no protective technology that won't require updating to accommodate that fact. furthermore, there are always improvements that can be made to the way a security product (any security product) does it's job - the only way to get those improvements out to people is in the form of updates/upgrades, and the only way to pay for the research and development behind those improvements is to charge somebody money and it's only fair that the people they charge for the improvements are the people who benefit from those improvements.

still think they're intentionally dragging their feet with regards to non-signature-based technologies for some reason? fine, lets look at our old friend thunderbyte anti-virus. thunderbyte was an anti-virus suite back in the early 90's before av suites were even heard of. it had the signature based scanner, sure, but it also had the most transparent heuristic engine (by which i mean it told you what properties a file had that made it suspicious) i'd ever seen (then or since), it had rudimentary application whitelisting, it had behaviour blocking, it had integrity-based generic detection and cleaning. thunderbyte even marketed av hardware. the folks at thunderbyte were pioneers who in a very real sense built a better mouse trap and believe it or not the world did not beat a path to their door. the product was ultimately a failure in the market (their technology was bought by norman data defense which, with all due respect to the folks at norman, is a much more obscure company), not because it wasn't a superior product (it was), nor because it was too much of a niche product (it was readily available in computer stores where i live despite coming from a different continent and i imagine it was available in stores elsewhere as well), but because the market wasn't ready for it. just because you build it doesn't mean they will come - it might work like that in the movies but not in real life. it would be unreasonable to expect other vendors to waste their money developing technology that the market wasn't already clamouring for - the reason vendors have been slow to develop these alternative technologies is because the market for those technologies has been slow to develop. there weren't enough customers demanding the technology for it's development to make good business sense.

Tuesday, November 24, 2009

why are ethics so undervalued?

why are ethics so undervalued? i honestly don't know the answer to that question but i'd like to explore the topic and explain what i mean.

first i'd like to dispel any fears that i'm about to go on at length about people not understanding the difference between right and wrong - i think most people do understand the difference. that said, i don't think most people appreciate the difference - which is to say i don't think it holds much meaning for people, i don't think it's important to them.

i'll give you an example. not too long ago anton chuvakin posted an article on FUD - specifically one that is, if not an outright endorsement of FUD, at the very least an argument that sometimes it's a good thing. i'm not going to pick too much on the notion of endorsing the use of manipulation in the workplace, what interests me in this discussion was something he wrote in response to a blog post criticizing his stance:
personally, I think that “trumping with ethics” is a low card in intellectual arguments! IMHO it is one step above name calling
i don't think there can be any question that this statement represents a remarkably low valuation of the topic of right and wrong.

by way of contrast, i would place ethical right/wrong one step below technical right/wrong - and those of you who know me know how highly i value technical accuracy (hint: i make enemies simply by correcting people).

so where does such a huge difference in values come from? and what does it mean for the security community that anton is not only not an outlier but in all likelihood far closer to the norm than i am. have we become an "ends justify the means" sort of society? is security as a goal something we need to promote at all costs?

i suppose i need to better understand why it means as much as it does to me, so i guess i've got some soul searching ahead of me, but nowhere in that search do i expect to find why it's so much easier for others to put aside. i don't get many comments on my posts (since normally i know the answer to the question i'm asking) but in this case i'm hoping to hear what others think so please feel free to comment.

some new snake oil from kaspersky

i found this out thanks to a thread at wilders - apparently kaspersky is taking a page out of the mcafee snake oil playbook. mcafee has total protection and now kaspersky has total security.

i've been over this time and time again - this kind of branding is snake oil. the obvious implication that the average person would draw is that they simply have to use kaspersky total security and then they can be totally secure. that's a false sense of security and the folks at kaspersky know it.

obviously someone cares more about market share and getting to make commercials with jackie chan than about intellectual honesty.

oh crap - looks like bitdefender did same thing.

being a whitehat means taking sides

you wouldn't think this needs to be said, but apparently it does - being a whitehat means taking sides. more than that, it means taking the side aligned (more or less) with the general public's interests - doing things for their direct or indirect benefit.

and so it is that i always seem to find myself surprised by people who call themselves whitehats but who sacrifice the public's interests for their own agendas. those people are just lying - to others and perhaps even to themselves - about how good of a 'good guy' they really are. these are greyhats at best or, perhaps more likely, blackhats.

one such case that came up recently was that of peter kleissner (another post on the subject here), an ex-employee of the av vendor ikarus software who released proof of concept attack code and then, after being ousted from his position within the av industry, came up with a service to help malware authors evade the av industry.

i suspect mr. kleissner doesn't actually think of himself as a whitehat anymore, even though he would have generally been considered one at the time his descent started. the thing that stands out most to me, however, and the thing i think needs underlining is the following quote:
I won't make a difference between black hats and AV companies. To me it's not good or bad, it's just technology.
which seems to suggest he doesn't care to draw a distinction between good and bad. there's a word for that boys and girs, and that word is amoral. while it is true that he is still quite young, he is 18 and he was part of the av industry for over a year. i'm curious how one at such an impressionable age could manage to be part of the av industry and still manage to avoid having his moral compass align with that industry and community.

i'm still here

i know it's been a while - i'm still alive, just preoccupied with other things. i'm going to try to clear out some of the backlog of things i intended to write about. expect some old subjects for the next little while.

Wednesday, October 14, 2009

sector.ca's wall of shame was dead-on...

... and you should all be ashamed of yourselves for being caught on it.

for those missing the background, last week's sector security conference had this thing called the wall of shame. it was information gathered by sniffing the network. a lot of people thought it was gathered by sniffing the wireless network but it was actually gathered by sniffing the wired network. they got all in a huff because they thought by using the secure wireless option they'd actually be secure.

are you face palming yet? yeah, securing your wireless connection to a network doesn't secure your use of that network. this is a network none of those people controlled - it's about as secure as a public access terminal in a cybercafe and still they thought it was safe? these are security pros no less, at a security conference.

this is pretty unbelievable to me, that security pros can't keep their own shit secure at a security conference. no wonder security appears to be so hard and we have so many breaches - you folks aren't paranoid enough! you absolutely belong on a wall of shame if you thought you could use some strange networking service and just naturally be secure. use an encrypted tunnel to a proxy on a network you control for crying out loud, or better still just don't use the network at all.

i didn't even bring a laptop (or any electronics device except for a cheap mp3 player) and i managed to enjoy the conference without incident. i could say the reason i didn't bring any connected devices was because i've heard of shenanigans like this at security conferences in the past (as should you all have), but the truth is i just like to travel light.

it both scares and saddens me, though, to think that some of my data might actually rest in the hands of some of these people. frankly i think we need a version of the darwin awards for security and you folks on the wall of shame are all contenders. i can't decide, however, whether it should be called the shannon awards or the kerchoff awards.

finally, while i realize there are legitimate concerns about the legality of how the wall of shame was implemented, i would also argue that if you think the law is going to solve your network security problems then you might be a security idiot. the law is a deterrent, but as preventative controls go it's not particularly reliable.

Thursday, October 08, 2009

what is credentialed malware?

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

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

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

back to index

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

Wednesday, October 07, 2009

my sector '09 experience

last year i was lucky enough to get my employers to send me to the sector conference (the second one ever) and this year that luck continued. just as i did last year, here is a description of my experiences at sector '09.

first a note, perhaps a reminder to myself, who knows - but if you're going to attend a conference that, logically requires you to get out of bed at 6:30am in order to do what you need to do in the morning and make it there, you might want to go to bed earlier than 1:30am. people don't want to see you yawning during their talks, or when they're talking to you directly in the halls (or whatever). it makes them think they're boring you, even if they aren't.

the conference started off with a great keynote by chris hoff about the cloud - check that, about cloud computing because there is no "the cloud" according to chris; though the fact that it is clearly illustrated on many network architecture diagrams (representing everything else) seems to contradict him. however, and the fact that this became clear to me as a result of his keynote is one of the things that made it great, that rudimentary abstraction on old-school network architecture diagrams has little to do with the discussion of cloud computing. now i wish i'd seen his "4 horsemen of the virtualization apocalypse" talk last year.

next up was the first session of the day and this year, like last year, i spent it in kevvie fowler's talk - this year it was about catching sql injection by examining the sql cache. again, like last year, my decision to attend this talk was based on the perception that doing so would allow me to bring value back to my employers (who paid for my admission) and kevvie didn't disappoint.

following that was the lunch keynote given by andrew nash of paypal, talking about consumer identity. there didn't seem to be a lot of information there that i could use directly, either at work or at home, but some of his ideas/opinions seemed spot on. one of the concepts i don't like, however, (and i believe i've posted my complaints before) is something that i now know is called federated identity.

after that i attended roy firestein's talk about crimeware and web exploitation kits. aside from the fact that roy is one of those people who says anti-virus is useless (there seems to be one in every crowd, but if the sentiment were true then one has to wonder why malware writers continue to waste their time, energy, and money on developing innovative defenses from anti-virus) the talk was fairly interesting. one thing that struck me though (before the av is useless comment) was that roy (and others when i sit down and think about it) seem to focus more on and distinguish between what seem to me to be subtle distinctions between similar pieces of malware. i'm not sure why but those distinctions have started being less interesting to me these days. not that that stopped the talk from being interesting, mind you, that was just a thought that popped into my head while listening. i think i'd have more difficulty fleshing out a talk due to this mindset, were i to ever be in the position of trying to give one.

for the third session of the day i had decided to attend chris boyd's talk about security and gaming consoles. despite the fact that i don't own a gaming console myself (my gaming console experience is limited to a pong system, the colecovision, and the intellivision systems) and there isn't one at work, there were 2 reasons i wanted to attend this talk. the first was that chris is someone i've known online for a while now, and the second is that while this specific attack vector is outside my area of familiarity my suspicion is that the significance of this vector will increase in the future. the talk was quite interesting - some things were familiar, some i've seen analogs for in social gaming, others were new. the apparent cross-pollination of attack strategies is probably the most interesting thing to me because cross-pollination is not a unidirectional process and so i expect that some of the attack strategies that have been more or less peculiar to consoles so far will find their way out of the (thinly) walled garden of the console world.

as an aside, i also planned on introducing myself to chris after his talk but he had to go and recognize me beforehand. how, i don't know, since there are few photos of me online, fewer still that are current, and then of course there was my clark kent disguise (glasses, when i normally wear contact lenses). clearly, superman i ain't - but there's certainly nothing wrong with putting a face to a familiar name so i'm not complaining.

the last session i attended the first day was robert hansen's talk on information warfare and the future. as the talk was very much about the future, and as i don't actually put much stock in predictions i'll take the stance i always take in this context and wait and see. some of the descriptions of upcoming capabilities were quite provocative, however. the talk let out about 35 minutes early, so it was probably the shortest i saw while there.

letting out early at the end of the day can be a mixed blessing - for those who just wanted to go home they could get an early start, but i wanted to go to the reception at joe badalis which wasn't supposed to start until the last session was scheduled to finish so i tried to find something to do with the spare 35 minutes. that would have been easier if the vendors hadn't mostly already packed up for the day - it would have been the perfect opportunity for me to visit the booths since there was actual time (something that's harder to find during the day). eventually i just decided to go to the reception early (as apparently a number of others in the same boat already had). i had a good time there, talked to a few people, got a few business cards but unfortunately when i left the office on monday i had forgotten about sector so i didn't grab a handful of cards and thus had nothing to give in return. i also found out that apparently my day job is more unusual and interesting to other people than i ever realized - who knew?

after the reception was the speaker's dinner which i'm afraid i had to miss due to never quite figuring out where i was supposed to buy the $65 ticket, and a tweetup following that which i also missed since i doubted i could find something to do for the 2 1/2 hours between the end of the reception and start of the tweetup. apparently this worked out for the best as i was able to avoid seeing chris hoff give brian bourne (one of the organizers) a lap dance (or man-dance as i think i saw it called). yes, you read that right. the stills posted to twitter were bad enough, i can only imagine how scarred the people who saw it live must be.

the second day i attended (technically the 3rd day of sector, but i don't attend the first day because it's just training and their courses never seem to have enough relevance to me to justify the cost) started with a surprise. nicholas percoco and jibran ilyas' talk entitled "Malware Freakshow" was excellent. it did something that is actually exceptionally rare these days - it introduced me to a new malware classification which by itself is actually pretty rare, but unlike a lot of the more recent 'new' malware classifications i've heard recently this one actually sounded like a justifiable classification rather than a mashup of existing capabilities in a new package. credentialed malware, or malware designed to be used my multiple people with differing roles and privileges within a criminal organization is very much a sign of the times - computer related criminal enterprises have progressed to such a degree that malware actually comes in a multi-user flavour now and different users get different capabilities. that was quite neat and that alone would have made this talk my favourite, but there was more: all the real-life examples being used were the sorts of organizations that i could envision being customers of the company i work for (in fact it wouldn't surprise me if some of them were customers) - it was like worlds colliding (there's usually not much overlap between my day job and what i blog about) and i can't wait to share some of the stories with the guys at work tomorrow - especially since a procedural control that our product facilitates potentially could have thwarted the credentialed malware example.

following that talk i attended jerry mangiarelli's talk on sql injection - yes, a second talk on sql injection. again this is a relevance to the day-job sort of deal but it was good to hear some more about it, about the scale of the problem and that sort of thing. of course, considering how prevalent sql injection is now it's actually shouldn't be a surprise that there would be multiple talks on it or that someone would attend both.

then we had the lunch keynote for that day which was with adam laurie (aka major malfunction). it was quite a fun presentation as, just like adam, i like to break things too (especially at work, though i don't get to do it as much as i used to). he talked about breaking a number of things (like breaking into a state of the art hotel room safe with a pair of pliers and a screw driver), and he also talked a great deal about biometric passports. i didn't care that much for his treatment of biometrics, but having worked in the field (in an integration capacity) my views and populist views aren't likely going to match up.

after lunch i attended the sslfail.com panel discussion with tyler reguly, mike zusman, jay graver, and robert hansen (yes, robert hansen again - that wasn't in the programme). sslfail.com is something i've been hearing about for a while and wanted to know what all the hubbub was about and the panel did a pretty good job of raising my awareness of a number of issues (which was the goal they stated at multiple points throughout the discussion). one of the points i think was a red herring, however. the complaint about changes to the user experience over different versions of the browser is predicated on the idea that the ssl indicators are useful to ordinary people (since us technical folks are better able to adapt to such things). as has been covered in the past, however, at a fundamental level we just aren't wired to notice when something like a little lock icon is missing. that isn't a failure of ssl, it's a failure of the very concept of a safe-site indicator.

for the last talk of the day i chose to sit in on nick owen's discussion on approaching secure online banking. he's someone whom i recalled having a brief discussion with about authentication in the comments here at one point and i was interested to hear what he had to say. i was impressed to see that wasn't just saying X solves our problems, that he'd actually identified the different countermeasures appropriate to the different compromise techniques, etc. the banking industry specific stuff, i must admit, was way way over my head, however.

then things wound down and folks made their way to the keynote area for the final wrap-up. i said a brief hello to chris hoff, which seems to be a pattern now (note to self for next year: when it comes to con-tag, i'm it again), as well as introduce myself to tyler reguly briefly just as we were all getting ready to leave.

but anyways, it was great, i learned lots, met some great people, and had fun. hopefully i have the opportunity to do it again next year.

Sunday, October 04, 2009

mcafee and malware creation

if you hadn't already heard, mcafee plans to teach a class on "malware experience" at a 4 day security conference they're holding this coming week. there were only a couple of reactions to it that i saw, notably david harley's post at threatblog and michael st. neitzel's post on the sunbelt blog. the sunbelt post in particular drew the attention of mcafee's dave marcus who clarified exactly what was going to be going on - to the extent that the controversy around the promise of showing attendees how to create new malware seems to have died a quiet death.

i could have weighed in when i first read about this but the wheels of change had already started to turn and i wanted to see where things went before i said anything. the end result, however, seems to be mcafee has placated people's concerns with hollow promises that instead of teaching people how to make malware from scratch, they'll instead be using an existing toolkit to create the malware. the implication is that since this toolkit produces malware that is already detectable (at least as far as mcafee's product goes) then they aren't really contributing to the malware problem. if you're detecting the distinct aroma of a barnyard right now, you're not alone.

there are a couple of problems here so lets go through them one at a time. the first is the simple fact that mcafee is in the anti-malware business. i've said this before and i'll say this again - if you're anti-X you shouldn't go around making X's and you sure as hell shouldn't encourage others to do so. the company's namesake reputedly got into trouble with the rest of the industry by offering such encouragement in the form of financial incentives (paying for new viruses). now in this new case it's all going to be done inside a closed environment to prevent undesirable consequences so there should be no problems, right?

wrong. the work in the classroom will take place in a closed environment, but i have no doubt that some of the attendees will subsequently play the home version of the game, running malware toolkits on their own environments and creating malware in less secured environments (you can't really believe that they'll learn everything they need to to handle malware safely in those 4 hours the class will run). a class like this encourages precisely this behaviour. it makes it seem ok for less experienced people to handle malware, and to that end even people who never attended the class will also play the home game if such behaviour is endorsed.

think that sounds far-fetched? it isn't, there are already well intentioned but ultimately unqualified people playing with malware and inadvertently contributing to the malware problem. it's been going on for years. sarah gordon covered this in her paper "The Generic Virus Writer II". that's a pill that the technologically inclined don't want to swallow, they think they understand malware well enough to prevent unintended consequences, but the reality is that most people lack the wisdom to appreciate the extent of their own ignorance.

finally, given the probable result of people playing the home game with the same malware toolkit used in the class, should they contribute to the malware problem they will do so in a way that benefit's mcafee because their product already detects all the output of the toolkit. they will be breeding demand for their product in an absolutely unethical way - by teaching people just enough to cause problems that their product can fix (others may as well, but it's impossible to know at this point).

mcafee is behaving irresponsibly and unethically, and i'm struck by how things seem to have gone full circle with them. while others seem to have let them off the hook because they're using a toolkit instead of teaching how to create malware from scratch, as far as i'm concerned the only difference is the sophistication of the malware creators they are going to produce. mcafee will be teaching a new breed of script kiddie and tarnishing the industry's reputation once again. congratulations on being part of the problem, mcafee folks.