Challenge 44 ☆☆☆☆

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

Vault Metadata Challenge

Secrets management systems now often have metadata support for their secrets! This is awesome, as it allows you to enrich the secret with contextual data further, making it easier to remember the secret.

But what if you put confidential/secret information into a secret by mistake?

A developer has put secret metadata on a wrongsecret in Vault. Can you find it?

Tip: take a look at the policies when vault is installed; you can see that the application is only allowed to use the metadata ;-).

Answer to solution :

This challenge can be solved using the following steps:

  1. Find the secret with the commandline

    • use kubectl exec vault-0 -n vault — vault kv metadata get -mount=secret wrongsecret take a look at the metadata: do you see a map with a secret? that’s the value you need to enter

  2. Find the Secret in Vault using the logged root token:

    • When you setup the K8s environment, the script tells you the value of the root token as below:

      Key                  Value
---                  -----
token                s.Jqka4lSy8ayQw2LFsvyAgnTI
token_accessor       HEr9RYa3OcZNDOHeFRXIMYCV
token_duration       ∞
token_renewable      false
token_policies       ["root"]
identity_policies    []
policies             ["root"]

    • Use the token to login into Vault exposed at port 8200

    • Take a look around: can you find the location of the secret in the secrets overview?

  3. Find the secret as the SRE member

    • go to the vault web interface

    • login with in with username "helper" and password "foo"

    • find the actual secret.

Why putting sensitive data as metadata is a bad idea

Sometimes, people reason that less sensitive data should be stored as secret metadata. Think of, for instance, a username - less sensitive than a password, or is it? In many of these cases, these are equally important and should get equal protection as the secret (e.g. the password) itself.

We often don’t want to give read access to secrets to our employees, but we do want to give read access to metadata instead. If any secret is stored in the metadata, that secret is then compromised internally.


Previous
Go the main page
Next
0