[Feature Request] support for other CI Workflows

[bugbounty1420]

Problem Statement

expand tool to target other CI workflows

Proposed Solution

What i have done in the past regarding github tokens that dont have workflow scope is to target othe CI workflows that can be just triggered with PUSH scope to an alternate branch such as circleci(.circleci/config.yml) and travisci (.travis.yml). Any/all secrets configured in these environments are also vulnerable since they dont need workflow scope to be tiggered.

May be you can enhance your tool to target other CI tools such circleci, travisci, azure pipelines or even jenkins.

Also,
without workflow scope, injection points in workflows could be targeted. similar to pull_request_target where a sink is detected. we dont need pull_request_target since the token has push permissions.

Use Case

Target other CI workflows even if there is no workflow scope. No need of workflow scope to target other workflows and get secrets.

Feature Category

Attack/Exploitation

Priority

High - Important for my workflow

Alternative Solutions

No response

Additional Context

No response

Contribution

• I would be willing to help implement this feature
• I would be willing to help test this feature
• I would be willing to help write documentation for this feature

[AdnaneKhan]

Thanks for the request! This is something gato-x can do but UX will be tricky.

Will probably start with GitHub Actions only and then expand.

I’ve also been in the scenario many times where I have a repo scoped token and need to escalate.

In this case the main paths are:

• push (without branch restrictions)
• pull_request from feature branch
• workflow_dispatch

Other more exotic ones exist too. Typically the goal is to get to specific secrets (which repo scoped token can list the names of)

Do you see this feature as something like:

This token does not have workflow scope, but you can get secret A,B from workflow C by pushing a feature branch?

Do you think this feature should be limited to single repo mode (and an optional feature for org level runs)? In my experience running gato-x with a repo scoped token with access is fairly verbose as it is.

[Firebasky]

@AdnaneKhan I would like to know why workflow_dispatch is considered as a controllable point? Because I believe that workflow_dispatch can only be controlled by the repository's author. I don't understand this, and I need your help

[AdnaneKhan]

@Firebasky, workflow_dispatch often plays a role in escalation chains starting from a compromised GITHUB_TOKEN. Let’s say you get RCE in a workflow that has a full write github_token but no secrets.

If other workflows run on workflow_dispatch and use secrets, then you can often pivot to that workflow by modifying code in a feature branch and then issuing a dispatch event to that workflow for the feature branch you just created.