mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-02 02:54:53 -07:00
Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/
This commit is contained in:
Translator
@@ -1,10 +1,10 @@
|
||||
# Github Security
|
||||
# Segurança do Github
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## O que é o Github
|
||||
|
||||
(De [aqui](https://kinsta.com/knowledgebase/what-is-github/)) Em um nível alto, **o GitHub é um site e serviço baseado em nuvem que ajuda os desenvolvedores a armazenar e gerenciar seu código, além de rastrear e controlar alterações em seu código**.
|
||||
(De [aqui](https://kinsta.com/knowledgebase/what-is-github/)) Em um nível alto, **o GitHub é um site e um serviço baseado em nuvem que ajuda os desenvolvedores a armazenar e gerenciar seu código, além de rastrear e controlar as alterações em seu código**.
|
||||
|
||||
### Informações Básicas
|
||||
|
||||
@@ -32,7 +32,7 @@ Ferramentas (cada ferramenta contém sua lista de dorks):
|
||||
- [https://github.com/techgaun/github-dorks](https://github.com/techgaun/github-dorks) ([Lista de Dorks](https://github.com/techgaun/github-dorks/blob/master/github-dorks.txt))
|
||||
- [https://github.com/hisxo/gitGraber](https://github.com/hisxo/gitGraber) ([Lista de Dorks](https://github.com/hisxo/gitGraber/tree/master/wordlists))
|
||||
|
||||
### Github Leaks
|
||||
### Vazamentos do Github
|
||||
|
||||
Por favor, note que os github dorks também são destinados a pesquisar vazamentos usando opções de pesquisa do github. Esta seção é dedicada a aquelas ferramentas que irão **baixar cada repositório e procurar informações sensíveis neles** (até verificando certa profundidade de commits).
|
||||
|
||||
@@ -51,9 +51,9 @@ Ferramentas (cada ferramenta contém sua lista de regexes):
|
||||
|
||||
### Forks Externos
|
||||
|
||||
É possível **comprometer repositórios abusando de pull requests**. Para saber se um repositório é vulnerável, você precisa principalmente ler as configurações yaml do Github Actions. [**Mais informações sobre isso abaixo**](./#execution-from-a-external-fork).
|
||||
É possível **comprometer repositórios abusando de pull requests**. Para saber se um repositório é vulnerável, você precisa principalmente ler as configurações yaml das Ações do Github. [**Mais informações sobre isso abaixo**](./#execution-from-a-external-fork).
|
||||
|
||||
### Github Leaks em forks deletados/internos
|
||||
### Vazamentos do Github em forks deletados/internos
|
||||
|
||||
Mesmo que deletados ou internos, pode ser possível obter dados sensíveis de forks de repositórios do github. Confira aqui:
|
||||
|
||||
@@ -67,9 +67,9 @@ accessible-deleted-data-in-github.md
|
||||
|
||||
Existem alguns **privilégios padrão** que podem ser atribuídos aos **membros** da organização. Estes podem ser controlados a partir da página `https://github.com/organizations/<org_name>/settings/member_privileges` ou da [**API de Organizações**](https://docs.github.com/en/rest/orgs/orgs).
|
||||
|
||||
- **Permissões básicas**: Os membros terão a permissão Nenhuma/Leitura/escrita/Admin sobre os repositórios da organização. O recomendado é **Nenhuma** ou **Leitura**.
|
||||
- **Fork de repositório**: Se não for necessário, é melhor **não permitir** que os membros façam fork dos repositórios da organização.
|
||||
- **Criação de páginas**: Se não for necessário, é melhor **não permitir** que os membros publiquem páginas dos repositórios da organização. Se necessário, você pode permitir a criação de páginas públicas ou privadas.
|
||||
- **Permissões básicas**: Os membros terão a permissão Nenhuma/Leitura/escrita/Admin sobre os repositórios da org. O recomendado é **Nenhuma** ou **Leitura**.
|
||||
- **Forking de repositórios**: Se não for necessário, é melhor **não permitir** que os membros façam fork dos repositórios da organização.
|
||||
- **Criação de páginas**: Se não for necessário, é melhor **não permitir** que os membros publiquem páginas dos repositórios da org. Se necessário, você pode permitir a criação de páginas públicas ou privadas.
|
||||
- **Solicitações de acesso à integração**: Com isso habilitado, colaboradores externos poderão solicitar acesso a aplicativos do GitHub ou OAuth para acessar esta organização e seus recursos. Geralmente é necessário, mas se não for, é melhor desabilitar.
|
||||
- _Não consegui encontrar essa informação na resposta das APIs, compartilhe se você encontrar_
|
||||
- **Mudança de visibilidade do repositório**: Se habilitado, **membros** com permissões **admin** para o **repositório** poderão **mudar sua visibilidade**. Se desabilitado, apenas os proprietários da organização podem mudar as visibilidades dos repositórios. Se você **não** quiser que as pessoas tornem as coisas **públicas**, certifique-se de que isso esteja **desabilitado**.
|
||||
@@ -89,11 +89,11 @@ Várias configurações relacionadas à segurança podem ser configuradas para a
|
||||
|
||||
- **Políticas de ações do Github**: Permite indicar quais repositórios podem executar fluxos de trabalho e quais fluxos de trabalho devem ser permitidos. É recomendado **especificar quais repositórios** devem ser permitidos e não permitir que todas as ações sejam executadas.
|
||||
- [**API-1**](https://docs.github.com/en/rest/actions/permissions#get-allowed-actions-and-reusable-workflows-for-an-organization)**,** [**API-2**](https://docs.github.com/en/rest/actions/permissions#list-selected-repositories-enabled-for-github-actions-in-an-organization)
|
||||
- **Fluxos de trabalho de pull request de fork de colaboradores externos**: É recomendado **exigir aprovação para todos** os colaboradores externos.
|
||||
- **Fluxos de trabalho de pull requests de forks de colaboradores externos**: É recomendado **exigir aprovação para todos** os colaboradores externos.
|
||||
- _Não consegui encontrar uma API com essa informação, compartilhe se você encontrar_
|
||||
- **Executar fluxos de trabalho de pull requests de fork**: É altamente **desaconselhado executar fluxos de trabalho de pull requests** pois os mantenedores do fork de origem terão a capacidade de usar tokens com permissões de leitura no repositório de origem.
|
||||
- **Executar fluxos de trabalho de pull requests de forks**: É altamente **desaconselhado executar fluxos de trabalho de pull requests** pois os mantenedores do fork de origem terão a capacidade de usar tokens com permissões de leitura no repositório de origem.
|
||||
- _Não consegui encontrar uma API com essa informação, compartilhe se você encontrar_
|
||||
- **Permissões de fluxo de trabalho**: É altamente recomendado **dar apenas permissões de leitura de repositório**. É desaconselhado dar permissões de escrita e criar/aprovar pull requests para evitar o abuso do GITHUB_TOKEN dado para fluxos de trabalho em execução.
|
||||
- **Permissões de fluxo de trabalho**: É altamente recomendado **dar apenas permissões de leitura do repositório**. É desaconselhado dar permissões de escrita e criar/aprovar pull requests para evitar o abuso do GITHUB_TOKEN dado para fluxos de trabalho em execução.
|
||||
- [**API**](https://docs.github.com/en/rest/actions/permissions#get-default-workflow-permissions-for-an-organization)
|
||||
|
||||
### Integrações
|
||||
@@ -116,7 +116,7 @@ Note que **2FA pode ser usado**, então você só poderá acessar essas informa
|
||||
> [!NOTE]
|
||||
> Note que se você **conseguir roubar o cookie `user_session`** (atualmente configurado com SameSite: Lax), você pode **impersonar completamente o usuário** sem precisar de credenciais ou 2FA.
|
||||
|
||||
Verifique a seção abaixo sobre [**bypasses de proteção de branch**](./#branch-protection-bypass) caso seja útil.
|
||||
Verifique a seção abaixo sobre [**bypass de proteções de branch**](./#branch-protection-bypass) caso seja útil.
|
||||
|
||||
### Com Chave SSH de Usuário
|
||||
|
||||
@@ -130,7 +130,7 @@ git config --list
|
||||
```
|
||||
Se o usuário configurou seu nome de usuário como seu nome de usuário do github, você pode acessar as **chaves públicas que ele configurou** em sua conta em _https://github.com/\<github_username>.keys_, você pode verificar isso para confirmar se a chave privada que você encontrou pode ser usada.
|
||||
|
||||
**Chaves SSH** também podem ser configuradas em repositórios como **chaves de implantação**. Qualquer pessoa com acesso a essa chave poderá **iniciar projetos a partir de um repositório**. Normalmente, em um servidor com diferentes chaves de implantação, o arquivo local **`~/.ssh/config`** fornecerá informações sobre a chave relacionada.
|
||||
**Chaves SSH** também podem ser configuradas em repositórios como **chaves de implantação**. Qualquer pessoa com acesso a essa chave poderá **iniciar projetos de um repositório**. Normalmente, em um servidor com diferentes chaves de implantação, o arquivo local **`~/.ssh/config`** fornecerá informações sobre a chave relacionada.
|
||||
|
||||
#### Chaves GPG
|
||||
|
||||
@@ -152,7 +152,7 @@ Um token de usuário se parece com isso: `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX1
|
||||
|
||||
Para uma introdução sobre [**Aplicativos Oauth do Github, verifique as informações básicas**](basic-github-information.md#oauth-applications).
|
||||
|
||||
Um atacante pode criar um **Aplicativo Oauth malicioso** para acessar dados/ações privilegiados dos usuários que os aceitam, provavelmente como parte de uma campanha de phishing.
|
||||
Um atacante pode criar um **Aplicativo Oauth malicioso** para acessar dados/ações privilegiados dos usuários que o aceitam, provavelmente como parte de uma campanha de phishing.
|
||||
|
||||
Esses são os [escopos que um aplicativo Oauth pode solicitar](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps). Um deve sempre verificar os escopos solicitados antes de aceitá-los.
|
||||
|
||||
@@ -162,11 +162,11 @@ Além disso, como explicado nas informações básicas, **as organizações pode
|
||||
|
||||
Para uma introdução sobre [**Aplicativos do Github, verifique as informações básicas**](basic-github-information.md#github-applications).
|
||||
|
||||
Um atacante pode criar um **Aplicativo Github malicioso** para acessar dados/ações privilegiados dos usuários que os aceitam, provavelmente como parte de uma campanha de phishing.
|
||||
Um atacante pode criar um **Aplicativo Github malicioso** para acessar dados/ações privilegiados dos usuários que o aceitam, provavelmente como parte de uma campanha de phishing.
|
||||
|
||||
Além disso, como explicado nas informações básicas, **as organizações podem conceder/negá-los acesso a aplicativos de terceiros** a informações/repos/ações relacionadas à organização.
|
||||
|
||||
## Comprometimento & Abuso da Ação do Github
|
||||
## Compromisso e Abuso da Ação do Github
|
||||
|
||||
Existem várias técnicas para comprometer e abusar de uma Ação do Github, verifique-as aqui:
|
||||
|
||||
@@ -176,19 +176,19 @@ abusing-github-actions/
|
||||
|
||||
## Bypass de Proteção de Branch
|
||||
|
||||
- **Exigir um número de aprovações**: Se você comprometeu várias contas, pode simplesmente aceitar seus PRs de outras contas. Se você tiver apenas a conta de onde criou o PR, não poderá aceitar seu próprio PR. No entanto, se você tiver acesso a um **ambiente de Ação do Github** dentro do repositório, usando o **GITHUB_TOKEN**, você pode ser capaz de **aprovar seu PR** e obter 1 aprovação dessa forma.
|
||||
- **Exigir um número de aprovações**: Se você comprometeu várias contas, pode simplesmente aceitar seus PRs de outras contas. Se você apenas tem a conta de onde criou o PR, não pode aceitar seu próprio PR. No entanto, se você tiver acesso a um ambiente de **Ação do Github** dentro do repositório, usando o **GITHUB_TOKEN**, pode ser capaz de **aprovar seu PR** e obter 1 aprovação dessa forma.
|
||||
- _Nota para isso e para a restrição de Proprietários de Código que geralmente um usuário não poderá aprovar seus próprios PRs, mas se você puder, pode abusar disso para aceitar seus PRs._
|
||||
- **Rejeitar aprovações quando novos commits são enviados**: Se isso não estiver configurado, você pode enviar código legítimo, esperar até que alguém o aprove e colocar código malicioso e mesclá-lo na branch protegida.
|
||||
- **Exigir revisões de Proprietários de Código**: Se isso estiver ativado e você for um Proprietário de Código, poderá fazer uma **Ação do Github criar seu PR e então aprová-lo você mesmo**.
|
||||
- **Rejeitar aprovações quando novos commits são enviados**: Se isso não estiver configurado, você pode enviar código legítimo, esperar até que alguém o aprove, e colocar código malicioso e mesclá-lo na branch protegida.
|
||||
- **Exigir revisões de Proprietários de Código**: Se isso estiver ativado e você for um Proprietário de Código, pode fazer uma **Ação do Github criar seu PR e então aprová-lo você mesmo**.
|
||||
- Quando um **arquivo CODEOWNER está mal configurado**, o Github não reclama, mas não o utiliza. Portanto, se estiver mal configurado, **a proteção de Proprietários de Código não é aplicada.**
|
||||
- **Permitir que atores especificados contornem os requisitos de pull request**: Se você for um desses atores, pode contornar as proteções de pull request.
|
||||
- **Incluir administradores**: Se isso não estiver configurado e você for administrador do repositório, pode contornar essas proteções de branch.
|
||||
- **Sequestro de PR**: Você pode ser capaz de **modificar o PR de outra pessoa** adicionando código malicioso, aprovando o PR resultante você mesmo e mesclando tudo.
|
||||
- **Removendo Proteções de Branch**: Se você for um **administrador do repositório, pode desativar as proteções**, mesclar seu PR e reativar as proteções.
|
||||
- **Contornando proteções de push**: Se um repositório **somente permite certos usuários** enviar push (mesclar código) em branches (a proteção de branch pode estar protegendo todas as branches especificando o curinga `*`).
|
||||
- Se você tiver **acesso de escrita sobre o repositório, mas não for permitido enviar código** por causa da proteção de branch, ainda pode **criar uma nova branch** e dentro dela criar uma **ação do github que é acionada quando o código é enviado**. Como a **proteção de branch não protegerá a branch até que seja criada**, esse primeiro push de código para a branch **executará a ação do github**.
|
||||
- **Contornando proteções de push**: Se um repositório **somente permite que certos usuários** enviem push (mesclem código) em branches (a proteção de branch pode estar protegendo todas as branches especificando o curinga `*`).
|
||||
- Se você tiver **acesso de escrita sobre o repositório, mas não for permitido enviar código** por causa da proteção de branch, ainda pode **criar uma nova branch** e dentro dela criar uma **ação do github que é acionada quando o código é enviado**. Como a **proteção de branch não protegerá a branch até que ela seja criada**, esse primeiro envio de código para a branch **executará a ação do github**.
|
||||
|
||||
## Bypass de Proteções de Ambientes
|
||||
## Contornar Proteções de Ambientes
|
||||
|
||||
Para uma introdução sobre [**Ambiente do Github, verifique as informações básicas**](basic-github-information.md#git-environments).
|
||||
|
||||
@@ -200,7 +200,7 @@ push: # Run it when a push is made to a branch
|
||||
branches:
|
||||
- current_branch_name #Use '**' to run when a push is made to any branch
|
||||
```
|
||||
Note que **após a criação** do branch, a **proteção do branch será aplicada ao novo branch** e você não poderá modificá-lo, mas nesse momento você já terá extraído os segredos.
|
||||
Note que **após a criação** do branch, a **proteção do branch será aplicada ao novo branch** e você não poderá modificá-lo, mas nesse tempo você já terá extraído os segredos.
|
||||
|
||||
## Persistência
|
||||
|
||||
@@ -211,12 +211,12 @@ Note que **após a criação** do branch, a **proteção do branch será aplicad
|
||||
- Criar **webhooks** para exfiltrar informações
|
||||
- Convidar **colaboradores externos**
|
||||
- **Remover** **webhooks** usados pelo **SIEM**
|
||||
- Criar/modificar **Github Action** com uma **porta dos fundos**
|
||||
- Encontrar **Github Action vulnerável para injeção de comandos** via modificação de valor de **segredo**
|
||||
- Criar/modificar **Github Action** com uma **backdoor**
|
||||
- Encontrar **Github Action vulnerável a injeção de comando** via modificação de valor de **segredo**
|
||||
|
||||
### Commits de Impostor - Porta dos fundos via commits de repositório
|
||||
### Commits de Impostor - Backdoor via commits de repositório
|
||||
|
||||
No Github, é possível **criar um PR para um repositório a partir de um fork**. Mesmo que o PR não seja **aceito**, um **commit** id dentro do repositório original será criado para a versão fork do código. Portanto, um atacante **poderia fixar o uso de um commit específico de um repositório aparentemente legítimo que não foi criado pelo proprietário do repositório**.
|
||||
No Github, é possível **criar um PR para um repositório a partir de um fork**. Mesmo que o PR **não seja aceito**, um **commit** id dentro do repositório original será criado para a versão fork do código. Portanto, um atacante **poderia fixar o uso de um commit específico de um repositório aparentemente legítimo que não foi criado pelo proprietário do repositório**.
|
||||
|
||||
Como [**este**](https://github.com/actions/checkout/commit/c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e):
|
||||
```yaml
|
||||
|
||||
@@ -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)
|
||||
|
||||
+1
-1
@@ -1 +1 @@
|
||||
# GH Actions - Cache Poisoning
|
||||
# GH Actions - Envenenamento de Cache
|
||||
|
||||
@@ -1,27 +1,27 @@
|
||||
# Dados Deletados Acessíveis no Github
|
||||
# Dados Excluídos Acessíveis no Github
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Essas maneiras de acessar dados do Github que supostamente foram deletados foram [**reportadas neste post do blog**](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github).
|
||||
Essas maneiras de acessar dados do Github que supostamente foram excluídos foram [**reportadas neste post do blog**](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github).
|
||||
|
||||
## Acessando Dados de Forks Deletados
|
||||
## Acessando Dados de Forks Excluídos
|
||||
|
||||
1. Você faz um fork de um repositório público
|
||||
2. Você comita código no seu fork
|
||||
3. Você deleta seu fork
|
||||
1. Você faz um fork de um repositório público.
|
||||
2. Você comita código no seu fork.
|
||||
3. Você exclui seu fork.
|
||||
|
||||
> [!CAUTION]
|
||||
> Os dados comitados no fork deletado ainda estão acessíveis.
|
||||
> Os dados comitados no fork excluído ainda são acessíveis.
|
||||
|
||||
## Acessando Dados de Repositórios Deletados
|
||||
## Acessando Dados de Repositórios Excluídos
|
||||
|
||||
1. Você tem um repositório público no GitHub.
|
||||
2. Um usuário faz fork do seu repositório.
|
||||
2. Um usuário faz um fork do seu repositório.
|
||||
3. Você comita dados após eles fazerem o fork (e eles nunca sincronizam seu fork com suas atualizações).
|
||||
4. Você deleta o repositório inteiro.
|
||||
4. Você exclui o repositório inteiro.
|
||||
|
||||
> [!CAUTION]
|
||||
> Mesmo que você tenha deletado seu repositório, todas as alterações feitas nele ainda estão acessíveis através dos forks.
|
||||
> Mesmo que você tenha excluído seu repositório, todas as alterações feitas nele ainda são acessíveis através dos forks.
|
||||
|
||||
## Acessando Dados de Repositórios Privados
|
||||
|
||||
@@ -32,7 +32,7 @@ Essas maneiras de acessar dados do Github que supostamente foram deletados foram
|
||||
> [!CAUTION]
|
||||
> É possível acessar todos os dados enviados para o fork interno no período entre a criação do fork interno e a versão pública sendo tornada pública.
|
||||
|
||||
## Como descobrir commits de forks deletados/ocultos
|
||||
## Como descobrir commits de forks excluídos/ocultos
|
||||
|
||||
O mesmo post do blog propõe 2 opções:
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## Estrutura Básica
|
||||
|
||||
A estrutura básica do ambiente github de uma grande **empresa** é possuir uma **empresa** que possui **várias organizações** e cada uma delas pode conter **vários repositórios** e **várias equipes**. Empresas menores podem **possuir apenas uma organização e nenhuma empresa**.
|
||||
A estrutura básica do ambiente do github de uma grande **empresa** é possuir uma **empresa** que possui **várias organizações** e cada uma delas pode conter **vários repositórios** e **várias equipes**. Empresas menores podem **possuir apenas uma organização e nenhuma empresa**.
|
||||
|
||||
Do ponto de vista do usuário, um **usuário** pode ser um **membro** de **diferentes empresas e organizações**. Dentro delas, o usuário pode ter **diferentes funções de empresa, organização e repositório**.
|
||||
|
||||
@@ -24,7 +24,7 @@ E finalmente, **os repositórios podem ter mecanismos de proteção especiais**.
|
||||
Em uma organização, os usuários podem ter diferentes funções:
|
||||
|
||||
- **Proprietários da organização**: Proprietários da organização têm **acesso administrativo completo à sua organização**. Essa função deve ser limitada, mas não a menos de duas pessoas, em sua organização.
|
||||
- **Membros da organização**: A função **padrão**, não administrativa, para **pessoas em uma organização** é o membro da organização. Por padrão, os membros da organização **têm um número de permissões**.
|
||||
- **Membros da organização**: A função **padrão**, não administrativa para **pessoas em uma organização** é o membro da organização. Por padrão, os membros da organização **têm um número de permissões**.
|
||||
- **Gerentes de cobrança**: Gerentes de cobrança são usuários que podem **gerenciar as configurações de cobrança da sua organização**, como informações de pagamento.
|
||||
- **Gerentes de Segurança**: É uma função que os proprietários da organização podem atribuir a qualquer equipe em uma organização. Quando aplicada, dá a cada membro da equipe permissões para **gerenciar alertas e configurações de segurança em sua organização, bem como permissões de leitura para todos os repositórios** na organização.
|
||||
- Se sua organização tiver uma equipe de segurança, você pode usar a função de gerente de segurança para dar aos membros da equipe o menor acesso necessário à organização.
|
||||
@@ -51,7 +51,7 @@ As configurações aqui configuradas indicarão as seguintes permissões dos mem
|
||||
|
||||
Por padrão, as funções de repositório são criadas:
|
||||
|
||||
- **Leitura**: Recomendado para **contribuidores não relacionados ao código** que desejam visualizar ou discutir seu projeto.
|
||||
- **Leitura**: Recomendado para **contribuidores não de código** que desejam visualizar ou discutir seu projeto.
|
||||
- **Triagem**: Recomendado para **contribuidores que precisam gerenciar proativamente problemas e pull requests** sem acesso de escrita.
|
||||
- **Escrita**: Recomendado para contribuintes que **enviam ativamente para seu projeto**.
|
||||
- **Manutenção**: Recomendado para **gerentes de projeto que precisam gerenciar o repositório** sem acesso a ações sensíveis ou destrutivas.
|
||||
@@ -63,7 +63,7 @@ Você também pode **criar suas próprias funções** em _https://github.com/org
|
||||
|
||||
### Equipes
|
||||
|
||||
Você pode **listar as equipes criadas em uma organização** em _https://github.com/orgs/\<org_name>/teams_. Observe que, para ver as equipes que são filhas de outras equipes, você precisa acessar cada equipe pai.
|
||||
Você pode **listar as equipes criadas em uma organização** em _https://github.com/orgs/\<org_name>/teams_. Observe que para ver as equipes que são filhas de outras equipes, você precisa acessar cada equipe pai.
|
||||
|
||||
### Usuários
|
||||
|
||||
@@ -81,7 +81,7 @@ Acessando **github.com**, você pode fazer login usando seu **nome de usuário e
|
||||
|
||||
### **Chaves SSH**
|
||||
|
||||
Você pode configurar sua conta com uma ou várias chaves públicas permitindo que a **chave privada relacionada realize ações em seu nome.** [https://github.com/settings/keys](https://github.com/settings/keys)
|
||||
Você pode configurar sua conta com uma ou várias chaves públicas permitindo que a chave **privada relacionada realize ações em seu nome.** [https://github.com/settings/keys](https://github.com/settings/keys)
|
||||
|
||||
#### **Chaves GPG**
|
||||
|
||||
@@ -102,10 +102,10 @@ Aplicativos Oauth podem solicitar permissões **para acessar parte das suas info
|
||||
|
||||
Algumas **recomendações de segurança**:
|
||||
|
||||
- Um **Aplicativo OAuth** deve sempre **agir como o usuário autenticado do GitHub em toda a plataforma** (por exemplo, ao fornecer notificações ao usuário) e com acesso apenas aos escopos especificados.
|
||||
- Um **Aplicativo OAuth** deve sempre **agir como o usuário autenticado do GitHub em toda a plataforma GitHub** (por exemplo, ao fornecer notificações ao usuário) e com acesso apenas aos escopos especificados.
|
||||
- Um Aplicativo OAuth pode ser usado como um provedor de identidade ao habilitar um "Login com GitHub" para o usuário autenticado.
|
||||
- **Não** crie um **Aplicativo OAuth** se você quiser que seu aplicativo atue em um **único repositório**. Com o escopo `repo`, os Aplicativos OAuth podem **agir em \_todos**\_\*\* os repositórios do usuário autenticado\*\*.
|
||||
- **Não** crie um Aplicativo OAuth para atuar como um aplicativo para sua **equipe ou empresa**. Os Aplicativos OAuth se autenticam como um **único usuário**, então, se uma pessoa criar um Aplicativo OAuth para uma empresa usar, e depois ela deixar a empresa, ninguém mais terá acesso a ele.
|
||||
- **Não** crie um Aplicativo OAuth para atuar como um aplicativo para sua **equipe ou empresa**. Aplicativos OAuth se autenticam como um **único usuário**, então se uma pessoa criar um Aplicativo OAuth para uma empresa usar, e depois ela deixar a empresa, ninguém mais terá acesso a ele.
|
||||
- **Mais** em [aqui](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
|
||||
|
||||
### Aplicativos do Github
|
||||
@@ -116,41 +116,41 @@ Aplicativos do Github podem solicitar permissões para **acessar suas informaç
|
||||
- O Aplicativo do GitHub deve **conectar-se a uma conta pessoal ou a uma organização**.
|
||||
- Você pode criar seu próprio aplicativo do Github em [https://github.com/settings/apps](https://github.com/settings/apps)
|
||||
- Você pode ver todos os **aplicativos do Github que têm acesso à sua conta** em [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
|
||||
- Estes são os **Endpoints da API para Aplicativos do Github** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Dependendo das permissões do aplicativo, ele poderá acessar alguns deles.
|
||||
- Estes são os **Endpoints da API para Aplicativos do Github** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Dependendo das permissões do Aplicativo, ele poderá acessar alguns deles.
|
||||
- Você pode ver aplicativos instalados em uma **organização** em _https://github.com/organizations/\<org_name>/settings/installations_
|
||||
|
||||
Algumas recomendações de segurança:
|
||||
|
||||
- Um Aplicativo do GitHub deve **tomar ações independentemente de um usuário** (a menos que o aplicativo esteja usando um token [de usuário para servidor](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)). Para manter os tokens de acesso de usuário para servidor mais seguros, você pode usar tokens de acesso que expiram após 8 horas e um token de atualização que pode ser trocado por um novo token de acesso. Para mais informações, veja "[Atualizando tokens de acesso de usuário para servidor](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
|
||||
- Um Aplicativo do GitHub deve **realizar ações independentemente de um usuário** (a menos que o aplicativo esteja usando um token [de usuário para servidor](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)). Para manter os tokens de acesso de usuário para servidor mais seguros, você pode usar tokens de acesso que expiram após 8 horas, e um token de atualização que pode ser trocado por um novo token de acesso. Para mais informações, veja "[Atualizando tokens de acesso de usuário para servidor](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
|
||||
- Certifique-se de que o Aplicativo do GitHub se integre com **repositórios específicos**.
|
||||
- O Aplicativo do GitHub deve **conectar-se a uma conta pessoal ou a uma organização**.
|
||||
- Não espere que o Aplicativo do GitHub saiba e faça tudo o que um usuário pode.
|
||||
- **Não use um Aplicativo do GitHub se você só precisa de um serviço de "Login com GitHub"**. Mas um Aplicativo do GitHub pode usar um [fluxo de identificação de usuário](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) para fazer login de usuários _e_ fazer outras coisas.
|
||||
- Não crie um Aplicativo do GitHub se você _apenas_ quiser agir como um usuário do GitHub e fazer tudo o que esse usuário pode fazer.
|
||||
- Se você estiver usando seu aplicativo com GitHub Actions e quiser modificar arquivos de fluxo de trabalho, deve se autenticar em nome do usuário com um token OAuth que inclua o escopo `workflow`. O usuário deve ter permissão de administrador ou escrita para o repositório que contém o arquivo de fluxo de trabalho. Para mais informações, veja "[Entendendo escopos para aplicativos OAuth](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
|
||||
- Se você estiver usando seu aplicativo com GitHub Actions e quiser modificar arquivos de workflow, você deve se autenticar em nome do usuário com um token OAuth que inclua o escopo `workflow`. O usuário deve ter permissão de administrador ou escrita para o repositório que contém o arquivo de workflow. Para mais informações, veja "[Entendendo escopos para aplicativos OAuth](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
|
||||
- **Mais** em [aqui](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
|
||||
|
||||
### Github Actions
|
||||
|
||||
Isso **não é uma maneira de autenticar no github**, mas uma **ação maliciosa** do Github poderia obter **acesso não autorizado ao github** e **dependendo** dos **privilégios** dados à Ação, vários **ataques diferentes** poderiam ser realizados. Veja abaixo para mais informações.
|
||||
|
||||
## Ações do Git
|
||||
## Ações Git
|
||||
|
||||
As ações do Git permitem automatizar a **execução de código quando um evento acontece**. Normalmente, o código executado está **de alguma forma relacionado ao código do repositório** (talvez construir um contêiner docker ou verificar se o PR não contém segredos).
|
||||
As ações Git permitem automatizar a **execução de código quando um evento acontece**. Normalmente, o código executado está **de alguma forma relacionado ao código do repositório** (talvez construir um contêiner docker ou verificar se o PR não contém segredos).
|
||||
|
||||
### Configuração
|
||||
|
||||
Em _https://github.com/organizations/\<org_name>/settings/actions_ é possível verificar a **configuração das ações do github** para a organização.
|
||||
|
||||
É possível proibir o uso de ações do github completamente, **permitir todas as ações do github**, ou apenas permitir certas ações.
|
||||
É possível proibir completamente o uso de ações do github, **permitir todas as ações do github**, ou apenas permitir certas ações.
|
||||
|
||||
Também é possível configurar **quem precisa de aprovação para executar uma Ação do Github** e as **permissões do GITHUB_TOKEN** de uma Ação do Github quando ela é executada.
|
||||
É também possível configurar **quem precisa de aprovação para executar uma Ação do Github** e as **permissões do GITHUB_TOKEN** de uma Ação do Github quando ela é executada.
|
||||
|
||||
### Segredos do Git
|
||||
|
||||
A Ação do Github geralmente precisa de algum tipo de segredos para interagir com o github ou aplicativos de terceiros. Para **evitar colocá-los em texto claro** no repositório, o github permite colocá-los como **Segredos**.
|
||||
|
||||
Esses segredos podem ser configurados **para o repositório ou para toda a organização**. Então, para que a **Ação possa acessar o segredo**, você precisa declará-lo assim:
|
||||
Esses segredos podem ser configurados **para o repositório ou para toda a organização**. Então, para que a **Ação possa acessar o segredo**, você precisa declará-lo como:
|
||||
```yaml
|
||||
steps:
|
||||
- name: Hello world action
|
||||
@@ -172,11 +172,11 @@ example-command "$SUPER_SECRET"
|
||||
|
||||
> Uma vez configurados no repositório ou nas organizações, **os usuários do github não poderão acessá-los novamente**, eles só poderão **alterá-los**.
|
||||
|
||||
Portanto, a **única maneira de roubar segredos do github é conseguir acessar a máquina que está executando a Github Action** (nesse cenário, você poderá acessar apenas os segredos declarados para a Action).
|
||||
Portanto, a **única maneira de roubar segredos do github é conseguir acessar a máquina que está executando a Github Action** (nesse cenário, você só poderá acessar os segredos declarados para a Action).
|
||||
|
||||
### Git Environments
|
||||
### Ambientes do Git
|
||||
|
||||
Github permite criar **environments** onde você pode salvar **secrets**. Então, você pode dar à github action acesso aos segredos dentro do ambiente com algo como:
|
||||
O Github permite criar **ambientes** onde você pode salvar **segredos**. Em seguida, você pode dar à ação do github acesso aos segredos dentro do ambiente com algo como:
|
||||
```yaml
|
||||
jobs:
|
||||
deployment:
|
||||
@@ -202,10 +202,10 @@ Se o **Github Runner personalizado estiver configurado em uma máquina dentro da
|
||||
|
||||
### Comprometimento da Git Action
|
||||
|
||||
Se todas as ações (ou uma ação maliciosa) forem permitidas, um usuário pode usar uma **Github action** que é **maliciosa** e irá **comprometer** o **container** onde está sendo executada.
|
||||
Se todas as ações (ou uma ação maliciosa) forem permitidas, um usuário poderia usar uma **Github action** que é **maliciosa** e irá **comprometer** o **container** onde está sendo executada.
|
||||
|
||||
> [!CAUTION]
|
||||
> Uma **Github Action maliciosa** executada pode ser **abusada** pelo atacante para:
|
||||
> Uma **Github Action maliciosa** executada poderia ser **abusada** pelo atacante para:
|
||||
>
|
||||
> - **Roubar todos os segredos** aos quais a Action tem acesso
|
||||
> - **Mover lateralmente** se a Action for executada dentro de uma **infraestrutura de terceiros** onde o token SA usado para executar a máquina pode ser acessado (provavelmente via o serviço de metadados)
|
||||
@@ -223,7 +223,7 @@ As **proteções de ramo de um repositório** podem ser encontradas em _https://
|
||||
Diferentes proteções podem ser aplicadas a um ramo (como ao master):
|
||||
|
||||
- Você pode **exigir um PR antes de mesclar** (então você não pode mesclar código diretamente sobre o ramo). Se isso for selecionado, outras proteções podem estar em vigor:
|
||||
- **Exigir um número de aprovações**. É muito comum exigir que 1 ou 2 pessoas adicionais aprovem seu PR, para que um único usuário não possa mesclar código diretamente.
|
||||
- **Exigir um número de aprovações**. É muito comum exigir que 1 ou 2 pessoas adicionais aprovem seu PR, para que um único usuário não consiga mesclar código diretamente.
|
||||
- **Desconsiderar aprovações quando novos commits são enviados**. Caso contrário, um usuário pode aprovar código legítimo e, em seguida, o usuário poderia adicionar código malicioso e mesclá-lo.
|
||||
- **Exigir revisões de Proprietários de Código**. Pelo menos 1 proprietário de código do repositório precisa aprovar o PR (para que usuários "aleatórios" não possam aprová-lo)
|
||||
- **Restringir quem pode desconsiderar revisões de pull request.** Você pode especificar pessoas ou equipes autorizadas a desconsiderar revisões de pull request.
|
||||
|
||||
Reference in New Issue
Block a user