Well, today we've found out that the creater of the MySpace Samy worm has been sued by MySpace and sentanced: http://www.scmagazine.com.au/news/45262,myspace-superworm-creator-sentenced-to-probation-community-service.aspx
I'm honestly lost for words, that comes as quite a shock to me.
Now clearly he has done something wrong (and now it seems - illegal), but I don't think anyone expected this. Especially considering that while it did spread, it was completely non-malicious.
For the moment I'm safe since I've never attacked MySpace, but frankly, I'm just worried that they're going to come after people who have disclosed vulnerabilities in MySpace next.
Showing posts with label MySpace. Show all posts
Showing posts with label MySpace. Show all posts
Saturday, February 03, 2007
Tuesday, January 30, 2007
MySpace doesn't understand browsers (RCSR info)
You know what I hate? Advisories without enough info to verify a bug or PoC code. For example: http://www.info-svc.com/news/01-29-2007/myspace/ provides no information to anyone about what the nature of the issue is, or anything, it just says there is an issue, and of course once they do disclose something there is no proof that they did actually find something. And even more than that; I honestly don't care about people declaring that they've found security issues without giving specifics.
Anyway, I thought I'd go have a look myself, and here is a little snippet which works in both IE and Firefox;
Whether this is what Chapin Information Services found is unclear since they didn't release anything, but what is clear is that MySpace clearly understand the Non-Digit-Non-Alpha issue extends to all attributes, nor do they seem to understand that IE also allows grave accents (`) to be used instead of (single or double) quotes.
I really don't understand how many times they need to fix these issues before they begin to understand them.
Anyway, I thought I'd go have a look myself, and here is a little snippet which works in both IE and Firefox;
<input type_="password" type=`password`>Whether this is what Chapin Information Services found is unclear since they didn't release anything, but what is clear is that MySpace clearly understand the Non-Digit-Non-Alpha issue extends to all attributes, nor do they seem to understand that IE also allows grave accents (`) to be used instead of (single or double) quotes.
I really don't understand how many times they need to fix these issues before they begin to understand them.
Labels:
MySpace,
RCSR,
Security (All),
Web App Sec
Sunday, December 24, 2006
MySpace Non-Alpha-Non-Digit XSS 0day
It seems that MySpace has finally understood the issue here, which is good news, but the way their filter is written is working against them, or at least thats what I'm guessing from the results I'm getting.
Anyway, here's the exploit:
As you can see if you run that moz-binding is changed to .., and we are left with the following:
So from this I think we can quite safely assume that they have a few separate modules which have their go at the code in order, and if something gets changed to something dangerous, but the module that would filter that particular dangerous code out has already run (the non-alpha-non-digit filtering module), then the code is allowed through.
Isn't black box auditing fun? You end up making guesses that are quite often so very wrong but fit your results, :p.
Anyway, here's the exploit:
<body onLoadmoz-binding="alert('XSS');">As you can see if you run that moz-binding is changed to .., and we are left with the following:
<body onLoad..="alert('XSS');">So from this I think we can quite safely assume that they have a few separate modules which have their go at the code in order, and if something gets changed to something dangerous, but the module that would filter that particular dangerous code out has already run (the non-alpha-non-digit filtering module), then the code is allowed through.
Isn't black box auditing fun? You end up making guesses that are quite often so very wrong but fit your results, :p.
Labels:
Firefox,
MySpace,
Security (All),
Web App Sec,
XSS
Sunday, November 05, 2006
More MySpace XSS
I don't know whether to feel sorry for MySpace, or whether to laugh. The amount of XSS holes in MySpace is nothing short of outstanding.
And the sad thing is they've clearly tried to fix as many things as they've been able to find, but some things have fallen just short.
Anyway, the flaw I found this time around is that MySpace doesn't know that you can have an underscore (_) between an attribute name and the equals sign, and have it being valid, like so: (Note: This only works on Firefox)
But the interesting thing is that they have got a regex which dissallows everything which looks like on*= (obviously it doesn't look anything like that, but I'm not going to bother trying to write regexs), and yet they've done it in such a way that they need to know about what characters are allowed, essentially creating ablacklist of chars which they won't let you use between an attribute name and an equals sign. Why anyone would create a blacklist for that amazes me.
And the sad thing is they've clearly tried to fix as many things as they've been able to find, but some things have fallen just short.
Anyway, the flaw I found this time around is that MySpace doesn't know that you can have an underscore (_) between an attribute name and the equals sign, and have it being valid, like so: (Note: This only works on Firefox)
<body onLoad_="alert('XSS');">But the interesting thing is that they have got a regex which dissallows everything which looks like on*= (obviously it doesn't look anything like that, but I'm not going to bother trying to write regexs), and yet they've done it in such a way that they need to know about what characters are allowed, essentially creating ablacklist of chars which they won't let you use between an attribute name and an equals sign. Why anyone would create a blacklist for that amazes me.
Labels:
Firefox,
MySpace,
Security (All),
Web App Sec,
XSS
Friday, October 27, 2006
Myspace XSS Fragmentation - Again
Well, as Dark Reading reported I believed that the patch MySpace implemented was near-sighted, and that it was possibly vulnerable to more XSS Fragmentation attacks. And it is.
(The following rewritten for clarity. 28/20/06 11PM GMT)
===========================
MySpace XSS Vulnerability 0day
Released 28/10/06
by kuza55 of w4ck1ng.com
===========================
Contents:
1.0 Introduction
2.0 Analysis
2.1 MySpace's Fix
2.2 Other XSS Fragmentation Attacks
3.0 PoC
4.0 Final Notes
===========================
1.0 Introduction
===========================
The vulnerability explained here is an XSS Fragmentation attack. Breifly, and XSS Fragmentation attack is one which works by placing 2 seperately harmless pieces of HTML into two different input field which are rendered on the same page, which when rendered join to create a dangerous attack vector. More details, along with the previous MySpace attack, can be found here: XSS Fragmentation Attacks + Myspace 0day
MySpace found about the vulnerability in the above link and implemented a 'fix', it hasn't held.
===========================
2.0 Analysis
===========================
This section should explain what MySpace did, and why other Fragmentation attacks don't work.
===========================
2.1 MySpace's Fix
===========================
This section assumes you already know about the previous vulnerbaility.
Anyway, the fix that MySpace implemented altered their event handler stripping code, which previously removed event handlers if they were inside a tag. They changed it so that it also removed all event handlers after a single quote, no matter if it was in a tag or not. And while it addressed the PoC code in my earlier post, they did not implement the recomended fix, and now again find themselves vulnerable.
The reason this is not enough is because there are considerably more XSS attack vectors than the simple one I used. They range from the simplest (using other encapsulation characters - as this attack does) to using style and other attributes and tags to execute javascript.
===========================
2.2 Other XSS Fragmentation Attacks
===========================
Now, it would have been considerably more interesting to come out with a completely different XSS Fragmentation attack, but sadly that is not possible due to the way MySpace's filter works.
One of the requirements for being able to execute an XSS Fragmentation attack is that the filter must be stateful (or contextual, or however you want to describe it), in that it will allow things that are malicious under some circumstances to be included if they are judged to be being inserted in safe circumstances.
The only part of MySpace's filter which does this is the event handler code. All th other vectors which could be used like javascript in image tags, or javascript in URLs for background images, etc, are all filteredout wherever they are. For example if you type "moz-binding" in any input field it is automatically filtered out, the same goes for "expression (", "javascript:", "data:" and several others. In effect this stops XSS Fragmentation attacks in these altogether. And while this seems like its is not a very good solution because it possible for users to need to type those words normally, thats the way its been done, and no-one is complaining.
===========================
3.0 PoC
===========================
This PoC is almost identical to the previous one, except the single quotes (') are changed to grave accents (`). Insert these 2 separate pieces of code into 2 separate input fields: (Note: This only works on IE and Netscape 8.1, because other browsers don't understand grave accents as encapsulation chracters for HTML tag attributes.)
===========================
4.0 Final Notes
===========================
Well, what can I say? I explained a fix, they didn't use it, they ended up being vulnerbale again, what a surprise.
(The following rewritten for clarity. 28/20/06 11PM GMT)
===========================
MySpace XSS Vulnerability 0day
Released 28/10/06
by kuza55 of w4ck1ng.com
===========================
Contents:
1.0 Introduction
2.0 Analysis
2.1 MySpace's Fix
2.2 Other XSS Fragmentation Attacks
3.0 PoC
4.0 Final Notes
===========================
1.0 Introduction
===========================
The vulnerability explained here is an XSS Fragmentation attack. Breifly, and XSS Fragmentation attack is one which works by placing 2 seperately harmless pieces of HTML into two different input field which are rendered on the same page, which when rendered join to create a dangerous attack vector. More details, along with the previous MySpace attack, can be found here: XSS Fragmentation Attacks + Myspace 0day
MySpace found about the vulnerability in the above link and implemented a 'fix', it hasn't held.
===========================
2.0 Analysis
===========================
This section should explain what MySpace did, and why other Fragmentation attacks don't work.
===========================
2.1 MySpace's Fix
===========================
This section assumes you already know about the previous vulnerbaility.
Anyway, the fix that MySpace implemented altered their event handler stripping code, which previously removed event handlers if they were inside a tag. They changed it so that it also removed all event handlers after a single quote, no matter if it was in a tag or not. And while it addressed the PoC code in my earlier post, they did not implement the recomended fix, and now again find themselves vulnerable.
The reason this is not enough is because there are considerably more XSS attack vectors than the simple one I used. They range from the simplest (using other encapsulation characters - as this attack does) to using style and other attributes and tags to execute javascript.
===========================
2.2 Other XSS Fragmentation Attacks
===========================
Now, it would have been considerably more interesting to come out with a completely different XSS Fragmentation attack, but sadly that is not possible due to the way MySpace's filter works.
One of the requirements for being able to execute an XSS Fragmentation attack is that the filter must be stateful (or contextual, or however you want to describe it), in that it will allow things that are malicious under some circumstances to be included if they are judged to be being inserted in safe circumstances.
The only part of MySpace's filter which does this is the event handler code. All th other vectors which could be used like javascript in image tags, or javascript in URLs for background images, etc, are all filteredout wherever they are. For example if you type "moz-binding" in any input field it is automatically filtered out, the same goes for "expression (", "javascript:", "data:" and several others. In effect this stops XSS Fragmentation attacks in these altogether. And while this seems like its is not a very good solution because it possible for users to need to type those words normally, thats the way its been done, and no-one is complaining.
===========================
3.0 PoC
===========================
This PoC is almost identical to the previous one, except the single quotes (') are changed to grave accents (`). Insert these 2 separate pieces of code into 2 separate input fields: (Note: This only works on IE and Netscape 8.1, because other browsers don't understand grave accents as encapsulation chracters for HTML tag attributes.)
<body test=`` onLoad="alert('XSS');">===========================
4.0 Final Notes
===========================
Well, what can I say? I explained a fix, they didn't use it, they ended up being vulnerbale again, what a surprise.
Labels:
MySpace,
Security (All),
Web App Sec,
XSS
Saturday, October 21, 2006
XSS Fragmentation Attacks + MySpace 0day
===========================
Fragmentation Is Not Just For The Network
XSS Fragmentation Attacks
Written 18/10/06
by kuza55
===========================
Contents:
1.0 Introduction to Fragmentation Attacks
2.0 XSS Fragmentation Attacks
3.0 MySpace 0day!
4.0 Mitigation
5.0 Final Notes
===========================
1.0 Introduction to Fragmentation Attacks
===========================
At the simplest level, fragmentation attacks are possible when several fragments, which are by themselves not a security risk and can therefore be allowed to pass through a filter or firewall, but when the fragments reach their destination the fragments are combined and produce something dangerous.
Fragmentation attacks are usually seen in relation to the network/session layer where firewalls and IDSs try to filter packets on how dangerous they are deemed to be, they are also used to sometimes fool those same devices which try to rearrange the packets themselves and read the streams, but that is not what this article is about, this article is specifically about attacks where the whole document is not reassembled and checked.
===========================
2.0 XSS Fragmentation Attacks
===========================
XSS Fragmentation attacks are generally quite rare because they require either multiple sets of input being displayed on the same page which have all gone through the same (or at least a similar) XSS filter and are not tidied up.
Another requirement that must be placed on the XSS filter is that it must be completely dumb in the sense that it simply strips away < and > characters, or it is stateful, and allows certain strings in places where it would not allow them, e.g.
The idea behind XSS fragmentation attacks is to have your normally non-dangerous code (e.g. onload="alert('XSS');") placed in a dangerous position.
The simplest place to get your code placed is inside another tag and that is the example I'll go with now.
===========================
3.0 MySpace 0day!
===========================
The example I'll be using is a MySpace 0day I discovered. First of all I’ll give a quick explanation of the system MySpace has. You are not just given a single field to enter your profile into, you are given several fields about yourself, who you'd like to meet, your interests, etc.
Anyway, the sections we will be attacking are the most closely placed sections on the page, the interests sections (more specifically the Music and Film ones), normally your resulting code looks like this:
The only things separating our 2 fields was this small block of code:
Now what interesting things can we see about that code, well we can see that there are no single quotes there at all, and the only quotes used are double quotes.
So of course we can do something to encapsulate the text in between like so:
and as you can see we have included all that text in between in the test parameter for the body tag we've introduced! And as you can also see we have the ability to write things into our tag in the second input field and it will be automatically place din a dangerous position! So if we make our Films field look like so:
then we have XSS.
This is exactly the attack used on MySpace, and should work on many other sites where input is not cleaned up and dangling tags are allowed to be posted.
Maybe on some sites which allow user comments on articles, etc are vulnerable?
(Note: Wordpress and Blogger aren't vulnerable, see Mitigation)
===========================
4.0 Mitigation
===========================
The root of this problem is that sections are filtered separately, but that problem is one that is probably too time-consuming to bother with as fixing another requirement needed for the attack to work is much easier to fix.
The easiest fix is to use something many filtering systems already do for other reasons: disallow incomplete/unclosed tags. At the moment I see no way of being able to exploit the above idea if the filtering engine does not allow either unfinished tags (like in the example above) or unclosed tags (e.g. <style> tags).
===========================
5.0 Final Notes
===========================
Well, what can I say, this is probably a corner case of XSS filter evasion, but it is a corner case that could possibly be applied to many situations since we seem to be able to post html comments in many places these days. I also hope it helps illustrate how security mechanisms such as XSS filters cannot be used as simple drop in modules, but have to be integrated into your design for them to work effectively.
Sadly/Luckily (depending on your viewpoint) manyfilters such as the ones employed by Wordpress and Blogger force you to have 'neat' HTML so this attack is impossible on those 2 cases.
Fragmentation Is Not Just For The Network
XSS Fragmentation Attacks
Written 18/10/06
by kuza55
===========================
Contents:
1.0 Introduction to Fragmentation Attacks
2.0 XSS Fragmentation Attacks
3.0 MySpace 0day!
4.0 Mitigation
5.0 Final Notes
===========================
1.0 Introduction to Fragmentation Attacks
===========================
At the simplest level, fragmentation attacks are possible when several fragments, which are by themselves not a security risk and can therefore be allowed to pass through a filter or firewall, but when the fragments reach their destination the fragments are combined and produce something dangerous.
Fragmentation attacks are usually seen in relation to the network/session layer where firewalls and IDSs try to filter packets on how dangerous they are deemed to be, they are also used to sometimes fool those same devices which try to rearrange the packets themselves and read the streams, but that is not what this article is about, this article is specifically about attacks where the whole document is not reassembled and checked.
===========================
2.0 XSS Fragmentation Attacks
===========================
XSS Fragmentation attacks are generally quite rare because they require either multiple sets of input being displayed on the same page which have all gone through the same (or at least a similar) XSS filter and are not tidied up.
Another requirement that must be placed on the XSS filter is that it must be completely dumb in the sense that it simply strips away < and > characters, or it is stateful, and allows certain strings in places where it would not allow them, e.g.
<body onload="alert('XSS');"> would not be allowed, but onload="alert('XSS');" would be.The idea behind XSS fragmentation attacks is to have your normally non-dangerous code (e.g. onload="alert('XSS');") placed in a dangerous position.
The simplest place to get your code placed is inside another tag and that is the example I'll go with now.
===========================
3.0 MySpace 0day!
===========================
The example I'll be using is a MySpace 0day I discovered. First of all I’ll give a quick explanation of the system MySpace has. You are not just given a single field to enter your profile into, you are given several fields about yourself, who you'd like to meet, your interests, etc.
Anyway, the sections we will be attacking are the most closely placed sections on the page, the interests sections (more specifically the Music and Film ones), normally your resulting code looks like this:
<tr id=MusicRow><td valign="top" align="left" width="100" bgcolor="#b1d0f0"><span class="lightbluetext8">Music</span></td><td id="ProfileMusic" width="175" bgcolor="#d5e8fb" style="WORD-WRAP: break-word">Music Goes Here!</td></tr><script language="JavaScript">highlightInterests("ProfileMusic");</script><tr id=FilmsRow><td valign="top" align="left" width="100" bgcolor="#b1d0f0"><span class="lightbluetext8">Films</span></td><td id="ProfileFilms" width="175" bgcolor="#d5e8fb" style="WORD-WRAP: break-word">Films Go Here!</td></tr>The only things separating our 2 fields was this small block of code:
</span></td><td id="ProfileMusic" width="175" bgcolor="#d5e8fb" style="WORD-WRAP: break-word">Music Goes Here!</td></tr><script language="JavaScript">highlightInterests("ProfileMusic");</script><tr id=FilmsRow><td valign="top" align="left" width="100" bgcolor="#b1d0f0"><span class="lightbluetext8">Films</span></td><td id="ProfileFilms" width="175" bgcolor="#d5e8fb" style="WORD-WRAP: break-word">Now what interesting things can we see about that code, well we can see that there are no single quotes there at all, and the only quotes used are double quotes.
So of course we can do something to encapsulate the text in between like so:
<tr id=MusicRow><td valign="top" align="left" width="100" bgcolor="#b1d0f0"><span class="lightbluetext8">Music</span></td><td id="ProfileMusic" width="175" bgcolor="#d5e8fb" style="WORD-WRAP: break-word"><body test='</td></tr><script language="JavaScript">highlightInterests("ProfileMusic");</script><tr id=FilmsRow><td valign="top" align="left" width="100" bgcolor="#b1d0f0"><span class="lightbluetext8">Films</span></td><td id="ProfileFilms" width="175" bgcolor="#d5e8fb" style="WORD-WRAP: break-word">'>Films Go Here!</td></tr>and as you can see we have included all that text in between in the test parameter for the body tag we've introduced! And as you can also see we have the ability to write things into our tag in the second input field and it will be automatically place din a dangerous position! So if we make our Films field look like so:
' onLoad="alert('XSS');"></body>then we have XSS.
This is exactly the attack used on MySpace, and should work on many other sites where input is not cleaned up and dangling tags are allowed to be posted.
Maybe on some sites which allow user comments on articles, etc are vulnerable?
(Note: Wordpress and Blogger aren't vulnerable, see Mitigation)
===========================
4.0 Mitigation
===========================
The root of this problem is that sections are filtered separately, but that problem is one that is probably too time-consuming to bother with as fixing another requirement needed for the attack to work is much easier to fix.
The easiest fix is to use something many filtering systems already do for other reasons: disallow incomplete/unclosed tags. At the moment I see no way of being able to exploit the above idea if the filtering engine does not allow either unfinished tags (like in the example above) or unclosed tags (e.g. <style> tags).
===========================
5.0 Final Notes
===========================
Well, what can I say, this is probably a corner case of XSS filter evasion, but it is a corner case that could possibly be applied to many situations since we seem to be able to post html comments in many places these days. I also hope it helps illustrate how security mechanisms such as XSS filters cannot be used as simple drop in modules, but have to be integrated into your design for them to work effectively.
Sadly/Luckily (depending on your viewpoint) manyfilters such as the ones employed by Wordpress and Blogger force you to have 'neat' HTML so this attack is impossible on those 2 cases.
Labels:
MySpace,
Security (All),
Web App Sec,
XSS
Subscribe to:
Posts (Atom)