[Microsoft Passport Account Hijack Attack]
last major update: 08/10/2001
last minor updates: 23/07/2002
Hacking hotmail and more
Copyright © 2001,2002
Redistribution of this document is permitted as long as the contents
are not changed and this copyright notice is included.
Security issues in Web Applications rise because the HTTP protocol was not designed for Web Applications, and therefore many security measures and extended authentication methods have to be implemented into the Web Application.
Microsoft Passport: "A single name, password and wallet for the web". This means that using the same credentials you can access your e-mail (Hotmail), instant messenger service (MSN messenger), calendar (task manager, reminders and so on), and loads of other useful services. All these services are centralized and authenticate with a central system called MS passport. Of course as much as any authorized user can browse without supplying a password from a service which makes use of the Passport technology to another, a cracker (malicious hacker) can do the same without much problems once he gets to look like the authorized user. This kind of service is intended for personal use, so people certainly wouldn’t like others to read their e-mail, or view their daily schedule.
Microsoft is trying to build everything around their Network, using Passport authentication. This is complaint with the .NET framework, which allows everything to be seamlessly integrated so that users can jump from one service to another without any problems.
As currently implemented, users can authenticate to Passport via a number of ways:
Outlook Express and MSN Explorer make use of Integrated authentication. Hotmail and Passport sites use SSL (HTTPS) to authenticate, and MSN messenger makes use of “MD5” security package.
Once a malicious user gets hold of the session cookie, the above-mentioned authentication methods are useless for services, which rely on the HTTP protocol (such as Hotmail).
Previously many exploits inhibited the various Web Browsers, which enabled users to steal cookies from other websites. However this aspect of security in the Passport authentication scheme is supposed to be taken care of by the client user.
To steal the session cookie, the malicious user must either:
In this paper I will discuss the 3rd option.
Users do not need permission to send e-mails to authenticated users, giving them the possibility to post data to an authenticated user’s mailbox. This is obvious to some extent, since we are talking about e-mail. No one needs authentication to send an e-mail to a Hotmail account. Therefore the e-mail sent to the Hotmail user has to be treated as non-trusted content.
would get filtered by the Hotmail Filtering System. To get around this filtering, one has to just encode the http:// part like &x68;ttp://. 68 is the hex value h, and therefore the Web Browser converts back the encoded value to its original signifier. Of course, the Hotmail filtering system is not working exactly like the Web Browser, and this is where the flaw stands out. However this is not the major issue I am writing about in this document.
When a logged in user follows an non-trusted link, the Hotmail credentials do not get sent to the non-trusted website. The Hotmail filtering system also takes care to hide the URL of the user’s Hotmail account to ensure the user’s privacy and maybe to prevent other attacks.
On the other hand, when a user follows an MSN site from a non-trusted e-mail message received through Hotmail web interface, the credentials get sent to the Passport site, and no precautions are taken. This way users following links from a Passport site to another remain authenticated therefore the different services provided by MS Passport operate seamlessly as described earlier.
This also means that if an ASP script, which resides on any MS Passport enabled site allows the user to customize the page (even if not intended) problems will arise.
In my exploit, a user only needs to click on a trusted link and he (or she) will be sending his (or her) credentials to a remote server.
To further explain the issue, I will provide an example of a flawed ASP script on an MS Passport site: ErrorMsg.asp, which resides on http://auctions.msn.com/Scripts/
This ASP script can be passed 2 (or possibly more) arguments:
Here we are concerned with ErrMsg argument. This argument allows different scripts to generate different errors and display them to the user in some nice html.
ErrMsg will usually be filled in with something like “User is not authenticated”. Now what if it is filled with <b>This should be bold</b>. To my astonishment (at the time of writing this is not fixed yet), I got the HTML tag to work, with no filtering from the ASP script.
To further illustrate this, the url which is passed is actually:
The ASP script simply ignores the input, successfully filtering common Cross Site Scripting attacks.
However Microsoft did not fully patch the issue, so that if HTML encoding were used, the filtering system would not detect the embedded script code, and the code would still be executed.
Without any filtering we would just pass the following url and expect a message box to apprear with the MSN cookies:
However to get this to work with the actual ErrorMsg.asp script – we have to encode the URL such as the following:
To complete the exploit the malicious user has to send a URL, which actually passes the Cookie to a 3rd party CGI script (probably made by the cracker exploiting this issue) instead of displaying them to the Hotmail user in a Message box. The exploiting e-mail page could look very similar to the one below.
Once the target Hotmail user clicks on the “mypic.jpg” link, he would have sent his credentials to the attacker without asking, any alert or sign that this has actually happened.
This paper is based upon trial and error, which means that I do not have access to any source code, and therefore cannot know the actual underlying code that contains the flaw. By the time you read this, Hotmail and MS Passport sites, should have hopefully fixed the described issues.