Last updated
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
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.
Cuando se crea una organización, se crea un equipo llamado Owners y el usuario se coloca dentro de él. Este equipo dará acceso de administrador sobre la organización, esos permisos y el nombre del equipo no pueden ser modificados.
Los administradores de la organización (propietarios) pueden seleccionar la visibilidad de la organización:
Público
Limitado (solo usuarios registrados)
Privado (solo miembros)
Los administradores de la organización también pueden indicar si los administradores de repos 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:
En un repositorio, el administrador de la org y los administradores de repos (si lo permite la org) pueden gestionar los roles otorgados a colaboradores (otros usuarios) y equipos. Hay 3 posibles roles:
Administrador
Escribir
Leer
Usando nombre de usuario + contraseña y potencialmente (y recomendado) un 2FA.
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
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.
Puedes generar un token de acceso personal para dar acceso a una aplicación a tu cuenta. Un token de acceso personal da acceso completo a tu cuenta: http://localhost:3000/user/settings/applications
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 documentación, los scopes aún no son compatibles:
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.
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
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 que están en 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
Como puedes ver, incluso si lograste obtener algunas credenciales de un usuario, los repos pueden estar protegidos evitando que puedas hacer push de código a master por ejemplo para comprometer el pipeline de CI/CD.
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
