Gitea Security
Last updated
Last updated
Apprenez et pratiquez le piratage AWS :Formation HackTricks AWS Red Team Expert (ARTE) Apprenez et pratiquez le piratage GCP : Formation HackTricks GCP Red Team Expert (GRTE)
Gitea est une solution de hébergement de code léger gérée par la communauté et auto-hébergée écrite en Go.
Pour exécuter une instance Gitea localement, vous pouvez simplement exécuter un conteneur docker :
Connectez-vous au port 3000 pour accéder à la page web.
Vous pouvez également l'exécuter avec kubernetes :
Repos publics : http://localhost:3000/explore/repos
Utilisateurs enregistrés : http://localhost:3000/explore/users
Organisations enregistrées : http://localhost:3000/explore/organizations
Notez qu'en default 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 en mesure de visualiser plus de repos ou d'organisations.
Pour ce scénario, nous allons supposer que vous avez obtenu un accès à un compte github.
Si vous avez d'une manière ou d'une autre 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 quels 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 réussissez à voler le cookie i_like_gitea (actuellement configuré avec SameSite: Lax), vous pouvez complètement usurper l'identité de l'utilisateur sans avoir besoin d'identifiants ou de 2FA.
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 (aucune 2FA n'est appliquée).
Avec cette clé, vous pouvez effectuer des modifications dans les dépôts où l'utilisateur a des privilèges, cependant vous ne pouvez pas l'utiliser pour accéder à l'API gitea afin d'énumérer l'environnement. Cependant, vous pouvez énumérer les paramètres locaux pour obtenir des informations sur les repos et l'utilisateur auquel vous avez accès :
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. Quiconque ayant accès à cette clé pourra lancer des projets à partir d'un dépôt. En général, sur un serveur avec différentes clés de déploiement, le fichier local ~/.ssh/config vous donnera des informations sur la clé à laquelle il est lié.
Comme expliqué ici, il est parfois nécessaire de signer les commits sinon vous pourriez être découvert.
Vérifiez localement si l'utilisateur actuel a une clé avec :
Pour une introduction sur les jetons utilisateur, consultez les informations de base.
Un jeton utilisateur peut être utilisé au lieu d'un mot de passe pour s'authentifier contre le serveur Gitea via l'API. Il aura un accès complet sur l'utilisateur.
Pour une introduction sur les applications Oauth de 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.
Dans Github, nous avons github actions qui, par défaut, obtiennent un jeton avec un accès en écriture sur le dépôt qui peut être utilisé pour contourner les protections de branche. Dans ce cas, cela n'existe pas, donc les contournements sont plus limités. Mais examinons ce qui peut être fait :
Activer le push : Si quelqu'un avec un accès en écriture peut pousser vers la branche, il suffit de pousser.
Liste blanche des push restreints : De la même manière, si vous faites partie de cette liste, poussez vers la branche.
Activer la liste blanche de fusion : S'il y a une liste blanche de fusion, vous devez en faire partie.
Exiger que les approbations soient supérieures à 0 : Alors... vous devez compromettre un autre utilisateur.
Restreindre les approbations aux utilisateurs sur liste blanche : Si seuls les utilisateurs sur liste blanche peuvent approuver... vous devez compromettre un autre utilisateur qui est dans cette liste.
Rejeter 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.
Les Webhooks sont capables d'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, le mettent dans l'URL comme paramètre, donc vérifier les URL 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 au niveau de l'org.
Si d'une manière ou d'une autre vous parvenez à entrer dans le serveur où gitea fonctionne, vous devriez chercher le fichier de configuration de 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 base de données sqlite : Si gitea n'utilise pas une base de données externe, il utilisera une base de données sqlite.
Les sessions dans le 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 dans la base de données).
La clé privée jwt dans le 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é (persistance).
gitea admin user change-password --username admin --password newpassword Changer le mot de passe.
gitea admin user create --username newuser --password superpassword --email user@user.user --admin --access-token Créer un nouvel utilisateur admin et obtenir un jeton d'accès.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
