Security Breach in Stripe GitHub's Repo: How to Secure GitHub Actions Workflows? Understanding the Pwn Request Vulnerability
A severe vulnerability in Stripe’s GitHub Actions Workflow allowed a researcher to gain access to the repository's GitHub token. This vulnerability, known as "Pwn Request," exploited the trust placed in pull requests to gain unauthorized access to sensitive information and perform actions such as merging unauthorized commits into the main branch.
This incident serves as a stark reminder of the importance of understanding and securing GitHub Actions workflows and the potential risks posed by untrusted code and malicious actors.
[
Un exploit en GitHub permitía inyectar archivos en -casi- cualquier repositorio y distribuir malware “legítimo”
Una vulnerabilidad de seguridad en GitHub permitía a atacantes inyectar malware en repositorios legítimos. El atacante podría subir un archivo malicioso como comentario en un issue o pull request. Incluso si el comentario se eliminaba, el archivo malicioso seguía siendo accesible a través de una URL pública. Esto se debe
SREDevOps.orgNicolás Georger
](sredevops.org/es/un-exploit-en-github-permi..)
Related content
The Vulnerability Explained
Remember that time you left your social media accounts logged in on a friend's computer? This security breach is kind of like that, but instead of being trolled by your friends, it involves code, credentials, and a whole lot of potential damage to your whole codebase and production deployments.
A security researcher, probably fueled by caffeine and the thrill of the chase, found a 'pwn request' vulnerability in a public Stripe repository. This vulnerability allowed them to do things they shouldn't be able to do – like merging unauthorized commits into the main branch and, even worse, getting their hands on the workflow's precious GitHub token.
The vulnerability itself is a classic case of "Pwn Request," which, despite sounding like something a hacker would scream in a bad action movie, is a serious security flaw. In simple terms, it takes advantage of the trust placed in pull requests.
Here's how it went down:
- Risky Business with Triggers: The vulnerable workflow used the
pull_request_targettrigger, which, in the world of GitHub Actions, is like giving someone the keys to your kingdom. This trigger runs with elevated privileges, meaning it has access to all the good stuff, including secrets like the GitHub token.
Source: stepsecurity.io/blog/security-breach-in-str..
- Checking Out Code from Untrusted Forks: To make matters worse, the workflow checked out code from an explicit ref that originated from an untrusted fork. This is like inviting a stranger into your home and letting them rummage through your valuables.
Source: stepsecurity.io/blog/security-breach-in-str..
This combination of a risky trigger and unchecked code checkout created a perfect storm for the researcher to exploit.
The Attack Breakdown
Now, let's break down the attack like it's a heist movie montage, complete with dramatic music and slow-motion shots:
- Forking and Submitting a Malicious Pull Request: The researcher, like any good hacker worth their salt, started by forking the Stripe repository and submitting a pull request (PR) containing malicious code. Think of it as sneaking a Trojan Horse past the guards.
Source: stepsecurity.io/blog/security-breach-in-str..
- Exploiting the Workflow: The repository's GitHub Actions workflow, none the wiser and triggered by the
pull_request_targetevent, happily ran the researcher's malicious code. This gave the attacker access to the repository's GitHub token – the crown jewels of this operation.
Source: stepsecurity.io/blog/security-breach-in-str..
- Merging the PR and Exfiltrating the Token: With the GitHub token in their possession, the researcher could automatically merge their PR into the main branch, bypassing any pesky review processes. It's like walking straight into the vault because you tricked someone into giving you the code. In a subsequent PR, the researcher decided to show off a bit and exfiltrated the GitHub token to a remote server using
wget.
Source: stepsecurity.io/blog/security-breach-in-str..
Source: stepsecurity.io/blog/security-breach-in-str..
Source: stepsecurity.io/blog/security-breach-in-str..
Here are some receipts (evidence) of the hack:
- The researcher's merged pull request: https://github.com/stripe-samples/accept-a-payment/pull/2719
[
security test by ntk5 · Pull Request #2719 · stripe-samples/accept-a-payment
GitHubstripe-samples
](github.com/stripe-samples/accept-a-payment/..)
- The exploit pull request that exfiltrated the GitHub token: https://github.com/stripe-samples/accept-a-payment/pull/2723/files
[
Update gradlew by just-testing-stuff-thanks · Pull Request #2723 · stripe-samples/accept-a-payment
bug-bounty-test-not-malicious-hackerone
GitHubstripe-samples
](github.com/stripe-samples/accept-a-payment/..)
Implications and Risks
This incident is a stark reminder that even tech giants like Stripe aren't immune to security vulnerabilities. Here's why this breach should make everyone nervous:
- Unauthorized Code Execution: Imagine someone breaking into your house and rearranging your furniture. Now imagine them breaking into your code repository and injecting malicious code. That's precisely what unauthorized code execution allows, potentially leading to backdoors, compromised software, and a whole lot of headaches.
- CI/CD Credentials Theft: Stealing CI/CD credentials, like GitHub tokens, is like handing over the master key to your entire digital infrastructure. Attackers can access package registries, cloud environments, and even more sensitive code repositories.
- Unauthorized Merges: By automating the merging of PRs with stolen tokens, attackers can bypass those pesky manual review processes that are in place for a reason. This can lead to serious security risks, including supply chain compromises, where malicious code sneaks its way into widely used software.
Preventing Future Attacks
So, how do we prevent these attacks and avoid becoming the next cautionary tale in the cybersecurity world? Here are a few ideas:
- Treat Your GitHub Actions Workflows Like Royalty: Don't just set them up and forget about them. Regularly review and update your workflows, paying close attention to the triggers used and the permissions granted.
- Embrace the Principle of Least Privilege: Only give your workflows the bare minimum access they need to do their job. Limiting token scope is like locking up your valuables – it makes it much harder for attackers to make off with everything if they manage to breach your defenses.
- Implement Strict Branch Protection Rules: Make it harder for unauthorized changes to slip through by enforcing branch protection rules, like requiring multiple approvals for PR merges. It's like having a security system for your codebase.
- Use a Harden Runner: StepSecurity's Harden-Runner (https://github.com/step-security/harden-runner) is a lifesaver (or rather, a code-saver). It adds an extra layer of security by preventing sensitive data, like those juicy GitHub tokens, from being exfiltrated by malicious code. Think of it as the cybersecurity equivalent of a vault for your most valuable assets.
[
GitHub - step-security/harden-runner: Network egress filtering and runtime security for GitHub-hosted and self-hosted runners
Network egress filtering and runtime security for GitHub-hosted and self-hosted runners - step-security/harden-runner
GitHubstep-security
](github.com/step-security/harden-runner?ref=..)
Summary
This security breach in Stripe's repository is a wake-up call for everyone who thinks "it can't happen to me." Securing your CI/CD pipelines, especially those using GitHub Actions, is not a suggestion; it's a necessity. By implementing robust security measures, we can make life much more difficult for attackers and keep our codebases, and our sanity, intact.
Source
[
Security Breach in Stripe Repo: A Deep Dive into the “Pwn Request” Vulnerability
The Vulnerability in Stripe’s GitHub Actions Workflow Shows Why Securing CI/CD Pipelines Is Essential
