[NEWS] Microsoft Passport Account Hijacking (Hacking Hotmail and more)

From: support@securiteam.com
Date: 08/10/01

From: support@securiteam.com
To: list@securiteam.com
Subject: [NEWS] Microsoft Passport Account Hijacking (Hacking Hotmail and more)
Message-Id: <20010809221844.5352C138C4@mail.der-keiler.de>
Date: Fri, 10 Aug 2001 00:18:44 +0200 (CEST)

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com

  Microsoft Passport Account Hijacking (Hacking Hotmail and more)


Web Applications are made to extend the usability of the HTTP protocol,
along with the efficiency of HTML, JavaScript and so on. The big advantage
of Web Applications is that they are immediately accessible, relatively
easy to use and can be centrally customized by the developer, at the
expense of security issues.

Security issues in Web Applications rise because the HTTP protocol was not
made to be extended to Web Applications, and therefore many security
measures and extended authentication methods have to be implemented into
the Web App.


In Web Applications, users have to be authenticated, and will usually be
assigned a profile, limited hard disk space, the ability to send data and
communicate with other users on the same Web Application, and maybe other
Applications and protocols. Many Web Mail Applications, such as Hotmail,
make use of cookies to store authentication. For each session at Hotmail,
once a user is authenticated, he is assigned a random cookie, which
identifies him from other authenticated users. This way the password does
not have to be sent each time he accesses a different page while
authenticated. This also means that once the session has ended, the
session authentication should expire and therefore a new cookie has to be
assigned when the user authenticates himself with Hotmail and starts a new

All this is described well on the MS Passport site:
 <http://www.passport.com/Business/WhitePaper.asp?lc=1033> Passport White

From now on, we will be focusing only on Hotmail, rather than just about
any Web Application. However, one must understand that the same attacks
described here, can be easily adapted for other Web Applications and Web
Mail packages, which make use of html, JavaScript and Cookie technology.

Microsoft Passport
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 that makes use of the Passport
technology to another, a cracker (malicious hacker) can do the same
without many problems once he gets to look like the authorized user. This
kind of service is intended for personal use, so people certainly would
not 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:
 * Hotmail and Passport sites
 * MSN messenger
 * MSN Explorer
 * Outlook Express
 * Other MS applications.

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

Flaws in the design:
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:
 * Take hold of the target machine
 * Fool the user into sending the session cookie
 * Fool the system into sending the session cookie

In this paper we will discuss the 3rd option.

Fooling the system:
JavaScript allows users to set and retrieve cookies. This is very useful
for normal HTTP sites as well as Web Applications. However, Web
Applications need a lot more control over normal websites. This control is
normally achieved through filtering of possibly malicious code in the

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.

Hotmail takes very good care to filter out JavaScript, ActiveX, and Java
applets. Lately it also started checking for images that link to outside
the Hotmail account. Having images linking to non-trusted sites means that
those sites can easily track the status of the e-mail (if it was read or
not). So that a tag in an html mail such as:

<img src="http://spam.me.com/tracking.gif">

Would be 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 we are writing about in this document.

Cross site scripting:
When a logged in user follows a non-trusted link, the Hotmail credentials
are not sent to the website. The Hotmail filtering system also takes care
to hide the URL of the user's Hotmail account to ensure his privacy (and
maybe to prevent other attacks).

On the other hand, when a user follows an MSN (Passport and therefore
trusted) site from a non-trusted e-mail, the credentials is sent to the
Passport site, and no precautions are taken. This means that the Passport
authentication is not broken and therefore the different services provided
by MS Passport operate seamlessly as described earlier.

This also means that if an ASP script that resides on any MS Passport
enabled site allows the user to customize the page (even if not intended)
such as inserting JavaScript code, the whole system is flawed.

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

How is this achieved?
To further explain the issue, we will provide an example of a flawed ASP
script on an MS Passport site: ErrorMsg.asp, which resides on

This ASP script can be passed 2 (or possibly more) arguments:
 * Source
 * ErrMsg

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 This should be bold. To our
astonishment (at the time of writing this is not fixed yet), we got the
HTML tag to work, with no filtering from the ASP script.

To further illustrate this, the URL which is passed is actually:


If no filtering is done for JavaScript, we can very easily inject our own
JavaScript code to retrieve the session cookie stored in the Hotmail
user's browser. Sadly, lately (during the writing of this document),
Microsoft seemed to try to fix this by filtering JavaScript (and embedded
scripts) tags and entities. This means when the ASP script is passed the
 * <Script
 * Alert
 * JavaScript:
 * And other commonly used JavaScript methods

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.

This means that to produce an alert box to display the session cookies,
instead of simply using something like:

We have to encode the URL such as:

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
http://irc.m0ss.com/eos/content/articles/image002.gif> end picture would
look something like that.

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.


The original article (along with very illustrative pictures) can be viewed

The information has been provided by <mailto:obscure@zero6net> Obscure^.


This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com


The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.