Aviv Raff On .NET

Skeletons in Adobe's security closet

Aviv Raff — Thu, 18 Feb 2010 21:39:12 GMT

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]

May the force be with you

Aviv Raff — Mon, 15 Feb 2010 12:23:35 GMT

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.

Private browsing support in Flash

Aviv Raff — Sun, 14 Feb 2010 12:59:58 GMT

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.

Not so private after all

Aviv Raff — Mon, 17 Aug 2009 16:54:06 GMT

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.

Month of Twitter Bugs

Aviv Raff — Mon, 15 Jun 2009 17:41:25 GMT

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.

Cross-Web2.0 Scripting

Aviv Raff — Mon, 18 May 2009 22:40:14 GMT

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…

A La CORE Impact

Aviv Raff — Tue, 14 Apr 2009 20:44:57 GMT

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.

A different Opera

Aviv Raff — Thu, 30 Oct 2008 17:47:21 GMT

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.

Sharing is not always a good thing

Aviv Raff — Fri, 10 Oct 2008 13:03:06 GMT

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

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.

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.

Happy New Year

Aviv Raff — Thu, 02 Oct 2008 06:16:33 GMT

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:

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:

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