Live data from Hacker News

Reflected File Download: A New Web Attack Vector

drive.google.com

61–70 of 81 posts

Re: Reflected File Download: A New Web Attack Vector

#61
post #48

Earlier quoted context omitted.

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."

It comes from https://mail-attachment.googleusercontent.com, so it's not super useful for the sort of attacks that this approach would be used for.

Re: Reflected File Download: A New Web Attack Vector

#62

Earlier quoted context omitted.

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.

It has nothing to do with the standards being strict; the standards can be as strict as they want. If the standards are strict and useless, no one will follow them, instead implementing something less strict and more useful.

For example, when downloading a file from a website, what default name should you use for it? There is a header to tell you, but not ever page supplies such a header; so the browser needs to do something. It chooses to pick the last component of the URL as that filename. However, URLs are somewhat more complex than you might expect, so this becomes more complicated and can lead to attacker controlled ways to manipulate this filename.

Now, you could make a more strict spec, for example by forbidding downloading files unless the filename is properly specified, or forbidding using any kind of default filename and making the user choose it themselves, or something of the sort. But if any browser vendor implemented this more strict spec, they would instantly annoy a lot of users who would find things breaking that used to work, and they would be likely to switch to another more permissive browser.

Security, compatibility, and robustness are hard factors to balance. Just blaming this on "slop in protocols" is a vast over simplification.

Re: Reflected File Download: A New Web Attack Vector

#63
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.

Re: Reflected File Download: A New Web Attack Vector

#64
post #10
post #8

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

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.

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.

Re: Reflected File Download: A New Web Attack Vector

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

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.

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.

Re: Reflected File Download: A New Web Attack Vector

#66
post #8

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

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.

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

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

Re: Reflected File Download: A New Web Attack Vector

#67

Earlier quoted context omitted.

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…

And the page 18 of the document is even scarier: the name of the program is not even displayed -- the (bad) logic was obviously "normal users wouldn't know the difference."

Re: Reflected File Download: A New Web Attack Vector

#68
post #45
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…

Wait you dumbasses still use flash?

Re: Reflected File Download: A New Web Attack Vector

#69
post #49

Earlier quoted context omitted.

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

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

Exactly. People that have a hard time understanding this, should maybe spend some time helping non-technical users use their computers and carefully pay attention how they interact with it.

Help a friend clean up their adware-infested Win7 laptop. Just show them how to remove unwanted browser extensions, and use PC-decrapifier to mass-uninstall the crapware. Nothing too fancy, because it will take the better part of an afternoon or evening anyway, because 1) these computers will be slow and most importantly 2) you're going to let them do all the clicking and typing (they will learn a lot, even if only more confidence in using their machine).

I don't like doing this because it always takes way more time than I planned, but if you do it right, the speed difference will make them really really happy and thankful for months :)

Anyway the point is, if you pay careful attention, you will first-hand notice all the idiosyncrasies with which non-tech people use their machines. It's fascinating, in a way.

Re: Reflected File Download: A New Web Attack Vector

#70
post #39
post #5

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

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.

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.

Post reply on HN