From 2d20c080f1b83856e45c1a4a3b659fe2059946d6 Mon Sep 17 00:00:00 2001 From: Carlos Polop Date: Sun, 13 Apr 2025 16:30:15 +0200 Subject: [PATCH] im --- .../README.md | 66 ++++++------------- 1 file changed, 21 insertions(+), 45 deletions(-) diff --git a/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md b/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md index a0a7a9b6c..f19f9ff19 100644 --- a/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md +++ b/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md @@ -213,11 +213,16 @@ Therfore, it's possible to **get inside a pod and steal the token of the SA**, o kubectl exec -it -n -- sh ``` +> [!NOTE] +> By default the command is executed in the first container of the pod. Get **all the pods in a container** with `kubectl get pods -o jsonpath='{.spec.containers[*].name}'` and then **indicate the container** where you want to execute it with `kubectl exec -it -c -- sh` + +If it's a distroless container you could try using **shell builtins** to get info of the containers or uplading your own tools like a **busybox** using: **`kubectl cp :`**. + ### port-forward This permission allows to **forward one local port to one port in the specified pod**. This is meant to be able to debug applications running inside a pod easily, but an attacker might abuse it to get access to interesting (like DBs) or vulnerable applications (webs?) inside a pod: -``` +```bash kubectl port-forward pod/mypod 5000:5000 ``` @@ -599,7 +604,7 @@ For a [`mutatingwebhookconfigurations` example check this section of this post]( ### Escalate -As you can read in the next section: [**Built-in Privileged Escalation Prevention**](#built-in-privileged-escalation-prevention), a principal cannot update neither create roles or clusterroles without having himself those new permissions. Except if he has the **verb `escalate`** over **`roles`** or **`clusterroles`.**\ +As you can read in the next section: [**Built-in Privileged Escalation Prevention**](#built-in-privileged-escalation-prevention), a principal cannot update neither create roles or clusterroles without having himself those new permissions. Except if he has the **verb `escalate` or `*`** over **`roles`** or **`clusterroles`** and the respective binding options.\ Then he can update/create new roles, clusterroles with better permissions than the ones he has. ### Nodes proxy @@ -659,53 +664,23 @@ The privilege to create Rolebindings allows a user to **bind roles to a service By default there isn't any encryption in the communication between pods .Mutual authentication, two-way, pod to pod. -#### Create a sidecar proxy app +#### Create a sidecar proxy app -Create your .yaml +A sidecar container consists just on adding a **second (or more) container inside a pod**. -```bash -kubectl run app --image=bash --command -oyaml --dry-run=client > -- sh -c 'ping google.com' -``` - -Edit your .yaml and add the uncomment lines: +For example, the following is part of the configuration of a pod with 2 containers: ```yaml -#apiVersion: v1 -#kind: Pod -#metadata: -# name: security-context-demo -#spec: -# securityContext: -# runAsUser: 1000 -# runAsGroup: 3000 -# fsGroup: 2000 -# volumes: -# - name: sec-ctx-vol -# emptyDir: {} -# containers: -# - name: sec-ctx-demo -# image: busybox -command: - [ - "sh", - "-c", - "apt update && apt install iptables -y && iptables -L && sleep 1h", - ] -securityContext: - capabilities: - add: ["NET_ADMIN"] -# volumeMounts: -# - name: sec-ctx-vol -# mountPath: /data/demo -# securityContext: -# allowPrivilegeEscalation: true +spec: + containers: + - name: main-application + image: nginx + - name: sidecar-container + image: busybox + command: ["sh","-c",""] ``` -See the logs of the proxy: - -```bash -kubectl logs app -C proxy -``` +For example, to backdoor an existing pod with a new container you could just add a new container in the specification. Note that you could **give more permissions** to the second container that the first won't have. More info at: [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) @@ -713,7 +688,7 @@ More info at: [https://kubernetes.io/docs/tasks/configure-pod-container/security An admission controller **intercepts requests to the Kubernetes API server** before the persistence of the object, but **after the request is authenticated** **and authorized**. -If an attacker somehow manages to **inject a Mutationg Admission Controller**, he will be able to **modify already authenticated requests**. Being able to potentially privesc, and more usually persist in the cluster. +If an attacker somehow manages to **inject a Mutation Admission Controller**, he will be able to **modify already authenticated requests**. Being able to potentially privesc, and more usually persist in the cluster. **Example from** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers): @@ -751,7 +726,7 @@ kubectl describe po nginx | grep "Image: " As you can see in the above image, we tried running image `nginx` but the final executed image is `rewanthtammana/malicious-image`. What just happened!!? -#### Technicalities +#### Technicalities The `./deploy.sh` script establishes a mutating webhook admission controller, which modifies requests to the Kubernetes API as specified in its configuration lines, influencing the outcomes observed: @@ -806,6 +781,7 @@ https://github.com/aquasecurity/kube-bench - [**https://www.cyberark.com/resources/threat-research-blog/kubernetes-pentest-methodology-part-1**](https://www.cyberark.com/resources/threat-research-blog/kubernetes-pentest-methodology-part-1) - [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers) - [**https://kubenomicon.com/Lateral_movement/CoreDNS_poisoning.html**](https://kubenomicon.com/Lateral_movement/CoreDNS_poisoning.html) +- [**https://kubenomicon.com/**](https://kubenomicon.com/) {{#include ../../../banners/hacktricks-training.md}}