7 ms·

My MetaMask Private Keys Stolen from GitHub Private Repo in 1 Hour

25 points by hasangursoy 5y ago

I am working on a crypto project using React.JS, just experimenting with web3 and MetaMask wallet. In the project, I was reading my private keys from a json file and last night I accidentally committed this json file to my GitHub private repository. The repository was brand new and I just emailed an invitation to my colleague that we were working together on Zoom. After realizing that I have committed the private keys, I immediately deleted the whole repository and pushed a whole new repo again. But after 1 hour, I discovered that nothing was left in my wallets and whatever I sent to these wallets is being transferred to another account afterwards. Here is an example of transactions from the last night: https://polygonscan.com/address/0x7a9eb3cc39bc6ac940febbdb5bb29b8f9ece8a5b All of the sender wallets were mine for the recipient above. What do you think?

ketz1 5y ago
This means private repositories aren't really private?
f0e4c2f7 5y ago
There are bots that scan GitHub for credentials and private keys. Sorry that happened to you, I hope it wasn't a lot of money. Considered adding files like that to .gitignore in the future.
- Stevvo 5y ago
  When I used to work in Crypto we had git hooks set up to prevent this from happening. It takes a bit more time to set up than just adding something to .gitignore but is a more robust solution of you design your hook well.
- beingflo 5y ago
  But they shouldn't have access to private repos, right?
  - londons_explore 5y ago
    I deliberately leave various types of cryptocurrency in 'private' areas of quite a lot of online services, including GitHub. So far, nothing has been taken from GitHub. (It's part of research for my side project serverthiefbait.com)
    - rdbell 5y ago
      Cool project. If I pay you $900 how much of that goes into cryptocurrency? Seems like you could achieve the same result if you just let your customers buy their own coins and provide an address for you to watch?
      - londons_explore 5y ago
        about $90-$150 initially, but usually within a few weeks the balance will be upped to $400 or so. I have had troubles with people using the service as a way to get money off stolen credit cards, so the low initial deposit is a way to avoid that. There is also a lot of per-customer randomness to prevent bad guys writing logic to detect which wallets are provided by my services. That's why they don't all have a fixed balance. > Seems like you could achieve the same result if you just let your customers buy their own coins and provide an address for you to watch? Yes - there are other services that do that for free already. This is more of an all-in-one setup for those who want to set-and-forget.
    - sinbadpalomar 5y ago
      Really like this project.
- hasangursoy 5y ago
  Actually already added to .gitignore file but then realized that .js files are not being discarded by .gitignore
  - chrisco255 5y ago
    If this is a Node.js program you should store private variables in a .env file (with .env added to your .gitignore) then call process.env.[variable name here] to get the key at runtime. Look up documentation and examples on .env files. If you deploy to a service such as Vercel or AWS you can set environment variables there for production.
  - SahAssar 5y ago
    They are if the gitignore matches the file, just like any other filetype.
kjaftaedi 5y ago
You're leaving out a lot of valuable information. Did you check your security log in github? Do you have MFA enabled on your account? Did you check your repository and account and make sure that all of the SSH keys saved are recognized and known to you? Did you refresh all of your keys and make new ones? You need to start at the beginning.. starting with the theft transactions is starting at the end. ---- Long story short, there is no way to tell you what happened without you investigating first. It could be you just not MFAing your account and re-using passwords.. and someone logged into your github account and added their own private keys. Really it could be a million different scenarios, but whatever happened, you need to investigate first.
- hasangursoy 5y ago
  I use both MFA and a password manager tool for security purposes, and the account is connected to my work email. I am pretty sure that no security flaws was the cause of this, except pushing to the private repo. I have checked the transaction and the commit dates, which are matching perfectly. No doubt about that.
  - listenallyall 5y ago
    Were all the wallets part of the same Metamask account? The transfers are all a few seconds apart... they could have gotten in the front door by obtaining your Metamask password without needing any keys. Because Metamask is a hot wallet, it's always connected and easy to steal. Metamask also produces a set of words for emergency recovery -- attacker could have obtained those as well. With that said, they stole 7 dollars. Pretty cheap lesson on security in my opinion.
Stevvo 5y ago
"I just emailed an invitation to my colleague that we were working together on Zoom" Most likely explanation is that if you didn't drain the wallet yourself then the only other person with access to your private key did.
- hasangursoy 5y ago
  He was sharing his screen when I realized the mistake, and he did not even see the keys.
  - spzb 5y ago
    On that screen, he didn't
  - mmcwilliams 5y ago
    Was that their only screen? The simplest explanation here is that the only other person you know, even temporarily, to have your credentials used them. Another way to think about it is if you made that first mistake, maybe you made another similar one at some point?
pjc50 5y ago
I hope you're enjoying being your own bank and in full control of your resources. Maybe you need to ask your bank (yourself) about your security policies. /s (Information security is hard and you only have to make a mistake once.)
- jm50 5y ago
- anm89 5y ago
  What he is doing should have been secure. The question is valid. How were the keys exposed from a private repo?
  - pjc50 5y ago
    "Secure" is kind of a relative term, it only exists with regard to a threat model and a likely spectrum of attacks. Simply having the key in plaintext on a developer PC connected to the regular internet is fairly low-security to start with; there are all sorts of opportunities for coincidental compromise that may have exposed it directly from his PC or his collaborator's PC.
    - anm89 5y ago
      Agreed, all I'm saying is that he did not give any specific detail which demonstrated a specific vulnerability. so just feel like more info is needed.
  - Hoasi 5y ago
    > What he is doing should have been secure. Sure, but using any third party is inviting a layer of risk. Banks get hacked too. No system is without vulnerabilities. You decide which to trust, including your potentially error-prone self.
londons_explore 5y ago
I think your colleague cloned the repo, and he had wallet stealing malware in his PC, which probably automatically stole it within milliseconds of the clone happening.
- kolinko 5y ago
  This sounds like a most plausible explanation. Or perhaps you unknowingly uploaded the file to another repo as well? Others in the thread mentioned that they have private keys in their repo as a honeypot - if there was a security breach within GitHub, their keys would also be lost.
- x86_64Ubuntu 5y ago
  This is a horrifying scenario.
  - pjc50 5y ago
    "person has malware on their desktop PC" is a perfectly ordinary scenario. Happens to thousands of people every day.
  - hatenberg 5y ago
    It’s an everyday scenario in the financial world. Humans make mistakes. The systems that currently power finance may be flawed but they have affordances for mistakes and provisions to fix them. What would be a horrifying scenario would be to lose those affordances and backstops for new technology that requires humans to not make mistakes to operate it safely
  - anm89 5y ago
    Not really. Why would you wver share non multisig keys with anyone outside of a test scenario. Tbh anyone who cant understand why this is a bad idea should not be holding crypto anyway as they are going to get separated from it one way or another
  - anm89 5y ago
    Not really. Why would you ever share non multisig keys with anyone outside of a test scenario. Tbh anyone who cant understand why this is a bad idea should not be holding crypto anyway as they are going to get separated from it one way or another
aaron695 5y ago
chrisco255 5y ago
You should never be developing code with your own personal wallet. Every time you need to create a program that needs to control its own private key, you should create an entirely new wallet and fund it with the minimum amount needed to transact. If you are using code to deploy a smart contract, fund a single-use wallet to make the deployment then transfer ownership of the contract to a multisig or hardware wallet.
tyingq 5y ago
Browser extension maybe? Did you or your partner look at the newly created repo in a browser right after creating it? I could see an extension watching for git like listings with json files named like wallets and fetch()ing them when they appear. Easy enough to recreate, test with the devtools tab open.
- Stevvo 5y ago
  You just gave me a scary idea. Everyone has Metamask set to auto-update. If somehow an attacker could get a compromised update pushed out it would not be pretty.
3np 5y ago
I thought that at this point it’s common sense that any secret pushed to a public GitHub repo should be considered compromised, regardless of how quick you roll it back. There are many people writing automated tools doing their best to catch slip-ups like this before everyone else. Dark Forest and all that. And as someone else said, why use a wallet holding mainnet private funds as a dev wallet? Separate your keys.
- hasangursoy 5y ago
  A quick note, all of the wallets were the part of my experiment, not the main one.
- Buttons840 5y ago
  > There are many people writing automated tools doing their best to catch slip-ups like this before everyone else. Dark Forest and all that. And these scripts can see my private GitHub repositories? If so, what's the difference between public and private repositories? Is this a failure of GitHub's security?
  - spzb 5y ago
    Maybe, maybe not. He admits that he shared the repo with at least one other individual. It's quite possible that what he thought was a private repo wasn't.
- anm89 5y ago
  PRIVATE repo*. These should not he searchablr with that method.
hatenberg 5y ago
You work on web3, you should be comfortable with the no help, no accountability situation it creates for its users. It’s a feature after all, or a bug.
me_me_mu_mu 5y ago
> I just emailed an invitation to my colleague Did you try asking your buddy to give back your coins lol Always roleplay as your favorite neutral characters and don’t trust anyone when dealing with crypto! Trustless
gbraad 5y ago
You assume they gained access because of/due to the info in your github repo. Based on? Trace back as you might have overlooked something. Start from the beginning.
izoow 5y ago
Did you use any automatic tools such as Github Actions or Github Apps?
mzfr 5y ago
Assuming that the person you were working with didn't drain your wallet, there are many tools which can be used to actively monitor for commits being done on GitHub with secrets of sort. The first one that comes to my mind is shhgit (https://github.com/eth0izzle/shhgit https://github.com/eth0izzle/shhgit) Anyone can self host it and then add multiple GitHub Dev keys to it. Then this can be used to monitor GitHub commits being done, majority of which can be categorized as "secrets".

25 points by hasangursoy 5y ago

ketz1 5y ago

This means private repositories aren't really private?

f0e4c2f7 5y ago

There are bots that scan GitHub for credentials and private keys. Sorry that happened to you, I hope it wasn't a lot of money. Considered adding files like that to .gitignore in the future.

Stevvo 5y ago
When I used to work in Crypto we had git hooks set up to prevent this from happening. It takes a bit more time to set up than just adding something to .gitignore but is a more robust solution of you design your hook well.
beingflo 5y ago
But they shouldn't have access to private repos, right?
- londons_explore 5y ago
  I deliberately leave various types of cryptocurrency in 'private' areas of quite a lot of online services, including GitHub. So far, nothing has been taken from GitHub. (It's part of research for my side project serverthiefbait.com)
  - rdbell 5y ago
    Cool project. If I pay you $900 how much of that goes into cryptocurrency? Seems like you could achieve the same result if you just let your customers buy their own coins and provide an address for you to watch?
    - londons_explore 5y ago
      about $90-$150 initially, but usually within a few weeks the balance will be upped to $400 or so. I have had troubles with people using the service as a way to get money off stolen credit cards, so the low initial deposit is a way to avoid that. There is also a lot of per-customer randomness to prevent bad guys writing logic to detect which wallets are provided by my services. That's why they don't all have a fixed balance. > Seems like you could achieve the same result if you just let your customers buy their own coins and provide an address for you to watch? Yes - there are other services that do that for free already. This is more of an all-in-one setup for those who want to set-and-forget.
  - sinbadpalomar 5y ago
    Really like this project.
hasangursoy 5y ago
Actually already added to .gitignore file but then realized that .js files are not being discarded by .gitignore
- chrisco255 5y ago
  If this is a Node.js program you should store private variables in a .env file (with .env added to your .gitignore) then call process.env.[variable name here] to get the key at runtime. Look up documentation and examples on .env files. If you deploy to a service such as Vercel or AWS you can set environment variables there for production.
- SahAssar 5y ago
  They are if the gitignore matches the file, just like any other filetype.

kjaftaedi 5y ago

You're leaving out a lot of valuable information. Did you check your security log in github? Do you have MFA enabled on your account? Did you check your repository and account and make sure that all of the SSH keys saved are recognized and known to you? Did you refresh all of your keys and make new ones? You need to start at the beginning.. starting with the theft transactions is starting at the end. ---- Long story short, there is no way to tell you what happened without you investigating first. It could be you just not MFAing your account and re-using passwords.. and someone logged into your github account and added their own private keys. Really it could be a million different scenarios, but whatever happened, you need to investigate first.

hasangursoy 5y ago
I use both MFA and a password manager tool for security purposes, and the account is connected to my work email. I am pretty sure that no security flaws was the cause of this, except pushing to the private repo. I have checked the transaction and the commit dates, which are matching perfectly. No doubt about that.
- listenallyall 5y ago
  Were all the wallets part of the same Metamask account? The transfers are all a few seconds apart... they could have gotten in the front door by obtaining your Metamask password without needing any keys. Because Metamask is a hot wallet, it's always connected and easy to steal. Metamask also produces a set of words for emergency recovery -- attacker could have obtained those as well. With that said, they stole 7 dollars. Pretty cheap lesson on security in my opinion.

Stevvo 5y ago

"I just emailed an invitation to my colleague that we were working together on Zoom" Most likely explanation is that if you didn't drain the wallet yourself then the only other person with access to your private key did.

hasangursoy 5y ago
He was sharing his screen when I realized the mistake, and he did not even see the keys.
- spzb 5y ago
  On that screen, he didn't
- mmcwilliams 5y ago
  Was that their only screen? The simplest explanation here is that the only other person you know, even temporarily, to have your credentials used them. Another way to think about it is if you made that first mistake, maybe you made another similar one at some point?

pjc50 5y ago

I hope you're enjoying being your own bank and in full control of your resources. Maybe you need to ask your bank (yourself) about your security policies. /s (Information security is hard and you only have to make a mistake once.)

jm50 5y ago
anm89 5y ago
What he is doing should have been secure. The question is valid. How were the keys exposed from a private repo?
- pjc50 5y ago
  "Secure" is kind of a relative term, it only exists with regard to a threat model and a likely spectrum of attacks. Simply having the key in plaintext on a developer PC connected to the regular internet is fairly low-security to start with; there are all sorts of opportunities for coincidental compromise that may have exposed it directly from his PC or his collaborator's PC.
  - anm89 5y ago
    Agreed, all I'm saying is that he did not give any specific detail which demonstrated a specific vulnerability. so just feel like more info is needed.
- Hoasi 5y ago
  > What he is doing should have been secure. Sure, but using any third party is inviting a layer of risk. Banks get hacked too. No system is without vulnerabilities. You decide which to trust, including your potentially error-prone self.

londons_explore 5y ago

I think your colleague cloned the repo, and he had wallet stealing malware in his PC, which probably automatically stole it within milliseconds of the clone happening.

kolinko 5y ago
This sounds like a most plausible explanation. Or perhaps you unknowingly uploaded the file to another repo as well? Others in the thread mentioned that they have private keys in their repo as a honeypot - if there was a security breach within GitHub, their keys would also be lost.
x86_64Ubuntu 5y ago
This is a horrifying scenario.
- pjc50 5y ago
  "person has malware on their desktop PC" is a perfectly ordinary scenario. Happens to thousands of people every day.
- hatenberg 5y ago
  It’s an everyday scenario in the financial world. Humans make mistakes. The systems that currently power finance may be flawed but they have affordances for mistakes and provisions to fix them. What would be a horrifying scenario would be to lose those affordances and backstops for new technology that requires humans to not make mistakes to operate it safely
- anm89 5y ago
  Not really. Why would you wver share non multisig keys with anyone outside of a test scenario. Tbh anyone who cant understand why this is a bad idea should not be holding crypto anyway as they are going to get separated from it one way or another
- anm89 5y ago
  Not really. Why would you ever share non multisig keys with anyone outside of a test scenario. Tbh anyone who cant understand why this is a bad idea should not be holding crypto anyway as they are going to get separated from it one way or another

aaron695 5y ago

chrisco255 5y ago

You should never be developing code with your own personal wallet. Every time you need to create a program that needs to control its own private key, you should create an entirely new wallet and fund it with the minimum amount needed to transact. If you are using code to deploy a smart contract, fund a single-use wallet to make the deployment then transfer ownership of the contract to a multisig or hardware wallet.

tyingq 5y ago

Browser extension maybe? Did you or your partner look at the newly created repo in a browser right after creating it? I could see an extension watching for git like listings with json files named like wallets and fetch()ing them when they appear. Easy enough to recreate, test with the devtools tab open.

Stevvo 5y ago
You just gave me a scary idea. Everyone has Metamask set to auto-update. If somehow an attacker could get a compromised update pushed out it would not be pretty.

3np 5y ago

I thought that at this point it’s common sense that any secret pushed to a public GitHub repo should be considered compromised, regardless of how quick you roll it back. There are many people writing automated tools doing their best to catch slip-ups like this before everyone else. Dark Forest and all that. And as someone else said, why use a wallet holding mainnet private funds as a dev wallet? Separate your keys.

hasangursoy 5y ago
A quick note, all of the wallets were the part of my experiment, not the main one.
Buttons840 5y ago
> There are many people writing automated tools doing their best to catch slip-ups like this before everyone else. Dark Forest and all that. And these scripts can see my private GitHub repositories? If so, what's the difference between public and private repositories? Is this a failure of GitHub's security?
- spzb 5y ago
  Maybe, maybe not. He admits that he shared the repo with at least one other individual. It's quite possible that what he thought was a private repo wasn't.
anm89 5y ago
PRIVATE repo*. These should not he searchablr with that method.

hatenberg 5y ago

You work on web3, you should be comfortable with the no help, no accountability situation it creates for its users. It’s a feature after all, or a bug.

me_me_mu_mu 5y ago

> I just emailed an invitation to my colleague Did you try asking your buddy to give back your coins lol Always roleplay as your favorite neutral characters and don’t trust anyone when dealing with crypto! Trustless

gbraad 5y ago

You assume they gained access because of/due to the info in your github repo. Based on? Trace back as you might have overlooked something. Start from the beginning.

izoow 5y ago

Did you use any automatic tools such as Github Actions or Github Apps?

mzfr 5y ago

Assuming that the person you were working with didn't drain your wallet, there are many tools which can be used to actively monitor for commits being done on GitHub with secrets of sort. The first one that comes to my mind is shhgit (https://github.com/eth0izzle/shhgit https://github.com/eth0izzle/shhgit) Anyone can self host it and then add multiple GitHub Dev keys to it. Then this can be used to monitor GitHub commits being done, majority of which can be categorized as "secrets".