This repository provides a laboratory for demonstrating the risk of a vulnerable application combined with overly permissive access deployed on a Kubernetes cluster.
In the ever-evolving landscape of digital infrastructure, Kubernetes stands tall as a cornerstone of modern application deployment. However, with great power comes great responsibility, and the perils of overly permissive access can cast a shadow over this powerful tool.
- a Kubernetes cluster (Vanilla or managed) : you can use the following link to deploy an EKS cluster: https://github.com/cleypanw/terraform-aws-eks
- Fork this repository
Compromising an application running on the cluster and use its service account token to perform a privilege escalation attack
- Fork this repo, Go to vul-app/k8s and deploy app with yaml file
$ kubectl apply -f deploy-vul-app.yaml
serviceaccount/secret-sa created
clusterrolebinding.rbac.authorization.k8s.io/pod-sa-clusterrolebinding created
clusterrole.rbac.authorization.k8s.io/secret-role created
replicationcontroller/vul-app created
service/vul-app-svc created- Check that the application is running and accessible
$ kubectl get all
NAME READY STATUS RESTARTS AGE
pod/vul-app-nhmzh 1/1 Running 0 58s
NAME DESIRED CURRENT READY AGE
replicationcontroller/vul-app 1 1 1 58s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 172.20.0.1 <none> 443/TCP 20d
service/vul-app-svc LoadBalancer 172.20.181.148 a35ffdf61921e47299c905d536881c8c-1546501490.eu-west-3.elb.amazonaws.com 80:30399/TCP 58s- Open your browser and go to the LoadBalancer URL as shown in the output above.
The application is running and accessible. Let's start the attack.
The application, our security website, is now accessible from the Internet.
The first action of an attacker is to scan the application to detect any injection point. In today's world, all scanning actions are automated within minutes by bots, or crawlers.
For our demo, scan actions were automated in a pipeline (GitHub Action), using the SSTIMap tool.
From the repository Go to Actions and Run 0_Scan_WebApp workflow to trigger the scan:
Scan detected several injection points which we are now going to exploit (os cmd for the demo)
The fully automated attack will exploit the CVE-2023-42282 vulnerability to compromise the application with an SSRF injection.
The attacker will take control of the container to deploy kubernetes tools (kubectl), use the cluster's misconfiguration to grant a permission elevation by elevating the token, then deploy several workloads (web-app, etc...) and become the master/owner of the Kubernetes cluster.
Go to Actions / Workflows / 1_Run_Attack - Server-Side Request Forgery (SSRF)
Set the URL of the application to be attacked as a parameter (output of 1.2 Check that the application is running and accessible) and run the attack
At the end of the workflow, applications will be deployed and running and a cluster-admin token will be print as output:
- https Kubernetes-dashboard URL (Red Below)
- http Hacked application URL (Green Below)
- Cluster-admin Token (Blue Below)
Note : Github action output detects the output as a token.* For demo purposes, I've removed the first two digits of the token output so that it's visible on the screen.
To obtain the token you therefore need to add ey to the cluster-admin token output character string
Example above token will be :
eyJhbGciOiJSUzI1NiIsImtpZCI6IjBmOTkyOTVjMDlmYjlkOTk1ZWY2MmMxMDExMzI3ZTUyYmEwMDEzNmUifQ.eyJhdWQiOlsiaHR0cHM6Ly9rdWJlcm5ldGVzLmRlZmF1bHQuc3ZjIl0sImV4cCI6MTcxODk2NzQxMSwiaWF0IjoxNzE4OTYzODExLCJpc3MiOiJodHRwczovL29pZGMuZWtzLmV1LXdlc3QtMy5hbWF6b25hd3MuY29tL2lkLzE3QzhDMERGMjNDMEQzNTE2OTIwM0Q5OURFRTFENDREIiwia3ViZXJuZXRlcy5pbyI6eyJuYW1lc3BhY2UiOiJkZWZhdWx0Iiwic2VydmljZWFjY291bnQiOnsibmFtZSI6ImNsdXN0ZXItYWRtaW4tc2EiLCJ1aWQiOiIxNDc2NmNkNC1mZDE0LTQ1NjQtYWI4OC00OTYyOTVlNzU3NTIifX0sIm5iZiI6MTcxODk2MzgxMSwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50OmRlZmF1bHQ6Y2x1c3Rlci1hZG1pbi1zYSJ9.GP4I0_V39oBQ_fLVvLJDRIRUuB1V-oReydjYkXjpbuKIb9Hq3EbpUFhC68MKAd_Tdug-6zPrKKsk1obS6RuAeUXjksgO4iaYPDUx2xfp2KC7SM4qxm1zw2TZYUAhFRQn5A3qqVotSPIWb9506ek_Ct5-H46sPyGWfJKRkDbuC3Or9dENCee6JFM_WaYz1Hr1t9XaimD2PbCfnAhIPQKrVaFolgR08yjpqMPY11JMm738hhdIDErZuSjjySW6icIqfFrbBBqBasrUuKdQX_HtQ2p3szP-ukNQx9cphCwErobhBxQ8pJPyQ3ZCSbKqNE0AandR8_2SO-Zn8sdJywWFnA
Check the token information from jwt.io
Please keep this token to log in kubernetes dashboard URL or to communicate with the K8s cluster api through the infected container to run other specific command: Remember that kube-api is not open to the world, only accessible in a private network (see HLD above).
Open in browser, the https kubernetes Dashboard URL shows as output during the attack and uses cluster-admin token to log in
You now have full graphical access to the entire cluster. You are the cluster admin. You can :
- delete applications
- deploy applications
- modify cluster parameters
- lock the cluster, etc...
Note: if you have the warning below, trust the URL by typing this is unsafe in the Chrome browser page
Open in browser, the http hacked application URL. The url is available in the github-action output of the attack or from the kubernetes dashboard in the hacked namespace.
Hacked application
You can access the Kube API via the infected container.
You can run any kubernetes command (deploy, create, delete, etc...) via the GitHub actions 3 or 4.
Delete application deployment
$ kubectl delete -f deploy-vul-app.yaml
serviceaccount "secret-sa" deleted
clusterrolebinding.rbac.authorization.k8s.io "pod-sa-clusterrolebinding" deleted
clusterrole.rbac.authorization.k8s.io "secret-role" deleted
replicationcontroller "vul-app" deleted
service "vul-app-svc" deleted
serviceaccount "cluster-admin-sa" deleted
clusterrolebinding.rbac.authorization.k8s.io "admin-clusterrolebinding" deletedDelete namespaces created during the attack
$ kubectl delete ns hacked kubernetes-dashboard