Português - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Basic Github Information

Aprenda hacking no AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks:

Estrutura Básica

A estrutura básica do ambiente do github de uma grande empresa é possuir uma enterprise que detém várias organizações e cada uma delas pode conter vários repositórios e vários times. Empresas menores podem simplesmente possuir uma organização e nenhuma enterprise.

Do ponto de vista do usuário, um usuário pode ser membro de diferentes enterprises e organizações. Dentro delas, o usuário pode ter diferentes papéis na enterprise, organização e repositório.

Além disso, um usuário pode fazer parte de diferentes times com diferentes papéis na enterprise, organização ou repositório.

E finalmente, repositórios podem ter mecanismos especiais de proteção.

Privilégios

Papéis na Enterprise

  • Proprietário da enterprise: Pessoas com esse papel podem gerenciar administradores, gerenciar organizações dentro da enterprise, gerenciar configurações da enterprise, aplicar políticas em organizações. No entanto, eles não podem acessar configurações ou conteúdos da organização a menos que sejam feitos proprietários da organização ou tenham acesso direto a um repositório de propriedade da organização.

  • Membros da enterprise: Membros de organizações pertencentes à sua enterprise também são automaticamente membros da enterprise.

Papéis na Organização

Em uma organização, os usuários podem ter diferentes papéis:

  • Proprietários da organização: Proprietários da organização têm acesso administrativo completo à sua organização. Esse papel deve ser limitado, mas não a menos de duas pessoas, na sua organização.

  • Membros da organização: O papel padrão, não administrativo para pessoas em uma organização é o de membro da organização. Por padrão, membros da organização têm uma série de permissões.

  • Gerentes de faturamento: Gerentes de faturamento são usuários que podem gerenciar as configurações de faturamento da sua organização, como informações de pagamento.

  • Gerentes de Segurança: É um papel que proprietários da organização podem atribuir a qualquer time na organização. Quando aplicado, dá a cada membro do time permissões para gerenciar alertas de segurança e configurações em toda a organização, bem como permissões de leitura para todos os repositórios na organização.

  • Se sua organização tem um time de segurança, você pode usar o papel de gerente de segurança para dar aos membros do time o menor acesso necessário à organização.

  • Gerentes de Github App: Para permitir que usuários adicionais gerenciem Github Apps de propriedade de uma organização, um proprietário pode conceder-lhes permissões de gerente de Github App.

  • Colaboradores externos: Um colaborador externo é uma pessoa que tem acesso a um ou mais repositórios da organização, mas não é explicitamente um membro da organização.

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

Privilégios dos Membros

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

As configurações aqui definidas indicarão as seguintes permissões dos membros da organização:

  • Ser administrador, escritor, leitor ou sem permissão sobre todos os repositórios da organização.

  • Se os membros podem criar repositórios privados, internos ou públicos.

  • Se é possível fazer fork de repositórios.

  • Se é possível convidar colaboradores externos.

  • Se sites públicos ou privados podem ser publicados.

  • As permissões que os administradores têm sobre os repositórios.

  • Se os membros podem criar novos times.

Papéis no Repositório

Por padrão, são criados papéis para o repositório:

  • Leitura: Recomendado para contribuidores não técnicos que querem visualizar ou discutir seu projeto.

  • Triagem: Recomendado para contribuidores que precisam gerenciar proativamente problemas e pull requests sem acesso de escrita.

  • Escrita: Recomendado para contribuidores que atuam ativamente no seu projeto.

  • Manutenção: Recomendado para gerentes de projeto que precisam gerenciar o repositório sem acesso a ações sensíveis ou destrutivas.

  • Administração: Recomendado para pessoas que precisam de acesso total ao projeto, incluindo ações sensíveis e destrutivas como gerenciar segurança ou deletar um repositório.

Você pode comparar as permissões de cada papel 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 papéis em https://github.com/organizations/<org_name>/settings/roles

Times

Você pode listar os times criados em uma organização em https://github.com/orgs/<org_name>/teams. Note que para ver os times que são filhos de outros times você precisa acessar cada time pai.

Usuários

Os usuários de uma organização podem ser listados em https://github.com/orgs/<org_name>/people.

Nas informações de cada usuário, você pode ver os times dos quais o usuário é membro, e os repositórios aos quais o usuário tem acesso.

Autenticação no Github

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

Acesso Web

Acessando github.com, você pode fazer login usando seu nome de usuário e senha (e potencialmente um 2FA).

Chaves SSH

Você pode configurar sua conta com uma ou várias chaves públicas permitindo que a chave privada relacionada execute ações em seu nome. https://github.com/settings/keys

Chaves GPG

Você não pode se passar pelo usuário com essas chaves, mas se você não as usar, pode ser possível que você seja descoberto por enviar commits sem uma assinatura. Saiba mais sobre modo vigilante aqui.

Tokens de Acesso Pessoal

Você pode gerar um token de acesso pessoal para dar a um aplicativo acesso à sua conta. Ao criar um token de acesso pessoal, o usuário precisa especificar as permissões que o token terá. https://github.com/settings/tokens

Aplicações Oauth

Aplicações Oauth podem solicitar permissões para acessar parte das suas informações no github ou para se passar por você para realizar algumas ações. Um exemplo comum dessa funcionalidade é o botão de login com github que você pode encontrar em algumas plataformas.

Algumas recomendações de segurança:

  • Uma aplicação OAuth deve sempre agir como o usuário autenticado do GitHub em todo o GitHub (por exemplo, ao fornecer notificações ao usuário) e com acesso apenas aos escopos especificados.

  • Uma aplicação OAuth pode ser usada como um provedor de identidade ao habilitar um "Login com GitHub" para o usuário autenticado.

  • Não crie uma aplicação OAuth se você quer que sua aplicação aja em um repositório único. Com o escopo repo do OAuth, aplicações OAuth podem agir em _todos_** os repositórios do usuário autenticado**.

  • Não crie uma aplicação OAuth para agir como uma aplicação para sua equipe ou empresa. Aplicações OAuth autenticam como um usuário único, então se uma pessoa cria uma aplicação OAuth para uma empresa usar, e depois ela sai da empresa, ninguém mais terá acesso a ela.

  • Mais em aqui.

Aplicações Github

Aplicações Github podem solicitar permissões para acessar suas informações no github ou se passar por você para realizar ações específicas em recursos específicos. Em aplicações Github você precisa especificar os repositórios aos quais o aplicativo terá acesso.

Algumas recomendações de segurança:

  • Uma aplicação Github deve realizar ações independentemente de um usuário (a menos que o aplicativo esteja usando um token de usuário para servidor). 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."

  • Certifique-se de que a aplicação Github integra com repositórios específicos.

  • A aplicação Github deve conectar-se a uma conta pessoal ou uma organização.

  • Não espere que a aplicação Github saiba e faça tudo o que um usuário pode.

  • Não use uma aplicação Github se você apenas precisa de um serviço de "Login com GitHub". Mas uma aplicação Github pode usar um fluxo de identificação de usuário para fazer login dos usuários e fazer outras coisas.

  • Não crie uma aplicação Github se você apenas quer agir como um usuário do GitHub e fazer tudo o que esse usuário pode fazer.

  • Se você está usando seu aplicativo com Github Actions e quer 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 admin ou escrita no repositório que contém o arquivo de workflow. Para mais informações, veja "Entendendo escopos para aplicações OAuth."

  • Mais em aqui.

Github Actions

Isso não é uma forma de autenticação no github, mas uma Github Action maliciosa pode obter acesso não autorizado ao github e dependendo dos privilégios concedidos à Action, vários ataques diferentes podem ser realizados. Veja abaixo para mais informações.

Ações Git

Ações Git permitem automatizar a execução de código quando um evento acontece. Geralmente o código executado está de alguma forma relacionado ao código do repositório (talvez construir um contêiner docker ou verificar que 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 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.

Git Secrets

Ação do Github geralmente precisa de algum tipo de segredos para interagir com o github ou aplicações de terceiros. Para evitar colocá-los em texto claro no repositório, o github permite colocá-los como Secrets.

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:

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

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

Segredos só podem ser acessados pelas Github Actions que os declararam.

Uma vez configurados no repositório ou na organização, usuários do github não poderão acessá-los novamente, apenas 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ê só poderá acessar os segredos declarados para a Action).

Ambientes Git

O Github permite criar ambientes onde você pode salvar segredos. Então, você pode dar acesso à github action aos segredos dentro do ambiente com algo como:

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

Você pode configurar um ambiente para ser acessado por todos os branches (padrão), apenas branches protegidos ou especificar quais branches podem acessá-lo. Também é possível definir um número de revisões necessárias antes de executar uma ação usando um ambiente ou esperar algum tempo antes de permitir que os deployments prossigam.

Git Action Runner

Uma Github Action pode ser executada dentro do ambiente do github ou pode ser executada em uma infraestrutura de terceiros configurada pelo usuário.

Várias organizações permitem executar Github Actions em uma infraestrutura de terceiros, 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 maneira 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 caixa auto hospedada de uma organização diferente porque um token único é gerado para o Runner ao configurá-lo para saber a qual organização o runner pertence.

Se o Github Runner personalizado estiver configurado em uma máquina dentro da AWS ou GCP, por exemplo, a Action poderá ter acesso ao endpoint de metadados e roubar o token da conta de serviço com a qual a máquina está operando.

Comprometimento da Git Action

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.

Uma execução maliciosa de Github Action pode ser abusada pelo atacante para:

  • Roubar todos os segredos aos quais a Action tem acesso

  • Mover-se lateralmente se a Action for executada dentro de uma infraestrutura de terceiros onde o token da SA usado para operar a máquina pode ser acessado (provavelmente via o serviço de metadados)

  • Abusar do token usado pelo workflow para roubar o código do repositório onde a Action está sendo executada ou até modificá-lo.

Proteções de Branch

As proteções de branch são projetadas 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 poder escrever código dentro de algum branch.

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

Não é possível definir uma proteção de branch no nível da organização. Portanto, todas elas devem ser declaradas em cada repositório.

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

  • Você pode exigir um PR antes de fazer o merge (então você não pode fazer o merge do código diretamente sobre o branch). Se isso for selecionado, outras proteções diferentes podem estar em vigor:

  • Exigir um número de aprovações. É muito comum exigir que 1 ou 2 pessoas a mais aprovem seu PR para que um único usuário não seja capaz de fazer o merge do código diretamente.

  • Descartar aprovações quando novos commits são enviados. Se não, um usuário pode aprovar um código legítimo e depois adicionar código malicioso e fazer o merge.

  • Exigir revisões de Code Owners. Pelo menos 1 code owner do repositório precisa aprovar o PR (para que usuários "aleatórios" não possam aprová-lo)

  • Restringir quem pode descartar revisões de pull request. Você pode especificar pessoas ou equipes autorizadas a descartar revisões de pull request.

  • Permitir que atores especificados ignorem os requisitos de pull request. Esses usuários poderão contornar as restrições anteriores.

  • Exigir que os status checks sejam aprovados antes de fazer o merge. Alguns checks precisam ser aprovados antes de poder fazer o merge do commit (como uma github action verificando que não há nenhum segredo em texto claro).

  • Exigir resolução de conversa antes de fazer o merge. Todos os comentários sobre o código precisam ser resolvidos antes que o PR possa ser feito o merge.

  • Exigir commits assinados. Os commits precisam ser assinados.

  • Exigir histórico linear. Impedir que commits de merge sejam enviados para branches correspondentes.

  • Incluir administradores. Se isso não for definido, os administradores podem contornar as restrições.

  • Restringir quem pode enviar para branches correspondentes. Restringir quem pode enviar um PR.

Como você pode ver, mesmo que você consiga obter algumas credenciais de um usuário, os repositórios podem estar protegidos evitando que você envie código para o master por exemplo para comprometer o pipeline de CI/CD.

Referências

Aprenda hacking no AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras maneiras de apoiar o HackTricks:

AnteriorGh Actions - Context Script InjectionsSiguienteGitea Security

Última actualización