Información Básica de Gitea

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Estructura Básica

La estructura básica del entorno de Gitea es agrupar repos por organización(es), cada una de ellas puede contener varios repositorios y varios equipos. Sin embargo, ten en cuenta que al igual que en github, los usuarios pueden tener repos fuera de la organización.

Además, un usuario puede ser miembro de diferentes organizaciones. Dentro de la organización, el usuario puede tener diferentes permisos sobre cada repositorio.

Un usuario también puede ser parte de diferentes equipos con diferentes permisos sobre diferentes repos.

Y finalmente, los repositorios pueden tener mecanismos de protección especiales.

Permisos

Organizaciones

Cuando se crea una organización, se crea un equipo llamado Owners y el usuario se coloca dentro de él. Este equipo otorgará acceso de administrador sobre la organización, esos permisos y el nombre del equipo no pueden ser modificados.

Org admins (propietarios) pueden seleccionar la visibilidad de la organización:

  • Pública
  • Limitada (solo usuarios registrados)
  • Privada (solo miembros)

Org admins también pueden indicar si los repo admins pueden agregar o eliminar acceso para equipos. También pueden indicar el número máximo de repos.

Al crear un nuevo equipo, se seleccionan varias configuraciones importantes:

  • Se indica los repos de la org a los que los miembros del equipo podrán acceder: repos específicos (repos donde se agrega el equipo) o todos.
  • También se indica si los miembros pueden crear nuevos repos (el creador obtendrá acceso de administrador a él)
  • Los permisos que los miembros del repos tendrán:
  • Acceso de Administrador
  • Acceso Específico:

Equipos y Usuarios

En un repositorio, el org admin y los repo admins (si lo permite la org) pueden gestionar los roles otorgados a colaboradores (otros usuarios) y equipos. Hay 3 posibles roles:

  • Administrador
  • Escribir
  • Leer

Autenticación de Gitea

Acceso Web

Usando nombre de usuario + contraseña y potencialmente (y recomendado) un 2FA.

Claves SSH

Puedes configurar tu cuenta con una o varias claves públicas que permiten que la clave privada relacionada realice acciones en tu nombre. http://localhost:3000/user/settings/keys

Claves GPG

No puedes suplantar al usuario con estas claves pero si no las usas, podría ser posible que se descubra que envías commits sin una firma.

Tokens de Acceso Personal

Puedes generar un token de acceso personal para dar acceso a una aplicación a tu cuenta. Un token de acceso personal otorga acceso completo a tu cuenta: http://localhost:3000/user/settings/applications

Aplicaciones Oauth

Al igual que los tokens de acceso personal, las aplicaciones Oauth tendrán acceso completo a tu cuenta y a los lugares a los que tu cuenta tiene acceso porque, como se indica en la docs, los scopes aún no son compatibles:

Claves de Despliegue

Las claves de despliegue pueden tener acceso de solo lectura o de escritura al repositorio, por lo que pueden ser interesantes para comprometer repos específicos.

Protecciones de Ramas

Las protecciones de ramas están diseñadas para no dar control completo de un repositorio a los usuarios. El objetivo es implementar varios métodos de protección antes de poder escribir código dentro de alguna rama.

Las protecciones de ramas de un repositorio se pueden encontrar en https://localhost:3000/<orgname>/<reponame>/settings/branches

Note

No es posible establecer una protección de rama a nivel de organización. Por lo tanto, todas deben ser declaradas en cada repositorio.

Se pueden aplicar diferentes protecciones a una rama (como a master):

  • Deshabilitar Push: Nadie puede hacer push a esta rama
  • Habilitar Push: Cualquiera con acceso puede hacer push, pero no forzar push.
  • Lista Blanca de Push Restringido: Solo usuarios/equipos seleccionados pueden hacer push a esta rama (pero no forzar push)
  • Habilitar Lista Blanca de Merge: Solo usuarios/equipos en la lista blanca pueden fusionar PRs.
  • Habilitar Verificaciones de Estado: Requiere que las verificaciones de estado pasen antes de fusionar.
  • Requerir aprobaciones: Indica el número de aprobaciones requeridas antes de que un PR pueda ser fusionado.
  • Restringir aprobaciones a los de la lista blanca: Indica usuarios/equipos que pueden aprobar PRs.
  • Bloquear fusión en revisiones rechazadas: Si se solicitan cambios, no se puede fusionar (incluso si las otras verificaciones pasan)
  • Bloquear fusión en solicitudes de revisión oficiales: Si hay solicitudes de revisión oficiales, no se puede fusionar
  • Desestimar aprobaciones obsoletas: Cuando hay nuevos commits, las aprobaciones antiguas serán desestimadas.
  • Requerir Commits Firmados: Los commits deben estar firmados.
  • Bloquear fusión si la solicitud de extracción está desactualizada
  • Patrones de archivos protegidos/no protegidos: Indica patrones de archivos para proteger/no proteger contra cambios

Note

Como puedes ver, incluso si lograste obtener algunas credenciales de un usuario, los repos pueden estar protegidos evitando que empujes código a master por ejemplo para comprometer el pipeline de CI/CD.

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks