21–30 of 81 posts
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.
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.
"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…
(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.
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 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.
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.
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…
Correction: this seems to rely almost entirely on the content-type sniffing of the client-side, provided the content-disposition is 'attachment'.
"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…
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.
http://lcamtuf.blogspot.com.au/2014/03/messing-around-with-d...