mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['src/pentesting-ci-cd/github-security/abusing-github-actions
This commit is contained in:
Translator
Binary file not shown.
|
After Width: | Height: | Size: 26 KiB |
@@ -2,17 +2,27 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Narzędzia
|
||||
|
||||
Następujące narzędzia są przydatne do znajdowania workflow Github Action, a nawet do znajdowania podatnych:
|
||||
|
||||
- [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven)
|
||||
- [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)
|
||||
- [https://github.com/AdnaneKhan/Gato-X](https://github.com/AdnaneKhan/Gato-X)
|
||||
- [https://github.com/carlospolop/PurplePanda](https://github.com/carlospolop/PurplePanda)
|
||||
- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Sprawdź także jego listę kontrolną w [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits)
|
||||
|
||||
## Podstawowe informacje
|
||||
|
||||
Na tej stronie znajdziesz:
|
||||
|
||||
- **Podsumowanie wszystkich skutków** dostępu atakującego do Github Action
|
||||
- **Podsumowanie wszystkich skutków** ataku, który zdołał uzyskać dostęp do Github Action
|
||||
- Różne sposoby na **uzyskanie dostępu do akcji**:
|
||||
- Posiadanie **uprawnień** do tworzenia akcji
|
||||
- Wykorzystywanie wyzwalaczy związanych z **pull request**
|
||||
- Wykorzystywanie **innych technik zewnętrznego dostępu**
|
||||
- **Pivoting** z już skompromitowanego repozytorium
|
||||
- Na koniec sekcja o **technikach post-exploatacyjnych do wykorzystywania akcji od wewnątrz** (powodując wspomniane skutki)
|
||||
- Na koniec sekcja o **technikach post-exploitation do wykorzystywania akcji od wewnątrz** (powodując wspomniane skutki)
|
||||
|
||||
## Podsumowanie skutków
|
||||
|
||||
@@ -23,26 +33,26 @@ Jeśli możesz **wykonywać dowolny kod w GitHub Actions** w ramach **repozytori
|
||||
- **Kraść sekrety** zamontowane w pipeline i **wykorzystywać uprawnienia pipeline** do uzyskania nieautoryzowanego dostępu do zewnętrznych platform, takich jak AWS i GCP.
|
||||
- **Kompromitować wdrożenia** i inne **artefakty**.
|
||||
- Jeśli pipeline wdraża lub przechowuje zasoby, możesz zmienić końcowy produkt, umożliwiając atak na łańcuch dostaw.
|
||||
- **Wykonywać kod w niestandardowych pracownikach** w celu wykorzystania mocy obliczeniowej i przejścia do innych systemów.
|
||||
- **Wykonywać kod w niestandardowych workerach** w celu wykorzystania mocy obliczeniowej i pivotowania do innych systemów.
|
||||
- **Nadpisywać kod repozytorium**, w zależności od uprawnień związanych z `GITHUB_TOKEN`.
|
||||
|
||||
## GITHUB_TOKEN
|
||||
|
||||
Ten "**sekret**" (pochodzący z `${{ secrets.GITHUB_TOKEN }}` i `${{ github.token }}`) jest przyznawany, gdy administrator włączy tę opcję:
|
||||
Ten "**sekret**" (pochodzący z `${{ secrets.GITHUB_TOKEN }}` i `${{ github.token }}`) jest przyznawany, gdy administrator włącza tę opcję:
|
||||
|
||||
<figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Ten token jest tym samym, którego użyje **Aplikacja Github**, więc może uzyskać dostęp do tych samych punktów końcowych: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
|
||||
Ten token jest tym samym, który **aplikacja Github będzie używać**, więc może uzyskiwać dostęp do tych samych punktów końcowych: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)
|
||||
|
||||
> [!WARNING]
|
||||
> Github powinien wydać [**przepływ**](https://github.com/github/roadmap/issues/74), który **pozwala na dostęp między repozytoriami** w GitHub, aby repozytorium mogło uzyskać dostęp do innych wewnętrznych repozytoriów za pomocą `GITHUB_TOKEN`.
|
||||
> Github powinien wydać [**przepływ**](https://github.com/github/roadmap/issues/74), który **pozwala na dostęp między repozytoriami** w GitHub, aby repozytorium mogło uzyskiwać dostęp do innych wewnętrznych repozytoriów za pomocą `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](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token)
|
||||
|
||||
Zauważ, że token **wygasa po zakończeniu zadania**.\
|
||||
Te tokeny wyglądają tak: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7`
|
||||
|
||||
Kilka interesujących rzeczy, które możesz zrobić z tym tokenem:
|
||||
Niektóre interesujące rzeczy, które możesz zrobić z tym tokenem:
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Merge PR" }}
|
||||
@@ -81,7 +91,7 @@ https://api.github.com/repos/<org_name>/<repo_name>/pulls \
|
||||
{{#endtabs }}
|
||||
|
||||
> [!CAUTION]
|
||||
> 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.
|
||||
> Zauważ, że w kilku przypadkach będziesz mógł znaleźć **tokeny użytkowników githuba w zmiennych środowiskowych Github Actions lub w sekretnych**. Te tokeny mogą dać ci więcej uprawnień do repozytorium i organizacji.
|
||||
|
||||
<details>
|
||||
|
||||
@@ -111,7 +121,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Uzyskaj powłokę odwrotną z tajemnicami</summary>
|
||||
<summary>Uzyskaj odwrotną powłokę z tajemnicami</summary>
|
||||
```yaml
|
||||
name: revshell
|
||||
on:
|
||||
@@ -143,7 +153,7 @@ Możliwe jest sprawdzenie uprawnień nadanych tokenowi Github w repozytoriach in
|
||||
> [!NOTE]
|
||||
> 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 tej sytuacji, możesz po prostu sprawdzić [techniki post-eksploatacji](#post-exploitation-techniques-from-inside-an-action).
|
||||
> Jeśli jesteś w tym scenariuszu, możesz po prostu sprawdzić [techniki post-eksploatacji](#post-exploitation-techniques-from-inside-an-action).
|
||||
|
||||
### Wykonanie z Utworzenia Repozytorium
|
||||
|
||||
@@ -153,7 +163,7 @@ W przypadku, gdy członkowie organizacji mogą **tworzyć nowe repozytoria** i m
|
||||
|
||||
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 **zostanie utworzony PR** lub gdy **zostanie przesłany jakiś kod** (w zależności od tego, jak głośny chcesz być):
|
||||
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ć):
|
||||
```yaml
|
||||
on:
|
||||
workflow_dispatch: # Launch manually
|
||||
@@ -174,31 +184,31 @@ branches:
|
||||
|
||||
### `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 **pierwszy raz**, gdy **współpracujesz**, niektórzy **utrzymujący** będą musieli **zatwierdzić** **wykonanie** workflow:
|
||||
Wyzwalacz workflow **`pull_request`** uruchomi workflow za każdym razem, gdy otrzymany zostanie pull request z pewnymi wyjątkami: domyślnie, jeśli to **pierwszy raz**, gdy **współpracujesz**, niektórzy **utrzymujący** będą musieli **zatwierdzić** **wykonanie** workflow:
|
||||
|
||||
<figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
> [!NOTE]
|
||||
> Ponieważ **domyślne ograniczenie** dotyczy **pierwszych** współpracowników, możesz przyczynić się do **naprawy ważnego błędu/typówki**, a następnie wysłać **inne PR-y, aby nadużyć swoich nowych uprawnień `pull_request`**.
|
||||
> 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.~~
|
||||
> **Testowałem to i to nie działa**: ~~Inną opcją byłoby stworzenie konta o nazwie kogoś, kto przyczynił się do projektu i usunął jego konto.~~
|
||||
|
||||
Ponadto, domyślnie **zapobiega uprawnieniom do zapisu** i **dostępowi do sekretów** w docelowym repozytorium, jak wspomniano w [**dokumentacji**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
|
||||
|
||||
> 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**.
|
||||
> 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ę Github Action, aby wykonać dowolne rzeczy i dodać dowolne akcje. Jednak nie będzie w stanie ukraść sekretów ani nadpisać repozytorium z powodu wspomnianych ograniczeń.
|
||||
|
||||
> [!CAUTION]
|
||||
> **Tak, jeśli atakujący zmieni w PR Github Action, która zostanie wyzwolona, jego Github Action będzie używana, a nie ta z repozytorium źródłowego!**
|
||||
> **Tak, jeśli atakujący zmieni w PR github action, która zostanie wyzwolona, jego Github Action będzie używana, a nie ta z repozytorium źródłowego!**
|
||||
|
||||
Ponieważ atakujący również kontroluje 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**.
|
||||
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 podanym przez PR (aby **nie wykonywać nieufnego kodu**). Aby uzyskać więcej informacji na temat `pull_request_target`, [**sprawdź dokumentację**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
|
||||
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ę**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
|
||||
Ponadto, aby uzyskać więcej informacji na temat tego konkretnego niebezpiecznego użycia, sprawdź ten [**post na blogu githuba**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
|
||||
|
||||
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**.
|
||||
@@ -217,10 +227,10 @@ workflows: [Run Tests]
|
||||
types:
|
||||
- completed
|
||||
```
|
||||
Ponadto, zgodnie z dokumentacją: 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ł**.
|
||||
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**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Pierwszy z nich polega na tym, że **workflow_run** wyzwolony przez workflow 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**.
|
||||
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`
|
||||
|
||||
@@ -228,13 +238,13 @@ TODO
|
||||
|
||||
TODO: Sprawdź, czy podczas wykonywania z `pull_request` używany/pobierany kod pochodzi z oryginału czy z forka PR
|
||||
|
||||
## Wykorzystywanie Wykonania Forków
|
||||
## Wykorzystywanie Wykonania Forka
|
||||
|
||||
Wspomnieliśmy o wszystkich sposobach, w jakie zewnętrzny atakujący mógłby sprawić, że workflow githuba zostanie wykonany, teraz przyjrzyjmy się, jak te wykonania, jeśli są źle skonfigurowane, mogą być wykorzystywane:
|
||||
Wspomnieliśmy o wszystkich sposobach, w jakie zewnętrzny atakujący mógłby zmusić workflow GitHub do wykonania, 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](#pull_request).
|
||||
W przypadku **`pull_request`** workflow będzie wykonywane 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](#pull_request).
|
||||
|
||||
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**.
|
||||
|
||||
@@ -269,14 +279,14 @@ message: |
|
||||
Thank you!
|
||||
</code></pre>
|
||||
|
||||
Potencjalnie **niezaufany kod jest uruchamiany podczas `npm install` lub `npm build`**, ponieważ skrypty budowania i odwołane **pakiety są kontrolowane przez autora PR**.
|
||||
Potencjalnie **niezaufany kod jest uruchamiany podczas `npm install` lub `npm build`**, ponieważ skrypty budujące i odwołane **pakiety są kontrolowane przez autora PR**.
|
||||
|
||||
> [!WARNING]
|
||||
> Github dork do wyszukiwania podatnych akcji to: `event.pull_request pull_request_target extension:yml`, jednak istnieją różne sposoby konfigurowania zadań do wykonywania w sposób bezpieczny, nawet jeśli akcja jest skonfigurowana w sposób niebezpieczny (jak używanie warunków dotyczących tego, kto jest aktorem generującym PR).
|
||||
> Dork GitHub do wyszukiwania podatnych akcji to: `event.pull_request pull_request_target extension:yml`, jednak istnieją różne sposoby konfigurowania zadań do wykonywania w sposób bezpieczny, 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 <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
|
||||
### Wstrzyknięcia skryptów kontekstowych <a href="#understanding-the-risk-of-script-injections" id="understanding-the-risk-of-script-injections"></a>
|
||||
|
||||
Zauważ, że istnieją pewne [**konteksty githuba**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context), 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 **wykonania dowolnego kodu:**
|
||||
Zauważ, że istnieją pewne [**konteksty GitHub**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context), których wartości są **kontrolowane** przez **użytkownika** tworzącego PR. Jeśli akcja GitHub używa tych **danych do wykonania czegokolwiek**, może to prowadzić do **wykonywania dowolnego kodu:**
|
||||
|
||||
{{#ref}}
|
||||
gh-actions-context-script-injections.md
|
||||
@@ -292,15 +302,55 @@ Na przykład ([**to**](https://www.legitsecurity.com/blog/github-privilege-escal
|
||||
|
||||
<figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Podatne Akcje Githuba Trzecich Stron
|
||||
### Dependabot i inne zaufane boty
|
||||
|
||||
Jak wskazano w [**tym poście na blogu**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), kilka organizacji ma akcję GitHub, która scala każdy PRR z `dependabot[bot]`, jak w:
|
||||
```yaml
|
||||
on: pull_request_target
|
||||
jobs:
|
||||
auto-merge:
|
||||
runs-on: ubuntu-latest
|
||||
if: ${ { github.actor == 'dependabot[bot]' }}
|
||||
steps:
|
||||
- run: gh pr merge $ -d -m
|
||||
```
|
||||
Który jest problemem, ponieważ pole `github.actor` zawiera użytkownika, który spowodował ostatnie zdarzenie, które uruchomiło workflow. Istnieje kilka sposobów, aby użytkownik `dependabot[bot]` mógł zmodyfikować PR. Na przykład:
|
||||
|
||||
- Forkuj repozytorium ofiary
|
||||
- Dodaj złośliwy ładunek do swojej kopii
|
||||
- Włącz Dependabot w swoim forku, dodając przestarzałą zależność. Dependabot utworzy gałąź naprawiającą zależność z złośliwym kodem.
|
||||
- Otwórz Pull Request do repozytorium ofiary z tej gałęzi (PR zostanie utworzony przez użytkownika, więc na razie nic się nie wydarzy)
|
||||
- Następnie atakujący wraca do początkowego PR, który Dependabot otworzył w swoim forku i uruchamia `@dependabot recreate`
|
||||
- Następnie Dependabot wykonuje pewne działania w tej gałęzi, które modyfikują PR w repozytorium ofiary, co sprawia, że `dependabot[bot]` jest aktorem ostatniego zdarzenia, które uruchomiło workflow (a zatem, workflow się uruchamia).
|
||||
|
||||
Przechodząc dalej, co by było, gdyby zamiast łączenia Github Action miało wstrzyknięcie polecenia, jak w:
|
||||
```yaml
|
||||
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 }}
|
||||
```
|
||||
Well, oryginalny post na blogu proponuje dwie opcje nadużycia tego zachowania, z których drugą jest:
|
||||
|
||||
- Forkowanie repozytorium ofiary i włączenie Dependabot z jakąś przestarzałą zależnością.
|
||||
- Utworzenie nowej gałęzi z złośliwym kodem wstrzyknięcia powłoki.
|
||||
- Zmiana domyślnej gałęzi repozytorium na tę.
|
||||
- Utworzenie PR z tej gałęzi do repozytorium ofiary.
|
||||
- Uruchomienie `@dependabot merge` w PR, który Dependabot otworzył w swoim forku.
|
||||
- Dependabot połączy swoje zmiany w domyślnej gałęzi twojego forka, aktualizując PR w repozytorium ofiary, czyniąc teraz `dependabot[bot]` aktorem ostatniego zdarzenia, które uruchomiło workflow, używając złośliwej nazwy gałęzi.
|
||||
|
||||
### Wrażliwe działania Github Actions osób trzecich
|
||||
|
||||
#### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact)
|
||||
|
||||
Jak wspomniano w [**tym poście na blogu**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), ta Akcja Githuba umożliwia dostęp do artefaktów z różnych workflow, a nawet repozytoriów.
|
||||
Jak wspomniano w [**tym poście na blogu**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), ta akcja Github pozwala na 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.
|
||||
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 wrażliwy, atakujący może to wykorzystać do skompromitowania innych workflow, które ufają artefaktowi.
|
||||
|
||||
Przykład podatnego workflow:
|
||||
Przykład wrażliwego workflow:
|
||||
```yaml
|
||||
on:
|
||||
workflow_run:
|
||||
@@ -342,7 +392,7 @@ path: ./script.py
|
||||
|
||||
## Inny dostęp zewnętrzny
|
||||
|
||||
### Przejęcie usuniętego repozytorium przestrzeni nazw
|
||||
### 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 utworzyć **repozytorium o tej samej nazwie** co usunięte.
|
||||
|
||||
@@ -360,7 +410,7 @@ Jeśli inne repozytoria korzystały z **zależności z repozytoriów tego użytk
|
||||
|
||||
### 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.
|
||||
Pamięć podręczna jest utrzymywana między **uruchomieniami workflow w tej samej gałęzi**. Oznacza to, że jeśli atakujący **skomprimitował** **pakiet**, który jest następnie przechowywany w pamięci podręcznej i **pobierany** oraz wykonywany przez **bardziej uprzywilejowany** workflow, będzie mógł również **skomprimitować** ten workflow.
|
||||
|
||||
{{#ref}}
|
||||
gh-actions-cache-poisoning.md
|
||||
@@ -368,7 +418,7 @@ gh-actions-cache-poisoning.md
|
||||
|
||||
### Zatrucie artefaktów
|
||||
|
||||
Workflow mogą korzystać z **artefaktów z innych workflow, a nawet repozytoriów**, jeśli atakujący zdoła **skomprumotować** Github Action, która **przesyła artefakt**, który jest później używany przez inny workflow, może **skomprumotować inne workflow**:
|
||||
Workflow mogą korzystać z **artefaktów z innych workflow, a nawet repozytoriów**, jeśli atakujący zdoła **skomprimitować** Github Action, która **przesyła artefakt**, który jest później używany przez inny workflow, może **skomprimitować inne workflow**:
|
||||
|
||||
{{#ref}}
|
||||
gh-actions-artifact-poisoning.md
|
||||
@@ -376,7 +426,7 @@ gh-actions-artifact-poisoning.md
|
||||
|
||||
---
|
||||
|
||||
## Posteksploatacja z akcji
|
||||
## Post eksploatacja z akcji
|
||||
|
||||
### Uzyskiwanie dostępu do AWS i GCP za pomocą OIDC
|
||||
|
||||
@@ -392,9 +442,9 @@ Sprawdź następujące strony:
|
||||
|
||||
### Uzyskiwanie dostępu do sekretów <a href="#accessing-secrets" id="accessing-secrets"></a>
|
||||
|
||||
Jeśli wstrzykujesz zawartość do skryptu, warto wiedzieć, jak uzyskać dostęp 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`**.
|
||||
- Jeśli sekret lub token jest ustawiony jako **zmienna środowiskowa**, można go bezpośrednio uzyskać przez środowisko za pomocą **`printenv`**.
|
||||
|
||||
<details>
|
||||
|
||||
@@ -466,11 +516,11 @@ 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 pliku konfiguracyjnym akcji Github.
|
||||
Sposobem na znalezienie, które **Github Actions są wykonywane w infrastrukturze niebędącej 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 akcja może **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 w dowolnym kroku, zrzucając jego pamięć:
|
||||
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 poprzez zrzut jego pamięci:
|
||||
```bash
|
||||
sudo apt-get install -y gdb
|
||||
sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')"
|
||||
@@ -517,12 +567,12 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
|
||||
|
||||
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ą osobistego tokena dostępu:
|
||||
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>
|
||||
```
|
||||
Następnie użytkownik mógłby wyszukiwać **wyciekłe sekrety w warstwach obrazu Docker:**
|
||||
Następnie użytkownik może wyszukiwać **wyciekłe sekrety w warstwach obrazu Docker:**
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
|
||||
@@ -530,24 +580,15 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forens
|
||||
|
||||
### Wrażliwe informacje w logach Github Actions
|
||||
|
||||
Nawet jeśli **Github** próbuje **wykrywać wartości sekretów** w logach akcji i **unika ich wyświetlania**, **inne wrażliwe dane**, które mogły zostać wygenerowane podczas wykonywania akcji, nie będą ukryte. Na przykład JWT podpisany wartością sekretu nie będzie ukryty, chyba że jest [specjalnie skonfigurowany](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
|
||||
Nawet jeśli **Github** próbuje **wykrywać wartości sekretów** w logach akcji i **unikać ich wyświetlania**, **inne wrażliwe dane**, które mogły zostać wygenerowane podczas wykonywania akcji, nie będą ukryte. Na przykład JWT podpisany wartością sekretu nie będzie ukryty, chyba że jest [specjalnie skonfigurowany](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
|
||||
|
||||
## Zacieranie śladów
|
||||
|
||||
(Teknika z [**tutaj**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Przede wszystkim, każdy PR zgłoszony jest wyraźnie widoczny dla publiczności w Github i dla docelowego konta GitHub. W GitHub domyślnie **nie możemy usunąć PR z internetu**, ale jest pewien zwrot akcji. Dla kont GitHub, które są **zawieszone** przez Github, wszystkie ich **PR są automatycznie usuwane** i usuwane z internetu. Aby ukryć swoją aktywność, musisz albo sprawić, by Twoje **konto GitHub zostało zawieszone, albo oznaczyć swoje konto**. To **ukryje wszystkie Twoje działania** na GitHubie przed internetem (w zasadzie usunie wszystkie Twoje PR związane z eksploatacją).
|
||||
(Technika z [**tutaj**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Przede wszystkim, każdy PR zgłoszony jest wyraźnie widoczny dla publiczności w Github i dla docelowego konta GitHub. W GitHub domyślnie **nie możemy usunąć PR z internetu**, ale jest pewien zwrot. Dla kont GitHub, które są **zawieszone** przez Github, wszystkie ich **PR są automatycznie usuwane** i usuwane z internetu. Aby ukryć swoją aktywność, musisz albo sprawić, aby twoje **konto GitHub zostało zawieszone, albo oznaczyć swoje konto**. To **ukryje wszystkie twoje aktywności** na GitHubie z internetu (w zasadzie usunie wszystkie twoje PR związane z eksploatacją).
|
||||
|
||||
Organizacja w GitHub jest bardzo proaktywna w zgłaszaniu kont do GitHub. Wszystko, co musisz zrobić, to podzielić się „jakimiś rzeczami” w Issue, a oni upewnią się, że Twoje konto zostanie zawieszone w ciągu 12 godzin :p i oto masz, uczyniłeś swoją eksploatację niewidoczną na githubie.
|
||||
Organizacja w GitHub jest bardzo proaktywna w zgłaszaniu kont do GitHub. Wszystko, co musisz zrobić, to podzielić się „jakimiś rzeczami” w Issue, a oni upewnią się, że twoje konto zostanie zawieszone w ciągu 12 godzin :p i masz, uczyniłeś swoją eksploatację niewidoczną na githubie.
|
||||
|
||||
> [!WARNING]
|
||||
> Jedynym sposobem, aby organizacja dowiedziała się, że została zaatakowana, jest sprawdzenie logów GitHub z SIEM, ponieważ z interfejsu GitHub PR zostałby usunięty.
|
||||
|
||||
## Narzędzia
|
||||
|
||||
Następujące narzędzia są przydatne do znajdowania workflow Github Action, a nawet do znajdowania podatnych:
|
||||
|
||||
- [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven)
|
||||
- [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)
|
||||
- [https://github.com/AdnaneKhan/Gato-X](https://github.com/AdnaneKhan/Gato-X)
|
||||
- [https://github.com/carlospolop/PurplePanda](https://github.com/carlospolop/PurplePanda)
|
||||
> Jedynym sposobem dla organizacji, aby dowiedzieć się, że zostały celem, jest sprawdzenie logów GitHub z SIEM, ponieważ z interfejsu GitHub PR zostałby usunięty.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user