Gitea Security

Apprenez et pratiquez le Hacking AWS :HackTricks Training AWS Red Team Expert (ARTE) Apprenez et pratiquez le Hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)

Soutenez HackTricks

Consultez les plans d'abonnement !
Rejoignez le 💬 groupe Discord ou le groupe Telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
Partagez des astuces de hacking en soumettant des PRs aux dépôts GitHub HackTricks et HackTricks Cloud.

Qu'est-ce que Gitea

Gitea est une solution d'hébergement de code légère, autogérée et gérée par la communauté écrite en Go.

Informations de base

Basic Gitea Information

Lab

Pour exécuter une instance Gitea localement, vous pouvez simplement exécuter un conteneur docker :

docker run -p 3000:3000 gitea/gitea

Connectez-vous au port 3000 pour accéder à la page web.

Vous pouvez également l'exécuter avec kubernetes :

helm repo add gitea-charts https://dl.gitea.io/charts/
helm install gitea gitea-charts/gitea

Énumération non authentifiée

Repos publics : http://localhost:3000/explore/repos
Utilisateurs enregistrés : http://localhost:3000/explore/users
Organisations enregistrées : http://localhost:3000/explore/organizations

Notez que par défaut, Gitea permet aux nouveaux utilisateurs de s'inscrire. Cela ne donnera pas un accès particulièrement intéressant aux nouveaux utilisateurs sur les repos d'autres organisations/utilisateurs, mais un utilisateur connecté pourrait être capable de visualiser plus de repos ou d'organisations.

Exploitation interne

Pour ce scénario, nous allons supposer que vous avez obtenu un certain accès à un compte github.

Si vous avez déjà des identifiants pour un utilisateur au sein d'une organisation (ou si vous avez volé un cookie de session), vous pouvez simplement vous connecter et vérifier quelles permissions vous avez sur quels repos, dans quelles équipes vous êtes, lister d'autres utilisateurs, et comment les repos sont protégés.

Notez que 2FA peut être utilisé donc vous ne pourrez accéder à ces informations que si vous pouvez également passer cette vérification.

Notez que si vous parvenez à voler le cookie i_like_gitea (actuellement configuré avec SameSite: Lax), vous pouvez complètement usurper l'identité de l'utilisateur sans avoir besoin des identifiants ou du 2FA.

Avec la clé SSH de l'utilisateur

Gitea permet aux utilisateurs de définir des clés SSH qui seront utilisées comme méthode d'authentification pour déployer du code en leur nom (aucun 2FA n'est appliqué).

Avec cette clé, vous pouvez effectuer des modifications dans les dépôts où l'utilisateur a certains privilèges, cependant vous ne pouvez pas l'utiliser pour accéder à l'api gitea pour énumérer l'environnement. Cependant, vous pouvez énumérer les paramètres locaux pour obtenir des informations sur les repos et l'utilisateur auxquels vous avez accès :

# Go to the the repository folder
# Get repo config and current user name and email
git config --list

Si l'utilisateur a configuré son nom d'utilisateur comme son nom d'utilisateur gitea, vous pouvez accéder aux clés publiques qu'il a définies dans son compte à https://github.com/<gitea_username>.keys, vous pouvez vérifier cela pour confirmer que la clé privée que vous avez trouvée peut être utilisée.

Les clés SSH peuvent également être définies dans les dépôts en tant que clés de déploiement. Toute personne ayant accès à cette clé pourra lancer des projets à partir d'un dépôt. Habituellement, sur un serveur avec différentes clés de déploiement, le fichier local ~/.ssh/config vous donnera des informations sur la clé concernée.

Clés GPG

Comme expliqué ici, il est parfois nécessaire de signer les commits ou vous pourriez être découvert.

Vérifiez localement si l'utilisateur actuel possède une clé avec :

gpg --list-secret-keys --keyid-format=long

Avec Jeton Utilisateur

Pour une introduction sur les Jetons Utilisateurs, consultez les informations de base.

Un jeton utilisateur peut être utilisé à la place d'un mot de passe pour s'authentifier contre le serveur Gitea via API. Il aura un accès complet sur l'utilisateur.

Avec Application Oauth

Pour une introduction sur les Applications Oauth Gitea, consultez les informations de base.

Un attaquant pourrait créer une application Oauth malveillante pour accéder aux données/actions privilégiées des utilisateurs qui les acceptent, probablement dans le cadre d'une campagne de phishing.

Comme expliqué dans les informations de base, l'application aura un accès complet sur le compte utilisateur.

Contournement de la Protection des Branches

Dans Github, nous avons github actions qui par défaut obtiennent un jeton avec accès en écriture sur le dépôt qui peut être utilisé pour contourner les protections des branches. Dans ce cas, cela n'existe pas, donc les contournements sont plus limités. Mais voyons ce qui peut être fait :

Activer Push : Si quelqu'un avec un accès en écriture peut pousser sur la branche, il suffit de pousser dessus.
Liste blanche de Push restreint : De la même manière, si vous faites partie de cette liste, poussez sur la branche.
Activer la liste blanche de fusion : S'il y a une liste blanche de fusion, vous devez en faire partie.
Exiger des approbations supérieures à 0 : Alors... vous devez compromettre un autre utilisateur.
Restreindre les approbations aux utilisateurs en liste blanche : Si seuls les utilisateurs en liste blanche peuvent approuver... vous devez compromettre un autre utilisateur qui est dans cette liste.
Annuler les approbations obsolètes : Si les approbations ne sont pas supprimées avec de nouveaux commits, vous pourriez détourner une PR déjà approuvée pour injecter votre code et fusionner la PR.

Notez que si vous êtes un admin d'org/repo, vous pouvez contourner les protections.

Énumérer les Webhooks

Les Webhooks peuvent envoyer des informations spécifiques de gitea à certains endroits. Vous pourriez être en mesure d'exploiter cette communication. Cependant, généralement un secret que vous ne pouvez pas récupérer est défini dans le webhook qui empêchera les utilisateurs externes qui connaissent l'URL du webhook mais pas le secret d'exploiter ce webhook. Mais dans certaines occasions, les gens au lieu de définir le secret à sa place, ils le mettent dans l'URL en tant que paramètre, donc vérifier les URLs pourrait vous permettre de trouver des secrets et d'autres endroits que vous pourriez exploiter davantage.

Les webhooks peuvent être définis au niveau du dépôt et de l'organisation.

Post Exploitation

À l'intérieur du serveur

Si d'une manière ou d'une autre vous avez réussi à entrer dans le serveur où gitea fonctionne, vous devriez rechercher le fichier de configuration gitea. Par défaut, il est situé dans /data/gitea/conf/app.ini

Dans ce fichier, vous pouvez trouver des clés et des mots de passe.

Dans le chemin gitea (par défaut : /data/gitea), vous pouvez également trouver des informations intéressantes comme :

La DB sqlite : Si gitea n'utilise pas une db externe, il utilisera une db sqlite.
Les sessions à l'intérieur du dossier des sessions : En exécutant cat sessions/*/*/*, vous pouvez voir les noms d'utilisateur des utilisateurs connectés (gitea pourrait également enregistrer les sessions à l'intérieur de la DB).
La clé privée jwt à l'intérieur du dossier jwt.
Plus d'informations sensibles pourraient être trouvées dans ce dossier.

Si vous êtes à l'intérieur du serveur, vous pouvez également utiliser le binaire gitea pour accéder/modifier des informations :

gitea dump va dumper gitea et générer un fichier .zip.
gitea generate secret INTERNAL_TOKEN/JWT_SECRET/SECRET_KEY/LFS_JWT_SECRET va générer un jeton du type indiqué (persistence).
gitea admin user change-password --username admin --password newpassword Change le mot de passe.
gitea admin user create --username newuser --password superpassword --email user@user.user --admin --access-token Crée un nouvel utilisateur admin et obtient un jeton d'accès.