09 Mar XSS Vulnerabilities in Russian Social Networking Site ‘VKontakte’ Alexander Antukh
26 Sep Another live XSS vulnerability Fabio Assolini
21 Sep Live Twitter XSS Georg 'oxff' Wicherski
07 Sep Twitter XSS in the wild Stefan Tanase
01 Jun The Twitter worm that isn't Roel
Join our blog
You can contribute to our blog if you have +100 points. Comment on articles and blogposts, and other users will rate your comments. You receive points for positive ratings.
Today, Microsoft released a set of eight security Bulletins (MS13-059 through MS13-066) for a broad variety of vulnerable technologies and exploit categories. The critical vulnerabilities are not known to be exploited publicly at the time of Bulletin release. The more interesting Bulletins this month address RCE and EoP vulnerabilities in Internet Explorer, Windows components, and yet again Exchange/OWA components licensed from Oracle. Also included in this month's release are fixes for RPC, kernel drivers, Active Directory, and the networking stack.
MS13-059 is the priority update to roll out across Windows clients, as it fixes nine critical memory corruption vulnerabilities (that look like use-after-free to me) in IE6, IE7, IE8, IE9, IE10 and even IE11 preview on Windows 8.1 preview, along with XSS due to flawed Kanji font handling and flawed code in the "Windows Integrity Mechanism", which is used for sandboxing apps like Internet Explorer, Adobe Reader and Google Chrome. On Windows server, the maximum severity is "Moderate" and doesn't effect "Server Core" installations at all. Admins need to refer to the severity ratings and maximum impact table to prioritize server patch deployments, but those that need to prioritize patch deployments probably shouldn't surf the web from these types of systems anyway.
MS13-060 corrects code in the Unicode Scripts Processor implementing OpenType font handling, a format developed by Microsoft and Adobe over the past decade built on top of the TrueType format, in USB10.dll. This dll is used by Windows and all sorts of third party applications to handle right-to-left scripts like Arabic and Hebrew, and other complex fonts like Indian and Thai scripts too. The vulnerability is a user mode vulnerability that effects only Windows XP SP 2 and 3 (64 bit too) and Windows 2003 versions. These types of systems continue to be widely deployed, especially in government and critical infrastructure systems around the world. Exploits may be delivered via spearphish, as in the Duqu incident, or via a web page for a browser like Internet Explorer, as in Duqu copycat malcode like the Blackhole exploit pack that continues to be widely distributed and highly active.
Another interesting update includes MS13-061 that patches code in third party components built by Oracle and licensed by Microsoft for Outlook Web Access on Exchange Server 2007, 2010, and 2013. Applying the patch will not require a system reboot, but it will restart related Exchange services. The interesting thing about this critical set of issues is that they enable exploitation of the WebReady Document Viewing and Data Loss Prevention features on OWA for code execution not on the client system, but on the server itself with LocalService credentials. So a client system browsing code sent to their email account can remotely execute code on the server in the service's context, which is very problematic.
Please review the set and update ASAP. While most of the vulnerabilities this month were privately reported, these present high risk opportunities and the Exchange issues and exploitation are publicly known.
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:
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.
Update 2: after more than 400,000 users affected, Google fixed the XSS in this saturday night.
It's one of these days where I just had one of these "Oh no..." moments when I logged into my Twitter account and suddenly a message box with my cookie popped up.
Update 3 (14:24 CEST): Worm code for this vulnerability has been posted on IRC, making the rounds.
Update 4 (14:36 CEST): Worm is live already...
Update 5 (14:59 CEST): It appears Twitter now properly escapes links, that specific vulnerability seems closed.
Update on Infection Rates (posted by Costin): During the peak of the infection, we noticed roughly 100 posts per second which seemed to be related to the exploit. Thanks to Paul Roberts who pointed out a simple way of looking at the outbreak using Twitscoop:
The graph suggests 93 posts per second, which is not far from the peak we observed.
Although accurate numbers are hard to extrapolate from the existing data, the total number of malicious posts could have easily exceeded half a million.
A new Twitter XSS exploit was identified in the wild as it started to be used by cybercriminals overnight.
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'.
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:
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.