Git Ransomware Attack Prompts Secure Best Practices Recommendations

by D. Howard Kass • May 10, 2019

Atlassian Bitbucket, GitHub, and GitLab this week issued a joint blog post to help educate and inform users of the three platforms on secure best practices in the wake of a Git ransomware incident two weeks ago.

“Though there is no evidence Atlassian Bitbucket, GitHub, or GitLab products were compromised in any way, we believe it’s important to help the software development community better understand and collectively take steps to protect against this threat,” the blog reads.

Quick background: On Thursday, May 2, the security teams of Atlassian Bitbucket, GitHub, and GitLab learned of user account compromises across all three platforms, ultimately resulting in hundreds of public and private repositories held for ransom by an unknown cyber kidnapper (see details below). The compromises largely came from “leakage” of user credentials, perhaps from third-parties. Weak passwords are the likely cause. At this time, the security teams of all three companies are collaborating to investigate the incidents, the blog said.

The incident: The ransomware hacker hit roughly 400 Git repositories and demanded roughly $600 in Bitcoin paid within 10 days (May 13) not to make the victims’ code public, multiple reports said. The hacker claimed the victims’ data was being held on their servers. The attacks occurred across Git hosting services GitHub, Bitbucket, and GitLab. Users affected by the ransomware reported that their code disappeared and replaced by this demand:

“To recover your lost code and avoid leaking it: Send us 0.1 Bitcoin (BTC) to our Bitcoin address ES14c7qLb5CYhLMUekctxLgc1FV2Ti9DA 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.”

As of Monday, May 6, there had been 36 abuse reports for the Bitcoin address, according to the Bitcoin Abuse Database blog, and the hacker threatened to delete code. In keeping with the cyber extortionists’ collective strategy that less is more, the demand was 0.1 bitcoin, which at the time of the incident was about $590 but has risen to roughly $780.

Key Learnings

In the hijack’s immediate wake, it wasn’t clear how the hackers conducted the attacks but the the platforms’ security teams now are “confident that we understand how the account compromises and subsequent ransom events were conducted,” the blog said. The hacker appears to have scanned the web for Git config files and used stolen credentials to carry out the heist at Git hosting services. Some users suspect that it wasn’t a targeted attack but a random, bulk attack carried out by a script. Apparently, some of the victims used weak passwords for their GitHub, GitLab and Bitbucket accounts. They also didn’t remove access tokens for apps left unused for months. Both mistakes left accounts vulnerable to hacking.

“My password was a weak one that could’ve been relatively easily cracked via brute-force (it’s not a common one but starts with “a” and has only a-z characters in it) and it could be that they just automatically checked if they can access the account and then ran some git commands,” wrote one user on the StackExchange forum. “It is also possible that my email address and that particular password are on a list of leaked accounts.”

Recommendations

Here’s how users can protect their repositories from such attacks:

• Enable multi-factor authentication on your software development platform of choice — Bitbucket, GitHub or GitLab.
• Use strong and unique passwords for every service to prevent credential reuse if a third-party experiences a breach and leaks credentials.
• Understand the risks associated with the use of personal access tokens, which, used via Git or the API, circumvent multi-factor authentication. Tokens may have read/write access to repositories depending on scope and should be treated like passwords. If you enter your token into the clone URL when cloning or adding a remote, Git writes it to your .git/config file in plain text, which may carry a security risk if the .git/config file is publicly exposed.
• When working with the API, use tokens as environment variables instead of hard coding them into your programs.
• Do not expose .git directories and .git/config files containing credentials or tokens in public repositories or on web servers.

The blog post also offers steps for users to recover their affected repositories. Users requiring additional assistance to recover their repository contents are referred to support sites for each platform.