A Blast from the Past: Revisiting the IIS Tilde Vulnerability
Reading time: 6 minutes
As Internet Information Services (IIS)—the underlying server technology behind scores of Windows-based web applications worldwide—continues to gain market share over rivaling platforms, its security vulnerabilities have not been in short supply.
Chief among relevant ones include the likes of Remote Code Execution scenarios made possible by inherent flaws in certain protocol stacks, or the existence of several server-side malware posing as legitimate modules, particularly when legacy IIS versions have been involved. For example, as recently as 2021, entire backdoor families were notoriously known to wreak havoc on the modular interdependence between popular Exchange Server components, such as Outlook Web Access (OWA), and the underpinning IIS infrastructure, allowing bad actors to steal credential information from unsuspecting users.
Ensconced by years’ worth of file system conventions turned features, the Windows NT family of products has also inadvertently introduced a handful of lesser-known vulnerabilities threatening software down the line. Such is the case of the Microsoft IIS Tilde Vulnerability: the topic of this article.
Read on as we briefly peer into the computing archives to explain how a compulsory OS implementation scheme set afoot a modern-day security risk.
- Fade to the 80s
- What exactly is the IIS Tilde or Shortname Vulnerability?
- Proactive IIS ShortName Vulnerability Detection using Attack Surface Intelligence
- Final thoughts
Fade to the 80s
In the early days of DOS and Windows, the FAT (File Allocation Table) file system was the prevailing standard. Conceptually, FAT was nothing more than a data structure consisting of indexing features, or pointers, signaling the location of specific files and directories on disk. FAT even accounted for unused space by logically combining all this content into contiguous data regions known as clusters, thereby significantly reducing the resulting index size.
Akin to a book’s table of contents, FAT quickly developed into subsequent versions to accommodate the growing need for disks with higher capacity and, thus, larger cluster addresses. Parallel to this effort was the introduction of constructs such as extended partitions; a fortunate side-effect-like happenstance that gave rise to the notion of logical drives.
Before FAT paved the way for newer file systems, however, filenames were being subjected to the now infamous “8.3” naming convention** **(also called a short filename or SFN)—an ASCII-based derivative limiting filenames to a maximum of eight characters, followed by a dot and a three-character extension (e.g., FILENAME.TXT), with similar restrictions applying to directory entries.
Ubiquitous to all pre-Windows NT operating systems, SFNs are essentially considered a fallback mechanism; in fact, as of today, Windows still auto generates SFNs in response to longer filenames to allow compatibility with older 16-bit applications. In this context, the 8.3 (or 8dot3) creation behavior includes the removal of invalid characters, extra spaces and dots, as well as the shortening of any file extension longer than three characters. Finally, a tilde (~) character is added along with incrementing numeric tails to complete the specification—if a naming conflict exists after the fourth tail, checksums are employed to avoid collisions.
What exactly is the IIS Tilde or Shortname Vulnerability?
Since at least 2010, different Microsoft IIS versions have been shown to be vulnerable to an information disclosure exploit, whereby the web server may be coerced into revealing files and folder information otherwise hidden from normal view.
This is all predicated on the systematic scanning—using specially-crafted HTTP requests leveraging the tilde character—of an entire website’s root structure in search of 404 responses, potentially indicating a valid 8dot3 path or filename. In turn, the rest of the brute-forcing process consists in deriving the long filename correspondence from any previous (positive) results; furthermore, file extensions (e.g., aspx) are easier to fuzz given the reduced character set.
For instance, we can begin by simply scanning for the string “~1”. (Note here the use of the asterisk in wildcard fashion.) Subsequently, we can start appending characters, such as “a”, as in** “a*~1*”**, looking out for valid (or invalid) responses to determine whether we’re approximating the correct SFN and extension, or not:
hxxp://sdl.me/*~1*/.aspx 404 - Valid: one or more file(s)/folder(s) with shortname is/are available on the server
hxxp://sdl.me/a*~1*/.aspx 404 - Valid: It starts with "A"
hxxp://sdl.me/aa*~1*/.aspx 400 - Invalid: The second letter is not "A"
hxxp://sdl.me/ab*~1*/.aspx 400 - Invalid: The second letter is not "B"
hxxp://sdl.me/ac*~1*/.aspx 404 - Valid: The second letter is "C"
hxxp://sdl.me/ac%3f~1*/.aspx 400 - Invalid: It has more than three characters
hxxp://sdl.me/ac%3f%3f%3f%3f~1*/.aspx 404 - Valid: It has 6 or more than 6 characters
hxxp://sdl.me/acsecr~1*/.aspx 404 - Valid: It starts with "ACSECR"
hxxp://sdl.me/acsecr~1/.aspx 400 - Invalid: It is not a folder and it has an extension
hxxp://sdl.me/acsecr~1.%3f/.aspx 400 - Invalid: Extension has more than 1 character
hxxp://sdl.me/acsecr~1.%3f%3f%3f/.aspx 404 - Valid: Extension has 3 or more characters
hxxp://sdl.me/acsecr~1.a%3f%3f/.aspx 400 - Invalid: Extension does not start with "A"
hxxp://sdl.me/acsecr~1.h%3f%3f/.aspx 404 - Valid: Extension starts with "H"
hxxp://sdl.me/acsecr~1.htm/.aspx 404 - Valid: Extension starts with "HTM"
Concluding that the SFN in question must be: "acsecret.html"
Source: https://rb.gy/ct8ux5
In many cases, the process will take numerous iterations before we arrive at the desired filename. In all, IIS versions spanning 1.0 through 7.5, as well as .NET frameworks 1.0 through 4.0, are affected; mitigation techniques include the suppression of all web requests having the tilde character, as well as a registry modification to disable the 8dot3 naming scheme at the OS level.
In a similar note, running the below command as local administrator should return whether or not 8dot3 filenames are enabled on the target volume:
Proactive IIS ShortName Vulnerability Detection using Attack Surface Intelligence
Our engineering team, following a recent upsurge in scanning activity seeking to exploit this vulnerability, quickly worked on getting a Risk Rule ready to help protect our customers and their infrastructure.
As shown below, Attack Surface Intelligence Risk Rules can effectively detect this type of attack, while alerting your security team—all from within the ‘Risk Rules’ tab inside the Attack Surface Intelligence interface:
Final thoughts
By now, it is no secret that Microsoft has consistently shown a lack of attrition by proffering the term “feature” to demystify several software vulnerabilities, and the IIS Tilde one is no exception. As in the past, with potential workarounds pointing to registry modifications or the need to cautiously filter out any offending input, overburdened security teams lacking proper visibility are likely to miss putting any significant countermeasures in place.
Attack Surface Intelligence, through its relentless ability to gaze into the very fabric of your internet presence, will give you that much-needed edge over any hidden vulnerability, regardless of exposure level. Such an overarching and consistent look at your inventory can result in a level of protection unimaginable only a few years ago.
