Windows Short (8.3) Filenames – A Security Nightmare?

Each time you create a new file on Windows, the operating system also generates an MS-DOS-compatible short file name in 8.3 format, to allow MS-DOS-based or 16-bit Windows-based programs to access files which have a long name. You can see these MS-DOS-compatible short file names by using the /X switch with the dir command. On my system I get something like this:

There have been a lot of security problems in the past related to short file names. Just yesterday, I found another paper that talks about this subject. The paper was written by Soroush Dalili and is called Microsoft IIS tilde character “~” Vulnerability/Feature – Short File/Folder Name Disclosure.

When using IIS, you can get a list of all the shortnames (both files and directories) from a certain directory. This can be a big problem if you can manage to guess, or bruteforce the full file or directory names from these short names. While working on a security script for Acunetix Web Vulnerability Scanner, I thought “Why you have to guess the full names once you have the short names? Why you cannot use the short names? It turns out that IIS doesn’t accept short names for a variety of reasons, most of which are security related”. But what about Apache? Apache SUPPORTS short file names, and this is a security problem.

Think of following scenario; a web application running on Apache on Windows, is creating a file with a long name that should not be guessed by an attacker. For example it creates a session file or an SQL backup file. In this case the security of this application relies on the fact that the name of this file cannot be guessed.

Let’s assume that this file name is backup-082119f75623eb7abd7bf357698ff66c.sql. Windows will create a short name for this file, BACKUP~1.SQL. If I can access this  file using the short file name then all the security is broken. I just request BACKUP~1.SQL and get the file, which includes a backup of an SQL database.

Being curious if this problem is a real life problem, I looked at two of the most popular backup plugins for WordPress. Both of them are affected by this problem, which is explained in detail below.

After installing one of the plugins, I have requested a backup of my WordPress blog:

The plugin creates a custom directory for this backup (backup-88456). Once the backup is completed, the directory contained a file named wordpress_wp_20120702_576.sql, which is the WordPress database backup. This should be pretty hard to guess. We have 5 numbers in the directory name (100 000 combinations) plus the date and plus 3 more numbers. In total it should be at least 100,000,000 combinations if we ignore the date. What do you think are the short names for this directory and file? Using short names this is pretty easy to guess.

Directory name is BACKUP~1 and file name is WORDPR~1.SQL. That’s ONE combination. 100,000,000 combinations were reduced to ONE combination because of  Windows short names. As expected I can read the SQL backup file from the first try:

What can you do to protect yourself against this problem, and who’s fault is it?

Is Microsoft’s fault that they still support the short names in 2012? Maybe. I’m not sure but legacy and security do not go well together. Or is it Apache’s fault that they support the short names? Maybe.  I don’t think it is the fault of the person who wrote the WordPress plugin.

The solution

There is a way to disable Windows 8.3 short name creation.You can create a registry key named NtfsDisable8dot3NameCreation in HKLMSYSTEMCurrentControlSetControlFileSystem and set it to 1.  That should disable short names creation. Refer to this Microsoft TechNet article to read more about the solution.

Share this post
  • Interesting and useful advice. Of course, a solution would be to use a Linux or OS X computer running Apache — that would offer better protection against this. But the registry addition is a good nugget.

    Also, maybe backups should be stored off-site?

    • Yes, Linux is not affected by this problem. However the backup problem was just an example. Any web application that is using the name of a file as a security measure will be affected by this.

  • Um, how is Linux affected by this problem? Linux doesn’t automatically create and translate DOS compatible filenames.

    And the solution is simple, disallow tilde altogether via htaccess or simply disallow [a-Z]{cnt}~{0-9}

  • I really don’t think that relying on a long/complex filename instead of moving it out of web root represents any kind of security measure.
    Specially in a wordpress plugin, since you can have a web server with directory listing set to on.

  • Is there a SFN Disclosure Vulnerability about apache on windows?

  • Applications should store backups in the hidden folders such as app_data, then the issue does not rise. It’s just an example of bad configuration if the backup files are in public folders that are exposed using http.

  • A interesting post right there mate . Thanks for posting !

  • I have a same opinion with Alex.
    In those cases, the real problem is not a 8.3 names. It is a matter of access permission. 100,000,000 combinations are too weak to protect data from brute-force attack.

  • > In this case the security of this application relies on the fact that the name of this file cannot be guessed.

    Well that’s a problem right there; security through obscurity is considered unreliable at best.

    The wonder of it all is that a “proper” solution to security usually ends up bypassing things like 8.3 issues altogether.

  • I’m not sure I understand Acunetix’s intepretation of this issue. We have a folder named “Admin” (Which hosts pages that help administrators configure the product) which is fully disclosed (in the form of links) after you login. There is nothing hidden or obscure about this folder.

    We got a high-issue back from an accunetix test that said the test requested “…/admin/admin/*~1*/a.aspx?aspxerrorpath=/” and got back a 404.

    This is exactly what I would expect. You requested a file that doesn’t exist, and got back an error that indicates the resource does not exist.

    What is the actual issue? What should we have done? Return a 500 due to an URL containing “~”. What disclosing of sensitive information could you get by executing this request? I want to solve the issue, but cannot see what solution would satisfy the Acunetix scanner’s parameters.

    • Hi Steven, From your description, the site is indeed behaving as one would expect. I suggest you get in touch with our Support Team (support@acunetix.com) in order for them to be able to take a closer look at your issue.

  • @Steven Stewart, I am seeing something very similar with the 404 response. What was your outcome on this?

  • Leave a Reply

    Your email address will not be published.