4 min read
We believe it's important to help the software development community better understand and collectively take steps to protect against events like last week's Git ransom campaign.
— GitHub (@github) May 14, 2019
The Git ransom attack
On May 2, the security teams at Atlassian Bitbucket, GitHub, and GitLab started getting numerous reports from users about their accounts being compromised. The reports mentioned that the source code from their repositories, both private and public, was being wiped off and replaced with the following ransom note:
“To recover your lost data and avoid leaking it: Send us 0.1 Bitcoin (BTC) to our Bitcoin address 1ES14c7qLb5CYhLMUekctxLgc1FV2Ti9DA and contact us by Email at [email protected] with your Git login and a Proof of Payment. If you are unsure if we have your data, contact us and we will send you a proof. Your code is downloaded and backed up on our servers. If we don’t receive your payment in the next 10 Days, we will make your code public or use them otherwise.”
The user accounts were compromised with legitimate user credentials including passwords, app passwords, API keys, and personal access tokens. After getting access to the user accounts, the attackers performed command-line Git commits, which resulted in overwriting the source code in repositories with the ransom note.
To recover your repository, in case you have its latest copy on your computer, you can force push the local copy to the current HEAD using the ‘git push origin HEAD:master –force’ command. If not, you can clone the repository and use the git reflog or git fsck commands to find your last commit and change the HEAD.
What the investigation revealed?
A basic GitHub search shows that 267 repositories were affected by the ransom attack. While investigating how the credential leakage happened, the security teams found a public third-party credential dump, which was hosted by the same hosting provider where the attack had originated. The dump had credentials of nearly one-third of the attacked accounts. After finding this out, the platforms took steps to invalidate the credentials by resetting or revoking them.
On further investigation, it was found that continuous scanning has been conducted by the same IP address as the attacker for publicly exposed .git/config and other environment files, which may have sensitive information like credentials and personal access tokens. Similar scanning behavior from other IPs residing on the same hosting provider was also found.
How you can protect your repositories from such attacks?
Strong and unique passwords: Users should use strong and unique passwords as attackers can easily crack simple passwords through brute-force attacks.
Enabling multi-factor authentication (MFA): Users are recommended to use multi-factor authentication, which is supported on all three platforms. MFA provides better security by combining two or more independent credentials for authentication.
Understanding personal access tokens (PATs) and their risks: PATs serve as an alternative to passwords when you are using two-factor authentication. Users should ensure that these are not publicly accessible in repositories or on web servers as in some situations these tokens may have read or write access to repositories. The report further recommends that users should use them as environment variables and avoid hardcoding them into their programs.
Additionally, the three platforms also offer other features through which we can prevent such attacks from recurring. Bitbucket gives admins the authority to control access of users through IP Whitelisting on their Premium plan. GitHub does token scanning on public repositories to check for known token formats and notifies the service providers if secrets are published to public GitHub repositories. GitLab 11.9 comes with a feature called Secret Detection that scans repositories to find API keys and other information that should not be there.
To read the official announcement, check out the joint incident report on GitLab blog.