On the Insecurity of
Microsoft's Identity Metasystem CardSpace

Sebastian Gajek, Jörg Schwenk and Xuan Chen. Technical Report.
HGI-TR-2008-003. May, 2008.

English Press Release
German Press Release

Abstract
Microsoft has enrolled a user-centric identity metasystem encompassing a suite of various protocols for identity management. CardSpace bases on open standards, such that various applications can make use of the identity metasystem, including, for example, Microsoft Internet Explorer 7. We therefore expect Microsoft's identity metasystem to become widely deployed on the Internet and a popular target to attack. We study the security of Cardspace and show that the browser-based protocol is susceptible to attacks, where the adversary steals the security token. Consequently, we prove evidence that users are impersonatable and the one who potentially suffer from identity theft. We confirm the practicability of the attack by presenting a proof of concept implementation. Finally, we discuss countermeasures, addressing both the CardSpace identity metasystem and the protocol.

A high-level description of the CardSpace protocol flow
The quintessence of Microsoft's identity metasystem protocols is to call the identity provider to issue a security token for the authentication with a relying party. In a high-level description, the CardSpace protocols proceed as follows:

• The user contacts the relying party and opts for CardSpace-based authentication. Then, the client receives relying party's policy.
• The browser calls the identity selector and forwards the relying party's policy to it so that the identity selector knows the requirements for the authentication process. A relying party may define its token requirements in its policy. For example, it can define which claims are required from the user, which token issuers are accepted, which types of token are supported and so on. Furthermore, it can also define how the interaction between users and the relying party should be secured.
• According to the relying party's policy, the identity selector looks into the user's InfoCard collection and highlights the InfoCards which satisfy the relying party's policy. The user may select to use one of these cards.
• The identity selector contacts the corresponding identity provider and gets the identity provider's policy. In the policy, an identity provider may define the user credential type, which is needed for the user authentication, and its security requirements to the interaction between it and users. Four user credential types are supposed at the moment: username/password, KerberosV5 service ticket, X.509v3 certificate and self-issued token.
• According to the identity provider's policy, the identity selector indicates the user to enter the requested credential.
• With a valid credential, the user authenticates to the identity provider and retrieves an issued security token for the selected InfoCard from the identity provider which satisfies the relying party's requirement.
• The identity selector forwards the security token to the application.
• The browser submits the security token to the relying party and gets access to the desired service or resource.

Demonstrator---How to steal a CardSpace Security Token?
Our demonstrator has been successfully tested on Windows XP SP2, running Internet Explorer Version 7.0.5730.13, and exemplarily designed to steal a CardSpace security token from http://sandbox.netfx3.com, a test site provided by Microsoft. The proof-of-concept attack makes use of dynamic pharming, where the main frame, i.e., frame0 hosts in frame1 the script stealing the token, and the legit site target to attack in frame2. In a nutshell, it proceeds as follows:

• The user loads our malicious web site in his browser.
• Our web server is stopped after two seconds.
• Six seconds later after our web server is stopped, the relying party login page is loaded into frame2.
• Two seconds later, our web server is started again.
• Three seconds later, the javascript codes in frame1 change the "target" and "action" attributes of the "cardspacelogin" form in frame2.
• The user clicks the "Sign in" button and retrieves a security token from an identity provider.
• The security token is submitted to our ASP page named "Sandbox_login.aspx" in frame1. The ASP page records the security token in a text area and forwards it further to the relying party in frame2.
• The user successfully logs into the relying party in frame2.
• The pharmer can reuse the security token anytime he wants within the token's lifetime to log into the relying party as the user.

How to use our demonstrator
Before you proceed, please make sure that you are able to login to https://sandbox.netfx3.com. You might need to update your .NET Framework and create a personal CardSpace Identity Card. Logout and close your browser after you have successfully logged in.
Further, you must download our root certificate, representing the fact that the adversary may have retrieved a valid certificate or the average user does not validate the certificate. Place the certificate in the "Trusted Root Certification Authority" (in the negative case you have to manually choose the certificate storage location).

To reproduce our attack, you need to create a round robin entry in the DNS server for the domain "sandbox.netfx3.com" with two IP addresses: Our IP 134.147.40.84 (simulating the adversary) and the legitimate IP 66.129.68.21 (simulating the relying party). Make sure that the next IP address for the domain is our server's IP address.
Note that we have already set up a DNS Server with the appropriate configuration. You need to replace your current DNS Server with the IP address 134.147.40.84 and remove possible secondary DNS Server entries. Next, go to https://sandbox.netfx3.com/root_page.htm with your Internet Explorer 7. Our pharming page will be loaded into your browser (sometimes the first attempt may fail with a 404 error so you need to restart your browser and try again). You will see two frames. The first frame (frame1) contains a simple text box and the button "Login again". The second frame (frame2) will load after a short delay and contains the original login page. Please wait for the text "I'm listening" to appear in the upper text box, before you proceed with CardSpace login. After having logged in, the text box shall reveal your security token. Next, copy the content from the text box to your clipboard, log out and restart your browser. Once again, visit https://sandbox.netfx3.com/root_page.htm. Now paste the security token content into the text box, and click on the button "Login again". You shall now be logged in without sending your original token via the Windows CardSpace interface. The latter step simply mimics the fact that the adversary has impersonated you!

Frequently Asked Questions

Q: Do EV SSL certificates protect against the attack?
A: Maybe, if the user checks the SSL indicators of his browser. However, usability studies have shown that most users simply ignore SSL warnings, or may not be aware of the subtleties between a "normal" certificate and an EV certificate.

Q: How can the adversary control the DNS name resolution? Is this a realistic assumption?
A: In the last two years, many attacks have been described and observed "in the wild" that employ DNS Spoofing for which the term "Pharming" has been coined. Examples include

• Drive-by-Pharming where the DNS configuration of a DSL home router is changed by Javascript embedded in a web page
• Rogue WLAN Access Points which play the role of a free Internet access point in public facilities for the user
• etc.

Q: Does the attack work without a SSL certificate for the outer frameset?
A: Yes, it does with the exception that the browser indicates that there are some problems with the server certificate. As mentioned before, the average Internet user ignores the warning.

Q: Do other standards/frameworks like SAML or Liberty Alliance offer better security?
A: We have not analyzed the other protocols yet.

Q: How can Browser-based identity management systems prevent such attacks?
A: In the past, the cryptographic burden to verify the peer player has been put into the arms of inexperienced users: They were asked to verify the validity of SSL server certificates, without being able to understand even simple technical details of the underlying technology. This is cumbersome because a plethora of root certificates (not all for SSL) are installed in the Windows OS, whereby root authorities enforce different policies to issue server certificates. Against this background, some provisions have been made by introducing EV certificates and restricting the number of trusted root certificates, and improving the security indicators of IE. However, the basic concept to make the user verify the server remains.
Our proposal is to reverse the roles, and to automate the verification. This can be done, e.g., by using SSL client certificates, even if they are self-signed. They allow a server to uniquely identify the browser. Another candidate solution is the "Strong Locked Same Origin Policy" recently introduced by [Karlof et al., CCS'07]. If the policy would be enforced, the browser would be capable of automatically detecting Pharming and Dynamic Pharming attacks based on the public key of the SSL certificate.

For more details, see the Technical Report.

Additional information:
What is Windows CardSpace?
Complete technical report
How to change DNS server settings for Windows XP
How to change DNS server settings for Windows Vista
Studies of IT-Security (german)

Please contact Christoph Löhr or Xuan Chen for questions regarding the technical implementation.