Attacking SSO Part 1: ID Spoofing

In 2013 we started a security study on one of the most widespread SSO protocols: OpenID. As described in previous posts, OpenID is a decentralized protocol, which provides a way to prove that a user controls an Identifier – URL.ID_C. Additionally, OpenID is designed to support the usage of arbitrary IdPs: “An end user can freely choose which OpenID Provider to use ...“.

Considering the properties of OpenID, we came up with the idea to study the relation between the IdP, generating the authentication token, and the Identifier URL.Idc contained in the token. In other words – is this relation critical regarding the security of OpenID implementations deployed on the SPs.

My Own IdP

As mentioned before, in OpenID the usage of arbitrary IdPs is allowed. By this means, a user or company can set up an own IdP, which is a public accessible domain, e.g. http://myOwnIdP.com, and can be discovered during the OpenID Discovery phase.

The IdP then can carry out the authentication of the users against arbitrary SPs. Consequentially, the IdP generates authentication tokens containing the users Identifier, e.g. http://myOwnIdP.com/?identity=userA.

ID Spoofing (IDS)

The idea of ID Spoofing is simple – by using a malicious IdP we create authentication tokens containing Identifiers that the IdP does not control.

For instance, an IdP running on http://mIdP.com must not be allowed to issue tokens for Identifiers controlled by Google, e.g. https://google.com?id=someuser.

Goal:

The attacker wants to get access to the account of a victim on a SP.

Assumptions and Requirements:

• The victim has an account on the SP and uses his Identifier, e.g. https://google.com?id=victim, for authentication.
• The Identifier of the victim is controlled by a trusted IdP, e.g. Google.
• The attacker knows, which Identifier the victim is using on the SP.

• The attacker deploys his malicious IdP on a public accessible domain, e.g. http://mIdP.com. By “malicious”, we mean that the IdP issues tokens containing Identifiers, which are controlled by other IdPs, e.g. Google, Yahoo, Wordpress.

Description:

Protocol Flow: IDSpoofing

1. The attacker navigates his browser to the target SP and enters an Identifier, controlled by his malicious IdP, e.g. http://mIdP.com/Id=evilUser
2. The SP discovers the malicious IdP and establishes a shared key (with the malicious IdP) during the association phase.
3. The SP redirects the browser to the malicious IdP.
4. The malicious IdP generates an authentication token containing the victims Identifier – https://google.com?id=victim
5. The token are sent to the target SP and the attacker gets access to victim's account.

Please consider the fact that no communication with "Google User 1" or "Google IdP" is needed to execute the attack.

Countermeasures

According to the specification, the SP should verify the Discovered Information. By this means, it should verify if the entered Identifier in Step 2 matches the Identifier in the authentication token.

Sourceforge: Interesting facts during the security evaluation

We started a security analysis on Sourceforge against ID Spoofing. Initially, we started a black-box testing and detected that the applied OpenID authentication is vulnerable against IDS. This vulnerarbility allows us to login with arbitrary OpenID accounts on Sourcefroge, and we could (theoretically) get full access to these accounts and the SF-projects that they are capable of. Consequentially, we contacted the support team and described the issue. Later on, they answered us that vulnerability is fixed and thanked us for helping them.

We then analyzed the implementation again. Using OpenID Attacker, we found out that the IDS attack was no longer working. Consequentially, we provided more tests against the OpenID implementation on Sourceforge. Unfortunately, we found another security issue, which is described in a follow-up blog post.

Authors of this Post

Vladislav Mladenov
Christian Mainka (@CheariX)