3 min read

Attackers Can Bypass GitHub Required Reviewers to Submit Malicious Code

Featured Image

Code reviews are an essential security guardrail, but GitHub’s required code reviewers' settings might be giving you a false sense of security – they can easily be bypassed by any collaborator with reviewer permissions.

See how an attacker can use a compromised account to submit malicious code and merge it into your repository’s main branch while bypassing code review restrictions in this post.

TL;DR

  • GitHub’s required reviewers capability can be bypassed if currently using this setting to require at least one code review before merging code.

  • Any code reviewer reviewing code can simply submit malicious code on pull requests during the review process and merge that code to the main branch without review.

  • GitHub does not currently provide users the ability to directly eliminate this risk.

Even if you followed every agile development best practice perfectly, there are still risks in agile software development. Agile has proven that it offers more benefits than drawbacks so it’s important to understand the potential security risks so that you can mitigate them ahead of time.

What are Required Reviewers?

A typical development workflow looks like the following:

  1. The developer diverges from the repository’s main development branch

  2. Then the developer adds/deletes/modifies the code as needed.

  3. Finally, a second person must review and approve the changes before that code can be merged back to the main branch.

securing code review in the software development lifecycle

To support this common workflow, GitHub introduced the concept of Protected Branches. A protected branch is a branch that contains restrictions on who can modify it and how.

For example, the below configuration enforces any developer who wants to push code to the main branch to create a pull request and also get approval from a second, authorized person to approve pull requests.

securing default main branch

branch protection settings to secure the main branch

(A complete list of Branch Protection rules can be found in GitHub’s documentation.)

For obvious reasons, GitHub doesn’t allow developers to authorize their own pull requests – otherwise, there’d be no point in requiring a “required approval”.

However, I’ve discovered that there is an easy method a developer can use to authorize their own pull requests: pull request hijacking.

What is Pull Request Hijacking?

Any user authorized to approve pull requests can modify existing pull requests of other users as desired. After modifying the existing pull requests, they can approve and merge the code without requiring approval. This works because the original pull request was opened by another user (i.e. “User A”) and GitHub doesn't recognize that a different user (i.e. “User B”) modified it.

You can test this yourself:

  1. Find an open pull request.

  2. Modify it or even replace the entire branch content

  3. Approve your own modifications

  4. Bypass required approvals for your modified code

HubSpot Video

 

Responsible Disclosure: GitHub Response

When disclosing pull request hijacking to GitHub, they responded that GitHub is working as intended in this scenario.

“This is an intentional design decision and is working as expected. We may make this functionality more strict in the future, but don't have anything to announce right now. As a result, this is not eligible for reward under the Bug Bounty program.” -GitHub

We believe that GitHub didn’t fix this issue because the resulting experience might be too restrictive for the modern development teams. There are many frequent and harmless cases in which developers collaborate on the same branch. For example, if I fixed a small typo when reviewing another developers code, it makes some sense that I should also be allowed to go ahead and push that code.

How to Protect Yourself From Pull Request Hijacking

The following two defensive techniques will protect your business from malicious code submissions during a pull request hijack attempt. In addition to these two techniques, you can also lower the risk of malicious in a variety of ways like strengthening authentication requirements for developers that are also reviewers and practicing least privileges in relation to your GitHub organization.

Require At Least 2 Reviewers

Configure GitHub to require more than 1 reviewers. This way, even if an existing pull request is modified and approved by the same user, it would still need a review from an additional person. You can configure with in your GitHub settings as pictured below.

improve github code review security by requiring 2 reviewers
 

Restrict Who Can Push To Matching Branches

GitHub allows you to create a “personal branch” pattern for each developer that no other developer could modify (pictured below).

example branch name pattern aligning to developer specific branch 
secure settings for branch naming protection strategy
 
In this example, if my branch name pattern is noam/*. I can configure that only Noam can push to this branch. Due to this, a different developer reviewing Noam’s code cannot hijack Noam’s branch to submit malicious code.
Legit Security Can Help

A pre-requisite to hardening your GitHub required reviewer configurations is to have visibility into your development pipelines, know where you are using GitHub, whether or not you are requiring code reviews, and whether you have stale or inactive accounts with reviewer permissions. Legit Security can provide visibility and answers to these questions in minutes. In addition, Legit helps you holistically assess security and compliance risks in your development pipelines across other SCMs and also other developer systems like build servers and artifact registries. Learn more about Legit by visiting our platform page or booking a demo with us today.

 
 
 

 

Related Blogs

Software Supply Chain Risks: What Every CISO Needs to Know

As software technology evolves, it’s being continuously integrated into nearly every aspect of business processes. And while this has given many...

Read More

Why You Can Still Get Hacked Even After Signing Your Software Artifacts

Malicious actors are poisoning your artifacts in an attempt to infect your software supply chain so that you deploy those compromised (i.e. poisoned)...

Read More

New Software Supply Chain Attack Installs Trojans on Adobe's Magento E-Commerce Platform

A popular vendor of Magento-Wordpress plug-ins/integrations with over 200,000 downloads, has been hacked. This recent attack is a reminder that...

Read More