I’ve spent the last year researching the trust and safety mechanisms in SCM platforms like GitHub, GitLab, and Gitea. These platforms are important in the ecosystem, as GitHub and GitLab together host most of the world’s source code. My interest in their trust and safety mechanisms was driven by my experience as a red-teamer and software supply chain offensive security practitioner.

For years I’ve used GitHub and GitLab components in my red-team engagements.  For example, the file upload service which I’ll talk about today is a great way to host attack chain components when you are targeting software engineers.  I mean, what better domain is there to use than “github.com”, right?  Red teaming is all about emulating attackers and the reality is that GitHub is where bad guys are hosting many of their attack chain components, so why not do the same?

Bad guys make fake GitHub and GitLab accounts which I call “Code Puppets”.  Bad guys also use malicious NPM packages and GitHub repos to pull their payloads from.  Supply chain threats are made worse by the sheer number of ways that threat actors can use to poison your applications. I teach these concepts in my “Red Teaming the Software Supply Chain” training.

My trust and safety research finds new attack vector in GitHub and GitLab

I’ve identified a brand new type of attack that I’m calling “repo swatting”. This attack targets developers’ accounts on major source code management (SCM) platforms like GitHub, GitLab, and Gitea. This malicious technique allows attackers to potentially delete a user’s entire account or repository, posing a significant threat to developers and their intellectual property.

So, what exactly is repo swatting?  I coined the term as a nod to the infamous “swatting” practice where bad actors make false emergency calls to provoke an armed response at someone’s address.

Repo swatting is similar to real swatting in the sense that the attack abuses the trust and safety mechanisms in the SCM providers to do harm instead of good.

tl;dr

This attack is straightforward and abuses the trust and safety processes in the SCM platforms to delete the target accounts:

1. An attacker exploits a “feature” in SCM platforms that allows users to add files to other users’ repositories, often anonymously.
2. They upload a malicious file to the targeted user’s repository.
3. The attacker then reports the targeted user to the platform’s abuse team, claiming the account contains malicious content.
4. In response to the report, the SCM platform deletes the targeted user’s account or repository.

What is “swatting”?

Physical or “real-world” swatting is a terrible practice where a criminal makes a false report to emergency services to trigger an armed police response to an unsuspecting victim.  The bad guy intends to get the police to go to the target’s house where often innocent people are hurt.  Swatting became popular on 4chan and has now moved into the mainstream and is often abused by online gamers against other gamers.

This is a simple way to think of physical swatting:

Fundamentally, when someone swats another person they are abusing a system that is meant to do good (911) and twists it to do something evil.  This abuse of a trust and safety mechanism is the important factor in this new “repo swatting” attack type.

Unfortunately, swatting in the physical world has led to real fatalities and real prison sentences.

Why are you talking about swatting?

As I mentioned above, physical swatting abuses the emergency services function to do bad things.  This idea of abusing trust and safety mechanisms is something I saw bad guys doing in the software development lifecycle (SDLC) by abusing functions in GitHub and GitLab. 

I wanted to understand this attack type more.

SCM platforms enable collaboration

I think it is important for everyone reading this to understand why SCM platforms like GitHub and GitLab are so powerful.  I will discuss several features of these platforms and why they are targeted by criminals.

The primary value that SCM provides is not storing source code as much as it is the collaboration that happens *around* that source code.

• Companies store their source code in a SCM platform and developers use work emails to interact with source
• Startups and smaller orgs might let their developers use their own GitHub accounts with their personal email addresses
• Collaboration is the real business value to SCM platforms.  They allow your software engineers and support staff to build and deploy applications
• Multiple developers working on the same project can check in code and the SCM platform manages how it’s integrated together (CI) and then deployed (CD). 
• All of this involves LOTS of collaboration.

What explicit permission do you need to collaborate?

There are several ways you can collaborate with other users and their content on GitHub that require explicit permissions:

EDIT SOURCE IN WEB UI -You can edit source code directly in the GitHub or GitLab web UI.  This requires that the original author gives you permission to edit the content.  It’s not a common use case, but it’s supported.  So, for example, I could add another user to my source code repository and say they are an editor, and they could change my repository any way they want.  Again, this requires explicit permission.

FORKING – You can use a function in the SCM providers called “forking”.  Forking creates an exact copy of someone’s repository in your account.  So for example, if the original repo address was github.com/bob/test-app your copy would be github.com/your-user/test-app.   Users can maintain their own fork of the original project, or more commonly they can use forking as a way to contribute code back into the original repository.   This happens via a “merge request” or “pull request”.  The original repository owner can look at the changes suggested by the fork owner and decide to merge those changes into the original.  Then the fork is no longer necessary as its changes have been merged into main, and the fork can be deleted.  Forking requires explicit permission in the sense that the original repository owner has to allow the changes made by the editor into their version of the code.  They give their permission and then GitHub will merge the two repos together.

Are there ways to collaborate without explicit permission?

Yes!  As surprising as this may sound to people unfamiliar with SCM providers, you can indeed interact with other peoples content without them giving you permission, or even knowing about it!

There are at least two ways you can collaborate with other users source code on GitHub without being given explicit permission:

1. GITHUB/GITLAB ISSUES – Any authorized user can go to another users project and create whats called an “Issue”.  This is similar to creating a support ticket in other platforms.  The idea behind Issues is that if you come across a problem, or an inconsistency, or anything else that you want to let the maintainer about, you can.

Sometimes GitHub Issues will be disabled or you can’t use that feature for some reason.  There is another way to collaborate on someone else’s project without explicit permission:

2. COMMIT COMMENTS – Any authenticated user can add comments to commits in the commit history.  You simply browse to a git commit and click inside either of the two code comparison windows and a little plus will appear.  If you click on that plus you’ll get a comment form much like the one in GitHub Issues.

Let’s test my theory…

So, my theory was that I could combine the GitHub anonymous file upload feature with an abuse complaint and maybe get a repo taken offline. 

I needed to test this so I spun up a “code puppet”.  A code puppet is a sock puppet for GitHub and GitLab.  If you aren’t familiar with sock puppets you can think of them as disposable personas you use while doing security research.  Why?  Because, you don’t want to do this stuff as yourself, right?

BTW, I have a whole section about creating and identifying code puppets in my training.  My students love it and its typically their favorite part of my training!

Ground rules for testing

No innocent bystanders were hurt during the testing of this vulnerability.  In other words, all accounts involved were my own code puppets. I asked a couple of my friends if I could try and repo swat them, but they weren’t interested in being guinea pigs.

I originally started researching this attack back in February 2024.  Over time all the SCM providers mentioned in this article have made important changes to their platforms to address these attack vectors.  I think it’s important to note that the number of attacks, and the sheer volume of malicious content being created in these platforms is increasing.  Both GitHub and GitLab have great teams working on these problems, and this blog post should not be seen as disrespecting their work and the changes they’ve introduced to their respective platforms.

Okay, let’s get this ball rolling…

GitLab tl;dr

The short answer is: Yes, repo swatting works for GitLab too.