Message-ID: <008e01c8b1f3$975e0630$c61a1290$@com>
Date: Fri, 9 May 2008 12:41:54 -0400
From: "Jediah" <jediah@...iodice.com>
To: <full-disclosure@...ts.grok.org.uk>
Subject: Download Vulnerability in Internet Explorer 6 & 7


This vulnerability may have limited destructive powers based on the current
description that I've come up with - it is also possible that someone else
with more time on their hands can come up with other variants that would be
a bit more destructive. It does require bad habits on both the
web-administrators and the users side - but isn't that often the center of
vulnerabilities?


Web application Scenario:

1.Website accepts file uploads from users 
2.Website follows recommended security for file uploads including two that
are important to this discussion:
a.The document being uploaded is not stored in a directory that is
accessible by Web Users (it is served up from a back end process when
requested by users) 
b.The users do not have execute permissions on the documents that are stored
on the server (only permissions that are granted for download)

Attack scenario:

1.Attacker uploads HTML file to site
a.This HTML file contains:
i.Copy of logon form from the website, including relative pathing to website
for cascading style sheets, images, etc.
ii.Attacker modifies form post location, so form posts go to a site the
attacker controls 
2.Website provides other users the ability based on their authorization to
download and view the HTML file that the attacker uploads

IE Response:

1.Authenticated users click on HTML file and are presented with the download
popup, file is streamed from a repository other than a web accessible
location from the server 
2.When prompted, users choose "Open"  from the download popup, allowing
default application to open the downloaded file 
3.IE opens the HTML page in the current IE window (this has been verified
against both IE 6 and IE 7), but IE does not change the security zone, or
the URL of the IE address bar, so now the user sees the (modified) logon
page of the site, but is given no indication (apart from opening and
reviewing source code) that this page is not hosted on the site they are
visiting 
4.IE, thinking the HTML page has been served up from the remote site in the
normal use case, also resolves all relative paths (cascading style sheets,
images, etc) from the server 
5.User - while thinking it odd that they are being prompted to logon again,
looks and sees they are still in the same security zone, and URL of their
trusted website 
6.User logs on again (sending credentials to the attacker), and attacker
does anything he wants with the post (serve up the actual file, redirect
back to the original site, etc.)


Contrast IE's response to FireFox's response.

FireFox response:

1.Authenticated users click on HTML file and choose to download, when
prompted, users choose "Open"  for HTML file, allowing default application
to open the downloaded file 
2.Default browser (or alternate browser) opens the HTML page from local
internet cache after download complete 
3.Browser does not resolve relative paths, and URL is changed to show it's
running from a local location 
4.Attack is obvious, User doesn't proceed.



Perhaps I've missed something that makes this of no use to an attacker, and
perhaps I've missed something that makes this an even bigger problem than I
realized - but none-the-less, here it is.

r/Darth Jedi


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists