· Security musings

Catégories

Tags

🔍 Licence d'Utilisation 🔍

Sauf mention contraire, le contenu de ce blog est sous licence CC BY-NC-ND 4.0.

© 2025 à 2042 Sébastien Gioria. Tous droits réservés.

⏱️
Temps de lecture estimé
~4 minutes

Un dépôt GitHub sans une seule ligne de code malveillant. Un agent de codage qui suit sagement un message d’erreur bien formulé. Et pourtant : un shell inversé, les credentials du développeur exfiltrées, une persistance installée. La charge utile n’apparaît jamais dans le dépôt, jamais dans la revue de code, jamais dans le contexte que l’agent traite avant de l’exécuter.

Source : 0DIN Blog (Andre Hall, Miller Engelbrecht), “Clone This Repo and I Own Your Machine”, 0din.ai/blog, relayé par tl;dr sec #336.


Trois composants anodins, un système complet

Le dépôt a une documentation d’installation parfaitement banale. Le package lève un RuntimeError dont le message vous recommande poliment la commande à lancer pour réparer. Et cette commande d’initialisation va chercher sa vraie instruction dans un enregistrement DNS TXT contrôlé par l’attaquant, qu’elle décode en base64 et passe directement à bash.

Un secret bien caché finit par se trouver. Un secret qui n’est nulle part dans ce que vous inspectez survit à un audit parfait.

Le shell inversé n’a rien d’original ; on en a vu des centaines. Ce qui l’est, c’est d’avoir compris qu’un agent de codage face à une erreur cherche à la corriger, pas à s’arrêter et à poser la question. Même mécanique que dans AWS Kiro : l’agent accorde sa confiance à un contenu que personne n’a validé.

Je détaille dans la version complète pourquoi cette technique rend la revue de code et le SAST structurellement aveugles, le tableau d’impact complet, et mes recommandations de durcissement pour les environnements de développement assistés par agent : sandboxing des scripts d’installation, traitement de la résolution DNS comme un canal de données, journalisation des requêtes DNS sortantes des postes de développement.