Many secrets are routinely accidentally released into public repositories.
During last year, number of secrets revealed your GitHub is certainly very important, but what really gets attention this year is what happened after the secrets were identified.
What is a zombie secret?
This term was coined after an observation: owners of code repositories often respond to a sensitive leak by deleting the repository or making it private, with the idea of ending public access to the problematic information.
The problem is that in doing so they can create a serious security breach for themselves or the organization they work for: they can create a “zombie secret”.
A zombie is created when a secret is revealed but not undone, thus remaining a potential attack vector. The author of the commit may think that it is sufficient to delete the commit or the repository, thus skipping the crucial step of undoing.
But let’s be clear: the only way to remove the risk inherent in leaking a secret is to remove all permissions associated with it. That’s exactly what cancellation means in this context. In this way, the secret becomes as harmless as any string of characters.
Declassifying the code, on the other hand, has absolutely no impact on the company’s security posture, since it has no control over the “distribution” of that secret (yes, even if the secret was exposed within a “private perimeter”). Even worse, it can make the job of security professionals trying to fix this type of vulnerability more difficult, if not impossible, because the leak is now invisible.
Let’s imagine the following scenario: a developer accidentally commits the .env file containing his company’s production secrets to his personal GitHub repository. Quickly realizing his mistake, he made the deposit private.
Feeling guilty and embarrassed by the mistake, he is reluctant to disclose the incident to his security team and believes their response was quick enough to mitigate any risk of compromise. Who could find that needle in a haystack that is GitHub after all?
Months later, the company’s security team conducted an audit to assess its exposure to GitHub. To this end, it sends a security questionnaire to all software engineers, asking them to declare whether they have a GitHub account.
Based on this, the security team then proceeds to scan all public repositories for leaked credentials. The problem is that they won’t see the leaked .env file because it’s gone from the public part of the platform. This vulnerability is no longer available to them unless they use a tool that can query the full GitHub history.
On the other hand, a malicious player might have discovered the .env file and the hard-coded credentials (there is more than a 50% chance that this file extension contains valid secrets). He then has many opportunities to use them to achieve his goals.
This is a typical example of a zombie secret leak: the secret exists, but no one (well-meaning) is actively monitoring it or taking steps to undo it.
There are many secrets about zombies
Services exist to alert code repository owners when they detect secret leaks in their public Git commits. In the five days after discovery, checks are made and repeated to determine if these secrets remain valid.
More than 91% of leaks remain valid after five days1 and this figure is alarming. Many repository owners deleted or made private their repositories after notification, but did not reverse the leaked secret.
A random selection of 5,000 repositories that were declassified within five days showed that 28.2% of repositories were still public, while 71.8% had been deleted or made private.
While it is difficult to speculate on the prevalence of zombie secrets, these clues suggest that they are quite widespread.
Secret leaks are high-risk vulnerabilities
When talking about secrets, it’s important to remember that any hard-coded active secret is a very high-impact vulnerability until it is revoked.
Although it seems obvious, it is important to prioritize this type of vulnerability over other application risks, such as the popular OWASP Top10 or the more recent OWASP Top 10 Open Source Software Risks.
Stealth leaks are a unique type of vulnerability because the potential threat they pose to its own lifecycle is completely independent of the source that hosts it. This means that a leaked secret does not cease to be a threat when:
● the application in which it is integrated stops working,
● the code, where it is hard-coded, is overwritten or made private,
● the message where it was shared is deleted,
● the disk where it is stored is permanently encrypted.
Why a high-risk vulnerability? Let’s take a look at the Common Vulnerability Scoring System (CVSS).
The highest level of risk is defined as follows:
Critical (9.0 to 10.0): These vulnerabilities are typically easy for an attacker to exploit and can lead to unauthorized access, data breaches, and system compromise or disruption. As with high-risk vulnerabilities, immediate attention and mitigation is recommended for these vulnerabilities.
The main difference between critical vulnerabilities and high-risk vulnerabilities is that exploiting a high-risk vulnerability usually results in the compromise of the core level of servers or infrastructure devices.
Expired credentials that remain active fit exactly this definition and are critical vulnerabilities at best.
How do we prevent secrets from turning into zombies?
They should be cancelled. It’s easy to say, but not so easy to do. But it is nevertheless essential.
Here’s an overview of the four-step process for organizations:
1. Get their secret management in order. This may include using an .env file, removing it from version control, or using an external secret manager such as CyberArk, AWS Secrets Manager, or HashiCorp Vault.
2. Generate a new secret to replace the leaked ones. Test your new code carefully to make sure everything works correctly with the new secrets and secret management tools.
3. Put the new code into production by removing the old secret(s).
4. Revoke the leaked secret and remove all permissions associated with it.
There is one thing we never emphasize enough, and that is necessity apply practices and procedures to detect and remove leaked secrets before they become a danger to the company and its customers.
