Archive for the ‘Research’ Category

If you’ve been following my meanderings over the past few months, you know about the Rootkit report where they say that rootkit incidents have risen 2300 percent over the past two years, and you’ve seen their assertion that we’re on the “cusp” of a phone-borne malware attack. Of course, I don’t subscribe to any of that. However, I came across this article today citing the McAfee OS X Malware paper where McAfee warns Apple users about the possibility of “chip-based” malware. Sigh.

Needless to say, I don’t think this is a real possibility. We haven’t seen malware propagation via a hardware vector ever and I don’t think we’re likely to see it start happening now. As any programmer will tell you, as more time goes by, operating systems offer fewer mechanisms for a developer to interact directly with system hardware. Since the introduction of the HAL in Windows NT, there are fewer and fewer ways for a developer to directly address hardware components from the application layer. Not to mention the fact that the number of different permutations of components makes it almost impossible to ensure compatability even on the same model system. One has to ask the question why some virus or worm would interact directly with hardware components, when it is a million times easier to propogate without doing that. So they can infect OS X? Not likely.

Remember when we went through the McAfee “Rootkit Report” and pointed out that their “statistics” were merely reflective of their product rather than actually reflective of what’s going on in the real world? Well, today I stumbled across the headline Virus emails drop to record low informing us that virus-laden emails are at the “record low” figure of 1.5%:

…total number of virus-laden emails fell by 56 per cent compared to March’s figures, with infected mail now making up just 0.79 per cent of inbound emails…

Bull. Why is it bull? Because this number (and others like them) don’t reflect the reality, they only reflect a particular vendor’s product – essentially the same point that I raised with McAfee’s the rootkit numbers. These numbers reflect the unique nuances of the instrument used to take the measurements – they do not necessarily tell us much about what’s going on outside of that. How do we know? Because the .79 percent figure is from the Blackspider statistics; but they’re not the only people publishing this stuff.

According to some of their “peers”, the April virus numbers were: Messagelabs – 1.5%, MX Logic – 3.8% (7 day window, not all of April), Sophos – 0.7%, EmailSystems – 0.42%, and so on. Look, these may sound like small percentages at first, but when we’re talking about 60 billion emails a day, the difference between .8 percent and 3.8% is 180 million emails per day. Over the month, that’s a range of error for these numbers +/- 5.5 billion. See what I mean? In my opinion, we would need to see all these different vendor numbers plotted out against each other over time in order to really make guesses about what’s really going on under the hood.

I noticed this morning a brief article over at Xatrix about rootkits on the rise, which sounded interesting. As it turns out, McAfee has put together some research indicating that “In the first quarter of 2006, the number of rootkits increased by 700 percent” and “Windows-based stealth components dominate the landscape, with an increase of 2,300 percent from 2001 to 2005″. Wow! 2300 percent? Double-wow! Needless to say, these numbers seemed so astronomically high that I just had to dig into the methodology to see why that is.

After deliving pretty deep, I’m convinced that this whitepaper, like much of the research coming out of the AV industry, suffers from a common flaw: namely, results that are reflective of a given vendor’s product are being used as a benchmark for interpreting broad events. What do I mean by that? Let me take you through an example of what I mean; take a look for a moment at the following startling graph from the McAfee whitepaper:

Seems pretty straightforward, right? Maybe, maybe not. Look closely at where the majority of the rootkit “growth” is coming from and you’ll see that the lion’s share is due to a relative small handfull of programs including “Backdoor-CKB”, “Backdoor-BAC”, and “W32/Feebs”. To illustrate, let’s do some digging on that huge spike of rootkit activity – the biggest one of the bunch – “Backdoor-CKB”. Looking at the details, we find out that McAfee added detection capability for this rootkit somewhere between 10/2004 and 2/2005*. Looking again at the graph, we see that in 2005 we see an astronomical spike in the number of infections during that time period. It goes from nothing to the most popular rootkit (by far) within that same time window. Coincidence?

So which is it? Did this rootkit came out in 2004 and spread across the Internet faster than any other rootkit before or since *OR* was this rootkit there all along and the spike on the chart is reflective of when McAfee added the ability to detect it? To find out, we need to do a bit of backtracking to try and estimate when the rootkit came out. “Backdoor-CKB” is, of course, not called that by the folks writing and using it; they call it “PCShare” of which the current version seems to be PCShare 3.11. The earliest reference I can find on the Internet to a version of PCShare that we can be sure was classified as “Backdoor-CKB” (using the presence of pcclient.dll in the rootkit to make sure) is from late 2003 (“PCShare 2.0 Beta1″.) We don’t have a file listing for earlier versions to ensure that they would still fall under the same McAfee classification, but even so – since rootkits are not generally available on major hacker sites for a few months after being written, we can conservatively estimate that this rootkit was around at least since late 2002.

Late 2002 – two full years before it appears on the McAfee chart. For two years, it’s gaining in popularity, getting more and more users, more and more infections. Then McAfee adds detection capability, bringing with it a tremendous spike in detection volume. Now, two years after that, McAfee is using this spike as part of the evidence to make the claim that rootkit infections are up 2300 percent. Hmmm… If I deleted half the signatures from the AV product on my laptop and I used that AV product’s output to collect data for a report entitled “50% less malware this year”, would that be accurate? Look, I’ve no beef with McAfee, and really it’s good that vendors are making this type of research available for free – but I really think we need to approach vendor-sponsored research with clear eyes. Especially if the instrument that they are using to collect the data is their own commercial product.

* The “discovered date” is Feb 2005 while the “minimum dat” was published in Oct 2004. Since it’s unlikely that protection was offered before it was discovered, we can assume that one of these dates is probably inaccurate.

The Register had an article today, “As Emperor of Security, I hereby decree…” It caught my attention since it was so atypical in style. The author spends some time discussing the things that he would decree if made emperor of security. Neat concept, right? I thought so too.

The mandates were totalitarian and restrictive; purposefully so (that’s sort of the point, right?) Some of them were good ideas (mandatory education for all new computer users), some were bad ideas (fines for insecure software), and some had both good points and bad points (mandatory anti-virus, anti-spyware, and firewall software). However, what really got me thinking was the discussion about “mandatory monocultures” :

It’s pretty well been proven that operating system monocultures are a bad thing. In a biological population, the introduction of a disease into a monoculture can spell doom for the entire group: since everyone is the same, everyone is vulnerable in similar ways. This is analogous to computing monocultures: if everyone is running Windows (or Mac OS X, or Linux, or whatever) and a serious compromise enters that population, then there is the danger that everyone in that group will suffer devastating losses.

This reference, of course, points back to the one and only Dan Geer “CyberInsecurity” paper that caught so much attention when it was published because of the ramifications of it’s release.

Now, I know better than to contradict Dan Geer. And I won’t, because I believe his paper to be absolutely true. But there’s a limit to how far the analogy holds; my laptop is not a Rhesus Monkey, a Lemur, or even a bacteria. While populations of machines can (and do) share a number of similarities with a population of organisms, that doesn’t mean that everything that’s true about organisms is true of laptops. For example, don’t put a bunch of laptops in a box and expect them to start making little laptops. In other words, just because certain threats are more virulent in a monoculture world, don’t assume that all of them are. And why not? First: because nobody has to manage a population of organisms, and Second: because there are more bad things than plague…

Consider two environments: one has a thousand machines each with identical OS, architecture, patch level, etc. The other also has one thousand machines but each one has different operating systems, architectures, and patch levels. Say (for the sake of argument) that two full time administrators manage that environment – a reasonable number, right? Dan’s paper points out that the first environment is much more likely to be impacted by worms; and that’s true. But which envrionment is more manageable? Which one is more likely to have automated security tasks like patch management, central monitoring, coordinated audity, etc? See what I mean?

Take the OS and application patches alone. Say that the operating systems in the second environment (the non-uniform one) each require an average of two vendor patches per week for all installed services and apps (a ridiculously low number.) Say each of those patches require 5 minutes to download, prepare, and install (another ridiculously low number.) Guess what: that patching process would take 166 full-time hours. If you had a more MANAGEABLE environment, you could have deployed something to automate that. You could start focusing on something more strategic than patches application with all the time you’d save.

Look – monoculture does increase the risk of population-level catastrophic events. However, diversity decreases the ability to manage the environment. Reduced manageability directly increases the risk of individual-level events like targeted attack. It’s not a traditional curve where the optimal position is maximum diversity; instead, it’s a bell curve: the optimal position is diversity – but manageable diversity.

This morning, I came across the excellently written post by Pete Lindstrom “Why Bugfinding is Irresponsible and Increases Risk”. As always, Pete is succinct, considered, and lays out his argument in exceptional clarity. That’s not to say that I agree with the entirety of what he says – just that I think he’s studying the problem in a comprehensive way, and I think his (non-mainstream) approach is thought provoking.

Pete’s position is that vulnerability research – more specifically for-disclosure research (“bugfiding”) – increases overall IT risk, and is therefore undesirable. I won’t dispute whether it does or does not increase risk; I think we can only speculate as to what kind of relationship risk and research might or might not have. Sure, there’s anecdotal evidence on both sides of the issue, but we don’t have any empirical evidence – we don’t have any way to test how research impacts risk – and we have a fairly equal number of smart people arguing for both sides. So, maybe it increases risk and maybe it doesn’t.

However, I think debaters on both sides of this issue are somewhat guilty of security-centrism. In other words, although risk is very important as part of doing business, there are other factors to consider; security is a means, not an end. When considering the value of vulnerability research, shoudn’t we also consider the broader ramifications that don’t directly relate to risk? In fact, some of these broader issues are things that we can actually get some data about; for example, the economic impact on vendors and others, like the impact on overall software quality, etc.

I guess my point is, why ignore all the other potential benefits of vulnerability research because of a potential (but not necessarily definite) increase in overall IT risk? Shouldn’t the discussion be broader than that?

Have you seen the Onion’s “Dolphins Not So Intelligent On Land” report? Is it just me or does this (obviously fictional) study remind anyone else of the hacking challenges going on in the OS X world the past few days:

After capturing the dolphins from the ocean, Lindell and his colleagues tagged them and placed them under the intense, high-wattage lights of a moisture-proof lab. The researchers then administered an extensive battery of tests designed to measure everything from the dolphins’ self-awareness to their aptitude for writing and reading comprehension…

Funny, right? Well, I thought so… For some reason, though, the “hacking contests” (equally absurd) don’t make me laugh quite as hard. Maybe I don’t find it as funny because in the back of my mind, I know that there are people who think the OS X contests have merit. I mean, to say that the challenges were “skewed” is beyond understantement – the the rm-my-mac competition competition allowed anybody from the Internet to connect to it and create a local account and the challenge was to find a local exploit. OF COURSE somebody could. Then we had the University of Wisconsin challenge, which locked the machine down and had only HTTP and SSH open. So, somebody needed to find a 0day remote exploit. OF COURSE somebody couldn’t.

Blah, what a waste of time.

Let’s try that again without the typos…

So, there’s been a bunch of hullabo today about how ethical (or unethical) it is to sell vulnerability research information before it’s disclosed. Everybody’s leaping into the fray – overall, though, I think I side with the capitalists: those who would give researchers the right to hawk their wares. I’m for “controlled capitalism” – in other words, we give researchers the right to sell vulnerabilities, but we control how it gets done.

In the past few days, we’ve had commentary from The Register, that seems to come down on both sides of the issue. As it relates to remunerating the researcher, they have this to say:

But should we then expect security researchers to audit commercial software, which is sold for profit, and to do so for free? If there are ethical issues in the sale of vulnerabilities, what’s ethical about selling very insecure software in the first place? While it’s impossible to write software without vulnerabilities, it’s pretty obvious that some companies don’t even try to create secure products – and thus, ethics don’t seem to come into play…

Pete Lindstrom picks this up and gives it his unique spin in a response on his Spire Security Viewpoint. Dancho Danchev gives us empirical observations on the current vulnerability underground markets, while Rainer B

This week, Symantec launched their new “Internet Threat Meter” site; the “Internet Threat Meter” is basically a portal where Joe Average can go to see aggregated information about the “state of the Internet” – there are “traffic lights” (green/yellow/red lights) on the site that correspond to the overall “safety level” associated with PC usage at the current time. In case you haven’t seen it, here’s the link.

Just for the record, although they look similar, do not confuse the “Symantec Threat Meter” with the “Symantec Threat-Con” which is entirely different. Whereas the ThreatCon has four levels, the Threat-Meter has only three (probably to make it more accessible to the average user.) And while the colors for the Threat-Meter are green, yellow, and red, the Threat-Con colors are green, yellow, ORANGE, red (they’ve weeded out the overly-technical “orange” level.) Obviously, I’m being sarcastic.

What strikes me about this is not just the similarity (and competition) with the existing tool, but the similarity with Windows OneCare. From a user interface perspective, this new “Threat Meter” is very close to Microsoft Windows OneCare Live – both in terms of what’s available on the interface but also the way that the controls/tools are categorized, made available, installed, etc. Of course, this begs the question: is Symantec feeling the pain from OneCare already? Is the beta cutting into their sales enough that they are responding ad-hoc in a way that competes with rather than compliments investments they’ve already made?

Here’s my thinking… Symantec will never say this flat out, but they make their money from consumer AV. Judging by what we can infer (the way they break down the numbers is less than transparent), their reliance on consumer AV is anywhere from 50% to 80% of overall yearly revenue. How can we tell? Read between the lines – in Symantec’s 2005 Annual Report for example, they tell us that the consumer segment is their strongest sector (the “star performer” they call it.) They also tell us that their top selling software category is “security solutions.” Now, take the union of where “security software” intersects “consumer segment” – and compare that with what’s in their product line. See what I mean? They’re talking about consumer AV. You can actually line up the numbers in the report to make guesses about percentage of revenue (why I say between 50 and 80 percent – 80 is more of a historic number while the current report points to more like 50.)

Which means that Symantec is in for a world of hurt when those sales start to dry up – and dry up they will. Here’s the deal – when Microsoft starts selling something, competitors tend to go away. If we look at it logically, Microsoft can own the consumer AV market whenever it wants: they can ship their AV or anti-spyware with Windows. They can make OneCare free. In fact, I’ll bet you dollars to donuts that Microsoft giving away the free AV beta is already impacting Symantec’s sales. I’m not sure how much we can read into what SYMC’s up to, but I for one will be interested to see where this goes.

Dancho Danchev (you may or may not know him from his blog) has put together a new whitepaper about the evolution of malware.

There is, by no means, a shortage of opinion on how malware will evolve – it is a topic of considerable interest in the security community and there are tons of predictions about how malware authors will (or will not) continue to incorporate new distribution vectors and new types of payloads into the software that they write. Most of the time, these predictions (particularly the ones from the AV community) are either biased or patently inaccurate. Given that, I found this paper to be a interesting viewpoint and free of the bias that typically peppers this type of report. Although some of the early supporting research is interesting too, I recommend skipping to the end for the time-challenged reader: particularly the last 3-4 pages where he lays out the trends that he feels are significant going forward.

Although I don’t agree with everything in the paper (e.g. malware on mobile devices), he lays out some really interesting data on localization/regionality, interoperability, and the economics of malware authorship. All in all, the last 3 pages are well worth the security researcher’s time.

In case you haven’t been keeping up with developments, last week some FUD came around about how ET was gonna haxor your bank account and use it to make REALLY long distance phone calls. Well, quite unexpectedly the situation has become much, much worse. SC has unfortunately elected to lend this cruft an air of respectability by including this asinine story in their “top infosec news” category. The premise of the argument seems to be that aliens, somehow aware of the intimate details of how SETI@home works, are going to write a computer virus that will infect machines by means of the signal data sent around from SETI@home and thereby somehow cause serious damage. Just for the record, this was no less dumb when it was the plot of “Independence Day” (remember when Jeff Goldbloom wrote that computer virus that killed the alien mothership.) This kind of paranoid rambling is why physicists shouldn’t do security (note that this works in reverse for all you aspiring Newtons stuck in InfoSec).

There are quite a few reasons why the premise is dumb, but let’s start with the most obvious one: the nearest star is 4.3 lightyears away – this means that in the optimal case these aliens would have to come up with a way to hack not the machines of today, but the machines that we’ll be running 4.3 years in the future. Humans couldn’t do that, and we build the stupid things – some alien with tentacles for a face isn’t going to figure out how to interact with *OUR* devices that we ourselves haven’t even built yet. Look, four years ago we were all running Windows 2000 (maybe) or something older (probably) – the platform du jour is XP SP2 – a platform that hadn’t been developed yet in 2001. Maybe somebody could pull off hacking a machine 4.3 years in the future if we lived on the set of the ‘Hackers’ movie, but not in any real life scenario.

Plus how’s Xenu gonna get the source code? Telepathy? Even in the extremely unlikely scenario that these aliens were to get ahold of the most current source of the platform, understand the hardware architecture of the futre, and get a copy of the most current source of SETI@home – they would still need to understand it enough to find a vulnerability. Not to mention that they would then need to manipulate their radio emissions or whatever in order to exploit the vulnerability of the future that they somehow managed to find. Blah. That’s about as likely to happen as my growing a set of wings and flying to Ming’s palace myself for a preemptive strike.