Direkt zum Hauptbereich

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

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.

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.

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)

Beliebte Posts aus diesem Blog

Printer Security

Printers belong arguably to the most common devices we use. They are available in every household, office, company, governmental, medical, or education institution.
From a security point of view, these machines are quite interesting since they are located in internal networks and have direct access to sensitive information like confidential reports, contracts or patient recipes.

TL;DR: In this blog post we give an overview of attack scenarios based on network printers, and show the possibilities of an attacker who has access to a vulnerable printer. We present our evaluation of 20 different printer models and show that each of these is vulnerable to multiple attacks. We release an open-source tool that supported our analysis: PRinter Exploitation Toolkit (PRET) https://github.com/RUB-NDS/PRET Full results are available in the master thesis of Jens Müller and our paper. Furthermore, we have set up a wiki (http://hacking-printers.net/) to share knowledge on printer (in)security.
The hi…

How to Break Microsoft Rights Management Services

In this post, we provide a security analysis of Microsoft Rights Management Services (RMS) and present two working attacks:  We completely remove the RMS protection of a Word document on which we only have a view-only permission, without having the right to edit it. This shows that in contrast to claims made by Microsoft, Microsoft RMS can only be used to enforce all-or-nothing access. We extend this attack to be stealthy in the following sense: We show how to modify the content of an RMS write-protected Word document issued by our victim. The resulting document still claims to be write protected, and that the modified content was generated by the victim This work is going to be presented at WOOT'16.