Microsoft's IIS 5.0 web server is shipped with a set of sample files to demonstrate different features of the ASP language. One of these sample files allows a remote user to view the source of any file in the web root with the extension .asp, .inc, .htm, or .html. The IISSamples virtual directory should not be left on production servers in the first place, but up until now, there were no serious (See note #1) vulnerabilities found in those sample scripts. Microsoft was not contacted about this, they can read the lists like everyone else. This issue can be fixed by proper system administration.
Credit:
The information has been provided by H D Moore.
The IIS developers actually put some thought into securing this sample script. Unfortunately, for them and their user base, they did not take into account the Unicode character set when checking the path passed to the script.
The function fValidPath in CodeBrws.asp has the following comment placed above it:
REM **************************************
REM intended behavior:
REM allow access to only .asp, .htm, .html, .inc files
REM in some directory starting from /IISSAMPLES
REM and without .. in the path
REM **************************************
The fValidPath function first checks to see if the base directory starts with "/IISSAMPLES", then verifies that the last characters of the request are one of the allowed extensions, and finally checks to see if the ".." sequence is anywhere in the string.
The problem is that ".." can be represented a number of other ways using the Unicode character set. For instance, the sequence %c0%ae%c0%ae will be decoded as two periods by IIS, but will not be caught by the InStr(1,strPath,"..",1) code in the ASP script. Therefore, to create a request that passes the input filters but retrieves the source of default.asp:
/iissamples/sdk/asp/docs/CodeBrws.asp?Source=/IISSAMPLES/%c0%ae%c0%ae/default.asp
Solution:
Remove the /IISSamples virtual directory using the Internet Services Manager. If for some reason this is not possible, removing the following ASP script will fix the problem:
This path assumes that you installed IIS in c:\inetpub
c:\inetpub\iissamples\sdk\asp\docs\CodeBrws.asp
Note #1:
While all versions of IIS before 5.0 had significant problems with the bundled sample scripts, IIS 5.0 has only had a couple information gathering issues to date. Due to the lowered risk, many administrators have left the IISSamples virtual directory mapped on their production servers.