Gitea Security

Soutenir HackTricks

Qu'est-ce que Gitea

Gitea est une solution d'hébergement de code léger gérée par la communauté et auto-hébergée écrite en Go.

Informations de base

Laboratoire

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

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.

Exploitation interne

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.

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 (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 pour é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 :

# 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 comme 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é.

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 a une clé avec :

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

Avec le jeton utilisateur

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.

Avec l'application Oauth

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 au compte utilisateur.

Contournement de la protection des branches

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, poussez simplement vers celle-ci.

  • 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 administrateur d'organisation/dépôt, vous pouvez contourner les protections.

Énumérer les Webhooks

Les Webhooks sont capables d'envoyer des informations spécifiques de gitea à certains endroits. Vous pourriez être en mesure de 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 en tant que 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'organisation.

Post-exploitation

À l'intérieur du serveur

Si d'une manière ou d'une autre vous parvenez à entrer dans le serveur où gitea fonctionne, vous devriez rechercher 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 administrateur et obtenir un jeton d'accès.

Soutenir HackTricks

Last updated