Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New attack techniques: Kubernetes #550

Open
micahhausler opened this issue Aug 8, 2024 · 2 comments
Open

New attack techniques: Kubernetes #550

micahhausler opened this issue Aug 8, 2024 · 2 comments

Comments

@micahhausler
Copy link

There are other publicly known attack methods in Kubernetes, would be great to see documented and automated.

Cred Access:

  • Call token request POST /api/v1/namespaces/$NS/serviceaccounts/$SA/token with a cloud-provider scoped audience. This can be done if the kubelet's API credential is accessed for pods assigned to it
  • Run a pod in host networking mode to access cloud provider VM credentials

Persistence:

  • Run a pod or ephemeral container that copies binaries into existing hosts. Bonus points if you can write to a persistent volume thats replicated across host restarts
  • Create a CronJob with successfulJobsHistoryLimit and failedJobsHistoryLimit of 0 to delete the pod after running so it doesn't show up as an exited pod after completion.
  • Add a MutatingWebhookConfiguration pointing to an external C&C host. The server receiving the webhook request can mutate whatever resource is provided (pods, configmaps, secrets, etc)
  • Add a non-existent finalizer to a malicious resource to prevent it from being deleted
  • Modify an existing ConfigMap used as an init shell script in an existing victim pod
  • For victim daemonsets/deployments that have an imagePullPolicy: IfNotPresent, pull a malicious image to a host and re-tag it as the victim image name/tag

Defense Evasion:

  • Disable cloudprovider Kubernetes audit logs
@christophetd
Copy link
Contributor

Thanks a lot for the great suggestions! Do you have any thoughts on exploitation/usage in the wild (whether by attackers or pentesters) that would be helpful for prioritization?

@micahhausler
Copy link
Author

I don't have any data on usage, but in terms of accessibility to an attacker, changing an aud on a TokenRequest by a kubelet is the greatest current risk as the kubelet can legitimately specify whatever aud it wants.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants