From e1a1b2a31f0d5ea9c068d5e6c8526052d57e332b Mon Sep 17 00:00:00 2001 From: carlospolop Date: Wed, 25 Jun 2025 02:19:23 +0200 Subject: [PATCH] f --- .../abusing-github-actions/README.md | 44 +++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md index 707a79a38..8664c5887 100644 --- a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md +++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md @@ -316,6 +316,50 @@ For example ([**this**](https://www.legitsecurity.com/blog/github-privilege-esca
+### Dependabot and other trusted bots + +As indicated in [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), several organizations have a Github Action that merges any PRR from `dependabot[bot]` like in: + +```yaml +on: pull_request_target +jobs: + auto-merge: + runs-on: ubuntu-latest + if: ${ { github.actor == 'dependabot[bot]' }} + steps: + - run: gh pr merge $ -d -m +``` + +Which is a problem because the `github.actor` field contains the user who caused the latest event that triggered the workflow. And There are several ways to make the `dependabot[bot]` user to modify a PR. For example: + +- Fork the victim repository +- Add the malicious payload to your copy +- Enable Dependabot on your fork adding an outdated dependency. Dependabot will create a branch fixing the dependency with malicious code. +- Open a Pull Request to the victim repository from that branch (the PR will be created by the user so nothing will happen yet) +- Then, attacker goes back to the initial PR Dependabot opened in his fork and runs `@dependabot recreate` +- Then, Dependabot perform some actions in that branch, that modified the PR over the victim repo, which makes `dependabot[bot]` the actor of the latest event that triggered the workflow (and therefore, the workflow runs). + +Moving on, what if instead of merging the Github Action would have a command injection like in: + +```yaml +on: pull_request_target +jobs: + just-printing-stuff: + runs-on: ubuntu-latest + if: ${ { github.actor == 'dependabot[bot]' }} + steps: + - run: echo ${ { github.event.pull_request.head.ref }} +``` + +Well, the original blogpost proposes two options to abuse this behavior being the second one: + +- Fork the victim repository and enable Dependabot with some outdated dependency. +- Create a new branch with the malicious shell injeciton code. +- Change the default branch of the repo to that one +- Create a PR from this branch to the victim repository. +- Run `@dependabot merge` in the PR Dependabot opened in his fork. +- Dependabot will merge his changes in the default branch of your forked repository, updating the PR in the victim repository making now the `dependabot[bot]` the actor of the latest event that triggered the workflow and using a malicious branch name. + ### Vulnerable Third Party Github Actions #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)