Security Weaknesses In The Passport Security Model

By now most people are familiar with Microsoft Passport since it has been around for a while. It also helps that Microsoft owns Hotmail and has forced all of its users to be Passport users as well. However, this isn't an article on how to hack Microsoft Passport so you can read other people's juicy Hotmail accounts. No, this is an article on how to hack the Passport security model, which is used by several other vendors. I am simply focusing on Microsoft since Passport is the most widely used.

Hacking Passport is rather hard, but its security model just plain stinks, so we are going to hack that instead. This article will show you how to build a very simple program to collect Passport user logins and passwords. This program will be web-based, so it will be easy for millions of Passport users to well… use. However, it will become painfully obvious to the intended readers of this article that the real trick will be convincing people to actually use this program. We will then engage in a bit of social engineering and learn how to get Passport users to use our little program.

Before getting started lets define some ideas, so we are on the same page. The first idea to define is that of hacking. When this author hacks, he is attempting to find clever solutions to complex problems. This is the more traditional definition of hacking used by geeks everywhere. However, there is another definition of hacking used by the media and many uninformed people. They define hacking as the attempt to break into something illegally. We won't be doing that in this article. Although, if you use the techniques described in this article and do obtain Passport user logins and passwords for the purpose of accessing accounts that don't belong to you, then you are of course fitting into the latter definition of hacking I offered earlier and of course committing a crime; maybe several. You have been warned.

Next up is the security model idea, which is vague and generic, so I won't define it. However, if we are going to hack it, we need to know what it is. In this case, the Passport security model refers directly to the problem Passport attempts to solve — centralized authentication for heterogeneous applications a.k.a. single sign-on (SSO). It has long been the dream of many to have the ability to log in once and have every web site know whom you are without needed to log in at each web site. Passport offers a solution to this problem. As more and more web sites switch over to Passport for their authentication the easier it will get for consumers. In addition, the companies who implement Passport get all the advantages that are listed on this web page. Although, lets not forget that above all others, Microsoft benefits most. So if everyone benefits including consumers, why am I against it? Well, no one has a good answer for what happens when someone steals a consumer's Passport. Think about, if John Doe has a Passport account that will get him into x number of sites with a single log in and his Passport is stolen. Then the person who obtains his Passport can now log in to all those sites as well.

Now we all know that Microsoft is an expert at getting consumers to do what it wants. Currently it wants among other things for consumers to use Passport. Thus, it will only be a matter of time before I as a consumer will be forced to have a Passport account as well. Actually, I already have a Passport account, as one of the projects at my former job required it. However, I don't need that Passport to do shopping and I don't relish the thought of that changing, so let's poke some holes in the security and see what happens.

Our first step is to create a program to capture Passport account information. The easiest way to do this is to create an interactive web form that looks like a Passport login form. This can be done with a variety of languages rather easily. Just download the HTML source to Passport's login page and change the form action attribute to point towards your logging script. Now mind you, the Passport login page is copyrighted, so it is illegal to do this, but hey I pointed that out earlier. The server side script you just created needs to log the user and password information that gets submitted by the user and then repost that form data without change to where the original form action attribute pointed. You can log the data into a file, a database, or even email it to yourself. The Passport server will then send a redirect that you will need to forward on to the user's browser, so that the user will be logged into whatever web site they thought they were logging into.

As you can see the above is rather easy to do. However, it doesn't seem all that clever and there is of course the problem of getting the user to use your web form on your server instead of the one he is supposed to. That problem requires a clever solution.

What I am going to explain now is known as a semantic attack. We need the user to think she is logging into the correct place. For almost all users on the Internet, there are two basic ways to determine what site they are looking at. The first and most obvious to look at is the rendered page. If you can produce a web page that makes the user think he is looking at the Passport login page than most of the time your done. However, users also look at the URL in the browser address bar as an indicator of where they are. Luckily for us most URLs are quite long these days and include lots of query parameters. This is good, but we are going to need a long fake URL in order to hide the real URL. What do I mean by this? Let's look at an example. Below is the URL we want the user to think she is connected to.

http://www.somecompany.foo/somedirectory/somefile

However, we actually want the user to connect to the following URL.

http://i.am.stealing.your.password/somefile

To pull that off we use the following URL.

http://www.somecompany.foo/somedirectory/somefile:somejunktomaketheurllonger

@i.am.stealing.your.password/somefile

The URL will scroll of the screen and the user will only see the left side of it. This will give the impression that they are connected to the correct URL. However, the correct URL will be sent to our password stealing script in the form of web server CGI variable.

Now to actually make use of this attack we still need the user to use our URL instead of the one the Passport server provides. The hardest, but most effective way to do this is to break into a corporate proxy and have it change the URLs on the fly. Again, that is illegal, so you shouldn't do it. However, there is a much simpler way, but not as effective. To do this you will need to know the person's email address. Once you have that you create an email asking to user to update their Passport account information by clicking on a URL that you have conveniently provided in the email for them. As most IT managers will confess, users will follow the instructions in the email and click away.

This kind of attack can really be done on any web application that has a login form. However, when it only takes stealing a password once to access hundreds of sites the danger is too great. There are some ways to slow down this sort of attack, but no way to really stop it. That is unless we give up on username and passwords altogether.