Thinking About Secrets

Introduction

We have two types of projects that often uncover secrets being shared in ways that aren’t well thought through.

1. During code review, it is actually rare that we do not find some sort of secret.  Maybe a database password or maybe an ssh key.  Sometimes, it is AWS credentials.  We’ve even built our own code review assist tool to check for all the ones we commonly see.
2. During security engineering or appsec automation projects we end up wiring static analysis tools to source code and JIRA and this often uncovers plaintext secrets in git.

So, generally, plaintext secrets are everywhere.

Best Practice

I said above that people are sharing secrets in ways that aren’t well thought through.  Let me expand on that.  If all of your developers have access to secrets, that’s a problem.  Of course, most developers aren’t going to do anything nefarious but they might, especially after they leave.  Most companies have a further challenge that it is very difficult to change system passwords.  So .. developer leaves the company and chances are low any secrets are changing.  Suppose a laptop with source code on it gets stolen?

The other problem with having secrets around is that it makes it easy for an attacker to pivot and find other things they can target.  Suppose I get code execution on Server 1.  If all of the secrets Server 1 uses are stored in files on the server that the code uses, it makes that pivot to get on Server 2 via SSH or pull data from DB Server 3 trivial.

Testing

Here are two instant ways to look for secrets in your code:

docker run owasp/glue -t sfl https://github.com/Jemurai/triage.git

This runs a check for sensitive files that are often in the source code.

docker run owasp/glue -t trufflehog https://github.com/Jemurai/triage.git

This looks for entropy in the files in a project.  It can take a while to run but is a good way to find things like keys or generated passwords.

Nothing beats a person that is looking carefully and knows what to look for but grep is your friend for sure.  We try to find these and offer alternatives for storing secrets.

The Alternatives

Generally, we want to keep secrets in a place where:

• People can’t just go read them
• It is easy to change them
• We know if anyone uses them (audit)

We see a lot of projects adopting Vault and tools like it to store secrets.

Even better is a scenario where credentials don’t even exist but get generated for a particular action and then automatically expired.  Ideally, we require MFA.  99-Design’s AWS-Vault does this with AWS and its sessions in an elegant way.  This pattern, in general, allows us to know that there aren’t existing passwords out there that people could use without our necessarily realizing.  It also reduces the challenge of responding to a stolen laptop for example.

References

• An older reference from a ThoughtWorker:  https://danielsomerfield.github.io/turtles/
• A tool:  https://www.vaultproject.io/
• Another tool: https://github.com/99designs/aws-vault