Evil merge dans Git : malware dans le commit de merge

Fusion Malveillante : Code Malicieux Dissimulé dans les Commits de Fusion Git

Du code malveillant et obfusqué a été découvert dans le fichier vite.config.js d'un projet. Il n'a pas été introduit via une pull request (PR), mais directement dans un commit de fusion lors de la résolution d'un conflit. La vue PR de GitHub n'affiche que le diff de la branche de fonctionnalité, ignorant les modifications apportées dans le commit de fusion lui-même. Une analyse avec git log a révélé un commit de fusion avec des commits parents identiques mais un contenu de fichier altéré.

Les hachages MD5 des commits parents correspondaient :

• Parent 1 : aa82acb0c335430d8300b6cb306dc824 (propre)
• Parent 2 : aa82acb0c335430d8300b6cb306dc824 (propre)
• Fusion : 2a54754defae4d13aab39f256738dbbf (modifié)

Dans une fusion à trois voies, Git devrait produire un résultat inchangé lorsque les fichiers parents sont identiques. Toute différence indique une édition manuelle pendant le processus de fusion.

Mécanisme d'Injection et d'Obfuscation

La charge utile malveillante a été injectée dans deux fichiers de modules différents. Le contributeur a ajouté la charge utile en cliquant sur le bouton de fusion dans la PR. Le code s'est exécuté pendant npm run dev et npm run build pendant 3,5 mois.

Les techniques d'obfuscation comprenaient :

• La reconstruction de chaînes comme require, module, constructor en les brouillant avec une graine numérique.
• L'utilisation de Function au lieu de eval pour contourner l'analyse statique.
• Un décodeur personnalisé utilisant une table de substitution de caractères.

La charge utile ne contenait aucune URL ou adresse IP. Au lieu de cela, elle :

• Interrogeait la dernière transaction d'un portefeuille TRON.
• Extrayait un hachage de transaction BSC.
• Effectuait un appel JSON-RPC eth_getTransactionByHash à un nœud BSC.
• Déchiffrait le code par XOR à partir du champ input de la transaction.

Aptos était utilisé comme solution de repli si TRON n'était pas disponible. L'exécution utilisait child_process.spawn avec detached: true et stdio: 'ignore', et un minuteur de 30 secondes pour contrer la détection en mode surveillance.

Raisons pour lesquelles cela est passé inaperçu

• GitHub n'affiche pas les diffs pour les commits de fusion dans les PRs.
• git log ne révèle pas les changements ; il faut utiliser git diff <parent1>..<fusion>.
• Le code était décalé au-delà de la 200e colonne avec des espaces blancs.
• Les outils SAST ont échoué en raison de l'absence de signatures : pas de eval, d'URLs ou de base64.

Cette technique est connue sous le nom de fusion malveillante — une fusion qui introduit des changements absents des deux parents (gitglossary(7)). Elle a été décrite par un mainteneur de Git en 2013, mais peu d'outils de détection existent.

Détecteur de Fusion Malveillante : Scanner Automatisé

Un détecteur écrit en Go compare le résultat attendu de la fusion à trois voies (via un ancêtre commun) avec le commit de fusion réel. Les écarts signalent des éditions manuelles.

Utilisation :

evilmerge scan /chemin/vers/dépôt

Options :

• --format=sarif pour GitHub Code Scanning.
• Niveaux de sévérité : résolutions manuelles de conflits vs éditions sans conflits.

Intégrations :

• Action GitHub :

```yaml

- uses: fimskiy/Evil-merge-detector@v1

with:

fail-on: warning

```

• Application GitHub : vérifications de PR et analyses rétrospectives de l'historique.
• Modèles pour GitLab, Bitbucket et configurations auto-hébergées (hooks pre-receive).

Atténuations et Vulnérabilités du Workflow

Attaques via l'accès contributeur : commits légitimes suivis d'une injection pendant une fusion. La PR elle-même reste propre.

Recommandations :

• Utiliser un historique linéaire (squash/rebase).
• Implémenter des hooks pre-receive sur le serveur.
• Sur GitHub : activer "Dismiss stale reviews" pour exiger une re-vérification si la branche PR change.

GitHub a confirmé qu'il s'agit d'un choix de conception intentionnel, avec de possibles restrictions futures. Les mesures actuelles se concentrent sur la prévention, pas la détection.

Points Clés à Retenir

• Fusion malveillante est le terme officiel pour les éditions manuelles dans les commits de fusion.
• La charge utile utilise la blockchain (TRON/BSC/Aptos) pour le commandement et contrôle sans URLs/IPs.
• Le détecteur basé sur Go scanne l'historique et s'intègre dans CI/CD.
• 3,5 mois d'activité non détectée dans un projet avec CI et revue de code.
• GitHub n'a pas de plans immédiats pour changer le workflow de fusion.

— Editorial Team