Do you know it is easy to impersonate other users on GitHub if you have write access to any repository? I will show you an example, and how to protect from that.

Impersonating Paul

Letā€™s start with an example, where I am trying to impersonate my friend Paul in our repository called impersonation-example. I have write access to the repository and Paul could be a random GitHub account (no need to be part of organization or have any access to the repo). At the beginning, the repo is empty with no commits.

Empty repository

Knowing Paulā€™s GitHub email address, I can change my local git configuration as presented below.

Impersonation

When you look at the commitā€™s list on the GitHub repository, you will see that this commit looks like it has been added by Paul!

Impersonated commit

This sounds like a critical vulnerability, but is it? Well, no. GitHub is simply a place where you keep any git repository that you actually fully control.

That means, you can change your configuration to any values, including otherā€™s emails. You can do it locally at first and then (even after a year) publish that on GitHub. How does GitHub know whether that commit was really added by the owner of the used e-mail or not? Itā€™s not that easy.

However, the problem is not the prank within the company that I presented here. The vast majority of teams working on projects in our ecosystem are decentralized (maybe even more than other things ;)). They do not have offices, and co-workers know each other in many organizations by avatars and nicknames.

The Tornado Governance Hack example showed how "carefully" proposals are read, and the issue of using someone's reputation only makes matters worse. You look at a commit added by a random person in a different way than at a commit added by a core developer.

This can lead to disastrous consequences and leaves plenty of room for hackers and insiders.

Commit signature verification

So there is no rescue for such impersonation? There is! It is called commit signature verification. Letā€™s see how to make sure the commit was submitted by the real owner of the presented GitHub account.

First of all, you have to generate a GPG key. To do that you can use the gpg tool with the following command:

gpg ā€“default-new-key-algo dsa ā€“gen-key

You are going to be asked for a password that will protect the key. Make sure that nobody is able to see your screen when you generate the key and you do not share the password with anyone!

Generating the key

Then, you need to export it in a human readable format by following command:

gpg ā€“armor ā€“export <KEY-ID>

Exporting the key

Now, you have to assign it to your GitHub profile.

Go to your profile Setting > SSH and GPG keys and use the New GPG button. Name your key, paste it and confirm.

Adding the key to GitHub

Now, you should have your key added and visible on the GPG keys list.

Key added to GitHub

Besides GitHub, you must also inform git that it should now sign all commits with the generated key using the following commands (see example on screen below):

git config user.signingkey <KEY-ID>

git config commit.gpgsign true

Note: you can add --global flag to apply this config globally, meaning that from now on, commits in all repositories will be signed.

Now you can add a new commit. You will be asked for the password that was used to protect the key.

Adding signed commit

Letā€™s check what it looks like.

Signed commit

You can see 3 commits I submitted from the same account without any additional permissions (ordered by commit date descending):

  • the last one is the impersonation I have presented before,
  • the middle one is my legitimate one, but you cannot actually verify it,
  • finally, the first one (the recent one) is signed and has the "Verified" label meaning that it has been signed with my GPG key.

Summary

This impersonation is not critical, because it does not bypass the authorization. Moreover, people can pick this up on peer review.

However, it is a good example of how best security practices help build multiple layers of security. Besides, this one can be added easily and that is why we recommend doing it for everyone.

Here is the GitHub page explaining deeper the commit signature verification: https://docs.github.com/en/authentication/managing-commit-signature-verification

  • Did you like this article? Share it on social media!

Composable Security šŸ‡µšŸ‡±ā›“ļø is a Polish company specializing in increasing the security of projects based on smart contracts written in Solidity. Examples of projects that have trusted us are market leaders such as FujiDAO, Enjin, Volmex Finance, DIVA Protocol or Tellor. We are creators of the Smart Contract Security Verification Standard. Speakers at various conferences such as EthCC, ETHWarsaw, or OWASP AppSec EU. Authors of numerous publications on DeFi security. Experienced auditors operating in the IT Security space since 2016.

If you need support in the field of security or auditing smart contracts do not hesitate to contact us.

Damian Rusinek

Damian Rusinek

Managing Partner & Smart Contract Security Auditor

About the author

PhD, Speaker, Co-Author of SCSVS and White Hat. Professionally dealing with security since 2009, contributing to the crypto space since 2017. Smart contract security research lead.

View all posts (13)