Contenu du dépôt

Environnement testé

La preuve de concept a été validée dans l'environnement isolé suivant :

Une exploitation réussie a produit une sortie de commande similaire à :

Prérequis

• Python 3.8 ou version ultérieure
• Accès réseau à l'instance Gitea cible
• Un compte Gitea valide avec les permissions de création et d'écriture de dépôt, ou une instance de laboratoire cible avec l'inscription publique activée
• Un environnement de test explicitement autorisé

Le script utilise uniquement la bibliothèque standard de Python et ne nécessite aucun paquet supplémentaire.

Utilisation

Exemple pour une instance de laboratoire locale :

Le script tente d'abord une inscription web, puis s'authentifie avec les identifiants fournis. Cela permet à la même commande de fonctionner soit avec un nouveau compte sur une instance avec inscription ouverte, soit avec un compte existant.

Analyse technique

La chaîne d'exploitation se compose de quatre étapes :

1. Soumission d'un patch contrôlé par l'attaquant
   POST /api/v1/repos/{owner}/{repo}/diffpatch applique le contenu du patch fourni à l'aide de git apply --index --recount --cached --binary --ignore-whitespace --whitespace=fix -3 dans un clone temporaire.

2. Placement du chemin du hook
   Le dépôt temporaire est créé en tant que clone nu et partagé. Dans un dépôt nu, la racine du dépôt est également $GIT_DIR ; par conséquent, le chemin du patch hooks/post-index-change se résout à l'intérieur du répertoire de hooks actif de Git.

3. Matérialisation du hook exécutable
   Le même patch est soumis deux fois. La seconde application produit un conflit add/add, provoquant la matérialisation du chemin sur le disque par le repli three-way avec le mode 100755, malgré l'utilisation de --cached. Une mise à jour ultérieure de l'index invoque post-index-change, exécutant le code shell injecté en tant que compte de service Gitea.

4. Récupération de la sortie native à Git
   Le hook identifie le dépôt d'origine via objects/info/alternates, stocke la sortie de commande en tant que blob Git, crée une arborescence et un commit, et met à jour refs/heads/output-leak. La preuve de concept récupère ensuite le résultat via l'API de fichiers bruts de Gitea. Cette technique ne nécessite pas de connexion sortante directe depuis la cible.

Impact

Une exploitation réussie accorde l'exécution de commandes avec les privilèges du compte de service Gitea. Selon la configuration du déploiement, un attaquant peut être en mesure d'accéder à :

• app.ini et aux identifiants de base de données
• SECRET_KEY, INTERNAL_TOKEN et aux secrets liés à LFS
• Aux dépôts montés ou lisibles par le processus Gitea
• Aux variables d'environnement du processus
• Aux services internes accessibles depuis l'hôte ou le conteneur Gitea

Il a été confirmé que le compte de laboratoire disposait d'un accès en lecture à app.ini.

Indicateurs de compromission

Les défenseurs doivent examiner les artefacts et les schémas de requêtes suivants :

• Deux requêtes identiques ou quasi identiques vers /api/v1/repos/*/*/diffpatch en succession rapide
• Une branche nommée output-leak
• Des commits dont l'auteur est poc <[email protected]>
• Des fichiers exécutables inattendus nommés hooks/post-index-change dans des dépôts nus ou des répertoires de clone temporaires
• Une activité suspecte sous des chemins tels que /data/gitea/tmp/local-repo/upload.git*

Ces indicateurs décrivent la preuve de concept incluse et ne sont pas exhaustifs ; un exploit modifié peut utiliser des chemins, des refs, des identités ou des canaux de sortie différents.

Remédiation et atténuation

1. Mettre à niveau vers Gitea 1.27.1 ou version ultérieure. Il s'agit de la remédiation recommandée. Le correctif modifie le flux de travail affecté pour utiliser un clone temporaire non nu.
2. Restreindre l'API diffpatch au niveau du reverse proxy jusqu'à ce que la mise à niveau soit terminée, par exemple en refusant l'accès aux routes /api/v1/.../diffpatch correspondantes. Validez la règle par rapport aux intégrations légitimes avant le déploiement.
3. Désactiver l'inscription publique en définissant DISABLE_REGISTRATION=true si elle n'est pas opérationnellement requise. Cela réduit l'accessibilité non authentifiée mais ne protège pas contre les utilisateurs existants disposant d'un accès en écriture au dépôt.
4. Examiner les journaux et les refs des dépôts pour les indicateurs ci-dessus, et faire tourner les identifiants ou secrets accessibles au compte Gitea si une compromission est suspectée.

Pour le conteneur de laboratoire utilisé dans cette recherche, le démontage peut être effectué avec :

Utilisation responsable

Ce matériel est fourni pour aider les défenseurs à reproduire, comprendre, détecter et remédier à la vulnérabilité. Les opérateurs ne doivent tester que dans des environnements isolés et respecter les exigences d'autorisation et de divulgation de leur organisation.