Man Google is pissing me off lately. No it's not stock envy (although that doesn't help) - I'm talking about shady things like this (which b.t.w I also got an email like this from them once, hilarity ensued), or bundling their damned search bar with every application known to man (installed any Adobe software lately?) . . . a practice we've been sued for many times but when Google does it - oh that's no big deal.
No - I'm talking about reports like this one about one of my favorite topics - web based 'drive-by's' - or more accurately 'miscreants hacking web sites using web application vulnerabilities in commonly misconfigured or under-patched software, and then planting exploit web pages at those URL's which exploit vulnerabilities in a browser to download and run malware'. Drive-by's is sooooo much easier to say isn't it?
It seems that Google has surveyed "billions" of URL's and from that set they culled about 450,000 malicious URL's that were hosting 'drive-by's'. Cool! That's good data! Glad to see Google doing something useful with all that power! Yea Google!
So given that information you would THINK we'd be seeing some interesting statistics on the most targetted vulnerabilities broken out by browser . . . or maybe the top hosting providers serving up drive-bys . . . or maybe the top regions of the world hosting up drive-bys or maybe even the most popular server software hosting up these drive-bys.
Man I can't wait - this is going to be juicy . . .
Well the first thing you'll notice as you read the paper is that they really only focus on IE . . . they instrumented some VM's so that they could know when IE was installing malware. Okay - that's fine - given that IE commands 75% of the market - it seems like the logical choice to use as a browser when surfing the web looking for malware URL's. And let's be honest - it's definitely the most targetted browser due to its popularity. So whatever - I'll let the fact that they didn't instrument a Firefox VM slide (although a side by side comparison would have been interesting and Google would be in more of a position to do this and record results than say Microsoft) . . . on with the reading!
So now go ahead and search the paper for 'IIS'.Not a single hit! WOOHOO! We freaking rule! IIS6 / ASP.NET rocks!Now search for 'Apache'. Not a single hit! WOO - wait . . . WHAT?!?!
How the @$%#$ can you have a discussion about 450,000 URL's hosting malware and not mention even once what software stack is serving up those URL's . . . not ONCE!?! Surely these malware URL's have to be served up by either Apache or IIS . . . I would think you'd want to like . . . mention that.
Now do another search for me . . . last one - I promise.
Go ahead and search for 'PHP'. It's really easy to search through the document for all the hits using the right arrow button in the latest Acrobat reader so make sure you clck the right arrow a few times to scroll all through the document and highlight all the 'PHP' referrences. If you don't have the time right now I'll save you the trouble . . . PHP is mentioned . . . a lot. And in fact PHP pages seem to be the ones used in most (all?) of the examples in the paper . . . PHP's or popular applications written in PHP that is (with some indeterminate CGI's thrown in for good measure). In fact I didn't see mention of any popular ASPX or ASP applications and there didn't seem to be any examples cited in this paper for this platform.
Boy that's strange . . . it's pretty easy to tell what software stack is serving up a URL . . . but for some strange reason - this information is not mentioned (although implicitly one can sort of figure it out) in the paper?? Maybe it's just supposed to be 'assumed' by the reader that this is a well known fact - like IE being the most 'insecure' browser or something??
Perhaps they were simply struggling for a place to list these statistics in the paper.
To characterize the nature of this rising thread, we identify the four prevalent mechanisms used to inject malicious
content on popular web sites: web server security, user contributed content, advertising and third-party widgets.
Hmm - might I suggest adding it to the section on 'web freaking server security'!?!?!? How do you claim to have a section on 'web server security' and then not even mention any web server software stacks by name?To be fair they do call out two popular PHP applications in that section of the paper - but again - don't give any statistics on their prevelance in this pool of 450,000 drive-by URL's they just list them as 'examples'.
So they'll give all sorts of statistics on the number of URL's and the number of malware speciments etc. . . . but not on the software used to propagate it.C'mon - get specific here. What sort of problem are we dealing with?
But hey - their only goal was to:
"... present the state of malware on the Web and emphasize the importance of this rising threat.
But clearly not in any way that talks about the *source* of the problem - the web servers hosting this crap!!!
Now I'm not suggesting that IIS / ASP / ASP.NET are never hacked and used for drive-bys. What I AM suggesting is that our platform is used in these types of attacks FAR less than the competing stack (Apache / PHP). I say this without having anything other than logic and deductive reasoning behind me. We know that IE commands 75% of the browser market and thus this paper focuses on IE / Windows as the client stack of choice . . . but we ALSO know that Apache commands 75% of the web server market and Apache isn't real useful until you install something like PHP on it. It makes sense that if the bad guys are going after the most commonly used browser on the *client* - then they must be going after the most commonly used server stack on the *server* side of this equation. But hey - I'm just guessing here. I didn't cull through billions of URL's and do all sorts of fancy statistical anlysis. It sure would be nice if someone who had access to this sort of data and interested in writing a report would release facts or figures like this so the industry could take notice and maybe prompt people into doing something about the server side of this client/server problem.
Why do I want this stuff to be talked about in a paper like this? Because perhaps then it would serve as a wake-up call to everyone reading the paper that software security is an industry problem and it doesn't *start* (nor end) on the client . . . perhaps it would also serve to vindicate people like Stefan Esser or to lend credence to reports like this: http://www.securityfocus.com/news/11430. Perhaps if someone talked about how bad the situation is with a particular software stack then some Apache / PHP admin would get off their but and inventory their applications and go looking for updates to install vs. assuming there aren't any because they switched from IIS / ASP. And that's assuming there's a patch to install and that it's not some home-grown, inherently vulnerable web application which they'd have to review and patch themselves . . .
But no . . . all you learn when you read that paper is that lots of 'anonymous' web sites can use lots of vulnerabilities and lots of fancy script to install malware in a single web browser - Internet Explorer . . . so that must be the problem.
I find the fact that these cats spent over a year going through this data and but didn't bother to document any statistics on the server side or to take the software stacks or web sites hosting these drive-by URL's to task a bit shady . . .
Don't be evil Google . . .