A short while ago, I decided to prepare a presentation on web vulnerabilities and specifically on XSS attacks. This involved studying the way today’s filtration systems work.

I selected the most popular Russian social networking website, VKontakte.ru, as a test bed. One thing that grabbed my attention was the updated user status system.

The HTML code in the part of the page where users edit their status messages is shown below:

As you can see, filtering is performed by the infoCheck() function. The status itself is located in this string:

What we have here is two-step filtration. The first step is performed when the user enters the status message. The second step involves converting the status message to text and returning it to the page in the shape in which other users will see it.

While the second step definitely works well and it would clearly be impossible to convert to active XSS, things are not as simple where the first step is concerned, so it is that step that we will look at in greater detail.

Predictably, the simple <script>alert()</script> did not work, and the status remained empty. Other ‘script-like’ attempts didn’t work, either – it seems that this particular string is explicitly filtered.

However, the <script> tag is not essential for a script to be executed. The first vulnerability is introduced on the user’s machine by using the <img> tag: by entering the string <img src=1.gif onerror=some_function> as the user’s status, we can get that function to be executed. For example, we can call the function profile.infoSave(), which is called with an empty parameter to clear the status, but use a parameter of our choice. Thus, if we enter <img src=1.gif onerror=profile.infoSave('XSS')>, we get the string “XSS” as our status message:

Another interesting vulnerability associated with the filter is that the tag <A> is not filtered. If we enter <A HREF="//www.google.com/">XSS</A> as our status, we get… a hyperlink clicking on which brings up a status editing window and, a moment later, opens google.com.

As we all remember, XSS = cross site scripting, so I decided to test the next vulnerability using a third-party website with a script loaded on it. In addition to the tags mentioned above not being filtered, the <iframe> tag also successfully passed the filter. As a result, entering <iframe src="yoursite.com" width="100%" height="300"> in the status line will produce an iframe which will launch the above-mentioned script loaded on the page. Below is an example of what the iframe can look like:

This is a more serious vulnerability than the other two. One way of exploiting it is by creating a URL to change user status and sending it to the victim user in the hope that the user will click on it. The script will be executed on the user’s page even before the status message is published. This is a classic example of passive XSS.

These vulnerabilities existed from 01 August, 2010 – the time when the new user status system was introduced. We notified VKontakte’s administration on 01 March, 2011 and the vulnerabilities were closed on 03 March.

There is a new and live XSS vulnerability being exploited right now in Orkut – Brazil’s favorite social network, which happens to be a Google-owned property. More than 26 millions Brazilians have Orkut profiles. In less than 12 hours after being discovered and being exploited the XSS vulnerability affected more than 180,000 users and more profiles are being compromised as we speak.

No user interaction is required to be compromised – you simply need to log into your profile and go visit a friend’s profile. If you have a small picture of the Brazilian flag in your scraps section and so does your friend:

You will be infected. When infected, this message calls an external javascript file and runs it:

Everyone who is infected with this script is being added silently to a community called “Infected by the Virus of Orkut”, which registers all of the users compromised by this new vulnerability:

In Portuguese the description of the community says: “Você chegou aqui através de uma falha grave no orkut. A falha já foi comunicada ao Google e deve ser corrigida em breve. A comunidade só tem o intuito de forçar uma correção mais rápida".

English translation: "You arrived here by a serious security vulnerability in Orkut. This vulnerability has already reported to Google and must be fixed soon.This community only has the intention of forcing a quicker fix"”.

How did this all start? The author of this community is supposedly using this XSS vulnerability to force Google to fix it quickly. This is not the only such case we have seen - in December 2007 a similar case affected more than 660,000 Orkut users in few hours.

We suggest that you avoid Orkut and/or turn off the JavaScript in your browser until Google patches this vulnerability.

But if you are a Kaspersky customer you are already protected - the javascript file exploiting this XSS and future variations is detected and blocked in all our products as Exploit.JS.Orkut.f. So just make sure your databases are updated before you go to Orkut.

Update 2: after more than 400,000 users affected, Google fixed the XSS in this saturday night.

A new Twitter XSS exploit was identified in the wild as it started to be used by cybercriminals overnight.

The malicious JavaScript payload that's being distributed is rather simple. It uses an XSS (Cross-Site Scripting) vulnerability to steal the cookie of the Twitter user, which is transferred to two specific servers. Essentially, any account which clicked on the malicious links is compromised.

But how many people clicked the link? The bit.ly statistics for one of the malicious links are more than worrying, showing an alarming number: more than 100.000.

All clues point to Brazil as the originating country for this attack. First, the 2 domain names used to get the stolen cookies are registered under Brazilian names. More than that, one of them is actually also hosted in Brazil. Last, but not least, just take a look at the tweet used in distributing this malicious payload:

Pe Lanza da banda Restart sofre acidente tragico - it's a short tweet in Portugese about the Brazilian pop band Restart suffering a "tragic accident". I'd say there's not much doubt about the origins of this attack.

We've added detection for the malicious scripts as Exploit.JS.Twetti.a and also made sure the URLs used in this attack are blacklisted. We are currently working on taking down the malicious URLs and minimizing the damage as much as possible. Twitter along with other significant industry peers have of course been notified.

UPDATE: Twitter has confirmed the vulnerability is fixed now.

On Saturday an alert went out about a new Twitter worm.

Could this have been another XSS-Worm? Upon clicking the link users would see the following:

However that's not all that happens. Covertly a connection is made to another server that will result in a malicious PDF being downloaded. This PDF contains a flurry of exploits.

If exploitation is successful a file will be downloaded. Given the reports one would expect this to be the worm. However, it turned out to be yet another Fraudware installer. This time a fake program called "System Security" is being promoted.

During the research process I was not able to detect any worm-like component. There's another very plausible explanation for the worm-like activity we've seen.
About a week ago there was a pretty high-profile phishing attack targeted at Twitter. It was only going to be a matter of time before we would see the abuse of the stolen accounts one way or the other.

Most likely the cyber criminals behind this attack simply used the stolen credentials of those phished accounts to tweet the messages. From my perspective this would also have been the more likely scenario rather than using a worm.

This attack is very significant. It would seem that at least one criminal group is now exploring the distribution of for-profit on Twitter. If the trends we've seen on other social platforms are any indicator for Twitter then we can only expect an increase in attacks.

Today we've seen a new variant of Net-Worm.JS.Twettir going around on Twitter. Kaspersky products detect it as Net-Worm.JS.Twettir.h.

This worm appeared right after an announcement that a security firm has hired the author of the original worm. Not wanting to stray too much from the intended topic of this blog post I'll only say that we feel very strongly that this is an extremely bad move.

This new variant selects a message to tweet from a pool of choices. Some of them reference big twitter names, others simply talking about "Mikeyy", the original author.

One of the messages also asserts that this XSS vulnerability only affects Internet Explorer users. At the time of writing, we can confirm only that the latest version of Firefox (3.0.8) is indeed not vulnerable to this exploit.

What's interesting about this is that the XSS script is hosted on the same domain as the original worm. That would imply that Mikeyy has been at it yet again. Rather odd for someone who just landed a security job, isn't it?

On the other hand, there are rumors floating about that “Mikeyy’s” machine along with his passwords is compromised. So it might be someone else after all.

For all of you tweeters out there who love to click on profiles and URL - your best bet is to use the latest version of Firefox with the noscript plugin available at noscript.net. This should provide reasonable protection from new XSS-worms which Twitter may be facing at this point in time.

We'll keep monitoring the situation and keep you posted.

Now these worms come as little surprise. Twitter has had a number of security issues recently.

The worm is not particularly complex in the vulnerability it is exploiting.
The original author? A bored 17 year old who had nothing better to do over the Easter weekend.

A story like this is clearly reminiscent of the malware landscape ten years ago – the malware is noisy and annoying rather than a serious threat as no user credentials are currently being stolen.

Yesterday, while watching what was going on Twitter I noticed a lot of tweets about twitzap.Suspecting this was a worm I did some digging and found that it wasn't.It turned out this was a separate service with a nice "promote us" button that made a Twitter user post a status update promoting the service.
What do you have to do to activate it? Click on the button – and it sends a promotional update to your Twitter account!

A quick search on the net revealed that this service only started receiving attention this Monday.

Given the XSS worm, I think the promotion of this service could have been a whole lot better.

Also in response to the new XSS-Worms some web services have been created to supposedly protect the user. But again, these services ask users to just click on a link – while asking their friends to do the same. So your Twitter account gets updated, but if the service happens to be malicious, you could be sending off your account details to who knows where!

It's actually this part of the social networks that scares me much more than an XSS-worm.

Web sites left and right that integrate with Twitter - and other networks – are asking users to use their services.Many people seem to be making use of them without too many questions, and without any proper means of verifying the integrity of these services.

What does this mean? Users are basically being trained to give up their credentials just like that.

XSS-Worms are not the real problem here, folks. We're basically growing a new set of (extra) vulnerable users which will be more vulnerable to attack simply because they’re not asking any questions.

Quite a long time ago I contacted Microsoft regarding what I thought was a XSS vulnerability in IE.

Microsoft disagreed, preferring to call it a 'feature'.

This feature allows javascript embedded into GIF files to be executed under certain circumstances. The javascript may point to an alternate domain (as is the case with XSS vulnerabilities).

And this is what I saw yesterday - a compromised site containing a modified GIF file which exploits this XSS vulnerability.

The GIF file contains an embedded iframe pointing to a malicious site. (Thankfully, the site is currently presenting a 'file not found' error message.)

Here's the GIF:

This is one step more on from today's common web site compromises where some javascript gets added to the main page.

Clicking "view source" doesn't reveal any malicious code – and this makes a quick analysis of the threat more difficult.

Following this discovery we've contacted Microsoft again – hopefully they'll reconsider their position on this issue.