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

How To Spoof PDF Signatures

One year ago, we received a contract as a PDF file. It was digitally signed. We looked at the document - ignoring the "certificate is not trusted" warning shown by the viewer - and asked ourselfs:

"How do PDF signatures exactly work?"

We are quite familiar with the security of message formats like XML and JSON. But nobody had an idea, how PDFs really work. So we started our research journey.

Today, we are happy to announce our results. In this blog post, we give an overview how PDF signatures work and on top, we reveal three novel attack classes for spoofing a digitally signed PDF document. We present our evaluation of 22 different PDF viewers and show 21 of them to be vulnerable. We additionally evaluated 8 online validation services and found 6 to be vulnerable.

In cooperation with the BSI-CERT, we contacted all vendors, provided proof-of-concept exploits, and helped them to fix the issues and three generic CVEs for each attack class were issued: CVE-2018-16042

DTD Cheat Sheet

When evaluating the security of XML based services, one should always consider DTD based attack vectors, such as XML External Entities (XXE) as,for example, our previous post XXE in SAML Interfaces demonstrates.

In this post we provide a comprehensive list of different DTD attacks.

The attacks are categorized as follows:
Denial-of-Service AttacksClassic XXEAdvanced XXEServer-Side Requst Forgery (SSRF)XIncludeXSLT

Practical Dictionary Attack on IPsec IKE

We found out that in contrast to public knowledge, the Pre-Shared Key (PSK) authentication method in main mode of IKEv1 is susceptible to offline dictionary attacks. This requires only a single active Man-in-the-Middle attack. Thus, if low entropy passwords are used as PSKs, this can easily be broken.