David wrote in pointing us to an exploit against IIS 5.0 and 5.1 . The exploit was discovered on December 15, 2006, and made public since the end of May 2007. The design of IIS 5.x allows to bypass basic authentication by using the hit highlight feature.

Microsoft's response seems to be a bit atypical for them as it includes a section on how to reproduce the exploit. In other words: Microsoft is telling the world how to exploit their products being used by their customers. Not that the worst of those interested in it did not already know, but the one thing we need from Microsoft is not the exploit, but the patch or at least a decent work-around. And that patch is lacking. Their only defensive advice is to upgrade to IIS 6.0.

Since this means that you would also need to upgrade the windows 2000 or XP to Windows 2003, and that such an upgrade isn't free, nor easy. So what do we do when Microsoft does not give any advice but to upgrade to IIS 6.0 ?  Let's look at alternatives.

Feel free to write in if you know more effective alternatives:

• Most probably there is a way to remove something or change some registry setting to prevent this, unfortunately exactly what is neither documented nor validated.
  Eric told us to "If you don't use the web hits functionality, a simple workaround would be to remove the script mapping for .htw files". Without a script mapping, IIS should treat the file as static content.
• Try to use application level firewalls (filters), while they aren't the easiest to configure considering all the ways URLs can be encoded, it's something that might help for a while, but getting it fully right will be a pain. If you have the infrastructure it can be a temporary measure till you can upgrade IIS, solving the actual problem.
• URLScan, a URL filter by Microsoft actually can be used to stop access to .htw files and is reported by some readers as being effective. While a URL scanner inside the web browser might know all possible encodings, it remains the poor man choice, but most likely good enough as a workaround in the short run provided you do not need .htw functionality.
• A number of readers who are preventing access to files by managing rights on the confidential files or directories themselves. To people used to apache this sounds odd, but IIS uses OS level users and therefore the permissions set in the filesystem can be used to limit rights and it will protect against server side scripts walking the documentroot tree as well.
  
• Upgrade to apache or another web server, with or without a (cross) upgrade of the OS.
• Scramble an upgrade to Windows 2003, potentially on more potent hardware.

Some URLs:

• KB 328832
• CVE-2007-2815
• URLScan

While the public exploits seem to focus on leaking protected information, the ability to execute code is unexplored, but hinted about.

Unlike my normal habit of avoiding to broadcast exploitable information, but since Microsoft themselves are telling the world already, take a look in your IIS logs for hits like:

"/null.htw?CiWebhitsfile=protected_file&CiRestriction=none&CiHiliteType=full"

Don't be blindsided if you do not find "null.htw" in your document root directory, the exploit does not need that file at all, in fact the reference needs to be to a file that does not exist, but since it can be located anywhere, that's not a working workaround either.

The one workaround that seems to be functioning is to install and configure -if not done so already- URLScan. Andrew wrote in with: "use URLScan to block all requests for htw files (or, better yet, set URLScan never to permit requests for any extensions but ones you know you need)". URLScan as a workaround remains an ugly solution as it uses filtering as an afterthought instead of proper security by design, but then again, not that many web servers come with security as one of the very top requirements.

A reader pointed us to Aqtronix Webknight as an alternative URL filter that could help stop the exploits agaisnt IIS (GNU licensed).

--
Swa Frantzen -- NET2S