Why you need to be careful with CI/CD and secrets
When using CI/CD tooling, you often need to let the tooling (e.g. runner/agent that executes a job) use a secret to authenticate to a secondary service. Exfiltrating these secrets can become quite interesting.
There are various ways to do this:
-
run a CI/CD tool in debug mode, or request more env vars, which, in turn, might be readable to everybody who has access to the build(log)
-
use exfiltration techniques such as the ones useful in this challenge to get the secret, which might be readable to everybody who has access to the build(log)
-
Use your access rights as an admin/maintainer of a repository or project to get the secrets.
Thus, it is vital that you:
-
Limit who has access to the job runs/job configuration/actual secrets
-
Log all actions of the system and alert on any exfiltration actions
-
Make sure that you have no long-living secrets in your CI/CD setup
Want to know more? Check the resources at the resources on the home page of the app.
Why Crypto is still very hard
As you can tell from the Challenge13 source code: we selected a pre-defined IV. We did this to ensure we would end up with the same ciphertext every time.
One could argue that this is a bad instance of Convergent Encryption.
This convergent encryption has a benefit: you can now tell whether a secret has changed if you have a fixed key and IV. However, this will get you into trouble if secrets are too short. You will end up with a collision when trying to find the plaintext by encrypting various plaintext pieces hoping to end up with the same ciphertext.