(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.
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.
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.
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.
If you do this, then you become the "go to guy" whenever they have a problem - there is precious little appreciation of the amount of time and effort it takes to clean up a system.
I now claim "it's a specialization" and give out the contact info of local people who do this for a living. After the end-user has to drop a couple of bills every few months to get the dancing gorilla removed, they finally begin to pay attention - otherwise they treat the free advice you gave them as valued at what it cost.
Yes this sort of clean-up job costs at least 3 hours or so (because the machine will be slow).
So I make sure whoever I'm doing it for is present during this time. I'm not going to sit in a cold home office room battling spyware alone (that's setting yourself up for the scenario you describe). It's also not very difficult work (or interesting), so I can easily do it while having a beer or a smoke, chatting, enjoying music, having dinner with my friends. Often that means there's more than one tech-savvy person around, and we can take turns pressing the "Next" and "Are you sure?" buttons, and have some fun making up weird stuff for the occasional "Please tell us why you're no longer using Power Clicky Pro Live Updater" feedback forms. In the mean time I give them some general computer advice (Windows key shortcuts you thought everybody knew), replace Acrobat with SumatraPDF, WinRAR with 7-Zip, etc.
In return I can call upon them for other favours. As I said, often I get the occasional "thank you our laptop is still much faster", months afterwards.
If they won't appreciate what you do, the time you spend applying your knowledge on their problem, then by all means, don't do it. Compare it with a friend helping you out with some technical DIY task at home, applying their knowledge, time and tools for your benefit. Does that automatically make them the "go-to guy" for fixing your sink or toilet? Just make sure people understand what you're doing for them is in the same category.
If you find that hard to explain, or make clear, then don't do it. Good call on giving them contact info for local shops that will do it for money, it's a great alternative, better than nothing. But just like some random friend who knows plumbing or electricity, even if that shop's hourly wage x time spent is perfectly fair (and it's often cheaper than that), I still have a weird feeling telling my friends to pay $75 (or whatever) to get their machine cleaned.
It's basically a multi-uninstall tool, with a sort of crowd-sourced knowledge-base to classify installed programs into two categories "stuff you probably want to remove/don't need" and "everything else".
I like how it's very straightforward and pretty much "does one thing and does it well" (as opposed to being also a registry-cleaner, resident whatnot-shield, defragmentizer, antivirus RAM scrubber, etc etc).
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
Correction: this seems to rely almost entirely on the content-type sniffing of the client-side, provided the content-disposition is 'attachment'.
Has anyone tried this on other browsers?
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."
Content-Disposition: attachment; filename="f.txt"
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.
Yeah, and that's slop in the protocol. If the header was required everything would still work, web sites would just have to fill in the header. What's easier to do, comply with a protocol where your site brakes if you don't, or to have swiss cheese and then make site developers learn a bunch of security best practices and hope they get it right?
Also in there is the good old "this site wants to blah blah" and ask the user to decide. If you have to ask, the answer is "No! fix your site so it's not on the user to decide". Broken certificates? Not my problem, browser should just say "sorry site security is busted" and leave it at that. It's an old debate, but AFIAC there is no debate, only lazyness.
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 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.
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.
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.
"The URI specification 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."
A fairly obscure feature of URIs, apparently Correctly handled by some web servers, but apparently overlooked by most browsers. Argh. Again.
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.
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.
A user can be prompted to update flash or chrome itself and then be served a (somewhat) legitimate looking file from the respective website.
This sounds like an XSS attack against downloaded files as opposed to rendered HTML.
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.
That 2007 commit rolled back to just using slashes.
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.
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)]
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>
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.
...but we all use unbruteforcable passphrases, right?
If that data is the target of the attack, user privileges alone won't help you.