I had some fun today on Internet Explorer and tested the new IE8 also.
Along, I also compared the new security features to IE7. And there are many
things to say about both versions. Don’t get me started on the usability. To
be honest it looks horrible. Don’t know if you ever noticed it, but
selecting text with your mouse has become a real challenge. It has some
strange selection boundary which results in selecting text you don’t want to
select. Typically Microsoft, onto the security features. You might have
heard or read about a new feature called XDR that allows cross-domain
requests. If not, I’ll explain it here in short detail as well as the other
new features before I’m going into reverse engineering IE7 & IE8.
The XDR object.
xdr = new XDomainRequest();
xdr.open(‘POST’, ‘http://www.mr.bigglesworth.com’);
xdr.send(data);
Now, Mr.Bigglesworth needs to approve the send XDomainRequest header, but we
can approve the call by returning this header to the server that requested
legitimacy:
Response.AppendHeader(“XDomainRequestAllowed”,”1″);
Great, XSS made easy. No need for hijacked iframes, css or images. Nope pure
Javascript does the trick for us. This obviously can bypass many XSS filters
in use today, so if you run one be sure to check this beast out. In my
opinion this will broaden the attack landscape since there are more ways of
launching XSS or spreading worms. The XDR object also returns the
responseText that gives access to:
xdr.onerror
xdr.ontimeout
xdr.onprogress
xdr.onload
xdr.timeout
Useful, if you’re into worms and all.
next, I saw that they implemented cross-document messaging in the form of
the object postMessage. Opera already has it, and from a security standpoint
I don’t trust it. It basically means that a webpage can write into another
page that is running in the same session and on the same host by attaching
an event listener. Spoofing comes to mind, and maybe other attacks as well.
The real question is of course: what is it for? I don’t know.
Implementing it is a breeze:
page 1:
var doc = document.getElementsByTagName(‘iframe’)[0];
doc.contentWindow.postMessage(‘Hello Mr. Bigglesworth!’);
page 2:
document.attachEvent(‘onmessage’,function(e) {
if (e.domain == ‘example.com’) {
if (e.data == ‘Hello Mr. Bigglesworth!’) {
e.source.postMessage(‘Meow! Meow! Dr. Evil!’);
} else {
alert(e.data);
}
}
});
Hash write access.
Another thing that caught my eye was write access to the hash of an url.
Doesn’t sound smart because I don’t want Javascript to manipulate the hash.
Not only can it be annoying, it can lead to security issues depending on the
setting of your website.
Webslices.
If I understand it correctly this feature allows users to favorite the slice
or put it in their feed reader. Better expect some buffer overflows here
since IE8 now listens for a tag called ‘hslice’ on any page it opens, would
be nice to fuzz this feature.
<div class=”hslice” id=”main”>
<h2 class=”entry-title”>All I want are friggin’ sharks with friggin’ lazer
beams attached to their heads! </h2>
</div>
GlobalStorage & SessionStorage.
IE8 jumped on the Mozilla bandwagon and implemented the Session object. I
can’t say I’m that impressed because I as I said before; allowing 10MB of
data to be stored in such object (XML file in IE8) isn’t smart. Let alone
the permanent storage of user tracking details, XSS worms and other
spy-ware.
IE8 GlobalStorage
Reverse Engineering IE7 & IE8.
Okay, this is fun. I’m going to show you a couple things I found out about
Internet Explorer. First off IE8 prevents header forwards on files, pity
this was pretty ‘evil’ in MSIE 7 where it is still possible to change the
location of a file to a local file stored on your computer. It’s very
simple:
And IE7 follows it, whereas IE8 refuses to follow.
The reason why this is dangerous is because of this XML file that contains
system information which we could parse. Useful for reconnaissance and
possibly other attack schemes.
Results in IE7:
– <!– Copyright (c) Microsoft Corporation
–>
– <assembly xmlns=”urn:schemas-microsoft-com:asm.v1″
xmlns:asmv3=”urn:schemas-microsoft-com:asm.v3″ manifestVersion=”1.0″>
<assemblyIdentity
name=”Microsoft.Windows.InetCore.ieframe”processorArchitecture=”x86″
version=”5.1.0.0″
type=”win32″ />
–
–
<assemblyIdentity
type=”win32″name=”Microsoft.Windows.Common-Controls”version=”6.0.0.0″
processorArchitecture=”*”
publicKeyToken=”6595b64144ccf1df” language=”*”
/>
</dependentAssembly>
</dependency>
– <trustInfo xmlns=”urn:schemas-microsoft-com:asm.v3″>
–
–
<requestedExecutionLevel level=”asInvoker” uiAccess=”false” />
</requestedPrivileges>
</security>
</trustInfo>
–
– <asmv3:windowsSettings
xmlns=”http://schemas.microsoft.com/SMI/2005/WindowsSettings“>
</asmv3:windowsSettings>
</asmv3:application>
</assembly>
If you notice correctly I read res://ieframe.dll/24/123 located on
ieframe.dll which is the IEDataObjectWrapper (InProcServer32) I don’t know
why they still allow this to be browsable, because you can resource it on
iframes, XML and as a Javascript source. So I went further to find all data
object in IE8 and a few in IE7.
IE7/8 data sources are:
**res://ieframe.dll/MUI/1
**
**res://ieframe.dll/TYPELIB/1
**
res://ieframe.dll/UIFILE/{20481,20482,20483,20484,20484,20485,20486,20487,3**9
216,41555}
**
**res://ieframe.dll/WEVT_TEMPLATE/1
**
**res://ieframe.dll/Version Info/1
**
**res://ieframe.dll/23/ABOUT.js
**
**res://ieframe.dll/23/ANALYZE.js
**
**res://ieframe.dll/23/ANCHBRWS.js
**
**res://ieframe.dll/23/DOCBROWS.js
**
**res://ieframe.dll/23/ERROR.js
**
**res://ieframe.dll/23/HTTPERRORPAGESSCRIPTS.js
**
**res://ieframe.dll/23/IEERROR.js
**
**res://ieframe.dll/23/IMGBROWS.js
**
**res://ieframe.dll/23/INVALIDCERT.js
**
**res://ieframe.dll/23/ORGFAV.js
**
**res://ieframe.dll/23/PHISHSITE.js
**
**res://ieframe.dll/23/POLICY.js
**
**res://ieframe.dll/23/PREVIEW.js
**
**res://ieframe.dll/preview.dlg (dialog)
**
**res://ieframe.dll/23/PSTEMPLATES.js
**
res://ieframe.dll/24/123 (XML file)
IE6 has a few too:
_**res://mshtml.dll/REGINST/REGINST
**_
_**res://mshtml.dll/23/ABOUT.MOZ
**_
_**res://mshtml.dll/23/BLANK.HTM
**_
res://mshtml.dll/23/REPOST.HTM
As well as others.
These are nice to play with some more, I haven’t digged any deeper yet but
this is quite nice to have a look at. So, enough building blocks to pentest
IE a little further. If you find anything notable, do let me know.
