Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

Hazmat - Vos agents IA en cage sous macOS

Par : Korben
8 avril 2026 à 13:30

J'sais pas si vous vous en rendez compte mais les agents IA qui codent sur votre machine ont accès à vos clés SSH, vos credentials AWS, votre Keychain et compagnie. Ils ont accès à TOUT ! C'est comme filer les clés de votre appart à un gars que vous avez croisé sur le parking de Leclerc y'a pas 5 min.

Hazmat prend le problème à l'envers : au lieu de demander poliment à l'agent de se tenir tranquille, il l'enferme dans un compte macOS séparé. Du coup, vos ~/.ssh, ~/.aws, votre Keychain deviennent structurellement inaccessibles. Pour en profiter, faut faire un

brew install dredozubov/tap/hazmat

puis

cd /tmp
hazmat init --bootstrap-agent claude

Et hop, 10 minutes plus tard votre agent tourne dans sa cage. (le premier snapshot est ultra loooong mais après c'est de l'incrémental donc ça ira plus vite)

L'isolation repose sur 3 couches indépendantes, un peu comme les sas d'un sous-marin. Il y a d'abord un utilisateur agent dédié (vos fichiers perso deviennent alors hors de portée, point). Ensuite, une politique seatbelt générée dynamiquement à chaque session qui consiste à ce que le kernel de macOS vérifie chaque accès fichier et refuse tout ce qui n'est pas explicitement autorisé pour cette session précise.

Et par-dessus, des règles pf firewall qui empêchent l'agent d'envoyer du trafic SMTP, IRC, FTP, Tor ou VPN. Comme ça, un agent qui tentera d'exfiltrer vos données par mail se retrouvera bloqué net au niveau du noyau.

Côté supply chain, Hazmat force npm ignore-scripts=true par défaut. Comme ça, par exemple le fameux hack axios qui livrait un RAT via un hook postinstall en 2 secondes chrono n'est plus possible ici ! Y'a aussi une blocklist DNS qui redirige les services de tunnel connus (ngrok, pastebin, webhook.site) vers localhost. Contre un domaine perso fraîchement enregistré, ça passera mais les vecteurs d'exfiltration classiques, ça devrait résister.

Hazmat utilise TLA+, le même formalisme que les ingés d'Amazon utilisent pour vérifier les protocoles de DynamoDB. Genre, l'installation des règles sudoers AVANT le firewall (évidemment, ça crée une fenêtre de vulnérabilité), les restrictions qui bloquaient les lectures mais pas les écritures, ou encore une restauration cloud sans vérifier qu'un snapshot existait...etc, c'est le genre de truc qu'aucun test unitaire n'aurait chopé.

Ça supporte Claude Code (y compris le fameux --dangerously-skip-permissions), OpenCode et Codex. Attention par contre, si votre projet utilise Docker, y'a deux cas de figure : soit le daemon Docker est privé au projet et Hazmat le route automatiquement vers un mode Docker Sandbox, soit c'est un daemon partagé et là faudra passer --docker=none explicitement.

La commande hazmat explain montre aussi exactement ce que le sandbox autorise avant de lancer quoi que ce soit... et ça, c'est pas du luxe quand on sait pas trop ce qu'on va lâcher dans la nature. Le hazmat diff qui affiche les changements faits par l'agent depuis le dernier snapshot Kopia, c'est plutôt bien pensé. Et si l'agent casse un truc ? hazmat restore et c'est reparti, comme un Ctrl+Z géant pour tout votre projet.

Si vous avez déjà configuré votre Mac avec teaBASE pour sécuriser votre env de dev, c'est un complément logique.

Côté limites, faut être honnête, Seatbelt n'est pas documenté par Apple depuis macOS 10.5 et c'est du defense-in-depth, et pas une vraie frontière de VM. Quand à l'exfiltration HTTPS elle n'est pas bloquée car l'agent peut toujours curl n'importe quoi sur le port 443. C'est logique mais bon, c'est pas étanche à 100% quoi...

Et surtout c'est macOS only pour l'instant (le port Linux est en chantier), et bien sûr le /tmp partagé entre les comptes locaux reste un vecteur potentiel. J'aurais aimé aussi que le réseau soit coupé par défaut sauf whitelist, mais bon, faudra attendre. Après entre ça et laisser Claude Code en roue libre avec les pleins pouvoirs sur votre machine... y'a pas photo.

Bref, pour du vibe coding sur Mac, c'est le minimum vital.

Vos agents IA sécurisés en -10 sec. sur Mac

Par : Korben
2 février 2026 à 09:37

Si vous faites du "vibe coding" avec Claude ou Codex, vous savez que laisser un agent IA faire sa life, c'est un peu risqué. Si celui-ci se met à exécuter des rm -rf sur votre ordi de boulot, vous êtes dans la merde !

Heureusement, Kevin Lynagh a sorti Vibe et pour vous résumer le délire, c'est une VM Linux ultra-légère capable de sandboxer vos agents IA.

Ce qu'il vous faut

  • Un Mac ARM (M1, M2, M3...)
  • macOS 13 Ventura minimum
  • Temps estimé : 5 minutes

Installation

Hop, on commence par installer Vibe. Plusieurs options s'offrent à vous :

curl -LO https://github.com/lynaghk/vibe/releases/download/latest/vibe-macos-arm64.zip

unzip vibe-macos-arm64.zip

sudo mv vibe /usr/local/bin

Et là, c'est prêt. C'est du Rust pur compilé avec le framework Virtualization.framework d'Apple, donc ça va viiiiite !

Et ce que vous pouvez voir au lancement de Vibe, c'est le mapping entre vos dossiers locaux liés à Claude, Codex et compagnie, et les dossiers qui sont dans la VM.

Premier lancement

Pour démarrer une VM, c'est aussi simple que ça :

./vibe

Oui, c'est tout. 10 secondes plus tard, vous avez un shell Linux avec un accès réseau et un partage automatique de vos dossiers. Notez jute que la première fois il faut une connexion réseau pour télécharger l'image de base de Debian. Après, tout est en local.

Le truc cool, c'est que Vibe utilise un système copy-on-write où chaque VM part d'une image de base commune et seules les modifications sont stockées. Comme ça même si vous lancez 10 VMs, ça bouffe pas votre SSD.

Bon ok, j'en ai lancé que 2 en vrai mais l'idée est là ^^

Configurer Claude ou Codex

Ensuite c'est simple, il suffit de lancer la commande Claude ou Codex directement dans le terminal que ça vous a créé, de les configurer comme si vous étiez sur votre ordinateur et puis c'est parti, vous pouvez les lancer avec le mode --yolo pour Codex ou avec --allow-dangerously-skip-permissions pour Claude.

Et c'est tout ! Si ça fait de la merde, ce sera dans la VM et vous ne risquerez rien ! Les fichiers sont bien sûr créés et dispo dans le répertoire dans lequel vous avez lancé vibe. Mais tout sera exécuté dans la VM donc y'a plus aucun risque.

Bref, si vous faites du vibe coding et que vous voulez pas finir avec un sudo rm -rf / généré par une IA un peu trop enthousiaste... bah voilà quoi. Le tout en moins de 1200 lignes de Rust, open source sous licence MIT.

Taaadaaaa ! À découvrir ici !

TwoFace - Quand les sandbox deviennent inutiles

Par : Korben
18 novembre 2025 à 11:23

TwoFace est un outil développé par Synacktiv qui permet de créer des binaires Linux ayant 2 comportements bien distincts. Un comportement parfaitement inoffensif qui s’active dans 99% des cas et un comportement malveillant qui ne se déclenche que sur une machine ciblée spécifiquement pour l’occasion.

Comme ça, votre sandbox verra toujours la version “propre” parce qu’elle n’aura pas le bon UUID de partition.

D’après la doc de Synacktiv, voici comment ça fonctionne : Vous avez deux binaires en fait… Y’en a un qui est inoffensif et un autre malveillant. TwoFace les fusionne alors en un seul exécutable. Ainsi, au moment du build, le binaire malveillant est chiffré avec une clé dérivée depuis l’UUID des partitions disque de la machine cible. Cet UUID est unique, difficile à deviner, et stable dans le temps ce qui est parfait pour identifier une machine spécifique.

Ensuite au lancement, quand le binaire s’exécute, il extrait l’UUID du disque de la machine. Pour ce faire, il utilise HKDF (Hash-based Key Derivation Function) pour générer une clé de déchiffrement depuis cet UUID et tente de déchiffrer le binaire malveillant caché. Si le déchiffrement réussit (parce que l’UUID match), il exécute le binaire malveillant. Par contre, si ça échoue (parce que l’UUID ne correspond pas), il exécute le binaire inoffensif.

Le projet est écrit en Rust et c’est open source ! Et c’est une belle démo (PoC) d’un problème que tous ceux qui font de l’analyse de binaires ont. En effet, d’ordinaire, pour révéler le vrai comportement d’un malware on l’exécute dans une sandbox et on peut ainsi observer en toute sécurité ce qu’il fait, les fichiers qu’il crées, les connexions réseau qu’il établit etc…

Mais avec TwoFace ça casse cette façon de faire. Et c’est pareil pour les antivirus qui verront toujours la version inoffensive tant que l’UUID ne correspond pas.

Techniquement, TwoFace utilise memfd_create() pour exécuter le binaire déchiffré en mémoire, sans toucher au disque, ce qui veut dire zéro trace sur le système de fichiers. Le binaire malveillant apparaît directement en RAM, s’exécute, puis disparaît. Et si vous utilisez io_uring pour l’écriture mémoire, il n’y a même pas de trace syscall visible via strace.

Et ça, c’est la version basique car le document de Synacktiv mentionne également d’autres techniques avancées possibles comme du déchiffrement dynamique page par page du binaire ELF, des mécanismes anti-debugging, des chained loaders multi-niveaux…etc…

Le parallèle avec la backdoor XZ Utils backdoor est très instructif car celle-ci a failli compromettre des millions de serveurs Linux parce qu’un seul mainteneur a poussé du code malveillant dans une lib compressée. Elle a alors été découverte parce qu’un dev a remarqué un ralentissement SSH bizarre et a creusé… Et TwoFace montre qu’on peut faire encore pire sans toucher à la supply chain.

Pas besoin de corrompre un mainteneur de projet, de pousser un commit suspect chez Github. Là suffit d’écrire du code parfaitement propre, de le compilez avec TwoFace pour une machine spécifique, et de le déployez. Le code source sera alors auditable ainsi que le binaire mais l’audit ne révèlera rien parce qu’il se fera dans un environnement qui n’aura pas le bon UUID.

Après, techniquement, une défense existe. Vous pouvez par exemple détecter les appels à memfd_create(), monitorer les exécutions en mémoire, tracer les déchiffrements crypto à la volée…etc., mais ça demande du monitoring profond, avec un coût performance non-négligeable. Et ça suppose aussi que vous savez ce que vous cherchez…

Bref, si ça vous intéresse, c’est dispo sur GitHub !

Al-khaser - L'outil qui fait transpirer votre solution de cybersécurité

Par : Korben
10 octobre 2025 à 12:22

Vous venez de claquer plusieurs milliers d’euros dans une solution antivirus dernier cri pour votre boîte car le commercial vous a convaincu avec du machine learning, de l’IA comportementale, du threat hunting prédictif et j’en passe…

Cool story ! Mais si je vous disais qu’un petit exécutable open source gratuit peut potentiellement passer à travers ? Ce programme s’appelle al-khaser et je vous assure qu’il va vous faire déchanter, car ce truc, c’est le détecteur de mensonges des solutions de cybersécurité.

Al-khaser est outil qui ne fait rien de méchant en soi… C’est ce qu’on appelle un PoC, un “proof of concept” avec de bonnes intentions car il rassemble dans un seul programme toutes les techniques que les vrais malwares utilisent pour se planquer tels que la détection de machines virtuelles, le contournement des débogueurs, l’échappement aux sandbox, et j’en passe.

Comme ça, si votre antivirus ne détecte pas al-khaser, il y a de bonnes chances qu’il rate aussi les vraies menaces qui utilisent les mêmes techniques.

Faut dire que les éditeurs d’antivirus et d’EDR adorent nous vendre leurs nouvelles fonctionnalités IA de fou alors que certaines de leurs solutions ne détectent même pas des techniques pourtant connues depuis longtemps.

Al-khaser met donc tout ça en lumière de façon assez brutale en enchaînant des dizaines de vérifications. Par exemple, il va regarder si votre processeur a vraiment le bon nombre de cœurs ou si c’est une simulation. Il va checker l’adresse MAC de votre carte réseau pour voir si elle correspond à un hyperviseur VMware ou VirtualBox. Il va mesurer le temps d’exécution de certaines opérations pour détecter si le système est accéléré artificiellement, comme dans une sandbox d’analyse. Il va même tester des API Windows classiques comme IsDebuggerPresent ou CheckRemoteDebuggerPresent pour voir si quelqu’un espionne son exécution.

Maintenant si vous voulez tester les protections anti-debug de votre système, vous tapez :

al-khaser.exe –check DEBUG –sleep 30

Oui si vous voulez voir si votre virtualisation VMware ou QEMU est bien masquée :

al-khaser.exe –check VMWARE –check QEMU

Bien sûr, ces techniques ne sortent pas de nulle part car elles sont documentées depuis des années notamment dans ce référentiel dont je vous déjà parlé .

Les équipes de pentest et les red teams adorent al-khaser car ça leur permet de montrer aux décideurs que leur gros investissement en cybersécurité n’est peut-être pas aussi solide qu’ils le pensaient. Vous lancez l’outil un vendredi après-midi dans un environnement de test, et vous voyez instantanément ce que votre EDR détecte ou pas.

Voilà, une fois encore, rassurez-vous, al-khaser ne fait rien de malveillant… Il ne vole pas de données, ne chiffre pas vos fichiers, ne lance pas de ransomware mais se contente juste de lever la main et de dire “hé ho, je suis là, regardez moi, je fais plein de des trucs louches !!”.

Bien sûr, ne lancez pas al-khaser sur n’importe quelle machine car c’est un outil de test qui doit rester dans un environnement contrôlé. Si vous le lancez sur le réseau de prod sans prévenir votre équipe sécu, vous allez déclencher des alertes partout et recevoir des appels pas très sympathiques. Et surtout, juridiquement, vous devez avoir l’autorisation du propriétaire de l’infrastructure, sinon, vous risquez de gros ennuis.

Ce projet est open source, écrit essentiellement en C++, et disponible sur GitHub . Y’a plus qu’à vous monter une VM isolée, récupérer al-khaser, et voir ce que ça donne.

❌
❌