Recently a Windows 2000 / IIS 5 security hole was discovered that allows the source of ASP pages to be viewed through a simple HTTP request. This special HTTP request simply needs to be directed to an ASP page that is hosted on a Windows 2000 box that does not have either the security hole patch or Service Pack 1 installed. What makes this HTTP request special is that the ASP page being requested ends with a backslash and the HTTP header Translate: f is sent along. You can see ASP code that sends such a request at: http://216.87.1.71/learn/translatef.asp or you can try out a form-based version of this at: http://security.namodro.cz/urlcheck.asp?lang=en.

IIS 4 Vulnerable?

A couple of 4Guys visitors have alerted me that this security hole is also persistent in NT Server boxes with IIS 4 that have the 6a Service Pack installed (SP 6a). Also, from the NT BugTraq ListServ: "[The Translate: f bug] ... is a WINDOWS 2000 bug, but because of FrontPage Server Extensions 2000 installed even on IIS 4.0 sites, it is also IIS 4.0 bug. Also worth of note is that MANY IIS 4.0 sites will exhibit Translate: f bug when web files are stored on SHARED (network) directory - this has been reported to secure@microsoft.com the same time i started bombing them with information that there is BIG problem with Translate: f - and result of case at secure@microsoft.com. "YES, IIS 4.0 is vulnerable, if files are located on shared drive - in that case, please apply fix for "Virtualized UNC Share" vulnerability (please see MS00-019 for fixes). So even IIS 4.0 is not safe from this problem!" -- from Daniel Docekal, NTBugTraq ListServ

Do keep in mind that a patch can be downloaded from Microsoft's site: http://www.microsoft.com/technet/security/bulletin/ms00-058.asp.

Now for the specifics on the security hole; for this we turn to a posting by g on the ASPSecurity ListServ.

"[The Translate:f security hole is] ... used by DAV-aware applications, eg Office2K, IE5 or W2K's Web Folders.

"Basically, DAV is Distributed Authoring and Versioning, ie a bit like CVS or Visual SourceSafe, but meant for use over the internet. It runs over HTTP by using extensions to the HTTP headers (where necessary) so you could use it instead of FTP for example and take advantage of SSL, authentication, etc. and not have to open up another port of course :-)

"Because DAV works via HTTP, to retrieve a file the DAV client sends a GET request, but for script files this won't work as you'd just end up with the resulting output :(. Hence, MS came up with an extension where the DAV client sends a 'translate' header along too, which tells the server whether to 'translate' the requested file. For a script file, specifying translate:f this means don't translate (ie process) the file, just send back the source code.

"IIS5 is (I think) the first version of IIS to support DAV, and to enable it on a directory, you'd tick the box marked 'Script source access'. With this ticked, a client can request the source of any script-mapped files via a DAV client. If the 'Write' box was enabled too, they could upload a new version. Maybe IIS4 supports it too, though I always thought the 'Write' permission in IIS4 was for FrontPage...not that I have 'Write' enabled on any boxes around here though...

"By default, only Read is selected for websites anyway, so any user with a DAV client could only get the output of any file (which they could do via any browser anyway) so it's only a problem if you've got 'Script source access' also checked. Unless of course there's a bug in IIS5 which somehow lets this through without checking....until the URL posted comes back up again it's a bit difficult to tell. Anyone got a URL for a custom client that I can test on my W2K box? I'm too lazy to search right now as I only ever start up my IIS5 sites for specific things and then with full security and only for brief periods of time...and it's time I went home. Or anyone want to do the test for us. :-)

"I guess if you enabled Script source access and Write, thinking it was for FrontPage, and left the site un- protected and left all the files on the site as everyone full control you'd be in trouble.

"If you really want this sort of thing, then use another virtual directory mapped to the root of the site with this enabled but with security (ie integrated Windows authentication or digest, plus SSL preferably).

"Out of curiosity, I tried using the 'Add network place' wizard in W2K on a couple of familiar places:

"NOTE: Don't take the fact I tried these the wrong way, in particular, don't misinterpret this as meaning I was trying to crack any of the sites. If I'd found them vulnerable I'd have mailed the site ops straight away (as I've done in the past, when I've picked random sites to check that I've found vulnerable) and they wouldn't be in this mail. I only include them below because they gave interesting responses.

Site	Response
www.aspng.com	Prompted for username/password
www.learnasp.com	Same
www.4guysfromrolla.com	Same
www.microsoft.com	Hung the wizard then retried and got a valid connection but couldn't see anything! Bizarre.
Sites we host plus various others, eg www.amazon.com, www.ebay.com, www.softartisans.com	Invalid folder from all of them.

"Interestingly, both IIS4 (4guys) and IIS5 (aspng, learnasp) responded to requests with username/password prompts. Since none of the sites we host have FP on them, I assume this is what causes the prompt - the Web Folders understands both FP and DAV and can use them both.

"Even so, you need a un/pw so you can either start guessing or try a different tactic :) Quite frankly, unless you've got some novice op who's decided to give unrestricted access to the site, or a directory off it, I wouldn't really consider this a risk. I suppose you're vulnerable to being sniffed, but you can always use a product which supports encryption (eg DAV over SSL!) and eg, limiting IPs which can connect (eg DAV again, or PCAnywhere, etc), plus secure authentication (unlike FTP)."

More Great Info
Translate: f Security Hole be sure to read: Translate: f - History, Remedy, and Thoughts!