The term "0day" has the power to make sys admins cringe. It the greatest fear of anyone tasked with protecting critical assets - a problem without an easy solution.

Why? No, seriously why? 0day is a neon sign in the middle of Times Square. Once people start talking about it (at which point it's really not 0day), everyone is aware of it. Admins are scrambling to implement workarounds and slamming vendors to demand patches (as they should). How many angry phone calls do you suppose that Microsoft received during HD Moore's Month of Browser Bugs?

The point is, that new vulnerabilities draw attention. The ones that scare me are the old ones, the ones that have been forgotten about. Targeted attacks require specific vulnerabilities but many, if not most attacks, choose not to discriminate. The attacker simply wants control of as many machines as possible to send spam, phish for credit card numbers, etc. In this case, any old vulnerability will do, so long as a multitude of machines remain unpatched.

I've always believed that Internet is plagued with unpatched machines to an extent far greater than most people realize. Today, I set out to prove this to myself. The challenge in doing this is to find a way to identify vulnerable machines without attacking them. I want to prove a theory but I don't want to do damage in the process (note: no web servers were harmed during the filming of this blog). Fortunately, web applications provide us with a unique means of identifying vulnerable applications. Due to the fact that search engines archive and index the content served by web apps, if we can identify a unique signature within a vulnerable application, we can locate vulnerable servers without ever needing to connect to them. Johnny Long created somewhat of a cult following doing just this with his Google Hacking Database.

My first challenge was to identify a reasonably nasty vulnerability for which a patch has been available for some time. Fortunately, I had just the candidate. On December 4, 2005, MediaWiki, a popular open source wiki project, announced a remote PHP code execution vulnerability. I knew it well as I was using a server that was vulnerable.

Challenge number two involved identifying a unique string that could be used to locate vulnerable servers. According to the vendor advisory, all versions of MediaWiki in the 1.5.x branch prior to 1.5.3 are vulnerable. Fortunately, MediWiki made this challenge trivial as by default, it includes a page to identify the running version. The Special:Version page identifies not only the version of MediaWiki, but also the versions of PHP and MySQL that are used to support the application. Perfect. So long as servers exposed this page, I had the signature that I was looking for.

Next, I needed to craft a search term to accurately identify the signature. I wasn’t able to find a 'magic bullet' that would find exactly what I was looking for, so I settled on the following collection of terms:

• "This wiki is powered by MediaWiki" "1.5"
• phrases present on the Special:Version page
• allinurl:special version index php
• words present in the URL of the Special:Version page for a 'typical' installation
• inurl:wiki/MediaWiki
• a portion of a typical MediaWiki URL for any version

Using these search terms with both Google and Yahoo! (better results were ultimately obtained with Yahoo!) I set out to identify vulnerable servers. How many were there? Beats me, I stopped after the first 50. These are 50 publicly accessible servers, wide open to remotely running system commands.

A natural question to ask is, are these servers likely to contain sensitive information or are they just personal servers which we wouldn't expect to have strong security? Could they provide an attacker with a gateway into a significant network or are they a dead end into someone's home network? Let's take a look at some of the 50 organizations that participated in this impromptu survey to answer that question:

• Four US colleges
• One British University
• One Viennese university
• One Canadian university
• One Ivy League school (on a site hosted by the computer society no less)
• An Irish human rights organization
• A project for building Firefox extensions
• A New York based mobile software developer
• An entertainment company traded on the NYSE

While some of the vulnerable sites were small sites and likely don't have adequate resources to ensure adequate security, others were significant organizations that should absolutely have stronger security practices in place.

The point is that identifying vulnerable servers is a trivial task. In some cases it can be done without even needing to visit the site in question. Why are spam and phishing attacks so prevalent? We're making it far too easy for them.

- michael