Challenge 9 ☆☆☆

Welcome to challenge Challenge 9. You need to guess the secret that is hidden in Java, Docker, Kubernetes, Vault, AWS or GCP.

AWS Secrets Manager

Okay, now we’re generating a secret through Terraform and storing that with our Cloud Provider. What happens in the Terraform state?

You can try to find the secret by sniffing through your terraform.tfstate files using Trufflehog.

Answer to solution :

You can solve this challenge by the following alternative solutions:

  1. Dig through terraform.tfstate with Trufflehog:

    • After you have build the infrastructure following the instructions in the README of the aws folder, stay in that folder and run trufflehog3 --output=terraform-infra.json --format=json .

    • Now, open the terraform-infra.json file and start looking for the password.

  2. Find the secret in AWS Secrets Manager (this is the cheap way, try the other ones :) )

    • login to the AWS Console with the account with which you created the WrongSecrets setup.

    • go to the AWS Secrets manager

    • get the data from wrongsecrets1

  3. Find the secret by exec-ing into the POD

    • Make sure you have Kubectl installed as defined in the README.MD & make sure kubectl is configured to send commands to the right cluster.

    • now do kubectl get pods. Here you see all the Pods active in the namespace you are in, which is for this app normally default (unless otherwise specified by your administrator/trainer).

    • now for your instance of the WrongSecrets pod, do kubectl exec -it secret-challenge-<rest of the name of the pod from the prev.step> — sh.

    • now examinate the data which you can find in /mnt/secrets-store

Why you need to be careful with secrets in your cloud:

Secrets and terraform state:

Terraform state can be stored in many places: locally, on a cloud provider its storage solution, etc.. It can easily happen that secrets end up in Terraform state, as the systems which are created by it often needs to communicate with other systems for which it requires authentication. So, ensure that secrets are always encrypted in terraform state, or ensure that all secrets are stored in a secrets management system. Alternatively, ensure the secret is created in Terraform, but the value is set and managed through a different process.

Note that secrets are not the only reason not to let people access terraform state. TF state read access can expose configuration details to unauthorized eyes, while terraform write access can allow an attacker to setup a bogus state which, on the next terraform apply-run ends up with unauthorized changes.

Access to the Administrator/owner account: If you were able to use the AWS administrator account to access the data, then you can see why this is a bad idea for production. Because with this account you can change anything within the account, and you can easily exfiltrate any of the secrets.

Last but not least: we could easily exec into the container, to grep the mount with the secret. This has to do with 3 things:

  • we are allowed to do so by means of RBAC, which should not be your normal case in PRD: otherwise everybody of your organization can poke around in the container.

  • we are having executables within the container (sh/openssl/etc) which we can execute to setup a shell. Stripping your container from any non-necessary binary can help to reduce attack-surface and make it harder for any attacker that did an RCE at your container to jump to other places within the container to further gain execution.

  • we have exposed the configmap as an ENV. This means that anybody who got to the container runtime within the pod can now dump the secret. We brought the secret close to the consumer, but maybe not close enough yet (e.g. the app only).


0