Github account hacked and repo wiped - Github Response

Question

One of my repo's was wiped today and just a message left in its place with a bitcoin ransom. I've no idea how they accessed my account, can't really see anything on github security page.

The domain of the email they want me to contact was only created today, google brings nothing up, also seems like a fresh bitcoin address as google returns nothing for it.

They only wiped one repo and there's like 50+ which makes me think they never accessed my account directly and possible from a server where i had cloned the repo to, or it was a targeted attack and they knew exactly what they were after.

Is there anyway to check if my other repos have been accessed recently and cloned? they're all set to private.

I'm at a bit of a loss just now as what to do, 2 factor has been turned on in github, the main server where the code was used I've removed unused scripts etc changed passwords, currently building a new server droplet and moving everything as a precaution in case the server was accessed.

This code was still in beta, although we have about 50 customers using it. And there's a few instances during development just because of the sheer lack of time I've went for the old security through obscurity... So this will have a direct impact on my customers.

Anyone got any input, how i can try track back the source of this, find out how they got access in the first place?

Just checked the last commit details,

WARNING

gitbackup
gitbackup committed 4 hours ago

All history of commits and all code is gone.

Update: Bitcoin address and email are starting to surface on google with reports of similar incidents, at least I know now its random and not targeted.

Response from Github

Github Got back to me today with a pretty standard response.

We recently noticed some suspicious activity on your GitHub account that suggests an attacker may have logged in, downloaded, and maliciously modified certain repositories, listed below. Out of an abundance of caution, we made the decision to force a password reset for the account associated with this email address. We have no reason to believe that GitHub has been hacked or compromised.

This kind of unauthorized access often occurs as a result of credential reuse across multiple online services. An attacker is then able to obtain lists of email addresses and passwords from other online services that have been compromised in the past, and try them on GitHub.

Repositories suspected of takeover:

xxxx

If you have a local copy of the repository, force pushing it to GitHub should restore the repository to its previous state. If you do not have a local copy, please contact our Support team at the email address below in order to request help.

Answer 1

From the OP:

Ok looks like the source has been found.

https://en.internetwache.org/dont-publicly-expose-git-or-how-we-downloaded-your-websites-sourcecode-an-analysis-of-alexas-1m-28-07-2015/

Silly me! :)

PREVENTION -

<DirectoryMatch "^/.*/\.git/">
  Require all denied
</DirectoryMatch> 

in your apache config.

to restore your repo,

git push origin HEAD:master --force

To make it self-contained, though, this happens when you serve an entire Git repo for your website. So, for example, if your deploy process looks like

1. Push your changes
2. SSH into the webserver
3. Pull your changes

Then you should take note.

Git has a .git folder which contains all the meta-information about your repo, including your remote URLs. If you embed your credentials into the remote URL (if it looks like https://user@pass:github.com/user/repo.git, you've done this) then those credentials can be used to access your repository and do anything to it that you could do.

There are a few mitigations, depending on your situation:

1. As stated above, you can just configure your webserver to not serve the .git folder. This is the quickest, easiest solution, but also not a great one, because you're still exposing the contents of the repo to anyone who knows the paths. If you have any proprietary elements in there at all, use another mitigation.
2. Put your website's code in some subdirectory of the repository. You still get the ease of deployment, but now anything you want tracked but not published, you just... don't put in the public directory. This is a higher migration cost, but a cleaner approach, and easier to get right in the long run.
3. Pull with SSH, not with HTTPS. The keyfile, unless you're doing something horribly wrong, won't be published, so no one else can access the repo even if they do have access to the .git folder. Be aware that, with just this solution, they can still access the .git folder, but for some projects (e.g. most open-source ones) this is irrelevant, since everything in there is already public. As a nice side bonus, your server's connecting to GitHub will be more secure.