Fixing the IIS tilde vulnerability
One of our IIS servers (IIS 7.5, Server 2008 R2) is apparently "vulnerable" to the tilde Short Filename disclosure issue.
However, I'm having a hard time actually fixing the issue. So far, I've
Disabled 8.3 filenames, stopped the web server, recreated the site directory and started the service again
Added a filter rule for a tilde in the URL:
- Added a filter rule for a tilde ANYWHERE:
IISRESET
a couple of timesChecked that
web.config
has the relevant filter rules added
.. but still, I can't get my site to pass the test :
java -jar ~/temp/IIS-ShortName-Scanner-master/IIS_shortname_scanner.jar http://www.example.com
[...SNIP...]
Testing request method: "TRACE" with magic part: "/webresource.axd" ...
Testing request method: "DEBUG" with magic part: "" ...
Testing request method: "OPTIONS" with magic part: "" ...
Testing request method: "GET" with magic part: "" ...
Reliable request method was found = GET
Reliable magic part was found =
144 requests have been sent to the server:
<<< The target website is vulnerable! >>>
What else do I need to do to resolve this?
EDIT: here's DIR /x
which appears to show no 8.3 filenames:
and here's the app pool for the site (all other sites on the server are the same):
EDIT2: Verification there's no 8.3 filenames left:
Try to scan for existing short filenames with fsutil
:
fsutil 8dot3name scan /s /v E:\inetpub\wwwroot
And strip them if they are found:
fsutil 8dot3name strip /s /v E:\inetpub\wwwroot
Also looking at the log with empty magic part (magic part: ""
), I wonder could that be a bug in the POC. This line in config.xml looks like it has extra comma after /webresource.axd
:
<entry> key="magicFinalPartList">
<![CDATA[\a.aspx,\a.asp,/a.aspx,/a.asp,/a.shtml,/a.asmx,/a.ashx,/a.config,/a.php,/a.jpg,/webresource.axd,,/a.xxx]]>
</entry>
I've asked dev. via Twitter about it and he responded:
So, it seems that you're safe now :)
also "NOTE: The change to the NtfsDisable8dot3NameCreation registry entry affects only files, folders, and profiles that are created after the change. Files that already exist are not affected. "
Note: Although disabling 8.3 file name creation increases file performance under Windows, some applications (16-bit, 32-bit, or 64-bit) may not be able to find files and directories that have long file names.