Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reflected File Download: A New Web Attack Vector

drive.google.com

Post reply on HN
Print view View original

51–60 of 81 posts

Re: Reflected File Download: A New Web Attack Vector

#51

Post by iolsantr »

JackC wrote: post #14
metzman wrote: post #7

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 fro…

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.

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.

Re: Reflected File Download: A New Web Attack Vector

#52

Post by bthornbury »

alkonaut wrote: post #32

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 t…

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.

Re: Reflected File Download: A New Web Attack Vector

#53

Post by thefreeman »

ynik wrote: post #27
matthewmacleod wrote: post #4

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.

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.

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.

Re: Reflected File Download: A New Web Attack Vector

#54

Post by danielweber »

001sky wrote: post #48
andrewstuart2 wrote: post #33

Earlier quoted context omitted.

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

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…

Send it to their Gmail account. Tell them to download the attached file, which will "come from google.com."

Re: Reflected File Download: A New Web Attack Vector

#55

Post by jwarkentin »

iolsantr wrote: post #51
JackC wrote: post #14

Earlier quoted context omitted.

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.

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.

Being aware of exploits and protecting against them comes with the territory. Luckily there are things like owasp.org to help developers keep up on web security. However, security is hard and it can't be done absent mindedly. There is no getting around that.

Re: Reflected File Download: A New Web Attack Vector

#56

Post by eximius »

skue wrote: post #45
JackC wrote: post #24

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 use…

> 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…

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

Re: Reflected File Download: A New Web Attack Vector

#57

Post by Negitivefrags »

thefreeman wrote: post #53
ynik wrote: post #27

Earlier quoted context omitted.

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.

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.

Yes, they do.

However, anyone running something called ChromeSetup.bat would expect a UAC warning to come up since they are expecting to install something anyway.

I've actually run in to this issue myself when I had a program called "Patcher.exe" (an internal dev tool) that didn't require UAC elevation. Turns out that name was on the list. You can include a manifest in the executable to say that you explicitly don't require UAC elevation to prevent that.

Re: Reflected File Download: A New Web Attack Vector

#58

Post by iolsantr »

jwarkentin wrote: post #55
iolsantr wrote: post #51

Earlier quoted context omitted.

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.

Being aware of exploits and protecting against them comes with the territory. Luckily there are things like owasp.org to help developers keep up on web security. However, security is hard and it can't be done absent mindedly. There is no getting around that.

I get that. I just dread the days when malpractice for programmers is as common as it is for doctors. I like building functionality, not fortresses.

Re: Reflected File Download: A New Web Attack Vector

#59

Post by phkahler »

jwarkentin wrote: post #55
iolsantr wrote: post #51

Earlier quoted context omitted.

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.

Being aware of exploits and protecting against them comes with the territory. Luckily there are things like owasp.org to help developers keep up on web security. However, security is hard and it can't be done absent mindedly. There is no getting around that.

If the standards were more strict, some of these issues would not exist. I see this as exploiting a lot of slop in protocols. It should not be possible to interpret a URL as anything but a URL, yet here it's being reflected back and interpreted as something else entirely.

Re: Reflected File Download: A New Web Attack Vector

#60

Post by lambda »

JackC wrote: post #14
metzman wrote: post #7

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 fro…

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.

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.
Post reply on HN