Last updated
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
A estrutura básica do ambiente Gitea é agrupar repositórios por organização(ões), cada uma delas pode conter vários repositórios e várias equipes. No entanto, note que assim como no github, os usuários podem ter repositórios fora da organização.
Além disso, um usuário pode ser um membro de diferentes organizações. Dentro da organização, o usuário pode ter diferentes permissões sobre cada repositório.
Um usuário também pode ser parte de diferentes equipes com diferentes permissões sobre diferentes repositórios.
E finalmente, repositórios podem ter mecanismos de proteção especiais.
Quando uma organização é criada, uma equipe chamada Owners é criada e o usuário é colocado dentro dela. Esta equipe dará acesso de admin sobre a organização, essas permissões e o nome da equipe não podem ser modificados.
Org admins (proprietários) podem selecionar a visibilidade da organização:
Público
Limitado (apenas usuários logados)
Privado (apenas membros)
Org admins também podem indicar se os repo admins podem adicionar ou remover acesso para equipes. Eles também podem indicar o número máximo de repositórios.
Ao criar uma nova equipe, várias configurações importantes são selecionadas:
É indicado os repositórios da org que os membros da equipe poderão acessar: repositórios específicos (repositórios onde a equipe é adicionada) ou todos.
Também é indicado se os membros podem criar novos repositórios (o criador terá acesso de admin a ele)
As permissões que os membros do repositório terão:
Acesso Administrador
Acesso Específico:
Em um repositório, o org admin e os repo admins (se permitido pela org) podem gerenciar os papéis dados a colaboradores (outros usuários) e equipes. Existem 3 possíveis papéis:
Administrador
Escrita
Leitura
Usando nome de usuário + senha e potencialmente (e recomendado) um 2FA.
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. http://localhost:3000/user/settings/keys
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.
Você pode gerar um token de acesso pessoal para dar a um aplicativo acesso à sua conta. Um token de acesso pessoal dá acesso total à sua conta: http://localhost:3000/user/settings/applications
Assim como os tokens de acesso pessoal, as aplicações Oauth terão acesso completo à sua conta e aos lugares que sua conta tem acesso porque, como indicado na documentação, escopos ainda não são suportados:
Chaves de deploy podem ter acesso somente leitura ou de escrita ao repositório, então podem ser interessantes para comprometer repositórios específicos.
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://localhost:3000/<orgname>/<reponame>/settings/branches
Não é possível definir uma proteção de branch em nível de organização. Portanto, todas elas devem ser declaradas em cada repositório.
Diferentes proteções podem ser aplicadas a um branch (como ao master):
Desabilitar Push: Ninguém pode fazer push para este branch
Habilitar Push: Qualquer um com acesso pode fazer push, mas não forçar push.
Whitelist Restricted Push: Apenas usuários/equipes selecionados podem fazer push para este branch (mas sem forçar push)
Habilitar Merge Whitelist: Apenas usuários/equipes na lista branca podem mesclar PRs.
Habilitar verificações de status: Exigir que as verificações de status sejam aprovadas antes de mesclar.
Exigir aprovações: Indicar o número de aprovações necessárias antes que um PR possa ser mesclado.
Restringir aprovações a usuários na lista branca: Indicar usuários/equipes que podem aprovar PRs.
Bloquear mesclagem em revisões rejeitadas: Se mudanças forem solicitadas, não pode ser mesclado (mesmo que as outras verificações sejam aprovadas)
Bloquear mesclagem em solicitações de revisão oficiais: Se houver solicitações de revisão oficiais, não pode ser mesclado
Desconsiderar aprovações antigas: Quando novos commits forem feitos, aprovações antigas serão desconsideradas.
Exigir Commits Assinados: Commits devem ser assinados.
Bloquear mesclagem se a solicitação de pull estiver desatualizada
Padrões de arquivos protegidos/não protegidos: Indicar padrões de arquivos para proteger/desproteger contra mudanças
Como você pode ver, mesmo que você consiga obter algumas credenciais de um usuário, repositórios podem estar protegidos evitando que você faça push de código para o master, por exemplo, para comprometer o pipeline CI/CD.
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
