Summary

Internet Explorer is prone to a Cross-Zone Scripting vulnerability in its “Print Table of Links” feature. This feature allows users to add to a printed web page an appendix which contains a table of all the links in that webpage.

An attacker can easily add a specially crafted link to a webpage (e.g. at his own website, comments in blogs, social networks, Wikipedia, etc.), so whenever a user will print this webpage with this feature enabled, the attacker will be able to run arbitrary code on the user’s machine (i.e. in order to take control over the machine).

Affected version

Internet Explorer 7.0 and 8.0b on a fully patched Windows XP.

Windows Vista with UAC enabled is partially affected (Information Leakage only).

Earlier versions of Internet Explorer may also be affected.

Technical details

Whenever a user prints a page, Internet Explorer uses a local resource script which generates an new HTML to be printed. This HTML consists of the following elements: Header, webpage body, Footer, and if enabled, also the table of links in the webpage.

While the script takes only the text within the link’s inner data, it does not validate the URL of links, and add it to the HTML as it is. This allows to inject a script that will be executed when the new HTML will be generated.

As I said in a previous post, most of the local resources in Internet Explorer are now running in Internet Zone. Unfortunately, the printing local resource script is running in Local Machine Zone, which means that any injected script can execute arbitrary code on the user’s machine.

Proof of Concept

The following is an example of a URL which executes Windows Calculator:

I removed the proof-of-concept of the 0day treasure hunt. A live proof-of-concept can be found at milw0rm.

Solution / Suggestion

I’ve contacted Microsoft last Tuesday. Their last response was that they are looking at an appropriate fix.

Until a patch is available, I suggest not to use the “print table of links” feature when printing a webpage.

[And the winner is: George the Greek]
Today we are celebrating, here in Israel, 60 years of being an independent country. As part of the celebration, I’m releasing a new 0day vulnerability.
One of our customs in Independence day is to play a “treasure hunt” game. In this game there is a treasure hidden somewhere in our beautiful country, and we get mysterious clues that help us find this treasure by traveling to many great sites all over Israel.
In the spirit of this day, I’ve decided not to release full details about this vulnerability yet, but rather play a little “treasure hunt” game.
Somewhere in my blog, I embedded a proof-of-concept code which exploits this 0day vulnerability. The following are some clues that will help you find this 0day treasure:
  1) IE7.0 and IE8.0b users will get pwned.
  2) An interaction with the sploit is needed.
  3) There’s no need to find the post. It’s everywhere.
  4) 404 is the way to go.
  5) Acidus was right! Local resources is the key. 
  6) What else can you do with an anchor? Think out of the box, literally.
  7) Charles Babbage is probably turning in his grave. 
  8) The following screenshot should really help you find the source of the treasure:
    
9) Put the videos together to find the treasure.
        

Every day or two I will add a new clue to this list, in a hope that by next Wednesday someone will eventually find the treasure
Next Wednesday I will release the full technical details of this 0day vulnerability and the proof-of-concept code.
Until then, feel free to comment your findings. The first person who will post a comment with the proof-of-concept code and details on how to use it to exploit the vulnerability will be declared as the winner.
Now, I don’t have any laptop prize to give the winner. But, beside the credit for being the first to find a 0day treasure, I’m willing to offer the winner a free entrance to the IsraCON security conference that will take place in Israel this summer.

Happy hunting!

[UPDATE 08-May-2008] Some of you guys out there are already in the right direction, some are not. I've added 2 more clues.
[UPDATE 10-May-2008] You are getting closer. Pay attention to clue number 6.
[UPDATE 11-May-2008] Yet another clue added.
[UPDATE 12-May-2008] I've added a new screenshot clue. 
[UPDATE 13-May-2008] Last clue added (3 videos). The game will end tomorrow evening (Israel time). You still have enough time to find the treasure.
[UPDATE 14-May-2008 02:30] And we have a winner! details soon...
[UPDATE 14-May-2008 16:15] The winner is: George the Greek. Congratulations! Full technical details of the vulnerability are available here.

I hate when things like this happen. You are too eager to succeed in something, and it eventually fails because of pure bad luck. This exactly what happened to me in CanSecWest's PWN2OWN contest.

I've heard that the second PWN2OWN contest will be held at CanSecWest, a week before the conference began. I couldn't attend the conference this year, but I did want to participate. So, I looked at my vulns arsenal, and picked one that looked pretty neat, was easy to exploit, and met the contest terms: the vulnerable application is AIM (a popular software client), exploiting the vulnerability allows remote code execution, and the neat thing is that the exploiting the vulnerability requires Man-In-The-Middle, which can be easily achieved by using the cool AirPwn tool.

The next thing was to look for an on-site trusted person, with enough skills to build the attack. Fortunately, I've been able to contact Steve Manzuik, who teamed up with AirPwn creator, Bryan Burns, to create the exploit.

Now that we were ready, the only thing that we waited for was the first day of the contest to arrive. Unfortunately, and this is where the bad luck begins, a day before the contest began Tipping Point have decided to change the rules. So now, instead of being able to participate in the contest from the first day, we had to wait for others to try and exploit the machine for a whole two days, before we can start.

Day 3 came. Vista machine was still up, MacBook air already gone, and my friends, Steve and Bryan, are waiting in line for the contest. One place before them in the line was the winner of last year's contest, Shane Macaulay. Rumors were that he had a working exploit. 10 minutes passed, nothing. 20 minutes, not a single word. After 30 minutes (the official limit for each turn), the word was out that there were some kind of hardware problems. Eventually, after few hours (??), with some help from his friends, Shane was able to get his Flash exploit working. Kudos to Shane, Alexander and Derek for winning!

Now I left with one little problem. What should I do with the AIM vulnerability. The way I see it, I have three choices:

1) Leave it as it is - Only Steve, Bryan and me will know about it, until eventually someone else will find it.

2) "Responsibly" disclose it - Send all the information to AOL, wait for a fix to be delivered, and then publish the technical stuff.

3) Full Disclosure - Inform AOL, and in parallel publicly disclose all the technical information.

I'm interested in what you think the best choice is. Please comment or send me an email with your thoughts. New ideas are also welcomed.

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.

[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.

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:

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!