If at first you don't succeed; call it version 1.0
Thursday, 31 January 2008

A patch for the cross-zone scripting vulnerability in Skype is still not available. As I mentioned in my first advisory, Skype renders HTML pages in several dialogs.

One of these dialogs is used by a feature called "SkypeFind". This feature, available from version 3.1, allows Skype users promote and review businesses around the world. Sadly, it could also be used by attackers to own Skype users' machines.

Within this feature any Skype user can add a new business and review an existing business. Skype does a great job sanitizing the data provided in the business item entry, and also the text provided in the user's reviews.

Unfortunately, they forgot to sanitize the full name of the reviewers. So, an attacker can inject a malicious script in his Skype's Full Name, and whenever a victim will view a business which was reviewed by the attacker, in the SkypeFind dialog, the malicious script will be executed in an unlocked Local Zone!

Fortunately for the attacker, it is also possible to open the dialog in a specific business details page from the browser, using the skype: URI handler (e.g. skype:?skypefind ). This means that it is possible for the attacker to create a worm!

The attacker however, must authorize the victim to view the attacker's full name, but this can be easily achieved in the following two ways (thanks pdp for the second suggestion!) :

  1. Interactive bot:
    • The victim enters a malicious website which automatically calls the attacker via Skype. This can be done by using the skype: URI handler (e.g. skype:attacker?call)
    • The attacker's bot intercept the call, and cancels it. Now that the bot has the victim's username, it uses the User.IsAuthorize API call to allow the victim to view the attacker's full name.
    • After a few seconds, the malicious website opens the malicious SkypeFind dialog, and the victim gets owned!
  2. Passive bot:
    • A passive bot is searching the Skype network for active users.
    • For each user the bot uses the User.IsAuthorize API call to allow the victim to view the attacker's full name.
    • When a victim who was authorized visits a malicious website, the malicious SkypeFind dialog will be opened, and the victim will be owned!

I've contacted Skype security team, and they have provided a quick fix for the full name issue.
Unfortunately, this is not enough! I'm worried that there are probably other ways to inject a script to this dialog.
I strongly advised Skype to disable this feature until they provide a patch for the cross-zone scripting vulnerability. For no good reason, they have decided to decline my advice.

Therefore, until a patch is available, my suggestions to Skype users are:

  • Disable the SkypeFind tab. Goto "View" -> "Tab and panels", and uncheck "SkypeFind Tab".
  • Disable the skype: URI handler. This can be done by a registry change, and I recommend it only for power users.
  • Other users who don't want to mess with the registry should uninstall Skype. Having Skype installed without using it will not solve the problem, as the skype: URI handler will automatically open Skype and login!

Zull (Guy Mizrahi) has created a great demonstration video. A better quality video is available here.


Thursday, 31 January 2008 12:35:41 UTC | Comments [1] | Security#
Tuesday, 22 January 2008

[More updates at the end of the post]
As of last Saturday, Skype have disabled adding videos from Dailymotion. They have announced it in their security bulletin.

While this "workaround" was good enough to mitigate the proof-of-concept I provided, it cannot be considered a real workaround that will help secure Skype users, until a patch is available.

For an unknown reason, Skype have decided to leave adding Metacafe videos through its' "Add video to mood" and "Add video to chat" features. So basically, injecting a script to Metacafe video's metadata (Title, Description, etc.) should be - again - enough to execute code from remote.

So, I've tried a simple script tag injection to the metadata of a video, and failed because Metacafe are stripping HTML tags from the metadata. I did that by submitting a video through the Metacafe website.

But then I saw a little link on the upper right of the website, suggesting to download "Metacafe pro", which is the software version of the Metacafe website. So, I did, and surprise, surprise... Submitting a video with HTML and script tags through the "Metacafe pro" application does not filter the tags!

After few tweaks (Thanks Golan!) I was able to create a fully working proof-of-concept exploit.

The more troubling issue here is that this PoC can actually be triggered by simply visiting a website, or clicking on a link from your Instant Messaging application. Which basically means that this vulnerability is now wormable!

This is why I've decided not to publicly disclose the proof-of-concept, nor to show a video that might disclose too much information.

I've sent the PoC to Skype's security team, and have been told that they are going to release a patch for this vulnerability ASAP. Furthermore, they have now disabled the Metacafe tab too - which means, no more adding videos in Skype until a patch is released...


[UPDATE 23-JAN-2008 00:55 GMT+2:00] For no good reason, Skype have decided to bring back the Metacafe videos feature. The proof-of-concept still works. So, as this is a wormable vulnerability, my advice for you guys is to downgrade your Skype to a version that does not support adding videos (before v3.5.0), or even better - Uninstall Skype, and use an alternative client!

[UPDATE 23-JAN-2008 11:30 GMT+2:00] After talking with the Skype security team, it seems like bringing Metacafe back was probably a malfunction, and surely was not on purpose. They are doing their best to disable it again. I for one can say that on some of my computers Metacafe is now disabled. Let's hope they'll disable it everywhere, at-least until a patch will arrive.

Tuesday, 22 January 2008 16:15:28 UTC | Comments [1] | Security#
Thursday, 17 January 2008

Skype uses Internet Explorer web control within the application to render internal and external HTML pages. Examples for this pages are the "Send money via PayPal" dialog, or "Add video to chat" dialog.

Recently, I've discovered that Skype is running this web control in Local Zone. The more problematic issue here is that Skype runs the HTML pages is a not-locked Local Zone mode, the same as AOL's AIM does in the chat message window.

This means, that if it is possible to inject a script to any of those pages, it is possible to execute code on the user's machine. pdp suggested that AirPwn can be used for that, and I can't do more than agree with him.

Today, Miroslav Lučinskij posted to Full-Disclosure that it is possible to inject a script to the "Add video to chat" dialog via the Title field of the DailyMotion movie information. He called this a Cross-Site Scripting vulnerability, but it is actually a Cross-Zone Scripting vulnerability, because the script runs in IE's Local Zone instead of the Internet Zone.
This basically means that an attacker can now upload a movie, set a kewl popular keyword (e.g. "Paris Hilton"), and own any user that will search for a video with those keywords through Skype.

I've tested this with the latest version of Skype - v3.6.0.244. Prior versions may also be affected.

Until the Skype guys fix this vulnerability, I recommend that you stop searching for videos in Skype.

I've created a proof-of-concept which executes the calculator when searching for "calc test" in Skype's "Add video to chat" dialog.
The following video demonstrates the proof-of-concept:


Thursday, 17 January 2008 20:15:24 UTC | Comments [8] | Security#
Tuesday, 15 January 2008

After reading the great post, I must say, "Hacking the Interwebs" by the GNUCitizen team, I thought that it would be a waste not to try and find a way of attacking UPnP without the Flash requirement.

Basically, what needs to be achieved in order to attack the device through UPnP over HTTP is to:

  1. Be able to send a "POST" request to the device's IP address.
  2. Be able to set the "SOAPAction" header of the "POST" request.

Now, because we can't set headers in a simple HTML form submission, we can instead use XmlHttpRequest. But,  becuase the device's IP address is of-course different from the attacker's web site IP address, the same origin policy comes into play.

If we'll disregard that the device might have XSS vulnerabilities, another way of breaking the same origin policy is DNS pinning.

I was about to start and investigate whether XmlHttpRequest and DNS pinning can be used to attack UPnP enabled devices, just to find out that someone else has already done this research.
And this was done almost a year ago!

Yet another reason to shout: DISABLE UPnP NOW!

Tuesday, 15 January 2008 10:16:13 UTC | Comments [0] | Security#
Sunday, 13 January 2008

Evasive attacks are everywhere. Malicious attackers are using methods like blocking multiple visits to an exploit, or serving specific exploits per browser, in order to minimize the detection of the attack by the security vendors.

Another way to evade an attack is patch detection. Why try to exploit a machine which has a patch for a vulnerability already installed?

This method can be easily implemented using known local file enumeration attacks. For example, in Internet Explorer, using the res protocol handler, it is possible to detect local files by loading local image resources, or by using timing attacks.

Most installed patches are saving an un-installation setup program. The path to this program is usually: "\WINDOWS\$NtUninstallKBXXX$\spuninst\spuninst.exe", where XXX is the knowledge base number of the patch.

So, for example, if an attacker would like to know if he should serve an exploit for the MDAC vulnerability, he can detect if the client has the MS06-014 patch installed. According to the MS bulletin, 911562 is the knowledge base number of this patch, so he can now check if the file "\WINDOWS\$NtUninstallKB911562$\spuninst\spuninst.exe" exists. If this file does not exist, he will then serve the exploit. If the patch does exist, he will not serve the exploit, and by that he will minimize the probability of being detected.

There are already proof-of-concepts for local file enumerations out there, so I see no reason for providing another one. As I've already mentioned, the PoC's can be easily modified to implement patch detection.


P.S. - Patch detection can also be used for legitimate causes. I encourage you all to download Secunia's PSI (Personal Software Inspector), and check whether you have an unpatched software installed on your machine. Although, now that there is a way to detect patches from remote, we might see an online version of PSI soon :)

Sunday, 13 January 2008 17:35:41 UTC | Comments [0] | Security#
Saturday, 05 January 2008

Due to some questions I received regarding my latest post on the dialog spoofing vulnerability in Firefox, I've decided to put a list of frequently asked questions.


Q: Does this vulnerability affect Mozilla Firefox 3?

A: Yes. It does affect the latest available beta of Firefox 3.


Q: Is there an open ticket for this issue at Mozilla's Bugzilla?

A: According to Window Snyder's blog post, this bug can be tracked here: https://bugzilla.mozilla.org/show_bug.cgi?id=244273


Q: Why should Firefox sanitize single-quotes and spaces? Mozilla follows the standards, and the RFC says the Realm value is a quoted-string.

A: Nowhere in my advisory I said that Mozilla does not follow the standards in this case. But, because of the way they implement dialog, it is possible to create fake double quotes, and by using multiple spaces it is possible to fake a new line. I also did not suggest to sanitize the single-quotes and spaces as a solution. In my opinion, a better solution would be to display the server name before the realm value, or even in a different field or in the title of the dialog.


Q: Is there a proof-of-concept available for this vulnerability?

A: While I did not provide a proof-of-concept for this issue, it is very easy to follow the instructions on my advisory to create one. In fact, Alex of bitsploit.de has already created a good demonstration on his blog.


Q: How did you discover this vulnerability?

A: I've found a similar vulnerability in an early version of Firefox (back when it was still called Firebird). Lately, Zull's forums (Hebrew) were attacked by a basic authentication phishing attempt. This attack included just the server name of Zull (hacking.org.il) in the realm value. I then remembered my old finding, and tested it in the new version of Firefox, just to find out that there is a much easier way to exploit it.


Q: How do other browsers display the Basic Authentication page?

A: The guys at Kriptopolis blog have published some screenshots of Internet Explorer, Firefox, Opera and Konqueror displaying a spoofed Basic Authentication dialog.


Q: I'm using (Fill in product name)-Anti-Phishing tool. Am I protected against this vulnerability?

A: While anti-phishing tools may help in some cases, most of them will block the phishing  page only after the page is displayed, or will just display the currently visited domain in a toolbar. This means that some of the anti-phishing tools may not be able to protect you against this vulnerability, as the phishing attempt will occur before a page in the attacker's domain will be displayed.


Q: Are there any other attack vectors?

A: I'm sure that there are other attack vectors which can be used to attack this vulnerability. For example, Alex of bitsploit.de has found that if you have the FasterFox extension installed, an attacker can just put a link on a trusted page. FasterFox will then use its' pre-fetching feature to try and cache the attacker's link which will trigger the spoofed basic authentication dialog.


I hope that these answers make things more clear. If you have any other question, don't hesitate to comment or just send me an email.

Saturday, 05 January 2008 12:46:22 UTC | Comments [0] | Security#
Wednesday, 02 January 2008


Mozilla Firefox allows spoofing the information presented in the basic authentication dialog box. This can allow an attacker to conduct phishing attacks, by tricking the user to believe that the authentication dialog box is from a trusted website.


Affected versions

Mozilla Firefox v2.0.0.11.
Prior versions and other Mozilla products may also be affected.


Technical details

Mozilla Firefox displays an authentication dialog, whenever the visited web server returns 401 status code, and the "WWW-Authenticate" header. In order to specify basic authentication, the "WWW-Authenticate" header should have the value [Basic realm="XXX"] (without the brackets). The Realm value, which in this case is XXX, will be displayed in the authentication dialog window.

While Firefox does not display the characters in the "WWW-Authenticate" header Realm value after the last double-quotes ("), it fails to sanitize single-quotes (') and spaces. This makes it possible for an attacker to create a specially crafted Realm value which will look as if the authentication dialog came from a trusted web site.




There are at-least two possible attack vectors:

  1. An attacker creates a web page with a link to a trusted website (e.g. Bank, PayPal, Webmail, etc.). When the victim clicks on the link, the trusted web page will be opened in a new window, and a script will be executed to redirect the new opened window to the attacker's web server, which will then return the specially crafted basic authentication response.
  2. An attacker embeds an image (pointing to the attacker's web server, which will return the specially crafted basic authentication response) to:
    1. A mail which will be sent to a webmail user.
    2. RSS feed which will be consumed by a web RSS reader.
    3. A forum/blog/social network page.


A video which demonstrates the first attack vector can be found on YouTube. A better quality video can be download from here.

A video of a real live attack on a forum, which used basic authentication but without exploiting the vulnerability, can be found on Zull's weblog (Hebrew).


Suggestion / Workaround

Until Mozilla fixes this vulnerability, I recommend not to provide username and password to web sites which show this dialog.

[UPDATE:] Due to some questions, I've put a list of frequently asked questions.


Wednesday, 02 January 2008 22:15:57 UTC | Comments [9] | Security#
Send me an Email
Follow me on Twitter
RSS Feeds
Admin Login
Sign In
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.