Gitea Security

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert de l'équipe rouge AWS de HackTricks)!

Autres façons de soutenir HackTricks :

Qu'est-ce que Gitea

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

Informations de base

pageBasic Gitea Information

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 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 par rapport aux dépôts d'autres organisations/utilisateurs, mais un utilisateur connecté pourrait être en mesure de visualiser plus de dépôts 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'une manière ou d'une autre déjà les identifiants d'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 dépôts, dans quelles équipes vous êtes, listez d'autres utilisateurs, et comment les dépôts sont protégés.

Notez que l'authentification à deux facteurs (2FA) peut être utilisée, 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 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 (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 de Gitea pour énumérer l'environnement. Cependant, vous pouvez énumérer les paramètres locaux pour obtenir des informations sur les dépôts 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 sur https://github.com/<gitea_username>.keys, vous pourriez 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 parfois il est 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 un 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 une 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 de Branche

Sur Github, nous avons des actions github qui obtiennent par défaut un jeton avec 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 voyons ce qui peut être fait :

  • Activer la Poussée : Si n'importe qui avec un accès en écriture peut pousser sur la branche, il suffit de pousser dessus.

  • Liste blanche de Poussée Restreinte : De la même manière, si vous faites partie de cette liste, poussez sur la branche.

  • Activer la Liste Blanche de Fusion : Si une liste blanche de fusion existe, vous devez en faire partie.

  • Exiger des approbations supérieures à 0 : Alors... vous devez compromettre un autre utilisateur.

  • Restreindre les approbations aux utilisateurs autorisés : Si seuls les utilisateurs autorisés peuvent approuver... vous devez compromettre un autre utilisateur qui est dans cette liste.

  • Rejeter les approbations périmées : 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/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 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, au lieu de définir le secret à sa place, ils le définissent 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'org.

Post Exploitation

À l'intérieur du serveur

Si d'une manière ou d'une autre vous avez réussi à accéder au serveur où Gitea est en cours d'exécution, vous devriez rechercher le fichier de configuration de Gitea. Par défaut, il se trouve dans /data/gitea/conf/app.ini

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

Dans le chemin de 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 à 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 sauvegarder les sessions dans la base de données).

  • La clé privée jwt à l'intérieur du dossier jwt

  • D'autres 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 sauvegarder 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é (persistant)

  • 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

Dernière mise à jour