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…

CORS misconfigurations on a large scale

Inspired by James Kettle's great OWASP AppSec Europe talk on CORS misconfigurations, we decided to fiddle around with CORS security issues a bit. We were curious how many websites out there are actually vulnerable because of dynamically generated or misconfigured CORS headers. The issue: CORS misconfiguration Cross-Origin Resource Sharing (CORS) is a technique to punch holes into the Same-Origin Policy (SOP) – on purpose. It enables web servers to explicitly allow cross-site access to a certain resource by returning an Access-Control-Allow-Origin (ACAO) header. Sometimes, the value is even dynamically generated based on user-input such as the Origin header send by the browser. If misconfigured, an unintended website can access the resource. Furthermore, if the Access-Control-Allow-Credentials (ACAC) server header is set, an attacker can potentially leak sensitive information from a logged in user – which is almost as bad as XSS on the actual website. Below is a list of CORS misc…