Reflected File Download: A New Web Attack Vector

https://drive.google.com/file/d/0B0KLoHg_gR_XQnV4RVhlNl96MHM/view

by lelf • 12 years ago

285 76 12 years ago

drive.google.com

gohrt• 12 years ago

The linked document describes all the obvious parts that have been known foreer, but doesn't mention the interesting part: what webservices respond to user input (URL) by serving a previously nonexistent (server-side) document with a name derived from the URL.

lnanek2• 12 years ago

There are a lot of URLs that echo back the content from the path/parameters. google.com/s/whatever mentions /s/whatever is not found for example.

Arnor• 12 years ago

Having the ability to control some of the content that is returned by the server in the response body is crucial for an RFD exploit to be successful.

This sounds like an XSS attack against downloaded files as opposed to rendered HTML.

matthewmacleod• 12 years ago

during the RFD research I discovered that all [Windows security] warnings are dismissed if one of the following strings appear in the filename:

- Install

- Setup

- Update

- Uninst

That's pretty amazing – is this still the case? It's obviously a deliberate decision, and seems to totally negate the value of those warnings.

ynik• 12 years ago

With programs that need UAC elevation, there's no "Internet zone" warning because there's already the UAC warning, and it would be rather annoying to have to press "Yes, really" on two warnings per program. I guess if you disable UAC, it's possible that you get no warning at all.

thefreeman• 12 years ago

Do programs with names matching that pattern automatically request UAC elevation? Because the author doesn't mention that he received a UAC warning. If you are able to name an executable that way, and not request UAC elevation, and therefore bypass the warning, it sounds like an issue.

STRML• 12 years ago

The bit about the semicolon separator was new to me. Are there many web services using the semicolon to send parameters?

In any case, it seems that the real bug is that browsers don't properly recognize `;` as a separator and can derive the resource name from what comes after. That's definitely a problem; it would be crazy if, for example, you could craft a querystring ending with "&/file.bat" and the browser would parse it as a file download.

al2o3cr• 12 years ago

Parameters I'm not sure, but there was a hot minute back before Rails 2.0 shipped where it was using them:

https://github.com/rails/rails/commit/0cac2806a6fd9f1f63cdce...

That 2007 commit rolled back to just using slashes.

jfindley• 12 years ago

I'm sure there's some sites, but even if the percentage is in the low single digits (i.e. a smallish but still very significant percentage), I still think that browsers is probably the right place for this to be fixed.

Getting everyone to go through every part of their app and properly harden up their url routing to protect against this seems unlikely to happen - it's simply too much work for many companies.

murbard2• 12 years ago

I found this presentation a bit more helpful to understand the concept

https://www.blackhat.com/docs/eu-14/materials/eu-14-Hafif-Re...

metzman3• 12 years ago

I think the author is claiming that clicking on https://www.google.com/s;/ChromeSetup.bat;/ChromeSetup.bat?g... results in a file ChromeSetup.bat being downloaded, but in chrome and firefox the file downloaded is f.txt.

Has anyone tried this on other browsers?

EDIT:

Here is the portion of the paper explaining why this no longer works:

"However, a common implementation error could result in Reflected File Download from the worst kind. Content-Disposition headers SHOULD include a "filename" parameter, to avoid having the browser parse the filename from the URL.

This is the exact problem that multiple Google APIs suffered from until I reported it to the Google security team, leading to a massive fix in core Google components."

traek• 12 years ago

I can confirm that on Safari, the file downloaded is f.txt

ajanuary• 12 years ago

I read somewhere recently that Google used to be affected but have since patched their servers.

metzman3• 12 years ago

Ahh...that makes sense

JackC2• 12 years ago

The author mentions a mitigation of specifying a filename in the Content-Disposition header, which that particular url actually does:

    Content-Disposition: attachment; filename="f.txt"

Perhaps Google has fixed the problem for that URL -- I would hope the author contacted them in advance.

derobert• 12 years ago

§2.3.2 mentions that the author reported the security problems to Google, and Google fixed their APIs.

iolsantr2• 12 years ago

Stories like these make me never want to make a http webservice again. HTTP(S) is just way too complicated for me to ever be confident I've done everything right. It's getting to the point where webservices are like crypto: only experts should touch them.

lambda2• 12 years ago

Yes, the author mentions that in his paper. He contacted both Google and Microsoft; sounds like Google rolled out fixes before publication, while Microsoft is still working on them:

  On March 2014, I reported a security feature bypass to 
  Microsoft which enables batch files (“bat” and “cmd” 
  extensions) to execute immediately without warning the 
  user about the publisher or origin of the file. Hence, 
  RFD malware that uses the bypass will execute
  immediately once clicked.

  ...

  Microsoft is working on a Defense-in-Depth fix to solve 
  this issue.

And:

  This is the exact problem that multiple Google APIs 
  suffered from until I reported it to the Google security 
  team, leading to a massive fix in core Google components.

Someone12342• 12 years ago

I wonder if this can be mitigated by marking your JSON actions as HTTP POST only. Since this utilises HTTP GET the request would never be actioned and since JSON uses HTTP POST almost exclusively it wouldn't break existing code.

Ded7xSEoPKYNsDd2• 12 years ago

It's not so hard to build a form and submit it automatically with JavaScript in order to get a user's browser to do a POST request to any URL you want.

emersonrsantos• 12 years ago

On Safari 7 at OSX file is downloaded as f.txt.json.

larrys• 12 years ago

"The user executes the file which contains shell commands that gain complete control over the computer."

Perhaps someone could verify the following.

If a user is logged in without privileges (not the admin user for example on Mac but a "standard user") then there is no (is there?) way to "gain complete control over the computer" without entering an admin user and password later in the process.

Typically I operate two (or more) logins under OSX. One is "standard" user and one is "admin" user. I only browse under "standard" user never under "admin" user. To me "admin" user really serves no purpose but needs to be there for obvious reasons.

This way I always have to enter the name of an admin user in order to install or make any system changes.

Further, from the command line I would need to do:

su <admin user name> [password]

and then

sudo -s [password]

metzman3• 12 years ago

An attacker can use a privilege escalation attack to execute as superuser, so even though there should be no way to "gain control of the entire computer" without the admin password, in practice this isn't the case.

umurkontaci• 12 years ago

actually it is. when you are sudo you can practically do whatever you want, including opening a backdoor, adding another admin user, forwarding ports etc.

tedunangst2• 12 years ago

The obvious is that you think you're running "su" but you're really running some other command because your PATH is ~/.trojans:/bin:/usr/bin. They may not have immediate control, but they'll get it eventually.

daeken• 12 years ago

Just FYI, PATH is always reset by su to prevent exactly this. Same with LD_LIBRARY_PATH and other security-critical environment variables.

jluxenberg• 12 years ago

Lots of interesting things can be done without root.

The author gives an example where he quits and re-launches Chrome with flag "--disable-web-security" which disables the same-origin policy. He launches Chrome to a webpage which then steals your Gmail session cookies.

Most of the useful things you do on your computer, accessing all of your data, etc. doesn't require root.

yourad_io• 12 years ago

`cat ~/.ssh/id_?sa | ...`

...but we all use unbruteforcable passphrases, right?

DasIch• 12 years ago

Chances are that you are storing any data you care about in a way that's accessible to your user.

If that data is the target of the attack, user privileges alone won't help you.

ams6110• 12 years ago

If you think you're downloading an installer you might very well enter your password in the pop-up dialog, since many installers ask for admin privileges and people are conditioned to think that is normal.

0x0• 12 years ago

I'm not sure I understand how this is "worm"-able - it still requires the user to manually execute the downloaded file? How is this any different from pasting a link to a "lol.jpg.exe" malware?

fiatmoney• 12 years ago

I believe because the download "actually" (via reflection) comes from google.com .

Someone• 12 years ago

Compare "Are you sure you want to run 'lol.jpg', downloaded from hackers.com a minute ago?" With "Are you sure you want to run 'Windows Security Update 3.1', downloaded from update.microsoft.com a minute ago?". It would be even greater if that second alert showed that a certificate guarantees the file to come from a Microsoft site (would it, if this attack succeeded?)

The more you make your malware look like legit, the likelier that people fall for it. It's not a huge difference, but I guess more people would fall for the latter.

[and of course, it is unlikely that microsoft.com is suspectible to this attack. I don't even know whether it works anywhere at all anymore (from a comment elsewhere in this thread, Google fixed it on their site)]

lucb1e• 12 years ago

Yeah it sounds a bit exaggerated to me, but it's still nice work. It definitely abuses the system and spoofs things that should not be possible to spoof, but it's not as big as I was first afraid it might be after reading just a few lines. It won't silently worm through your social network if you don't execute things that randomly start downloading. However if someone targets you, sends you a link to a .exe or .bat from your own company's website with a good story... yeah that is tempting to click.

malka• 12 years ago

You could craft an url that makes your browser download a file named 'chromesetup.exe' that comes from a google URL, but is a worm.

JackC2• 12 years ago

So to summarize:

(1) You can use semicolons to get some web services to ignore the end of a request URL and respond normally, while tricking browsers into downloading the response as a file with an arbitrary name. This allows you to send a victim to a mainstream site (Google or Bing, e.g.) and have them end up with a file with the name of your choice in their Downloads folder.

(2) If the web service responds with user-submitted data, you can potentially get the contents of that file to be a valid executable. For example the author demonstrates a JSON response that is also a valid Windows shell script.

(3) By combining these two exploits, the author speculates that you can trick users into executing files that they wouldn't execute if they were hosted at g00gl3.com or similar.

The last part I'm not totally convinced of -- are there examples where attackers gain a big advantage by having a downloaded file come from a trusted URL?

Even setting that aside the first two parts are pretty neat, and I wouldn't be surprised if there are other interesting ways to exploit them.

tshadwell• 12 years ago

The important point to me is "some web services", which translates to 'some web servers', but which? Through a cursory browse I can't find one.

Correction: this seems to rely almost entirely on the content-type sniffing of the client-side, provided the content-disposition is 'attachment'.

andrewstuart2• 12 years ago

"Google downloaded a file for me. That's never happened before. Oh well, guess I better run it!"

Untit1ed• 12 years ago

Unfortunately I could easily see that happening.

001sky• 12 years ago

The confidence game here is the same as any other.

1> Google is a legit, law abiding, legal accountable entity

2> Because of (1), the download likely has the attributes associated with google, not more commonly with "bad guys"

3> The probability of google being spoofed is low enough to not empirically validate the premise or conclusion of (1)

4> Smart people therefore do dumb things as a result of (3)

5> Smart people doing dunmb things is a lucrative proposition, because smart people have money/wealth

patio11• 12 years ago

You have to understand that, seen from the perspective of non-technical users, the Googles do weird unpredictable things all the time.

duskwuff• 12 years ago

Are there examples where attackers gain a big advantage by having a downloaded file come from a trusted URL?

Some operating systems, like Mac OS X, will tag downloaded files with the domain they were downloaded from. A prompt asking the user whether they want to download a file that "was downloaded from google.com" will sound much more convincing than one with an unrecognizable domain name.

JoeAltmaier• 12 years ago

But with the proliferation of domain names (.business etc) anybody can have a convincing name?

skue• 12 years ago

are there examples where attackers gain a big advantage by having a downloaded file come from a trusted URL?

Yeah. I hope Adobe is all over this.

It's not hard for me to imagine a shady website that offers streaming videos prompting users that they need to update Flash, then redirecting the user to an adobe.com URL that downloads an installer. I bet even some savvy HNers could fall for that.

Or how about a similar attack on enterprise users by prompting them to update Adobe Reader.

eximius• 12 years ago

Yes, yes I might, especially if it goes to a download-esque page and I'm not looking too closely.

duaneb• 12 years ago

Mac os x, for instance, lets you know where the binary was downloaded from when you launch it the first time. 3 would help people trust the binary more when actually choosing to launch it.

akavel• 12 years ago

The gist:

"The URI specification[1] defines the ability to send parameters in the path portion of the URI by inserting the semicolon character (before the query portion that starts with a question mark "?"). Many Web technologies support this feature [a.k.a. "path parameters"].

In simple words, if a web server accepts path parameters it does not really consider them to be a part of the path, which means we can inject any content, as it will be ignored. However, when it comes to determine the filename of a download the vast majority of Web browsers (all browsers but Safari) parse and set a filename from path parameters."

[1] http://tools.ietf.org/html/rfc3986#section-3.3

A fairly obscure feature of URIs, apparently Correctly handled by some web servers, but apparently overlooked by most browsers. Argh. Again.

adr_• 12 years ago

This sounds basically the same as:

http://lcamtuf.blogspot.com.au/2014/03/messing-around-with-d...

jerf• 12 years ago

A similar technique used to build the payload, but the linked paper does have a more sophisticated technique for setting the target's filename arbitrarily, without having to somehow craft a link with a "download" attribute on a target website.

alkonaut• 12 years ago

If the downloaded payload would auto-execute without warning then this would be serious. Otherwise (if it needs intervention) it feels like a far fetched threat.

1) Aren't the people who would execute files that randomly download exactly the people who can never find the files they download?

2) Aren't the people who execute random stuff from the Internet also the people who won't be able to tell whether a URL feels trustworthy or not?

So by 1) you could just as well serve funny.jpg.exe to the victim, and by 2) you can reach a wide enough audience by serving it from your bad guy domain rather than trying to masquerade as Google.

bthornbury• 12 years ago

I think the point of this exploit is that the download does not need to feel random from the user perspective.

A user can be prompted to update flash or chrome itself and then be served a (somewhat) legitimate looking file from the respective website.

jchrisa• 12 years ago

I really enjoyed the tone of this paper. If only more technical articles can be written in a matter-of-fact voice like this.

hernan604• 12 years ago

Dont click on that link, it might contain a virus!

apeace• 12 years ago

It seems browsers are making a poor assumption here: that if HTTP/HTML say to download, the browser should immediately begin downloading the file to the user's computer.

The content-disposition filename is an effective hack to fix RFD. But as other commenters pointed out, just linking to evil.com/worm.jpg.exe achieves a similar effect to RFD, and can be just as effective on many users.

Windows has failed to warn users about what is happening when random executables are run (and RFD attacks that in particular). They should improve on this.

Perhaps the browsers should also change their behavior? They could prompt users with information about what is happening when a protocol specifies that a download should begin.

daddykotex2• 12 years ago

Where is the file downloaded from if it wasn't uploaded to the targeted site?

daddykotex2• 12 years ago

Oh I see, the content of the file is in the url... Nvm my question!

Reflected File Download: A New Web Attack Vector

Related Stories