PWN Request Threat: A Hidden Danger in GitHub Actions
Endor Labs provides comprehensive CI/CD security for GitHub action workflows that detect patterns that may indicate PWN request threats.
Endor Labs provides comprehensive CI/CD security for GitHub action workflows that detect patterns that may indicate PWN request threats.
Endor Labs provides comprehensive CI/CD security for GitHub action workflows that detect patterns that may indicate PWN request threats.
Endor Labs provides comprehensive CI/CD security for GitHub action workflows that detect patterns that may indicate PWN request threats.
Endor Labs provides comprehensive CI/CD security for GitHub action workflows that detect patterns that may indicate PWN request threats.
.png)
GitHub Actons is a powerful tool for automating software development workflows. As we explore and adopt the capabilities of GitHub Actions, it's essential to acknowledge potential risks. One such risk is the PWN request vulnerability, which allows adversaries to obtain elevated privileges to sensitive data from your repositories.
In this blog, we explore what happens when an attacker submits harmful input to a target repository, potentially leading to the execution of attacker-controlled code within a privileged environment. We'll walk you through the underlying causes of this threat, explain how attackers exploit it, and offer practical advice on how to stay safe by following best practices and avoiding common mistakes.
But first, the basics…
What are GitHub Actions?
GitHub Actions enables you to streamline your software development workflow by automating various tasks. You can set up workflows triggered by events in your GitHub repositories, such as commits or pull requests.
GitHub Actions has a marketplace that makes it easy for developers to create reusable “actions” (automation steps like uploading artifacts or installing tools) and integrate them into their pipelines with just one line of code. These actions can be JavaScript, Docker-based, or Composite actions. This adaptability makes GitHub Actions highly flexible.But not following best practices when writing actions can introduce threats.
One critical security concern is the PWN request threat, which can have serious consequences if not addressed properly.
What is a PWN request and what’s the threat?
A “PWN request” is an attack against your GitHub repository that enables an adversary to gain write-level privileges they wouldn’t otherwise have, or extract secrets from your repository. It leverages a workflow “trigger” (a rule for when a workflow should run) called pull_request_target that is intended to run workflows when certain activities occur in a pull request, like if it is closed or reopened.
The workflow gets elevated privileges when started by a pull_request_target trigger, an adversary who is able to abuse that trigger can write to your repository and read its secrets (like deployment API keys, auth tokens, etc.). In recent times we have seen PWN vulnerabilities being identified in popular public repos which have the potential to impact millions of users. One such example is the PWN vulnerability found in puppetlabs.
It’s important to note that pull_request_target and pull_request have almost the same behaviors.
The main difference between pull_request and pull_request_target triggers are:
- Workflows triggered via pull_request_target have write permission to the target repository. They also have access to target repository secrets. The same is true for workflows triggered on pull_request from a branch in the same repository, but not from external forks.
- pull_request_target runs in the context of the target repository of the PR, rather than in the merge commit.
In short, pull_request_target triggers are risky, while pull_request are not.
Now that we know what GitHub Actions and PWN requests are, let’s take a look at the threat they pose.
Identify if your workflow is susceptible to PWN threat
You can be vulnerable to PWN requests if you have workflows using the pull_request_target trigger, and the jobs and steps run with that trigger check out and build code in certain ways.
pull_request_target event should be used very carefully because it gives escalated permissions to the workflows running on the trigger.
To identify if the workflow is susceptible to PWN threat:
Step 1: Make sure the trigger event for the workflow is pull_request_target
Step 2: The PR triggering the workflow is being checked out using actions and commands listed below:
- actions/checkout@
- "${{ github.event.pull_request.head.sha }}"
- "refs/pull/${{ github.event.issue.number }}/head"
Step 3: After checking out the code, the build steps are executed using standard build commands, custom scripts, or any tools that interact with the code (e.g., npm install, make, etc.).
Best practices to avoid PWN vulnerabilities
Keep an eye out for pull_request_target while writing new workflows and fixing existing ones.
While writing new workflows: GitHub introduced the pull_request_target trigger to enable workflows that label pull requests (PRs) or comment on them. This allows developers to automate routine tasks and provide feedback on PRs without requiring extensive processing.
When writing workflows, it's essential to be mindful of code checkout. Specifically, avoid checking out code from PRs that run build or similar commands. Another crucial consideration is access to repository secrets. When using `pull_request_target` triggered workflows, it's vital not to pass credentials while invoking custom scripts on checked-out PR code.
While mixing pull_request_target with an explicit PR checkout may seem vulnerable, it's not always the case. In some cases, workflows may safely mix pull_request_target with an explicit PR checkout. For instance:
- Reformat and commit code without compromising security
- Generate a diff by checking out both base and head repositories
- Run grep on the checked-out source to analyze the code
Fixing existing workflows using the pull_request_target trigger:
If you already using `pull_request_target` trigger, consider implementing these strategies to enhance workflow security:
- Use pull_request trigger instead of pull_request_target if your workflow doesn’t require “write” permissions or secrets access.
- Consider assigning repository privileges only where necessary through ‘pull_request’ and ‘workflow_run’
- Add a condition to ‘pull_request_target’ that ensures the workflow only runs if a specific label is assigned to the pull request. This indicates the PR has been verified by someone with write privileges to the target repository.
How Endor Labs can help
At Endor Labs, we provide comprehensive CI/CD security for GitHub action workflows. Our scanning algorithm reviews all workflow files, identifying potential vulnerabilities and
detecting patterns that may indicate PWN request threats. Specifically, our scanners examine workflow files with ‘pull_request_target’ and ‘issue_comment’ triggers that may execute custom scripts or build commands. This could potentially lead to the execution of malicious code from pull requests. Additionally, we don't stop at a single workflow file. We drill down to all workflows called by parent workflows, searching for PWN request threat patterns that may indicate malicious code execution.
Book a demo to discuss your use cases or start a free trial where you can explore the Endor Labs Software Supply Chain Security platform in a pre-populated demo environment and with your own projects.
