Informações Básicas sobre Gitea

Reading time: 5 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 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 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.

Permissões

Organizações

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:

Equipes & Usuários

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

Autenticação Gitea

Acesso Web

Usando nome de usuário + senha e potencialmente (e recomendado) um 2FA.

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. http://localhost:3000/user/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.

Tokens de Acesso Pessoal

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

Aplicações Oauth

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 docs, escopos ainda não são suportados:

Chaves de Deploy

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.

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://localhost:3000/<orgname>/<reponame>/settings/branches

note

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 force push.
  • Whitelist Restricted Push: Apenas usuários/equipes selecionados podem fazer push para este branch (mas sem force 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/equipes 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 passem)
  • 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 são 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

note

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 master, por exemplo, para comprometer o pipeline CI/CD.

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