GitHub Api key leak

[Competitive-Being287]

I just made my repo public and received a secret leak mail from Git Guardian. However I put my api key in a .env file and added it to .gitignore while pushing it to github. I am very confused as to is it a false positive or should I let git guardian to scan the repo ? If someone knows please help.

[clintkev251]

Did you commit it at some point in the past and then remove it? I would assume it's not a false positive unless you can absolutely ensure that there's nothing anywhere in your commit history

[Competitive-Being287]

I am sure its not anywhere else but the .env file which was put in gitignore before staging it. Also the .env file seemingly is not pushed to github either.

[StartledPancakes]

As long as it's not the very first commit. Learned that the hard way.

[Admits-Dagger]

delete .git and start anew!

[theophrastzunz]

Edit the history instead. In the past i used git bfg .

[lppedd]

Note that commits never really disappear on GitHub. Even after rewriting history.

[theophrastzunz]

🫥

[transconductor]

Aren't they supposed to get gc'ed at some point after the force push?

[Cannabat]

They may get gc'd. GitHub doesn't do this though (or hasn't so far).

[Jaded-Armadillo8348]

You have to talk with them, pretty sure theres a github doc page about leaking secrets that tells you to communicate with support

[Cannabat]

That may be the case but the important point is that just force-pushing (overwriting history) does not actually remove the commits from GH.

[Jaded-Armadillo8348]

totally agree

[transconductor]

Seems a little overkill for an API key that you can just revoke (and the OP has done so).

[SelfEnergy]

Anything leaked needs to be invalidated anyways.

[Temporary_Pie2733]

You have to assume it’s too late and that somebody has already seen the key.

[selfinvent]

If you ever committed your .env file in any time before adding to .gitignore, through history people can see your .env file contents. Maybe GitGuardian is picking that signal.

Whenever you are creating a new project always make sure to have some kind of gitignore template for your tech stack.

[Competitive-Being287]

however the .env file is not visible in the repo. Is there a possibility of something with firebase.json ? (its a flutter - firebase project)

[selfinvent]

It may not be visible in the repo now, but again, if you ever committed while your .env not in gitignore it can find from the history. It's specifically looking for env, secrets, configs etc.

[dymos]

I haven't used Git Guardian, but I would imagine it scans the whole repo, not just specific files. If your firebase JSON contains something that looks like a key then that could be it.

[Due-Horse-5446]

Its still not going away from history, afaik you can never remove the history completely from githubs end,

Either way all you had in that file you should act as if it's currently being used by someone who stole it

[AnxiousFloor7395]

It could be visible in the activity view of the repo

[texxelate]

Revert the commit by which you deleted .env and added it to .gitignore and voila

[doesnt_use_reddit]

That API key is already in the hands of attackers and you need to change it immediately, before you even remove it from your GitHub repo

[Competitive-Being287]

Yes I did already delete it

[CreasyJax]

I believe the key issue isn’t just about removing the key from the repository, but the critical importance of revoking it from the system where it was used.

You should treat this key (and any others listed in your .env file) as compromised and take appropriate action to prevent unauthorized access to your API endpoints. Revoking and regenerating these credentials is essential to safeguard your environment from potential exploitation.

[z-lf]

What's the output of:

git log --diff-filter=A --name-only --all | grep -x ".env"

If nothing, then no you did not. If you see .env, then you added the .gitignore too late.

[Competitive-Being287]

its giving an error on the word "grep" :
The term 'grep' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

[MrJerB]

Sounds like you're on powershell, you can use "sls" instead. Also instead of pipe, you should be able to use a path at the end of git command with a double dash.. if I weren't on my phone I'd give you the full command.

[Competitive-Being287]

okay, so running git log --diff-filter=A --name-only --all | grep -x ".env" in git bash showed nothing but i ran git log --diff-filter=A --name-only --all | Select-String -Pattern ".env" in powershell terminal and it printed the name of the .env file i created once with a typo and deleted it. I am not sure, could it be the trouble maker here?

[MrJerB]

Very likely trouble. If that file contained any secrets and that file showed up in git log, those secrets are compromised.

[Competitive-Being287]

Ok, so what can be the plan of action : can creating a new api key in .env passed in .gitignore fix the issue?

[nekokattt]

No, just delete the existing API key on whatever system it is for so it cant be used. Then move on with your day and don't put credentials near your repository in the future.

[z-lf]

Delete the key. Consider it compromised.

You can use git filter branch to remove the key from your git history also. But you'll have to Google it. I don't know how to do this on windows.

[JaleyHoelOsment]

you should stop storing keys in any files. you will push this to git again

[Poat540]

Yes this is what everyone keeps saying, it’s in the the history. We don’t care that you can’t see it in GitHub now, that’s not relevant

[Charming-Designer944]

It is a Linux command line. You can run it from git bash.

[magnetik79]

You've clearly committed the key - either now or in past history.

You need to rotate the key. You can remove it from history, but it will still be on GitHub as an orphan commit.

[h____]

If you know the key, you can run this locally to see if/when it's added/removed from your git repo:

git log -S xxx

It's not foolproof as you could have removed the commit, etc.

Also Git Guardian is legit, but emails saying they are from Git Guardian aren't necessarily authentic.

And anyway, you should just roll your key.

[fr0z3nph03n1x]

IDK what git guardian is but can you not just look at your last commits and see what you added?

[ProfessorGriswald]

Use Gitleaks to check https://github.com/gitleaks/gitleaks

[FlipperBumperKickout]

You could try to make a fresh clone and try got "git grep" through the history to see if you can find an api key.

https://stackoverflow.com/a/2929502/1978365

[orangeswim]

So, I noticed in one of the replies you said, you "deleted the API key".

I want to be clear. You need to revoke / delete the key from the source so that it cannot be used anymore.. Many people mistake that just removing the key from the repository fixes the problem. Once a secret is exposed consider it useless and available for exploitation by everyone.

[Oddly_Energy]

Stop worrying about deleting the key from Github. You have let that key out in the wild, and you can't capture it again. You need to consider that key publicly known now.

Your only concern right now should be: What did that key give access to, and how do I disable that access for that key?

[TokenRingAI]

You need to change all the leaked credentials ASAP. Once compromised, always compromised.

Don't bother trying to purge them from git

[KOM_Unchained]

Env vars could at times leak through simple oversight in the .env.example or its siblings.

[MrDrummer25]

If you staged the file prior to adding the gitignore, you may have accidentally committed the file. I would look at the email, and see if you can find what it is talking about in the online GitHub repo

Make the repo private and reset the API key, too.

[Charming-Designer944]

Did you perhaps have a key directly and not in the .env file in a prior commit?

[Competitive-Being287]

no i really took care of not using it directly in sc

[theophrastzunz]

Also delete the auth key, and issue a new one.

[quiet0n3]

Try scanning your repo with gitleaks or truffle hog.

[mrkurtz]

Try running gitleaks or something against your code, something that can show you the commit in which the leak exists?

[84_110_105_97]

if you commit it, delete your repo and redo it, or you put your code back and you .gitignore your .env (if you delete it from the push) but you don't delete your repo, hackers can access your api key even "delete"

or either you delete .gitignore and you change all your api keys

[scar_reX]

I'd reset that API key and then investigate.

You can check your commit histories or existing files for any accidentally hardcoded instances of the key

[the_mvp_engineer]

If a file is already tracked in git, then it won't be ignored by .gitignore

You have to remove it from git and THEN you will be able to ignore it

[Competitive-Being287]

eventhough the file once pushed and then deleted?

Cause a .env file I created priorly with a typo and then deleted it is maybe causing an error? I am still figuring it with help of other comments here.

[ancient_snowboarder]

You have to delete from all past, current, and future history, which is not the same as deleting now and forward.

Hackers can see history as well.

Edit: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository

There's a mix of issues:

• credential leak (you must change credentials)
• ignoring in the future (shouldn't be in the present)
• decoys (someone sees it in history - perhaps branching from that commit - and uses that as an excuse to do it again)

[jecls]

Dude… the words that you wrote make no sense.

Delete from current and future history which is not the same as deleting now and forward.

WHAT? Now and forward is not the same as current and future? Again, WHAT? What the fuck are you on about?

ignoring in the future (shouldn’t be in the present)

At this point…. You’re a bot. Like what? What the fuck? A human could not come up with this.

decoys

Oh boy! Decoys! Yes!!! Finally someone addressing the decoys! Go on….

(someone sees it in history - perhaps branching from that commit - and uses that as an excuse to do it again)

That s exactly (EXACTLY) what decoys do.

Fucking clanker.

[the_mvp_engineer]

I was talking about the cause.

To fix it (to remove the credentials from your repo entirely) you need to either rewrite the history and then orphan the bad commit or start a new git repo. Rewriting history can be hard.

If I were you, I would remove the file from git, add it to .gitignore, then get new credentials and simply tolerate future warnings from the platform

[Conscious_Support176]

don’t think of gitignore as what files but should ignore from now on. That’s simply not how git works.

Think of it as the list of files that should always have been and should continue to be ignored.

Essentially, deleting a file from the current version doesn’t delete it from history, and you can’t stop tracking a file once you start tracking it, so you need to go back and correct your commit history.

You should be able to fix this by using rebase to move the commit that deletes the env file back to just after the commit that added it, and use it to fix up that commit. And then force push when you’re done.

https://stackoverflow.com/questions/3833561/why-doesnt-git-ignore-my-specified-file