Informations de base sur Gitea

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.

Structure de base

La structure de base de l’environnement Gitea consiste à regrouper les dépôts par organisation(s), chacune d’elles pouvant contenir plusieurs dépôts et plusieurs équipes. Cependant, notez que tout comme sur GitHub, les utilisateurs peuvent avoir des dépôts en dehors de l’organisation.

De plus, un utilisateur peut être membre de différentes organisations. Au sein de l’organisation, l’utilisateur peut avoir différentes permissions sur chaque dépôt.

Un utilisateur peut également être partie de différentes équipes avec différentes permissions sur différents dépôts.

Et enfin, les dépôts peuvent avoir des mécanismes de protection spéciaux.

Permissions

Organisations

Lorsqu’une organisation est créée, une équipe appelée Propriétaires est créée et l’utilisateur y est ajouté. Cette équipe donnera un accès admin sur l’organisation, ces permissions et le nom de l’équipe ne peuvent pas être modifiés.

Les admins d’org (propriétaires) peuvent sélectionner la visibilité de l’organisation :

• Publique
• Limitée (utilisateurs connectés uniquement)
• Privée (membres uniquement)

Les admins d’org peuvent également indiquer si les admins de dépôt peuvent ajouter ou retirer l’accès pour les équipes. Ils peuvent également indiquer le nombre maximum de dépôts.

Lors de la création d’une nouvelle équipe, plusieurs paramètres importants sont sélectionnés :

• Il est indiqué les dépôts de l’org auxquels les membres de l’équipe pourront accéder : dépôts spécifiques (dépôts où l’équipe est ajoutée) ou tous.
• Il est également indiqué si les membres peuvent créer de nouveaux dépôts (le créateur obtiendra un accès admin à celui-ci)
• Les permissions que les membres du dépôt auront :
• Accès Administrateur
• Accès Spécifique :

Équipes & Utilisateurs

Dans un dépôt, l’admin d’org et les admins de dépôt (si autorisés par l’org) peuvent gérer les rôles attribués aux collaborateurs (autres utilisateurs) et aux équipes. Il y a 3 rôles possibles :

• Administrateur
• Écrire
• Lire

Authentification Gitea

Accès Web

Utilisation de nom d’utilisateur + mot de passe et potentiellement (et recommandé) un 2FA.

Clés SSH

Vous pouvez configurer votre compte avec une ou plusieurs clés publiques permettant à la clé privée associée d’effectuer des actions en votre nom. http://localhost:3000/user/settings/keys

Clés GPG

Vous ne pouvez pas usurper l’identité de l’utilisateur avec ces clés, mais si vous ne l’utilisez pas, il pourrait être possible que vous soyez découvert pour avoir envoyé des commits sans signature.

Jetons d’accès personnels

Vous pouvez générer un jeton d’accès personnel pour donner à une application accès à votre compte. Un jeton d’accès personnel donne un accès complet à votre compte : http://localhost:3000/user/settings/applications

Applications Oauth

Tout comme les jetons d’accès personnels, les applications Oauth auront un accès complet à votre compte et aux endroits auxquels votre compte a accès car, comme indiqué dans la documentation, les scopes ne sont pas encore pris en charge :

Clés de déploiement

Les clés de déploiement peuvent avoir un accès en lecture seule ou en écriture au dépôt, elles peuvent donc être intéressantes pour compromettre des dépôts spécifiques.

Protections de branche

Les protections de branche sont conçues pour ne pas donner un contrôle complet d’un dépôt aux utilisateurs. L’objectif est de mettre plusieurs méthodes de protection avant de pouvoir écrire du code dans une certaine branche.

Les protections de branche d’un dépôt peuvent être trouvées sur https://localhost:3000/<orgname>/<reponame>/settings/branches

Note

Il n’est pas possible de définir une protection de branche au niveau de l’organisation. Donc, toutes doivent être déclarées sur chaque dépôt.

Différentes protections peuvent être appliquées à une branche (comme à master) :

• Désactiver Push : Personne ne peut pousser vers cette branche
• Activer Push : Quiconque ayant accès peut pousser, mais pas forcer le push.
• Liste blanche de Push restreint : Seuls les utilisateurs/équipes sélectionnés peuvent pousser vers cette branche (mais pas de force push)
• Activer la liste blanche de fusion : Seuls les utilisateurs/équipes sur liste blanche peuvent fusionner des PRs.
• Activer les vérifications d’état : Exiger que les vérifications d’état réussissent avant de fusionner.
• Exiger des approbations : Indiquer le nombre d’approbations requises avant qu’une PR puisse être fusionnée.
• Restreindre les approbations aux utilisateurs sur liste blanche : Indiquer les utilisateurs/équipes qui peuvent approuver les PRs.
• Bloquer la fusion sur des revues rejetées : Si des modifications sont demandées, elle ne peut pas être fusionnée (même si les autres vérifications réussissent)
• Bloquer la fusion sur des demandes de révision officielles : Si des demandes de révision officielles existent, elle ne peut pas être fusionnée
• Rejeter les approbations obsolètes : Lors de nouveaux commits, les anciennes approbations seront rejetées.
• Exiger des commits signés : Les commits doivent être signés.
• Bloquer la fusion si la demande de tirage est obsolète
• Modèles de fichiers protégés/non protégés : Indiquer les modèles de fichiers à protéger/non protéger contre les modifications

Note

Comme vous pouvez le voir, même si vous parvenez à obtenir des identifiants d’un utilisateur, les dépôts peuvent être protégés vous empêchant de pousser du code vers master par exemple pour compromettre le pipeline CI/CD.

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.