Consider this security scenario: Attackers gain access to developer or sysadmin accounts. They find and target the revision control system that is used to manage system configurations, internal code, or even software that is shipped to customers. The attackers use the compromised accounts to modify the source code and insert back doors or logic bombs. Now ask this question: How long will it take the organization to notice?

This scenario may seem far-fetched, but think about all of the breaches of software vendors you've read about: Adobe, the victims of Aurora, APT1, etc. Who says they only had their code read?

Repository Tampering

Malicious attackers who gain code repository access can do quite a bit of damage--and they can do it without anyone noticing. That's why we've been studying repository tampering attacks that bypass standard controls, and developing tools that can detect and pinpoint them.

Many people we talk to don't really grasp the problem at first, or they think that their existing monitoring or development workflow can detect repository tampering. But standard controls are insufficient against the kinds of attacks we have been studying.

There are two kinds of repository compromise scenarios. In the less severe case, an attacker has compromised an account that only has remote commit access to the repository. In the second and worse case, an attacker has compromised an account that has--or can get--write access to the repository's filesystem.

Remote Commit Access

In the case of an attacker with just commit access, the Source Code Management (SCM) system ought to prevent most outright tampering: if there's no remote SCM command with which to change history, then an attacker with only remote SCM access can't change history. However, it's likely there are still other ways the attacker can subvert the codebase.

One way that an attacker can subvert the codebase is by re-introducing previously fixed security flaws. When a bug that causes a security flaw is fixed, the revision including that fix is tagged for publication. But most SCM tools allow developers to move tags--including moving them backwards. So an attacker with just remote commit access can simply move the tag to an earlier revision that doesn't include the fix. At that point, the organization is shipping code with a known security vulnerability--without even realizing it.

Direct Repository Filesystem Write Access

Attackers who manage to obtain direct write access through a compromised account or other infrastructure flaw have much more freedom. Many people think that their SCM tools would notice any direct tampering. But if the attacker is careful to follow the proper syntax, they can make changes that will go entirely unremarked.

For instance, they can introduce new revisions while updating the HEAD pointer directly, which would bypass conventional notification systems or QA build hooks. Developers, expecting to be "covered" by those things, will happily pull the latest code and move forward.

Worse, the attacker could introduce changes to existing revisions--allowing them to embed new vulnerabilities in any future patches to previously shipped software. To do this, they would need to be careful to update the appropriate bookkeeping metadata. They would also need to avoid warnings being output to developers working on the current version of the code, which they could do by simply reversing their changes in subsequent revisions. That way, the current version would be consistent with what the developers and their tools expect, but anyone pulling the older revision to make a bug fix will get the poisoned code--which they will then unwittingly ship to customers.

The Bottom Line

The threat of repository tampering is real. The industry has been slow to recognize the danger, but we think that needs to change. Not only do organizations need to care about the integrity of their own code repositories, but they need to be concerned about the repositories of the vendors whose software they run. Supply chain attacks have been getting more attention in recent years, but this is an aspect of that threat that has so far gone largely unnoticed.