Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/

src/pentesting-ci-cd/github-security/abusing-github-actions/README.md

@@ -1,20 +1,20 @@
-# Abusing Github Actions
+# Abusando do Github Actions
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Basic Information
+## Informações Básicas
 
 Nesta página você encontrará:
 
-- Um **resumo de todos os impactos** de um atacante conseguindo acessar uma Github Action
+- Um **resumo de todos os impactos** de um atacante conseguindo acessar um Github Action
 - Diferentes maneiras de **obter acesso a uma ação**:
 - Ter **permissões** para criar a ação
-- Abusar de **gatilhos** relacionados a pull requests
+- Abusar de **gatilhos** relacionados a **pull requests**
 - Abusar de **outras técnicas de acesso externo**
 - **Pivotar** de um repositório já comprometido
 - Finalmente, uma seção sobre **técnicas de pós-exploração para abusar de uma ação de dentro** (causando os impactos mencionados)
 
-## Impacts Summary
+## Resumo dos Impactos
 
 Para uma introdução sobre [**Github Actions, confira as informações básicas**](../basic-github-information.md#github-actions).
 
@@ -28,11 +28,11 @@ Se você pode **executar código arbitrário no GitHub Actions** dentro de um **
 
 ## GITHUB_TOKEN
 
-Este "**segredo**" (vindo de `${{ secrets.GITHUB_TOKEN }}` e `${{ github.token }}`) é fornecido quando o administrador habilita esta opção:
+Este "**segredo**" (vindo de `${{ secrets.GITHUB_TOKEN }}` e `${{ github.token }}`) é dado quando o administrador habilita esta opção:
 
 <figure><img src="../../../images/image (86).png" alt=""><figcaption></figcaption></figure>
 
-Este token é o mesmo que uma **Aplicação Github usará**, então pode acessar os mesmos 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)
+Este token é o mesmo que uma **Aplicação do Github usará**, então pode acessar os mesmos 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)
 
 > [!WARNING]
 > O Github deve lançar um [**fluxo**](https://github.com/github/roadmap/issues/74) que **permita acesso entre repositórios** dentro do GitHub, para que um repositório possa acessar outros repositórios internos usando o `GITHUB_TOKEN`.
@@ -143,7 +143,7 @@ secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}}
 > [!NOTE]
 > Esta seria a maneira mais fácil de comprometer ações do Github, já que este caso supõe que você tenha acesso para **criar um novo repositório na organização**, ou tenha **privilegios de escrita sobre um repositório**.
 >
-> Se você estiver nesse cenário, pode apenas verificar as [técnicas de Pós Exploração](./#post-exploitation-techniques-from-inside-an-action).
+> Se você estiver nesse cenário, pode apenas verificar as [técnicas de pós-exploração](./#post-exploitation-techniques-from-inside-an-action).
 
 ### Execução a partir da Criação de Repositório
 
@@ -170,22 +170,22 @@ branches:
 ## Execução Forked
 
 > [!NOTE]
-> Existem diferentes gatilhos que poderiam permitir a um atacante **executar uma Github Action de outro repositório**. Se essas ações acionáveis forem mal configuradas, um atacante poderá comprometê-las.
+> Existem diferentes gatilhos que poderiam permitir a um atacante **executar uma Github Action de outro repositório**. Se essas ações acionáveis estiverem mal configuradas, um atacante poderá comprometê-las.
 
 ### `pull_request`
 
-O gatilho do fluxo de trabalho **`pull_request`** executará o fluxo de trabalho toda vez que um pull request for recebido, com algumas exceções: por padrão, se for a **primeira vez** que você está **colaborando**, algum **mantenedor** precisará **aprovar** a **execução** do fluxo de trabalho:
+O gatilho de workflow **`pull_request`** executará o workflow toda vez que um pull request for recebido, com algumas exceções: por padrão, se for a **primeira vez** que você está **colaborando**, algum **mantenedor** precisará **aprovar** a **execução** do workflow:
 
 <figure><img src="../../../images/image (184).png" alt=""><figcaption></figcaption></figure>
 
 > [!NOTE]
-> Como a **limitação padrão** é para **contribuidores de primeira viagem**, você poderia contribuir **corrigindo um bug/erro válido** e depois enviar **outros PRs para abusar de seus novos privilégios de `pull_request`**.
+> Como a **limitação padrão** é para **contribuidores de primeira viagem**, você poderia contribuir **corrigindo um bug/erro válido** e então enviar **outros PRs para abusar de seus novos privilégios de `pull_request`**.
 >
 > **Eu testei isso e não funciona**: ~~Outra opção seria criar uma conta com o nome de alguém que contribuiu para o projeto e deletou sua conta.~~
 
 Além disso, por padrão **impede permissões de escrita** e **acesso a segredos** no repositório alvo, conforme mencionado na [**documentação**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories):
 
-> Com a exceção de `GITHUB_TOKEN`, **segredos não são passados para o runner** quando um fluxo de trabalho é acionado de um repositório **forked**. O **`GITHUB_TOKEN` tem permissões de leitura** em pull requests **de repositórios forked**.
+> Com a exceção de `GITHUB_TOKEN`, **segredos não são passados para o runner** quando um workflow é acionado de um repositório **forked**. O **`GITHUB_TOKEN` tem permissões de leitura** em pull requests **de repositórios forked**.
 
 Um atacante poderia modificar a definição da Github Action para executar coisas arbitrárias e adicionar ações arbitrárias. No entanto, ele não poderá roubar segredos ou sobrescrever o repositório devido às limitações mencionadas.
 
@@ -196,20 +196,20 @@ Como o atacante também controla o código sendo executado, mesmo que não haja
 
 ### **`pull_request_target`**
 
-O gatilho do fluxo de trabalho **`pull_request_target`** tem **permissão de escrita** no repositório alvo e **acesso a segredos** (e não pede permissão).
+O gatilho de workflow **`pull_request_target`** tem **permissão de escrita** no repositório alvo e **acesso a segredos** (e não pede permissão).
 
-Note que o gatilho do fluxo de trabalho **`pull_request_target`** **executa no contexto base** e não no fornecido pelo PR (para **não executar código não confiável**). Para mais informações sobre `pull_request_target`, [**verifique a documentação**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
+Note que o gatilho de workflow **`pull_request_target`** **executa no contexto base** e não no fornecido pelo PR (para **não executar código não confiável**). Para mais informações sobre `pull_request_target`, [**verifique a documentação**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\
 Além disso, para mais informações sobre esse uso específico perigoso, confira este [**post no blog do github**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).
 
-Pode parecer que, porque o **fluxo de trabalho executado** é o definido na **base** e **não no PR**, é **seguro** usar **`pull_request_target`**, mas há **alguns casos em que não é**.
+Pode parecer que, como o **workflow executado** é o definido na **base** e **não no PR**, é **seguro** usar **`pull_request_target`**, mas há **alguns casos em que não é**.
 
 E este terá **acesso a segredos**.
 
 ### `workflow_run`
 
-O gatilho [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) permite executar um fluxo de trabalho a partir de outro quando está `completo`, `solicitado` ou `em_andamento`.
+O gatilho [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) permite executar um workflow a partir de outro quando está `completo`, `solicitado` ou `em progresso`.
 
-Neste exemplo, um fluxo de trabalho é configurado para ser executado após a conclusão do fluxo de trabalho separado "Executar Testes":
+Neste exemplo, um workflow é configurado para ser executado após a conclusão do workflow separado "Executar Testes":
 ```yaml
 on:
 workflow_run:
@@ -219,7 +219,7 @@ types:
 ```
 Além disso, de acordo com a documentação: O fluxo de trabalho iniciado pelo evento `workflow_run` é capaz de **acessar segredos e escrever tokens, mesmo que o fluxo de trabalho anterior não tenha**.
 
-Esse tipo de fluxo de trabalho pode ser atacado se **depender** de um **fluxo de trabalho** que pode ser **ativado** por um usuário externo via **`pull_request`** ou **`pull_request_target`**. Alguns exemplos vulneráveis podem ser [**encontrados neste blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** O primeiro consiste no fluxo de trabalho ativado por **`workflow_run`** baixando o código dos atacantes: `${{ github.event.pull_request.head.sha }}`\
+Esse tipo de fluxo de trabalho pode ser atacado se **depender** de um **fluxo de trabalho** que pode ser **ativado** por um usuário externo via **`pull_request`** ou **`pull_request_target`**. Alguns exemplos vulneráveis podem ser [**encontrados neste blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** O primeiro consiste no fluxo de trabalho acionado por **`workflow_run`** baixando o código do atacante: `${{ github.event.pull_request.head.sha }}`\
 O segundo consiste em **passar** um **artefato** do código **não confiável** para o fluxo de trabalho **`workflow_run`** e usar o conteúdo desse artefato de uma maneira que o torne **vulnerável a RCE**.
 
 ### `workflow_call`
@@ -236,10 +236,10 @@ Mencionamos todas as maneiras que um atacante externo poderia conseguir fazer um
 
 No caso de **`pull_request`,** o fluxo de trabalho será executado no **contexto do PR** (então executará o **código malicioso do PR**), mas alguém precisa **autorizá-lo primeiro** e ele será executado com algumas [limitações](./#pull_request).
 
-No caso de um fluxo de trabalho usando **`pull_request_target` ou `workflow_run`** que depende de um fluxo de trabalho que pode ser ativado a partir de **`pull_request_target` ou `pull_request`**, o código do repositório original será executado, então o **atacante não pode controlar o código executado**.
+No caso de um fluxo de trabalho usando **`pull_request_target` ou `workflow_run`** que depende de um fluxo de trabalho que pode ser acionado a partir de **`pull_request_target` ou `pull_request`**, o código do repositório original será executado, então o **atacante não pode controlar o código executado**.
 
 > [!CAUTION]
-> No entanto, se a **ação** tiver um **checkout explícito do PR** que irá **obter o código do PR** (e não da base), ele usará o código controlado pelos atacantes. Por exemplo (ver linha 12 onde o código do PR é baixado):
+> No entanto, se a **ação** tiver um **checkout de PR explícito** que **obterá o código do PR** (e não da base), usará o código controlado pelo atacante. Por exemplo (ver linha 12 onde o código do PR é baixado):
 
 <pre class="language-yaml"><code class="lang-yaml"># INSECURE. Fornecido apenas como exemplo.
 on:
@@ -288,7 +288,7 @@ De acordo com a documentação: Você pode tornar uma **variável de ambiente di
 
 Se um atacante puder **injetar qualquer valor** dentro dessa variável **env**, ele poderá injetar variáveis de ambiente que poderiam executar código nas etapas seguintes, como **LD_PRELOAD** ou **NODE_OPTIONS**.
 
-Por exemplo ([**este**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) e [**este**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), imagine um fluxo de trabalho que confia em um artefato carregado para armazenar seu conteúdo dentro da variável de ambiente **`GITHUB_ENV`**. Um atacante poderia carregar algo assim para comprometê-lo:
+Por exemplo ([**isso**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) e [**isso**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), imagine um fluxo de trabalho que confia em um artefato carregado para armazenar seu conteúdo dentro da variável de ambiente **`GITHUB_ENV`**. Um atacante poderia carregar algo assim para comprometê-lo:
 
 <figure><img src="../../../images/image (261).png" alt=""><figcaption></figcaption></figure>
 
@@ -323,7 +323,7 @@ with:
 name: artifact
 path: ./script.py
 ```
-Isto pode ser atacado com este fluxo de trabalho:
+Isso pode ser atacado com este fluxo de trabalho:
 ```yaml
 name: "some workflow"
 on: pull_request
@@ -349,7 +349,7 @@ Se uma conta mudar seu nome, outro usuário pode registrar uma conta com esse no
 > [!CAUTION]
 > Portanto, se uma ação estiver usando um repositório de uma conta inexistente, ainda é possível que um atacante crie essa conta e comprometa a ação.
 
-Se outros repositórios estavam usando **dependências desses repositórios de usuário**, um atacante poderá sequestrá-los. Aqui está uma explicação mais completa: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
+Se outros repositórios estavam usando **dependências desses repositórios de usuário**, um atacante poderá sequestrá-los. Aqui você tem uma explicação mais completa: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/)
 
 ---
 
@@ -360,7 +360,7 @@ Se outros repositórios estavam usando **dependências desses repositórios de u
 
 ### Envenenamento de Cache
 
-Um cache é mantido entre **execuções de workflow na mesma branch**. O que significa que, se um atacante **comprometer** um **pacote** que é então armazenado no cache e **baixado** e executado por um **workflow mais privilegiado**, ele poderá **comprometer** também esse workflow.
+Um cache é mantido entre **execuções de workflow na mesma branch**. O que significa que, se um atacante **comprometer** um **pacote** que é então armazenado no cache e **baixado** e executado por um **workflow mais privilegiado**, ele poderá também **comprometer** esse workflow.
 
 {{#ref}}
 gh-actions-cache-poisoning.md
@@ -394,7 +394,7 @@ Verifique as seguintes páginas:
 
 Se você estiver injetando conteúdo em um script, é interessante saber como você pode acessar segredos:
 
-- Se o segredo ou token estiver definido como uma **variável de ambiente**, ele pode ser acessado diretamente através do ambiente usando **`printenv`**.
+- Se o segredo ou token estiver definido como uma **variável de ambiente**, pode ser acessado diretamente através do ambiente usando **`printenv`**.
 
 <details>
 
@@ -468,7 +468,7 @@ key: ${{ secrets.PUBLISH_KEY }}
 
 A maneira de descobrir quais **Github Actions estão sendo executadas em infraestrutura não-Github** é procurar por **`runs-on: self-hosted`** na configuração yaml da Github Action.
 
-Runners **auto-hospedados** podem ter acesso a **informações extra sensíveis**, a outros **sistemas de rede** (pontos finais vulneráveis na rede? serviço de metadados?) ou, mesmo que esteja isolado e destruído, **mais de uma ação pode ser executada ao mesmo tempo** e a maliciosa poderia **roubar os segredos** da outra.
+Runners **auto-hospedados** podem ter acesso a **informações extra sensíveis**, a outros **sistemas de rede** (pontos finais vulneráveis na rede? serviço de metadados?) ou, mesmo que esteja isolado e destruído, **mais de uma ação pode ser executada ao mesmo tempo** e a maliciosa pode **roubar os segredos** da outra.
 
 Em runners auto-hospedados, também é possível obter os **segredos do processo \_Runner.Listener**\_\*\* que conterá todos os segredos dos fluxos de trabalho em qualquer etapa, despejando sua memória:
 ```bash
@@ -517,7 +517,7 @@ ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ e
 
 Como você pode ver no código anterior, o registro do Github está hospedado em **`ghcr.io`**.
 
-Um usuário com permissões de leitura sobre o repositório poderá então baixar a Imagem Docker usando um token de acesso pessoal:
+Um usuário com permissões de leitura sobre o repositório poderá então baixar a imagem Docker usando um token de acesso pessoal:
 ```bash
 echo $gh_token | docker login ghcr.io -u <username> --password-stdin
 docker pull ghcr.io/<org-name>/<repo_name>:<tag>
@@ -530,20 +530,20 @@ https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-m
 
 ### Informações sensíveis nos logs do Github Actions
 
-Mesmo que o **Github** tente **detectar valores secretos** nos logs das ações e **evitar mostrar** eles, **outros dados sensíveis** que poderiam ter sido gerados na execução da ação não serão ocultados. Por exemplo, um JWT assinado com um valor secreto não será ocultado a menos que seja [especificamente configurado](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
+Mesmo que o **Github** tente **detectar valores secretos** nos logs das ações e **evitar mostrá-los**, **outros dados sensíveis** que poderiam ter sido gerados na execução da ação não serão ocultados. Por exemplo, um JWT assinado com um valor secreto não será ocultado, a menos que seja [especificamente configurado](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret).
 
 ## Cobrir suas Trilhas
 
 (Técnica de [**aqui**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) Primeiro de tudo, qualquer PR levantada é claramente visível ao público no Github e à conta alvo do GitHub. No GitHub, por padrão, **não podemos deletar um PR da internet**, mas há uma reviravolta. Para contas do Github que estão **suspensas** pelo Github, todos os seus **PRs são automaticamente deletados** e removidos da internet. Portanto, para esconder sua atividade, você precisa ou ter sua **conta do GitHub suspensa ou ter sua conta sinalizada**. Isso **esconderia todas as suas atividades** no GitHub da internet (basicamente remover todos os seus PRs de exploração)
 
-Uma organização no GitHub é muito proativa em relatar contas ao GitHub. Tudo que você precisa fazer é compartilhar “algumas coisas” em uma Issue e eles garantirão que sua conta seja suspensa em 12 horas :p e aí está, fez sua exploração invisível no github.
+Uma organização no GitHub é muito proativa em relatar contas ao GitHub. Tudo o que você precisa fazer é compartilhar “algumas coisas” em uma Issue e eles garantirão que sua conta seja suspensa em 12 horas :p e aí está, fez sua exploração invisível no github.
 
 > [!WARNING]
 > A única maneira de uma organização descobrir que foi alvo é verificar os logs do GitHub a partir do SIEM, pois na interface do GitHub o PR seria removido.
 
 ## Ferramentas
 
-As seguintes ferramentas são úteis para encontrar fluxos de trabalho do Github Action e até mesmo encontrar vulneráveis:
+As seguintes ferramentas são úteis para encontrar fluxos de trabalho do Github Action e até mesmo encontrar os vulneráveis:
 
 - [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven)
 - [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato)

src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-cache-poisoning.md

@@ -1 +1 @@
-# GH Actions - Cache Poisoning
+# GH Actions - Envenenamento de Cache