|
Note: This vulnerability as well as many more can be seen at http://freehost07.websamba.com/greyhats/
MSIE DHTML Edit Control Cross Site Scripting Vulnerability
[Tested]
IEXPLORE.EXE file version 6.0.2900.2180
MSHTML.DLL file version 6.00.2800.1400
Microsoft Windows XP Home SP2
[Discussion]
I appologize for my previous vulnerability (longnamevuln) which, through default sp2 settings, would be
quite useless :). However, I'm sure that this will make up for it.
While looking at the popup block killer by http-equiv, I became interested in the dhtml edit control. I had
a gut fealing that more could be done than simple popup forcing. So I looked into it and surely enough, I did
find something. For the first time (afaik) since sp1, we can, without user interaction (which I hate btw),
inject script into a page that doesnt belong to us :).
While I don't exacly know the specifics of the dhtmled.ocx control, I believe it uses a lot of the same code
from old versions of internet explorer. That might explain why it acts so similarly to internet explorer.
Through my testing, I only found one way to navigate to a page using the dhtml edit control: make it run code
to 1) specify its window name, then 2) open( ) a page using its new name as the target parameter. This will
grab the page and display it in the control. After this, the control is still accessible by its parent, even
Script functions. execScript is what I use to directly inject javascript into the control.
SP2 puts extremely heavy security on the javascript: and vbscript: protocols, apparently rendering them
useless for hacking attempts. However, there are still plenty of ways to make a target run script. Hehe this
is just like to good ol' days of sp1 :)
The example opens http://google.com in the dhtml edit control and attempts to show the location.href and
document.cookie of the page in a message box.
Example at http://freehost07.websamba.com/greyhats/abusiveparent.htm
|
