CVE-2021-22205: How to determine if a self-managed instance has been impacted

Additionally, please consider subscribing to our security alerts via the Communication Preference Center | GitLab so you are emailed when GitLab publishes a security release.

3 Likes

We at AWS had all our AMIs of GitLab inspected and - if needed - upgraded.

1 Like

Another indicator was shared by @antondollmaier: Presence __$$RECOVERY_README$$__.html files in Git repos, plus POST /uploads/user HTTP/1.0 events in logs. Thank you!

3 Likes

We’ve seen recent reports of unpatched, publicly accessible GitLab instances having Git repository data encrypted by a ransomware attack.

Indicators of compromise associated with this may include:

  • Users unable to clone or push any projects
  • errors when trying to view repositories in the UI
  • suspicious files in the Git repo directories on the server (eg. files ending in .locked or .html)

If you find that data has been encrypted by a ransomware attack, industry-standard best practice is to:

  • follow your organizations’ security incident response and disaster recovery plan
  • restore to last known working backup (one taken before ransomware attack)

To help mitigate the threat of abuse and attacks moving forward:

1 Like

Guys, goddamnit, do something with your idea of “security”.

You should never ever process any files from an unauthenticated entity if the instance was set to private mode. Why would you comb out random files supplied from random internet address with random golang scripts invoking random 3rd party utils? Have you gone insane or what?

Here’s another thing, again, absolutely unexpected from admin perspective. Our instance has Restricted visibility levels setting configured with Public checked. One might expect that would fence off unauthenticated access from the entire gitlab install. But that’s not the case — see https://bit.ly/3A3CokF . Complete repo read access is possible! This is crazy.

There should be a way to lock the instance down from anyone unauthorized.

Third thing is /etc/gitlab/gitlab-secrets.json rotation. What are we supposed to do with them on a compromised instance? Those tokens need a way to be rotated. There currently is none.

I agree with everything in your post. We still have security alerts from our antivirus because of this vulnerability even though our instance is not vulnerable anymore.
I don’t get why gitlab still process those files from unauthenticated entities. It’s a major problem that should be patched asap but it seems like nobody cares.

@kulisse Gitlab has been patched. Since your installation was obviously infected, you need to clean it up - maybe the gists still exist on your install and are so being found, or files on the server itself that are found and scanned.

Usually when a server is compromised, you should really start from zero and restore. Otherwise you need to make sure it has been completely cleaned up. That is most likely why you still have issues.