Informações Básicas do Github

Reading time: 18 minutes

tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Estrutura Básica

A estrutura básica do ambiente github de uma grande company é ter uma enterprise que possui diversas organizations e cada uma delas pode conter vários repositories e várias teams.. Empresas menores podem simplesmente possuir uma organization e nenhuma enterprise.

Do ponto de vista do usuário, um user pode ser member de diferentes enterprises e organizations. Dentro delas o usuário pode ter diferentes enterprise, organization e repository roles.

Além disso, um usuário pode fazer parte de diferentes teams com diferentes enterprise, organization ou repository roles.

E finalmente os repositories podem ter mecanismos especiais de proteção.

Privilégios

Enterprise Roles

  • Enterprise owner: Pessoas com esse role podem manage administrators, manage organizations within the enterprise, manage enterprise settings, enforce policy across organizations. No entanto, eles não podem acessar organization settings ou conteúdo a menos que sejam tornados organization owner ou recebam acesso direto a um repository pertencente à organization.
  • Enterprise members: Membros das organizations possuídas pela sua enterprise também são automaticamente members da enterprise.

Organization Roles

Em uma organization os usuários podem ter diferentes roles:

  • Organization owners: Organization owners têm complete administrative access to your organization. Esse role deve ser limitado, mas não menor que duas pessoas na sua organization.
  • Organization members: O role default, não-administrativo para pessoas em uma organization é o organization member. Por padrão, organization members têm uma série de permissões.
  • Billing managers: Billing managers são usuários que podem manage the billing settings for your organization, como informações de pagamento.
  • Security Managers: É um role que organization owners podem atribuir a qualquer team dentro de uma organization. Quando aplicado, dá a cada membro do team permissões para manage security alerts and settings across your organization, as well as read permissions for all repositories na organization.
  • Se sua organization tem um security team, você pode usar o security manager role para dar aos membros do team o menor acesso necessário à organization.
  • Github App managers: Para permitir que usuários adicionais manage GitHub Apps owned by an organization, um owner pode conceder a eles GitHub App manager permissions.
  • Outside collaborators: Um outside collaborator é uma pessoa que tem access to one or more organization repositories but is not explicitly a member da organization.

Você pode comparar as permissões desses roles nesta tabela: https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles

Members Privileges

Em https://github.com/organizations/<org_name>/settings/member_privileges você pode ver as permissões que os users terão apenas por fazer parte da organization.

As configurações aqui indicadas vão determinar as seguintes permissões dos members da organization:

  • Ser admin, writer, reader ou sem permissão sobre todos os repositories da organization.
  • Se os members podem criar repositories private, internal ou public.
  • Se o fork de repositories é possível.
  • Se é possível convidar outside collaborators.
  • Se sites public ou private podem ser publicados.
  • As permissões que admins têm sobre os repositories.
  • Se os members podem criar novos teams.

Repository Roles

Por padrão os repository roles são criados:

  • Read: Recomendado para non-code contributors que querem visualizar ou discutir seu projeto.
  • Triage: Recomendado para contributors who need to proactively manage issues and pull requests sem acesso de escrita.
  • Write: Recomendado para contributors que actively push to your project.
  • Maintain: Recomendado para project managers who need to manage the repository sem acesso a ações sensíveis ou destrutivas.
  • Admin: Recomendado para pessoas que precisam de full access to the project, incluindo ações sensíveis e destrutivas como gerenciar segurança ou deletar um repository.

Você pode comparar as permissões de cada role nesta tabela https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role

Você também pode criar seus próprios roles em https://github.com/organizations/<org_name>/settings/roles

Teams

Você pode listar as teams criadas em uma organization em https://github.com/orgs/<org_name>/teams. Note que para ver as teams que são children de outras teams você precisa acessar cada parent team.

Users

Os users de uma organization podem ser listados em https://github.com/orgs/<org_name>/people.

Nas informações de cada user você pode ver as teams das quais o user é member, e os repos aos quais o user tem access.

Github Authentication

Github oferece diferentes maneiras de autenticar na sua conta e executar ações em seu nome.

Web Access

Acessando github.com você pode login usando seu username and password (e um 2FA potencialmente).

SSH Keys

Você pode configurar sua conta com uma ou várias public keys permitindo que a private key relacionada execute ações em seu nome. https://github.com/settings/keys

GPG Keys

Você não pode impersonate o user com essas keys mas se você não as usar pode ser possível que você seja descoberto por enviar commits sem assinatura. Saiba mais sobre vigilant mode here.

Personal Access Tokens

Você pode gerar personal access token para dar a uma aplicação acesso à sua conta. Ao criar um personal access token o user precisa especificar as permissões que o token terá. https://github.com/settings/tokens

Oauth Applications

Oauth applications podem pedir permissões para acessar parte das suas informações do github ou para impersonate você para executar algumas ações. Um exemplo comum dessa funcionalidade é o botão login with github que você pode encontrar em algumas plataformas.

Algumas recomendações de segurança:

  • Um OAuth App deve sempre act as the authenticated GitHub user across all of GitHub (por exemplo, ao fornecer notificações ao usuário) e com acesso apenas aos scopes especificados.
  • Um OAuth App pode ser usado como um provedor de identidade habilitando um "Login with GitHub" para o usuário autenticado.
  • Não construa um OAuth App se você quer que sua aplicação atue em um single repository. Com o scope repo, OAuth Apps podem act on _all_** of the authenticated user's repositorie**s.
  • Não construa um OAuth App para atuar como uma aplicação para o seu team ou company. OAuth Apps autenticam como um single user, então se uma pessoa cria um OAuth App para uso da empresa e depois sai da empresa, mais ninguém terá acesso a ele.
  • Mais em here.

Github Applications

Github applications podem pedir permissões para acessar suas informações do github ou impersonate você para executar ações específicas sobre recursos específicos. Nas Github Apps você precisa especificar os repositories aos quais o app terá acesso.

Algumas recomendações de segurança:

  • Um GitHub App deve take actions independent of a user (a menos que o app esteja usando um token user-to-server). Para manter os user-to-server access tokens mais seguros, você pode usar access tokens que expiram após 8 horas e um refresh token que pode ser trocado por um novo access token. Para mais informações, veja "Refreshing user-to-server access tokens."
  • Certifique-se de que o GitHub App se integre com repositories específicos.
  • O GitHub App deve connect to a personal account or an organisation.
  • Não espere que o GitHub App saiba e faça tudo que um usuário pode fazer.
  • Não use um GitHub App se você só precisa de um serviço "Login with GitHub". Mas um GitHub App pode usar um user identification flow para logar usuários and fazer outras coisas.
  • Não construa um GitHub App se você apenas quer agir como um GitHub user e fazer tudo que esse user pode fazer.
  • Se você estiver usando seu app com GitHub Actions e quiser modificar arquivos de workflow, você deve autenticar em nome do usuário com um OAuth token que inclua o scope workflow. O usuário deve ter admin ou write permission ao repository que contém o arquivo de workflow. Para mais informações, veja "Understanding scopes for OAuth apps."
  • Mais em here.

Github Actions

Isto não é uma forma de autenticar no github, mas um Github Action malicioso poderia obter acesso não autorizado ao github e dependendo dos privileges dados à Action diversos ataques diferentes poderiam ser realizados. Veja abaixo para mais informação.

Git Actions

Git actions permitem automatizar a execução de código quando um evento acontece. Normalmente o código executado está de alguma forma relacionado com o código do repository (talvez construir um docker container ou verificar que o PR não contenha secrets).

Configuration

Em https://github.com/organizations/<org_name>/settings/actions é possível verificar a configuração do github actions para a organization.

É possível desativar completamente o uso de github actions, allow all github actions, ou apenas permitir certas actions.

Também é possível configurar quem precisa de approval para executar um Github Action e as permissões do GITHUB_TOKEN de um Github Action quando ele é executado.

Git Secrets

Github Action geralmente precisam de algum tipo de secrets para interagir com github ou aplicações third party. Para evitar colocá-los em clear-text no repo, o github permite colocá-los como Secrets.

Esses secrets podem ser configurados para o repo ou para toda a organization. Então, para que a Action consiga acessar o secret você precisa declará-lo assim:

yaml
steps:
- name: Hello world action
with: # Set the secret as an input
super_secret:${{ secrets.SuperSecret }}
env: # Or as an environment variable
super_secret:${{ secrets.SuperSecret }}

Exemplo usando Bash

yaml
steps:
- shell: bash
env: SUPER_SECRET:${{ secrets.SuperSecret }}
run: |
example-command "$SUPER_SECRET"

warning

Secrets só podem ser acessados pelos Github Actions que os declararam.

Uma vez configurados no repo ou nas organizations users of github won't be able to access them again, eles apenas poderão alterá-los.

Portanto, a única forma de roubar github secrets é conseguir acessar a máquina que está executando a Github Action (nesse cenário você poderá acessar apenas os secrets declarados para a Action).

Git Environments

Github permite criar environments onde você pode salvar secrets. Depois, você pode dar ao github action acesso aos secrets dentro do environment com algo como:

yaml
jobs:
deployment:
runs-on: ubuntu-latest
environment: env_name

Você pode configurar um environment para ser acessado por all branches (padrão), only protected branches ou specify quais branches podem acessá‑lo.\
Além disso, as proteções do ambiente incluem:

  • Required reviewers: bloqueia jobs direcionados ao environment até serem aprovados. Habilite Prevent self-review para impor um princípio de quatro‑olhos adequado na própria aprovação.
  • Deployment branches and tags: restrinja quais branches/tags podem fazer deploy para o environment. Prefira selecionar branches/tags específicos e garanta que esses branches estejam protegidos. Nota: a opção "Protected branches only" aplica‑se às proteções clássicas de branch e pode não se comportar como esperado se estiver usando rulesets.
  • Wait timer: atrasar deploys por um período configurável.

Também é possível definir um número de revisões requeridas antes de executar uma action usando um environment ou aguardar algum tempo antes de permitir que os deploys prossigam.

Git Action Runner

Uma Github Action pode ser executada dentro do github environment ou pode ser executada em uma third party infrastructure configurada pelo usuário.

Várias organizações permitem executar Github Actions em uma third party infrastructure pois costuma ser mais barato.

Você pode listar os self-hosted runners de uma organização em https://github.com/organizations/<org_name>/settings/actions/runners

A forma de descobrir quais Github Actions estão sendo executadas em infraestrutura não‑github é procurar por runs-on: self-hosted no YAML de configuração da Github Action.

Não é possível executar uma Github Action de uma organização dentro de uma self hosted box de outra organização porque um token único é gerado para o Runner quando ele é configurado para saber a que runner pertence.

Se o custom Github Runner for configurado em uma máquina dentro de AWS ou GCP, por exemplo, a Action poderia ter acesso ao endpoint de metadata e roubar o token da service account com a qual a máquina está executando.

Git Action Compromise

Se todas as actions (ou uma action maliciosa) forem permitidas, um usuário poderia usar uma Github action que seja maliciosa e que comprometa o container onde está sendo executada.

caution

Uma malicious Github Action run poderia ser abusada pelo atacante para:

  • Roubar todos os secrets aos quais a Action tem acesso
  • Mover lateralmente se a Action for executada dentro de uma third party infrastructure onde o token SA usado para rodar a máquina possa ser acessado (provavelmente via metadata service)
  • Abusar do token usado pelo workflow para roubar o código do repo onde a Action é executada ou até modificá‑lo.

Branch Protections

As branch protections são desenhadas para não dar controle completo de um repositório aos usuários. O objetivo é colocar vários métodos de proteção antes de conseguir escrever código dentro de algum branch.

As branch protections de um repositório podem ser encontradas em https://github.com/<orgname>/<reponame>/settings/branches

note

Não é possível definir uma branch protection a nível de organização. Então todas devem ser declaradas em cada repo.

Diferentes proteções podem ser aplicadas a um branch (como ao master):

  • Você pode exigir um PR antes do merge (assim você não pode mergear código diretamente no branch). Se isso for selecionado, outras proteções podem estar em vigor:
  • Exigir um número de aprovações. É muito comum exigir 1 ou 2 pessoas adicionais para aprovar seu PR para que um único usuário não consiga mergear código diretamente.
  • Invalidar aprovações quando novos commits são enviados. Caso contrário, um usuário pode aprovar código legítimo e depois adicionar código malicioso e fazer o merge.
  • Exigir aprovação do push reviewável mais recente. Garante que quaisquer novos commits após uma aprovação (incluindo pushes por outros colaboradores) reativem a revisão, evitando que um atacante envie mudanças pós‑aprovação e faça o merge.
  • Exigir reviews de Code Owners. Pelo menos 1 code owner do repo precisa aprovar o PR (impedindo que "usuários aleatórios" aprovem).
  • Restringir quem pode dispensar pull request reviews. Você pode especificar pessoas ou equipes autorizadas a dispensar reviews.
  • Permitir atores especificados contornarem requisitos de pull request. Esses usuários poderão contornar as restrições anteriores.
  • Exigir que status checks passem antes do merge. Alguns checks precisam passar antes de poder mesclar o commit (como um GitHub App reportando resultados de SAST). Dica: vincule checks obrigatórios a um GitHub App específico; caso contrário qualquer app poderia falsificar o check via Checks API, e muitos bots aceitam diretivas de pular (por exemplo, "@bot-name skip").
  • Exigir resolução de conversas antes do merge. Todos os comentários no código precisam ser resolvidos antes do PR poder ser mesclado.
  • Exigir commits assinados. Os commits precisam ser assinados.
  • Exigir histórico linear. Impede que merge commits sejam enviados para branches correspondentes.
  • Incluir administradores. Se isto não estiver ativado, admins podem contornar as restrições.
  • Restringir quem pode push para branches correspondentes. Restringe quem pode enviar um PR.

note

Como pode ver, mesmo que você consiga obter algumas credenciais de um usuário, os repos podem estar protegidos impedindo que você faça push de código para master, por exemplo para comprometer o pipeline CI/CD.

Tag Protections

Tags (como latest, stable) são mutáveis por padrão. Para impor um fluxo de quatro‑olhos nas atualizações de tags, proteja tags e encadeie proteções através de environments e branches:

  1. Na regra de proteção de tag, habilite Require deployments to succeed e exija um deployment bem‑sucedido para um environment protegido (por exemplo, prod).
  2. No environment alvo, restrinja Deployment branches and tags para o branch de release (por exemplo, main) e, opcionalmente, configure Required reviewers com Prevent self-review.
  3. No branch de release, configure branch protections para Require a pull request, defina aprovações ≥ 1 e habilite tanto Dismiss approvals when new commits are pushed quanto Require approval of the most recent reviewable push.

Essa cadeia evita que um único colaborador re‑tague ou force‑publique releases editando o workflow YAML, já que os gates de deployment são aplicados fora dos workflows.

References

tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks