Direkt zum Hauptbereich

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.


      You can run our demo on:

      Authors of this Post

      Vladislav Mladenov
      Christian Mainka (

      Beliebte Posts aus diesem Blog

      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…

      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…