Attacking OpenID Connect 1.0 - Malicious Endpoints Attack

In this post we show a novel attack on OpenID Connect 1.0, which compromises the security of the entire protocol - the Malicious Endpoints attack. The idea behind the attack is to influence the information flow in the Discovery and Dynamic Registration Phase in such a way that the attacker gains access to sensitive information.

OpenID Connect authentication flow with Discovery and Dynamic Registration

OpenID Connect 1.0 protocol flow with Discovery and Dynamic Registration

1. Initiate Single Sign-On:
   An End-User visits the client (https://honestClient.com) and starts the Single Sign-On authentication in order to authenticate on the Client and get access to his resources. For this purpose, the End-User enters his identity on the Honest OP (e.g. alice@honestop.com).
2. Discovery Endpoint (Discovery):
   The Client normalizes the entered identity in order to estimate the correspondig OP. Afterwards the Client sends an HTTP request to this Discovery endpoint and subsequently retrieves the OP's confguration information including its endpoint locations: 
1. The (Dynamic) Registration Endpoint (regEndp).
2. The Authentication Endpoint (authEndp.
3. The Token Endpoint (tokenEndp).
3. Using the Registration Endpoint (regEndp):
   In order to use OpenID Connect services for authentication, a Client has to register on the OP. For this registration, the Client accesses this URL regEndp, for example, https://google.com/register.
4. Using the Authorization Endpoint (authEndp):
   In order to execute the Client's Authentication Request, the End-User has to be redirected to the authEndp of the OP, for example to https://login.google.com/. Here, the End-User has to authenticate to the OP via a corresponding authentication process and authorize the Client to access the requested resources.
5. Using the Token Endpoint (tokenEndp):
   The Client communicates with the tokenEndp, for example, https://google.com/consume-token, in order to obtain the id_token described in Section 2.5 and authenticate the End-User. In addition, an access_token can be sent to the Client in order to authorize the access to restricted resources. This communication is done directly between Client and OP (without involving the End-User).

Malicious Endpoint Attack

A view of the Malicious Endpoint attack and the protocol flow.

Phase 1.1 - Injecting malicious endpoints: The attacker's intention in the first phase is to force a valid Client to use the attacker's malicious Discovery service. For this purpose, he constructs a malicious link and sends it to the End-User. For example, this can be a link to the valid Client containing an identity alice@malicious.com.
If the victim clicks on the constructed link and thus visits the Client, the Client starts a discovery phase with the malicious Discovery service http://malicious.com. The Client sends a request to determine the corresponding endpoints. The attacker's Discovery service responds with the following values, initiating the actual attack:

Malicious Endpoints

issuer	http://malicious.com
regEndp	https://honestOP.com/register
authEndp	https://login.honestOP.com/
tokenEndp	http://malicious.com
userInfoEndp	http://malicious.com

Phase 1.2 - Dynamic Registration In the next step, the Client accesses regEndp for the Dynamic Registration. It sends a registration request to https://honestOP.com/register and receives a client_id and client_secret in the response.
The Client automatically starts the Dynamic Registration, even if it is already registered on the honest OpenID Provider. The reason for this behavior is that the Client believes that http://malicious.com is the responsible op, since it is not known from previous authentication procedures. Thus, http://malicious.com is a new OpenID Provider for the Client and it starts the registration procedure.

Phase 2 - End-User Authentication and Authorization In the next phase, the Client redirects the End-User to authEndp, https://login.honestOP.com/, where the End-User has to authenticate himself and authorize the Client. The End-User is not able to detect any abnormalities in the protocol flow: Phase 1.1 and Phase 1.2 cannot be observed by the End-User, and in Phase 2 the End-User will be prompted to authenticate to the honest OpenID Provider and authorize the honest Client, both of which he knows and trusts. Thus, the End-User authorizes the Client and the OpenID Provider generates the code, which is sent to the Client.
Note: Phase 2 exactly follows the original OpenID Connect protocol flow -- there is no parameter manipulation, no redirects to malicious websites and no observation of the network traffic between the End-User, the honest OpenID Provider and the Client. This means that the attack cannot be detected by the Client, the OpenID Provider and the End-User.

Phase 3 - The Theft In dependence of the protocol flow (Code or Implicit) the messages sent to the attacker differ.
Code Flow: Within the Code flow the Client redeems the received code from the previous phase: It sends the code together with the corresponding Client's credentials received during the Dynamic Registration (client_id/client_secret) to the tokenEndp originally specified by the malicious Discovery service - in this example http://malicious.com.
Implicit Flow: Since the Implicit flow does not use the tokenEndp, the attacker is not able to receive the information send in phase 2. But during the Discovery Phase an other malicious endpoint can be used - userinfo_endpoint. This endpoint is an OAuth 2.0 Protected Resource that returns Claims about the authenticated user. According to the specification, the obtained access token is sent as a Bearer token by the Client. Thus, the attacker can get access to a valid access token.

Demo

You can run our demo on:
http://ssoattacks.org/OIDC_MaliciousDiscoveryService/

Authors of this Post

Vladislav Mladenov
Christian Mainka (@CheariX)