a

Author: carlospolop

src/pentesting-ci-cd/github-security/abusing-github-actions/README.md

@@ -2,6 +2,16 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
+## Tools
+
+The following tools are useful to find Github Action workflows and even find vulnerable ones:
+
+- [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven)
+- [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)
+- [https://github.com/AdnaneKhan/Gato-X](https://github.com/AdnaneKhan/Gato-X)
+- [https://github.com/carlospolop/PurplePanda](https://github.com/carlospolop/PurplePanda)
+- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Check also its checklist in [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
+
 ## Basic Information
 
 In this page you will find:
@@ -569,15 +579,6 @@ An organization in GitHub is very proactive in reporting accounts to GitHub. All
 > [!WARNING]
 > The only way for an organization to figure out they have been targeted is to check GitHub logs from SIEM since from GitHub UI the PR would be removed.
 
-## Tools
-
-The following tools are useful to find Github Action workflows and even find vulnerable ones:
-
-- [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven)
-- [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)
-- [https://github.com/AdnaneKhan/Gato-X](https://github.com/AdnaneKhan/Gato-X)
-- [https://github.com/carlospolop/PurplePanda](https://github.com/carlospolop/PurplePanda)
-
 {{#include ../../../banners/hacktricks-training.md}}
 
 

src/pentesting-cloud/kubernetes-security/kubernetes-pivoting-to-clouds.md

@@ -287,11 +287,18 @@ for ns in `kubectl get namespaces -o custom-columns=NAME:.metadata.name | grep -
 done | grep -B 1 "amazonaws.com"
 ```
 
-### Node IAM Role
+### Node IAM Role to cluster-admin
 
-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_).
+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 an 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:
+To access the node metadata endpoint you need to:
+- Be in a pod and have the metadata endpoint configured to at least 2 tcp hops. This is the most common misconfiguration as usually different pods in the cluster will require access to the metadata endpoint to not break and several companies just decide to allow access to the metadata endpoint from all the pods in the cluster.
+- Be in a pod with `hostNetwork` enabled.
+- Escape to the node and access the metadata endpoint directly.
+
+(Note that the metadata endpoint is at 169.254.169.254 as always).
+
+To **escape to the node** you can use the following command to run a pod with `hostNetwork` enabled:
 
 ```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"}]}}'
@@ -314,6 +321,21 @@ if [ "$IAM_ROLE_NAME" ]; then
 fi
 ```
 
+### Privesc to cluster-admin
+
+Iin summary: if it's possible to **access the EKS Node IAM role** from a pod, it's possible to **compromise the full kubernetes cluster**.
+
+For more info check [this post](https://blog.calif.io/p/privilege-escalation-in-eks). As summary, the default IAM EKS role that is assigned to the EKS nodes by default is assigned the role `system:node` inside the cluster. This role is very interesting although is limited by the kubernetes [**Node Restrictions**](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction).
+
+However, the node can always **generate tokens for service accounts** running in pods inside the node. So, if the node is running a pod with a privileged service account, the node can generate a token for that service account and use it to impersonate the service account like in:
+
+```bash
+kubectl --context=node1 create token -n ns1 sa-priv \
+    --bound-object-kind=Pod \
+    --bound-object-name=pod-priv \
+    --bound-object-uid=7f7e741a-12f5-4148-91b4-4bc94f75998d
+```
+
 ## References
 
 - [https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity)