Recent IIS 5.1 Remote Exploit
By now, you should have read many blog postings or security advisory from various bodies that discussed about the new .dll exploit discovered by Inge Heriksen. Fairly new guy in IIS domain (afaik), an expert of coz. I came to noticed Inge few months ago in one of my blog comment. This is a very interesting discovery where it applies to XP Pro IIS 5.1 only. I'm curious of why IIS 5.0 is not affected, I could understand why IIS 6.0 is not, because of its new kernel mode driver, worker process model, etc. but IIS5.1 is using the same IIS 5.0 architecture. Could it be security fixes, service packs, bla bla ??? don't know... too lazy to think now. Anyway, Microsoft has been informed about this, but yet to make any statement.
Let's look at the exploit, in order to make this work, you need to make a malformed HTTP request with special char like "~" to a "scripts & executables" folder. Typical "scripts & executables" folder include _vti_bin (FrontPage bin folder), _sharepoint (sharepoint related), scripts (predefined for executable), etc. I read some comment about removing FrontPage extension, this will not block all possible exploit as it can be done on other executable folder. So how do you stop this? obviously at the moment this is temporary workaround to block the possible malformed requests. And I assumed you know what is Urlscan and you have already got it installed :) if not, better get it installed asap. This is a perfect isapi filter designed for IIS 5.0/4.0 server, it applies to HTTP requests only and it is has almost zero performance impact while filtering unwanted requests based the rules you specified in the urlscan.ini file. Specifically in this case, we need to block possible executable extension request + the "~" character. So first, open the urlscan.ini via notepad - default path "%windir%/system32/inetsrv/urlscan", go to [DenyExtensions] section add in ".dll", by default it blocks .exe, .com, bat, cmd, etc. You could put in all possible extension? are there more? .cpl ? etc? mm... or If you are like me, I preferred to use [AllowExtensions] to ensure only those extensions I configured are allowed to served by IIS, by default [DenyExtensions] is applied, you need to change the UseAllowExtensions=1 at the [Options] section to instructs Urlscan to enforce [AllowExtensions] section. Next, just to restrict further, add in "~" at the [DenyUrlSequences] section. Save the ini file and restart IIS services to apply the changes immediately.