GithubSpoofCommit

Intro

Developers looking for an open source project are more likely to choose one that is active and maintained, and more likely to trust long-time developers with a track record of activity in the past few years. GitHub makes it easy to assess this by providing much of this metadata. Unfortunately, some of these data points can be easily forged.

https://checkmarx.com/blog/unverified-commits-are-you-unknowingly-trusting-attackers-code/

Details

One of the building blocks of the Git version control system are the commits. GitHub’s documentation describes commits as follows:

As this points out, in addition to the data itself, which is the changes to the code, commits also includes metadata. This metadata comes in the form of timestamp and the identity of the creator. The issue is that both can be forged.

Falsified Commit Date

As mentioned, each commit on GitHub is attached with its own timestamp indicating when it was committed. However, this timestamp can be easily manipulated, meaning we can make commits look as if they were done in a different time other than the moment they were actually committed. To achieve that, all we have to do is alter two environment variables on the local machine with the command “git set”

Committing some changes with these environment variables and pushing them to GitHub will result in the following:

In this example, it’s worth mentioning that the fake timestamp predates the creation of both the user committing it, and the repository it was committed to.

What can we do with this?

Due to this lack of verification for timestamps, a malicious user can appear credible by making it look like they have been extremely active for a very long time.

A prominent measure of user activity on GitHub is the “activity graph” presented on the user’s profile page. This graph is essentially a heatmap showing the user’s activity through time. Hence, if we are able to fabricate commits with any timestamp we want, we can fill this graph with falsified activities.

If we go on with our previous example, fake commit in April 2010, we can see that the activity graph is as follows:

At this point, there is nothing preventing us from automatically generating fake commits and fill our graph of 2010 to look however we want.

Since the activity graph displays activity on both public and private repositories, it is impossible to discredit these fake commits, and therefore, this deception technique can be hard to detect as well.

Adding Spoofed Contributors

In a similar manner, it is also possible to spoof the identity of the committer and attribute a commit to a real existing user account on GitHub. For example, we could use the reputation of one of the top contributors on GitHub and push a commit on their behalf.

Spoofing commits to make it look like they were done by any user we choose is relatively simple:

1 - Find out the user’s email address

Although GitHub offers ways to prevent a user’s email from being exposed, they require the developer to opt into these features and are mostly not used. In order to find out the user’s email, we can manually follow the below steps or even automate them.

• Looking for an authentic commit of the user following this URL pattern:

1

<a href="https://github.com/<username>/<repo\_name>/commit/https://github.com/<username>/<repo\_name>/commit/<commit\_hash>

• Add the string “.patch” at the end of the URL, like so:

1

<a href="https://github.com/<username>/<repo\_name>/commit/https://github.com/<username>/<repo\_name>/commit/<commit\_hash>.patch

• browsing to this address will yield a result similar to the one below which will include the user’s email address.

2 - Set the username and email on git CLI

3 - Commit changes

What can we do with this?

As shown a few weeks ago by Aqua, the NPM package manager allowed package owners to add to their package any contributor they would like, and enhancing their project reputation and credibility by doing so.

By spoofing the identity of the committer, this can be done for GitHub repositories as well. To make their project look reliable, attackers can use this technique once or multiple times and populate their repository’s contributors section with known reliable contributors, which in turn, makes the project look trustworthy.

What makes this commit spoofing even more alarming is the fact that the user being spoofed isn’t notified and won’t know that their name is being used.

Verified Commits

To mitigate the risk of spoofed contributors described above, GitHub introduced “Commit Signature Verification”. This feature allows users to cryptographically sign their commits so their contribution can be checked and verified as their own’s and not of an imposter. However, this feature only verifies the signatures themselves and not their existence. If a commit isn’t signed it won’t be flagged in any way.

To increase the effectiveness of this feature in alerting of unverified commits, it is possible to enable “vigilant mode” which will display the verification status of all of your commits, including the ones that were not signed at all. This way, it is easier to spot attempts of this impersonation.

Conclusion

In this blog, Checkmarx SCS team detailed two ways in which threat actors can leverage GitHub’s features to trick developers into using repositories with potentially malicious code.

The metadata on GitHub helps developers make decisions regarding the usage of certain repositories.

Hence, fake metadata can mislead developers to use code they would knowingly not have used, and can potentially encompass malicious code.

The lack of validation of the committer identity and the commit’s timestamp is an issue by itself, but it also enables ill-wished actors to leverage it to gain credibility to their users and repositories.

GitHub offers a solution for verifying committers’ identity, but it requires active involvement from developers and can be expended to include more protective measures.

We encourage developers to sign their commits and enable vigilant mode on their user, steps that will help make the ecosystem safe.