# 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 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

{{#ref}}
basic-github-information.md
{{#endref}}

## Reconhecimento Externo

Os repositórios do Github podem ser configurados como públicos, privados e internos.

- **Privado** significa que **apenas** pessoas da **organização** poderão acessá-los
- **Interno** significa que **apenas** pessoas da **empresa** (uma empresa pode ter várias organizações) poderão acessá-lo
- **Público** significa que **toda a internet** poderá acessá-lo.

Caso você conheça o **usuário, repositório ou organização que deseja atacar**, você pode usar **github dorks** para encontrar informações sensíveis ou pesquisar por **vazamentos de informações sensíveis** **em cada repositório**.

### Github Dorks

O Github permite **pesquisar algo especificando como escopo um usuário, um repositório ou uma organização**. Portanto, com uma lista de strings que vão aparecer próximas a informações sensíveis, você pode facilmente **pesquisar por informações sensíveis potenciais em seu alvo**.

Ferramentas (cada ferramenta contém sua lista de dorks):

- [https://github.com/obheda12/GitDorker](https://github.com/obheda12/GitDorker) ([Lista de Dorks](https://github.com/obheda12/GitDorker/tree/master/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))

### 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).

Ferramentas (cada ferramenta contém sua lista de regexes):

- [https://github.com/zricethezav/gitleaks](https://github.com/zricethezav/gitleaks)
- [https://github.com/trufflesecurity/truffleHog](https://github.com/trufflesecurity/truffleHog)
- [https://github.com/eth0izzle/shhgit](https://github.com/eth0izzle/shhgit)
- [https://github.com/michenriksen/gitrob](https://github.com/michenriksen/gitrob)
- [https://github.com/anshumanbh/git-all-secrets](https://github.com/anshumanbh/git-all-secrets)
- [https://github.com/kootenpv/gittyleaks](https://github.com/kootenpv/gittyleaks)
- [https://github.com/awslabs/git-secrets](https://github.com/awslabs/git-secrets)

> [!WARNING]
> Quando você procura por vazamentos em um repositório e executa algo como `git log -p`, não se esqueça de que pode haver **outras branches com outros commits** contendo segredos!

### 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 das Ações do Github. [**Mais informações sobre isso abaixo**](./#execution-from-a-external-fork).

### 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:

{{#ref}}
accessible-deleted-data-in-github.md
{{#endref}}

## Fortalecimento da Organização

### Privilégios dos Membros

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 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**.
- _Não consegui encontrar essa informação na resposta das APIs, compartilhe se você encontrar_
- **Exclusão e transferência de repositórios**: Se habilitado, membros com permissões **admin** para o repositório poderão **excluir** ou **transferir** repositórios públicos e privados.
- _Não consegui encontrar essa informação na resposta das APIs, compartilhe se você encontrar_
- **Permitir que membros criem equipes**: Se habilitado, qualquer **membro** da organização poderá **criar** novas **equipes**. Se desabilitado, apenas os proprietários da organização podem criar novas equipes. É melhor ter isso desabilitado.
- _Não consegui encontrar essa informação na resposta das APIs, compartilhe se você encontrar_
- **Mais coisas podem ser configuradas** nesta página, mas as anteriores são as mais relacionadas à segurança.

### Configurações de Ações

Várias configurações relacionadas à segurança podem ser configuradas para ações a partir da página `https://github.com/organizations/<org_name>/settings/actions`.

> [!NOTE]
> Note que todas essas configurações também podem ser definidas em cada repositório de forma independente

- **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 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 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 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

_Deixe-me saber se você conhece o endpoint da API para acessar essa informação!_

- **Política de acesso a aplicativos de terceiros**: É recomendado restringir o acesso a todos os aplicativos e permitir apenas os necessários (após revisá-los).
- **Aplicativos do GitHub instalados**: É recomendado permitir apenas os necessários (após revisá-los).

## Reconhecimento e Ataques abusando de credenciais

Para este cenário, vamos supor que você obteve algum acesso a uma conta do github.

### Com Credenciais de Usuário

Se de alguma forma você já tem credenciais de um usuário dentro de uma organização, você pode **apenas fazer login** e verificar quais **papéis de empresa e organização você tem**, se você é um membro comum, verifique quais **permissões os membros comuns têm**, em quais **grupos** você está, quais **permissões você tem** sobre quais **repositórios** e **como os repositórios estão protegidos**.

Note que **2FA pode ser usado**, então você só poderá acessar essas informações se também conseguir **passar por essa verificação**.

> [!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 [**bypass de proteções de branch**](./#branch-protection-bypass) caso seja útil.

### Com Chave SSH de Usuário

O Github permite que **usuários** configurem **chaves SSH** que serão usadas como **método de autenticação para implantar código** em seu nome (nenhuma 2FA é aplicada).

Com essa chave, você pode realizar **alterações em repositórios onde o usuário tem alguns privilégios**, no entanto, você não pode usá-la para acessar a API do github para enumerar o ambiente. No entanto, você pode **enumerar configurações locais** para obter informações sobre os repositórios e o usuário ao qual você tem acesso:
```bash
# Go to the the repository folder
# Get repo config and current user name and email
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 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

Como explicado [**aqui**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/github-security/broken-reference/README.md), às vezes é necessário assinar os commits ou você pode ser descoberto.

Verifique localmente se o usuário atual possui alguma chave com:
```shell
gpg --list-secret-keys --keyid-format=long
```
### Com Token de Usuário

Para uma introdução sobre [**Tokens de Usuário, verifique as informações básicas**](basic-github-information.md#personal-access-tokens).

Um token de usuário pode ser usado **em vez de uma senha** para Git sobre HTTPS, ou pode ser usado para [**autenticar na API via Autenticação Básica**](https://docs.github.com/v3/auth/#basic-authentication). Dependendo dos privilégios associados a ele, você pode ser capaz de realizar diferentes ações.

Um token de usuário se parece com isso: `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123`

### Com Aplicativo Oauth

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 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.

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.

### Com Aplicativo Github

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 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.

## 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:

{{#ref}}
abusing-github-actions/
{{#endref}}

## 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ê 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, 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 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**.

## 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).

Caso um ambiente possa ser **acessado de todas as branches**, ele **não está protegido** e você pode facilmente acessar os segredos dentro do ambiente. Note que você pode encontrar repositórios onde **todas as branches estão protegidas** (especificando seus nomes ou usando `*`); nesse cenário, **encontre uma branch onde você possa enviar código** e você pode **exfiltrar** os segredos criando uma nova ação do github (ou modificando uma).

Note que você pode encontrar o caso extremo onde **todas as branches estão protegidas** (via curinga `*`), é especificado **quem pode enviar código para as branches** (_você pode especificar isso na proteção de branch_) e **seu usuário não é permitido**. Você ainda pode executar uma ação do github personalizada porque pode criar uma branch e usar o gatilho de push sobre ela mesma. A **proteção de branch permite o push para uma nova branch, então a ação do github será acionada**.
```yaml
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 tempo você já terá extraído os segredos.

## Persistência

- Gerar **token de usuário**
- Roubar **tokens do github** de **segredos**
- **Deleção** de **resultados** e **branches** de workflow
- Dar **mais permissões a toda a org**
- Criar **webhooks** para exfiltrar informações
- Convidar **colaboradores externos**
- **Remover** **webhooks** usados pelo **SIEM**
- 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 - 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**.

Como [**este**](https://github.com/actions/checkout/commit/c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e):
```yaml
name: example
on: [push]
jobs:
commit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e
- shell: bash
run: |
echo 'hello world!'
```
Para mais informações, consulte [https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd](https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd)

{{#include ../../banners/hacktricks-training.md}}