A while ago I found a bunch of web servers that had the Microsoft IIS Tilde Enumeration vulnerability on them. You can read more about the vuln http://soroush.secproject.com/downloadable/microsoft_iis_tilde_character_vulnerability_feature.pdf or http://www.acunetix.com/blog/web-security-zone/windows-short-8-3-filenames-web-security-problem/. Essentially, you can brute force file names that are on IIS web servers and possibly retrieve them using the ye olde style Windows 8.3 naming scheme.
When I went to exploit this, I found Soroush Dalili’s (@irsdl) very capable scanner (https://github.com/irsdl/iis-shortname-scanner/) which he continually updates. Since he released the proof of concept tool, other methods of exploiting this vuln have arisen. nmap even has an NSE (Nmap Scripting Engine) script to exploit it.
I have set up a vulnerable Windows 2003 system (at IP 192.168.217.132) to run these tools against. Let’s look at what files are in the C:\InetPub\wwwroot\ directory on the server. To see what the 8.3 names of the files are, let’s open a cmd prompt and type: dir /x
|Windows Server Files in wwwroot with 8.3 Name|
Here we can see that some of the files/directories have 8.3 names. These are what the Tilde Enumeration exploitation tools brute force. Let’s see how it looks in nmap.
(root @ kali) – /pentest/web $ nmap -p80 –script http-iis-short-name-brute 192.168.217.132
Starting Nmap 6.47 ( http://nmap.org ) at 2014-09-13 18:16 EDT
Nmap scan report for 192.168.217.132
Host is up (0.00027s latency).
PORT STATE SERVICE
80/tcp open http
| Microsoft IIS tilde character “~” short name disclosure and denial of service
| State: VULNERABLE (Exploitable)
| Vulnerable IIS servers disclose folder and file names with a Windows 8.3 naming scheme inside the root folder.
| Shortnames can be used to guess or brute force sensitive filenames. Attackers can exploit this vulnerability to
| cause a denial of service condition.
| Extra information:
| 8.3 filenames found:
- Can we visit http://192.168.217.136/eee~1.htm in a web browser? Nope. So, we know the file is there but cannot retrieve it. Well this definitely decreases the impact of the vulnerability. Telling a customer, “Your server is vuln but I can’t get the file.” is lame. I didn’t like saying that.
- We notice that this nmap script is not recursive. It found directories but did not dive into those to see if there were files in there.
The Java IIS-Scanner
Running the scanner against the vulnerable server is easy (provided that you use Java 7). The scanner prompts you when you run it with no commands and it is VERY fast!
We have some progress here. The EEE file is called out that it is an actual file and could be retrievable. But we again have the lack of recursion and the lack of file-retrievability.
Is there a better tool for this exploitation? Of course. Mine. (You knew this was coming…right?)
My script (https://github.com/WebBreacher/tilde_enum) does some interesting new things:
- So, in Soroush’s original PDF (linked above), he notes a couple of methods of getting the full name of the file. I’ve implemented that.
- Also added recursion.
- And pretty colors.
- And you can send my scanner through a proxy like BurpSuite or ZAP easily.
So, let me walk through the script at a very high level:
- It checks if the server is vulnerable.
- It will then do the brute forcing (similar to the nmap and original scanners).
- Once is has an 8.3 name, for example: passwo~1.xls, it will search for the “xls” extension in a list of common extensions I pulled from the Interwebs.
- It will then take the first 6 characters of the file name (passwo in the above example) and search for it in a word list that the user has specified.
- Then it tries the words it retrieved for the file name and the extensions it found to find a file that IS retrievable.
- It will note when it finds weird errors, file sizes, and response codes. This helps the tester understand what the tool is seeing.
Is it perfect? Nope. It has some failings:
- Unlike the java scanner, it does not exploit all servers.
- Complex file names won’t be retrieved. If you have a file in the web area of “passwords of micah.xlsx.orig” is may have an 8.3 name of passwo~1.ori and the scanner will not find it due to the multiple extensions and long and complicated file name.
- If you look at the directory listing of c:\InetPub\wwwroot at the top of this post, notice that some of the files have odd 8.3 names. The script will pull back the 8.3 names but won’t be able to retrieve the entire file name for 1 and 2 character files since there is padding that occurs in the file name.
Let’s look at the script running/output. Here is the help screen/output.
(root @ kali) – /pentest/web/tilde_enum $ ./tilde_enum.py -h
usage: tilde_enum.py [-h] [-d DIRWORDLIST] [-f] [-p PROXY] [-s SNOOZE]
[-u URL] [-v] [-w WORDLIST]
Exploits and expands the file names found from the tilde enumeration vuln
-h, –help show this help message and exit
-d DIRWORDLIST an optional wordlist for directory name content
-f force testing of the server even if the headers do not
report it as an IIS system
-p PROXY Use a proxy host:port
-s SNOOZE time in seconds to sleep/wait between requests
-u URL URL to scan
-v verbose output
-w WORDLIST the word list to be used for guessing files
And here is the script running against the same victim system. This is the first part of the script where it figures out the server is vulnerable and does the 8.3 tilde brute forcing, directory guesses (using the word list) and file look ups (again using the word list).
Hmmm. That is interesting. It found a 401 (unauthorized) response for development/passwords.xlsx.
What happens if we look at this in our web browser?
Yup. That resource requires authentication to retrieve. You better believe that I’ll run hydra/medusa/ncrack/whatever until I turn blue in the face to get a file named passwords.xlsx.
What about the rest of the output? It is below. I tried to show what I know is there, what may be there, and what you definitely should check out.
Hey…did you catch the documentation/parameters.xml file? What happens when we try to view that in our browser?
Contrived? Perhaps. But is this real? Would this really happen in the real world? Heck yeah. I actually found a similar XML file on a server using this very tool. And showing someone the clear text username and password from a config file you can actually retrieve using this vulnerability is absolutely the best method to demonstrate impact to your customers…and the reason I created this script.