Leaking secrets is bad, right? Not everyone fully understands the consequences of secrets committed to source code. It’s my aim in this article to prove out what could happen if a secret is leaked to a public repository. On May 9th, I set out to do that and decided to analyze a two week period. I uncovered 20 attempts to exploit these secrets since April 20th, 2022.
Key fact you should know: Within 4 minutes of the commit there was an attempt to use the secret. 20 minutes later 8 different attempts were made. The bad actor not only successfully scraped the API secret but has also attempted to login.
The remainder of the article explains what happened.
Notice I’ve created a repository that is Public.
It’s worth noting that it has only 11 commits in it’s history. A miniscule repo compared to most. Next, I used canarytoken.com to generate a fake AWS key. Anytime there is an attempt to login using the AWS ID / Key it triggers an email alert.
I then committed this secret to a newly created child branch in the repository.
Elaborating on the results we discussed earlier – within 4 minutes of the commit the first attempt to use the token was alerted, 20 minutes later 8 different IP addresses. Keep in mind each triggered alert means a bad actor not only successfully scraped the API secret but has also attempted to login.
It’s noteworthy that in fact this was a child branch in a repository with just 11 commits in its history. It’s fair to say bad actors are continuously scanning open source repositories for vulnerabilities including low hanging fruit such as secrets.
You may be thinking that this is a public repository and it’s unlikely to happen because perhaps most of the organization’s projects are private or the code server is on-premise.
Here are some scenarios that could lead to these secrets in private repositories being exposed:
- Bad Permission Hygiene
If permissions are not carefully audited internal developers / contractors can potentially gain access to repositories they shouldn’t. If these repositories contain secrets to high value assets a bad actor could escalate privileges and cause damage. We’ve also seen incidents where private repositories have been unwittingly made public by developers.
- Code Leaks
Developers at times commit code to personal or open source projects. Think of a situation where a developer needs to test functionality in a new feature and is getting restricted in the enterprise environment. They then commit the code into their personal repository to track changes and only upload to the enterprise later.
- Exposed Source Code Via Breach
More and more we’re seeing ransomware attacks and leaked source code by criminal groups.
How to Protect Yourself
Proactive learning is the first layer of defense. To protect yourself against these risks ensure developers are taught best practice for storing secrets including never committing secrets to source code, using a secrets manager or using at the very least using environment variables.
With BluBracket it’s easy to determine where in the source code secrets are exposed as well as by who. It’s often the majority of alerts are generated by a relatively small group of users. Identifying where and who helps any organization target their training to those that need it most.
Additional hardening can be done by implementing scans within the developers workflow and scanning the repository assets on a continuous basis.
BluBracket integrates steady state scans with continuous monitoring such that the entire git history and any ongoing commit diffs are automatically analyzed for risks.
BluBracket scans code present in git repositories to protect software supply chains by preventing, finding and fixing risks in source code, developer environments and pipelines. For more information on BluBracket please visit https://blubracket.com/products/enterprise-edition/
