Challenge 37 ☆☆

Welcome to challenge Challenge 37.

Giving your security tests access

Given all the daft findings we already have in this project, we decided to implement automated scanning using ZAP. To do that, we need to be able to fuzz the endpoint of this challenge: /authenticated/challenge37 and thus configure basic auth for ZAP. Can you find the secret returned at the endpoint?

Hint: We use GitHub actions.

💡 Tip: Secrets are often strings, numbers, or encoded values. Copy and paste exactly what you find.

This is a CI/CD configuration challenge. You can find the answer by authenticating to the protected endpoint with basic auth and getting the value:

  1. Use a browser to get the secret:

    • First, go to the Github Workflow

    • Find the environment variable with which we configure basic auth for ZAP (ZAP_AUTH_HEADER_VALUE)

    • Decode the base64 encoded value of the header

    • Navigate to /authenticated/challenge37 and fill in the username and password you retrieved from the previous step.

  2. Use CURL to get the secret

    • First, go to the Github Workflow

    • Find the environment variable with which we configure basic auth for ZAP (ZAP_AUTH_HEADER_VALUE)

    • In your terminal, do curl <domain where this is run>/authenticated/challenge37 -H "<basic_auth header of previous step>" where <basic_auth header of previous step> is the value of the ZAP_AUTH_HEADER_VALUE you found.

Why we need to be careful with security credentials in CI/CD

People who can access the configuration of your security checks in your CI/CD environment can easily access any credentials configured there. These credentials can then be used for anything.

This is why security should be very careful in managing their secrets: just because the credential is used by (a) security (tool) does not mean we can tolerate less security ;-).

What to do instead: - Store CI/CD credentials in the platform’s protected secret store or use short-lived workload identity, and grant each job only the permissions it needs. - Restrict who can change pipeline configuration: make sure configuration files (Workflows of ci files) are having CODE-OWNERS, require to be set on a protected branch, and limit maintainer/owner access to a repository. - Restrict who can see a pipeline its logs, mask sensitive output, and rotate credentials that may have been exposed.