diff --git a/src/images/CH_logo_ads.png b/src/images/CH_logo_ads.png new file mode 100644 index 000000000..b407c8929 Binary files /dev/null and b/src/images/CH_logo_ads.png differ diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md index 1d81ff803..a4a51d7c7 100644 --- a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md +++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md @@ -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ę:
-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///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.
@@ -111,7 +121,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
-Uzyskaj powłokę odwrotną z tajemnicami +Uzyskaj odwrotną powłokę z tajemnicami ```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:
> [!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! -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 +### Wstrzyknięcia skryptów kontekstowych -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
-### 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 -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`**.
@@ -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 --password-stdin docker pull ghcr.io//: ``` -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}}