Git ransom incident was due to leaked credentials, say hosters


GitHub, GitLab and Atlassian Bitbucket have issued a joint response to a security incident earlier this month which saw some users hit with ransom demands after their code repositories were accessed. It points the finger at leaked user credentials rather than a security hole in the services themselves.

Dubbed the Git ransom campaign incident, it came to light on Thursday, May 2, when the security teams of the three online repository services started to receive reports of account compromises from users.

The story was covered by The Register here, but the essence is that some user repositories, both public and private, had been wiped and their content replaced with a single file containing a ransom demand for payment in Bitcoin to secure the safe return of the code or prevent it being made public.

Following an investigation by the security and support teams of the three companies, they have concluded that the attack was carried out using leaked credentials, as legitimate passwords, app passwords, API keys, and personal access tokens were used to access the repositories. The attacker had performed Git pushes to overwrite repository contents with the ransom note and then erased the commit history of the remote repository.

Furthermore, the security teams traced the attacker’s account compromise activity to an unnamed hosting provider, where they found a stolen credential cache holding some of the credentials used in the incident.

The three companies have issued advice for users on how to better protect their hosted repositories against potential attacks such as this. It includes the usual exhortation to enable multi-factor authentication, and to use strong and unique passwords for every service, so as to prevent credential reuse if a third party experiences a breach and leaks credentials.

Users also need to understand the risks associated with the use of personal access tokens, which apparently circumvent multi-factor authentication. The trio also warn that tokens may have read/write access to repositories depending on scope and should be treated like passwords.

Another key piece of advice is that developers should use tokens only through environment variables rather than hardcoding them into their application.

The incident report outlines how to recover an affected repository on GitHub, GitLab or Bitbucket, which will often just consist of pushing content back up from a local repository.

The three online repository services said they are already taking steps to protect users. Bitbucket says it has the ability for admins to require two-factor authentication and provides customers with the ability to restrict access to users at specific IP addresses.

GitHub claims that it scans the contents of commits to public repositories for tokens issued by itself and other services such as cloud providers, to prevent such tokens from being disclosed.

GitLab states that GitLab 11.9 includes a similar facility called Secret Detection, which scans the content of the repository to find API keys and other information that should not be present. If found, this is flagged in the SAST report in the merge request widget, pipelines reports, and the security dashboards.