Paid Advertising
web application security lab

Additional Image Bypass on Windows

Michael Schramm posted about another way to do image filter bypassing using alternate file streams on NTFS file systems. Pretty cool stuff (thinking outside the box of what a file really means on different systems). Here’s his English translation:

It’s all about the alternate file streams (ads) in NTFS file system (itís a “feature”), you probably have heard of them. With ads, it’s possible to insert additional data streams to a file beside of its basic contents. For example you could insert ads.txt into the file foobar.txt with “type ads.txt>foobar.txt:somedescriptor”. A User won’t recognize that there is additional data in this file (even if the ads contains several gigabytes), the file foobar.txt will still appear with its original size and contents in file system. But anyway, this is not really essential for understanding what I’ve found out, I think you can inform yourself about ads if you want.

Every file in a NTFS-Volume has at least one data stream, this is the stream named “:$DATA” containing the contents of the file itself. For example if you want to create a file “foo.txt” you could do so with “echo something>C:\foo.txt”. Okay, this isn’t really something new so far, but let’s give a try with “echo something>C:\foo.txt::$DATA”. This will take the same effect as the command before: A file “foo.txt” will be created at C:\ containing the string “something”.

We now know that it’s possible to create “.txt”-files on the file system without really using the file extension “.txt”. Most web apps are validating uploaded files by their file extension because almost everything else is fakeable.

Due to the fact that programming languages/scripting languages are simply calling the api’s of the underlaying os, I thought it should be possible to pass a file with “::$DATA” attached to its name to a php upload-script (php is for example, could be also asp or something). I checked this out with the “filemanager” in the current release of fck-editor (gna, I’ve tried to exploit it damn often in the past - without success).

Fck-editor has a configfile containing a blacklist with denied file extensions, of course there’s “.php” included. And in fact, I was able to bypass this check of denied file extensions! I passed filename “foobar.php::$DATA” and it was saved as “foobar.php” without having problems!

This is only an example, but it should be possible to get this working in many other web apps too. As I mentioned, it only works on webservers running under windows (yes, not only IIS - Apache too!). The need of NTFS should not really be a problem, because almost _all_ Servers running Windows are using NTFS.

I’d love to hear any anecdotes where this actually works. I’m curious if anyone else can replicate this sort of thing. Pretty slick, and similar in some ways to injecting null bytes to bypass exact string match. Nice work, Michael!

16 Responses to “Additional Image Bypass on Windows”

  1. drew Says:

    Nice find! Passing in filenames with foo.txt::$DATA probably has security implications to all Windows apps running on NTFS.

  2. RSnake Says:

    Sounds like another place to use a whitelist instead of a blacklist to me.

  3. Michael Schramm Says:

    @RSnake: Indeed, I just forgot to add that :)

    @drew: There are many known security issues about alternate data streams, for example in earlier versions of iis an attacker was able to view the sourcecode of asp scripts by requesting the file foo.asp::$DATA
    I think this is currently the only useful way to make use of ads in web apps - but however, I will keep researching into ads :)

  4. Ronald van den Heetkamp Says:

    Interesting find Michael! :) Impressive find and good explanation. It shows again: there is a lot to be researched.

  5. AgentSmith15 Says:

    More details on the site below.

  6. Oniric Says:

    Very, very interesting, I think this is a serious security issue. Do you think any patches will be released by Microsoft? Or will it be a responsability for web developers?

  7. keydet89 Says:

    Has anyone actually gotten this to work?

  8. Mockturtle Says:

    that’s really interesting stuff. I’ll be using this to attack the guy in the cube next to me today…

    So with the last few things we’ve seen, does anybody have suggestions for a relatively secure way of validating uploads? Currently I check the extension (usually against a whitelist, but sometimes the specs call for more flexibility), then I change the filename to a timestamp concatenated with a random, seeded hash.

  9. justin Says:


    you could check to make sure after the extension that there is no ::$DATA ;)

  10. Dan Weber Says:

    > Most web apps are validating uploaded files by their file extension because almost everything else is fakeable.

    Maybe my sarcasm detectors are off-line, but the file extension has to be the easiest thing to fake.

  11. eth00 Says:

    use fat32 :D

  12. Michael Schramm Says:

    Maybe you got me wrong. Sure the extension is fakeable, what I meant to say with “fakeable” is that web apps won’t recognize that a file will be saved with an extension that is forbidden normally.

  13. blah Says:

    This is similar to a (very old) IIS vuln whereby IIS would return the source of a .asp file instead of executing it when ::$DATA was appended to the name when fetching via HTTP.

  14. Victor Says:

    Ok that made sense. But if I may ask, what if the site has a list of allowed extensions then this wouldn’t work… like .exe::$DATA wouldnt work if the allowed extensions are .jpgs and .pngs. or would it?

    Secondly, Does this mean that the filename parser sees the file as having an extension *.php::$DATA instead of the real thing

  15. Michael Schramm Says:


    “Does this mean that the filename parser sees the file as having an extension *.php::$DATA instead of the real thing”: Yes it does.

  16. Anonymous Says:

    How would one stop this (if it did work), and it did not work for my IIS 5.