Google hacks are for real

Friday August 06, 2004 (01:00 PM GMT)

One of the slides in Google hacking guru Johnny Long's presentation at the recent Black Hat Briefings used the following search criteria to locate IIS 6.0 Authentication Management pages: inurl:iisadmpwd. I ran that query adding first .mil, and later .gov, to restrict the results to those top-level domains. That's all it took to locate one Army site, two Navy sites, one from the National Institutes of Health, another from the Treasury, and two others from Argonne National Lab.

Is it really a vulnerability just because you can see the pages?

I asked Russ Cooper of NTBugtraq fame that very question. Cooper noted, "The box may be secured, yet that page is exposed for some particular reason. It's not likely; it's more likely that it is an unsecured IIS box. If you are able to get that page, that means that that port is not being restricted. And that port should definitely be restricted."

According to both SecurityFocus and InfoHacking.com, there are multiple vulnerabilities with IIS 6.0 Web-based administration beyond the obvious ability to attempt brute-force password cracks.

A Microsoft spokesperson told NewsForge:

The administration pages you referred to are the password change scripts. These pages are not enabled with IIS 6.0 by default, and enabling this functionality requires additional configuration on the part of the machine administrator. Even when enabled, administrators have the option to choose a secure URL. Microsoft has tested the code extensively for cross-site script vulnerabilities and is not aware of any existing XSS issues.

Brute force attacks are not unique to Microsoft's password change scripts; they're common to any Web-based login application including many Web-based mail systems, e-commerce Web sites and intranet applications. In this specific instance, the account lock-out policy, which locks an account after a specified number of unsuccessful login attempts, is the most straightforward mitigation strategy.

Click to enlarge

Reporting the vulnerability

After finding the sites mentioned above, I spent considerable time and effort trying to get someone to pay attention to them. Over the past two days I've spoken to the Navy, the National Security Agency, the office of an Undersecretary of the Army, the Department of Defense, and others closer to the actual sites involved. As a result of these calls, the Army site is no longer visible in Google search results, the most vulnerable Navy page has been taken down or moved, and the NIH page -- which it turns out was connected to a test machine -- is also gone. Argonne National Lab told me that its page was deliberately exposed to the Internet, although I noticed afterwards that it has begun protecting the site with a JavaScript warning banner.

It turns out I was going about the process of vulnerability notification all wrong. I should have gone to the United States Computer Emergency Readiness Team to report them.

The US-CERT home page provides an email address for reporting vulnerabilities. If you use it, you will receive more detailed instructions on how to complete this form.

More on Google hacking

As Johnny Long promised during Black Hat and Defcon, he made the latest version of his slide presentation on Google hacking available on his site this week. Unfortunately, it looks as if his site got defaced in response.

<  Will DB2 and Oracle databases go open source? | Why people weren't talking about The SCO Group at LinuxWorld  >