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!
June 6th, 2007 at 3:28 pm
Nice find! Passing in filenames with foo.txt::$DATA probably has security implications to all Windows apps running on NTFS.
June 6th, 2007 at 3:43 pm
Sounds like another place to use a whitelist instead of a blacklist to me.
June 6th, 2007 at 4:11 pm
@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
June 6th, 2007 at 4:49 pm
Interesting find Michael!
Impressive find and good explanation. It shows again: there is a lot to be researched.
June 6th, 2007 at 10:15 pm
More details on the site below.
http://www.irongeek.com/i.php?page=security/altds
June 7th, 2007 at 12:13 am
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?
June 7th, 2007 at 4:01 am
Has anyone actually gotten this to work?
June 7th, 2007 at 6:16 am
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.
June 7th, 2007 at 6:21 am
Mockturtle,
you could check to make sure after the extension that there is no ::$DATA
June 7th, 2007 at 6:51 am
> 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.
June 7th, 2007 at 7:06 am
use fat32
June 7th, 2007 at 9:49 am
@Dan
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.
June 7th, 2007 at 9:49 am
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.
June 7th, 2007 at 10:07 am
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
June 7th, 2007 at 12:21 pm
Victor,
“Does this mean that the filename parser sees the file as having an extension *.php::$DATA instead of the real thing”: Yes it does.
June 17th, 2007 at 10:54 pm
How would one stop this (if it did work), and it did not work for my IIS 5.