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