Background
In August of 2010, security researcher Soroush Dalili (@irsdl) reported the “IIS tilde character vulnerability” to Microsoft. Also known as the “IIS Shortname” vulnerability, it enabled retrieving the first 6 characters of a file name or directory and first 3 characters of an extension on a vulnerable IIS server.
To briefly cover the basics for the uninformed, it works by leveraging internal Microsoft weirdness relating to 8.3 filenames, that originated back in the DOS days and is somehow still alive and well in relatively recent versions of windows.
Take the filename “filename.aspx”. On a vulnerable IIS server, when a tilde “~” is included in the file path like this:
/file*~1*/.aspx
the server would respond with a 404 if anything starting with “file” was in the directory, and with a 400 if it was not. If you added the next letter correctly:
/filen*~1*/.aspx
you would get another 404, whereas adding the wrong character gave you a 400. (In IIS 7, the difference is a differing error code instead)
In this way, you can systematically enumerate up to the first 6 characters of a filename, along with the first 3 of the extension.
It’s a unique experience in pentesting. It creates this little step in your hacking process where suddenly all your web hacking skills are irrelevant as you find yourself in a weird version of scrabble, where maybe if you can just think of the right word to go with ~FILE_R.ASP you can “retrieve” some files that blow the whole app wide open. Sometimes, this leads to bringing the right word list to bear and doing efficient bruteforcing, leveraging what you already know. Other times, you just plain have to be good at guessing words and phrases.
You can find Soroush Dalili’s original writeup here: https://soroush.secproject.com/downloadable/microsoft_iis_tilde_character_vulnerability_feature.pdf
He goes into much greater detail on how everything works there than I will. Rehashing the details of the vulnerability isn’t the point of this post.
He created and regularly maintains the tool for automating the discovery / exploitation process of this vulnerability, IIS shortname scanner.
Microsoft’s Response
According to all available information, Microsoft completely blew this off. They told Dalili:
“As far as the exact date for this fix I am unsure when the next version of the product with this fix will be released. As this does not meet the bar for a security update it is up to the development team to determine when this fix will be implemented.”
They felt it wasn’t severe enough for a security bulletin, and seemingly said “we’ll fix it when we fix it”. To be fair, it seems that they did “fix” the issue in newer versions of IIS. However, a couple years later Dalili discovered a new way to get the vulnerability working again by simply changing the HTTP request method from GET to OPTIONS, and other methods like DEBUG frequently work as well. It seems like whatever Microsoft did was half-hearted at best.
One would think at this point Microsoft would take this seriously enough to take real action but apparently they still haven’t. The only official response they have issued (to my knowledge) is suggesting that 8.3 names be disabled via a registry key.
Key: HKLM\SYSTEM\CurrentControlSet\Control\FileSystem
Name: NtfsDisable8dot3NameCreation
Value: 1The one article you can find from Microsoft on how to do this is actually referencing a totally unrelated error, that just so happens to have the same fix.
To this day this is the most Microsoft has done on this issue, as Dalili reports this was his latest communication with Microsoft:
“Thank you for contacting the Microsoft Security Response Center. We appreciate your bringing this to our attention. Our previous guidance stands: deploy IIS with 8.3 names disabled.”
Microsoft could have killed this issue immediately if they wanted to. I have no idea what legacy systems they are still trying to support by keeping 8.3 filenames alive. There is certainly no justification for keeping this on by default. It’s not like Microsoft is incapable of “draconian” fixes for things.
In December of 2013, they decided to override the “enableViewStateMac=false” setting on aspx pages, which disabled viewstate validation, in light of the insecure deserialization threat this created. I am not suggesting these vulnerabilities are comparable in terms of severity – by all accounts the Viewstate MAC situation was a genuine emergency. Even then, their blog post was almost apologetic in tone – as if they were expecting some kind of great backlash from their customers (for removing a super critical RCE from their servers).
So why is it a big deal?
Why write more about it? There is no shortage of documentation about this vulnerability, from a variety of sources. Every commercial web scanner looks for it and finds it easily. It’s safe to say I’m not bringing anything new the table here.
In short, it’s 2021 and as a web application pentester I still encounter this issue on a regular basis. More than 10 years after it was initially reported, it is still an extremely prevalent issue. I don’t have any real statistics on what percentage of IIS servers are vulnerable, but my completely subjective and anecdotal guess based on servers I’ve been testing is around 25%. It’s a regular part of my routine when I am testing any IIS server, and until Microsoft finally puts an end to it, it should be part of yours too.
I think a big part of the thought process that leads someone to think this is just a low-impact vulnerability goes something like this: “Well, you could get to that file anyway, its really not making anything more insecure.” Sure – on paper it does not make anything more insecure, those vulnerable pages were always there. It’s not like you can actually access files with the shortname, it just gives you a clue to help you figure the full filename out.
We have all been told security through obscurity is a terrible practice, and you should never rely on it to keep something secure. This is usually good advice. You really shouldn’t host vulnerable code in the first place. But, it ignores the fact that in the real world obscurity is always part of the equation. The reality is, right at this moment there are thousands upon thousands of vulnerable web applications in the wild, being saved from the clutches of compromise though accidental obscurity.
There are plenty of obviously vulnerable .aspx pages that would have already been hacked had they been named slightly less uniquely and been therefore been found by someone running dirbuster. The IIS shortname vulnerability removes a great deal of that obscurity and dramatically increases the reach of reconnaissance techniques designed to discover vulnerable endpoints.
Experiences abusing IIS shortnames
As a pentester, depending on the type of engagement I might be in either blackbox or whitebox mode. But even when in “blackbox” mode, if I really suspect something is up with an app but just can’t enumerate it, I might just contact the customer and ask for source code. Finding the vulnerabilities and getting them fixed is top priority.
When I’m hunting bugs in my off time though, it’s an entirely different story. Everything is blackbox, and I’m now in competition with other hackers. I have showed up to old targets which haven’t had vulnerabilities in months or years, employed IIS shortname scanner, and wound up finding vast unexplored terrain and racked up tons of bugs in the process. That should give you an idea of both how common this bug is and how many testers still neglect to check for it. This should also give you a sense of its danger, in the right set of circumstances.
The right set of circumstances
Imagine you find an IIS server and the root page is just the IIS splash page.
Let’s say you run dirbuster with a great wordlist and all you come up with is js, css, and images directories. You’ve done your OSINT and have come up empty. You have no idea what the server is for, you just know its in scope and you are stuck. Now imagine you realize it is vulnerable to IIS shortnames. Suddenly, you can see a huge list of folders and .aspx, .ashx, and .asmx files that were just out of reach.
Now take the ones with readable words in the first 6 characters, and run a custom dirbusting session where you prepend everything with that word. You start to find a few pages. Those pages have links, revealing others. Those pages load obscure Javascript files, which contain references to more .aspx pages. You’ll start to learn the nomenclature of the naming scheme and can make better guesses on some of the files you couldn’t figure out before.
Now say after a few iterations of this, you find an arbitrary file read vulnerability in one of the discovered pages. Now you can pull down all the source code. You can spend hours pouring over every line of code and find every vulnerability and get them all to yourself because you were the first one to actually look at any it. Say what you will about security-through-obscurity, but in such an application, obscurity was the last line of defense.
Conclusion
This brings me to my dual purpose for this post. To the pentester / bug bounty hunter reading my blog – I want to encourage you to use this tool against each and every IIS server you encounter. Make it part of your standard routine. I’ve had my time with it being my secret weapon (as have many others), but it should be on every web hacker’s checklist.
I also hope to, in whatever small way I can, pile more pressure on Microsoft to actually do something real about this. They could issue a patch tomorrow that would erase this issue for any up-to-date server. Why don’t they? Why did they take such a dismissing approach when the vulnerability was reported? Why do they feel such a strong need to keep 8.3 filenames around? I spend hours and hours a day attacking web apps and the real impact of this bug simply does not match Microsoft’s reaction.
More notes about bug bounties
In my day job, I have the luxury of making it a point to always report this vulnerability and I have the opportunity to make my case for why it’s (often, but not always) a solid “medium” severity vulnerability. When it comes to the bug bounty scene, unfortunately it is very unlikely you will get any significant bounty (or any) for reporting this. I could easily see something like a $25 bounty being normal.
On Synack, where bug payouts are standardized and adjudicated by Synack’s vuln ops team (as opposed to by the customer), the vulnerability has been permanently banned to the “low impact” bucket; in the company of the lowely open redirect, phpinfo page, and wordpress user enumeration bugs. This means you will not get paid for it and it will not go to the customer. It means it remains on lots and lots of servers. I can hardly blame Synack for this decision, because they would be flooded with reports of it all the time, and with no real guidance from Microsoft on how to fix it – other than changing a registry setting. If that is not going to change, you might as well use it and find yourself some high quality attack surface to chew on.
Paul Mueller (@paulmmueller) 