That’s it, I pushed the secret key to github

Tram Ho

Story 1

One beautiful day, you engrossed in the project column, the work completed smoothly, you sent Pull Request and left.

Preparing to go home, suddenly there was a loud cry from the leader: “stupid pig, who pushes the secret key on github like this ???????”

From git log, you panicly realize that you are the killer, that’s it, what to do?

Story 2

Company X’s project is hosted on a private repo, people are only allowed to fork and create pull requests. All information is kept confidential.

One day, dev A resigned from his job.

To retain its code efforts, dev A silently copies the project’s code to its public repo.

At the end of the month, company X suddenly found AWS charged 50 thousand dollars

The company aggressively searched for the cause, finally discovering the AWS key was in public rep of employee A who was on vacation. Speechless.

Comment

I wonder if you can see your silhouette in the stories above in our programming life, we have probably made mistakes sometimes.

And not everyone is lucky.

There are many cases where a product is developing or even running and has been revealed a secret key, password, api key, private key, mnemonic or other sensitive information that has led to thousands, even goods. million dollar.

My team has also been exposed, and the damage is quite large, please do not disclose the number

You may not know it, but on the internet there are always tools running 24/24 just to scan such key leaks on information storage platforms such as github or gitlab, bitbucket … so fast that we can lose After less than 1 minute after the reveal key.

Even if our repo is private, the risk is still from the human factor (story 2).

And protecting the security key is always a top priority, from thinking (mindset) to action (actions).

Solution

So now how to not reveal the secret key ?

The answer is simple: do not put the secret key on github or anywhere else.

So we accidentally put up the secret key then how to handle it now?

The answer is disable and thoroughly delete it.

Disable

If you are using this secret key, api key, or password anywhere, immediately change the password, disable the api key at all services being used.

Born yourself a new key / password, absolutely do not use the old anymore.

Thoroughly erase

When I first started programming and became familiar with git, I often encountered this problem: Quickly delete the secret file, make a new commit, and push it up? As if nothing had happened.

This is a completely wrong handling. When we enter the commit history, we will see that the secret file remains in the old commit. Hopefully no one of us makes that rudimentary error anymore.

Once familiar with and experienced with git, we know that git stores tree history, commits after previous commits, meaning that to change the content of a commit, we will have to rebuild the entire history from the commit. that’s on (sounds like blockchain).

Now we have a more effective way than before: Use the tools to rebuild the commit history, make sure that the secret file is not contained in any commit, and then push the force onto the repo.

There are several things that can help us with this: git filter-branch or use an open source tool called BFG Repo-Cleaner .

One thing to note is that because commits are rewritten, their entire hashes have been changed. This can affect pull requests currently open on the repo. So we should merge or close all pull requests on the repo before proceeding to remove the file to change the commit history.

Delete a file from the commit history

1.1 Use BFG Repo-Cleaner

We will proceed to download and install according to the homepage here: https://rtyley.github.io/bfg-repo-cleaner/ .

BFG Repo-Cleaner is a tool built and maintained by the open sources community. BFG Repo-Cleaner provides a quick, simple way to delete unwanted files with many options.

For example, we can delete unwanted files (containing sensitive information) but still retain the last commit as follows:

Or, to replace text inside a password.txt file, for example, we can use the following command:

BFG Repo-Cleaner offers many other options, can be found at BFG Repo-Cleaner.

1.2 Use git filter-branch

To illustrate how git filter-branch , we will make an example of deleting files containing sensitive data on one of our repos.

  • clone repo about

  • into the repo

  • delete the file in the commit history, remember to replace PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA with the secret file we want to delete.

  • Double check that the file has been completely deleted at all commits
  • push force again to commit history

  • push force all git tags to avoid disclosing information in the release versions of the repo

2. Put the secret file into gitignore

After we have deleted the secret file from the repo, we need to add that file to the .gitignore to make sure that we will never miss a commit again.

3. Delete github cached view

We deleted the old commit, rebuilt the commit history, the secret file no longer exists, so is it safe?

The answer is no.

In fact, github has a mechanism, which is cached views , although there are no more commits on the repo, but if there is a commit hash, we can still see it as usual . Or through old forks and pull requests, we can still see all the information of the old commit, including the secret file we pushed.

Readers can verify this by themselves as follows:

  • Open the last commit of the repo in the browser
  • locally delete old commit (by git reset or check out to previous commit)
  • push force onto the repo, make sure the repo is no longer committed in step 1
  • Refresh the browser in step 1, we will see the commit content remains intact as there has been no erasure here.

Toang !!!

How to handle this pile? Github Suggest gives us a final solution, which is to contact GitHub Support and GitHub Premium Support so that they can delete cached views as well as all references to sensitive data in the pull requests on github.

When this new old code really disappears from our repo.

But does it exist in the github database or not … only github knows.

4. Collaborator rebase code

Now with the team, make sure other collaborators will update the latest code with rebase , not merge . Because if you use merge, the old history containing the commit with the secret (on the collaborators’ machine) will be merged with the new history we just rebuilt. So, putting up everything we did before will be successful.

When using rebase , the commit history will be guaranteed to be the new history starting from the commit we rebuilt.

5. Delete junk

Finally, when everything is stable, we will remove all the backup objects we created by the git filter-branch above, cleaning our git:

Conclude

Summarizing the handling steps as follows:

  • Disable all keys, change passwords (also notify related parties to do the same).
  • Rebuild the commit history since the commit has been revealed.
  • Put the secret file into .gitignore .
  • Conduct push force to update repo history.
  • Message the collaborators to conduct a rebase.
  • Contact GitHub Support and GitHub Premium Support to remove cached views and all references.
  • Clear junk to clean git.

Be careful and always keep your key / password / mnemonic safe.

Consider each of your commits worth thousands of dollars.

Refer

Share the news now

Source : Viblo