if ( !emtpy($headline_subheadline ) ) : ?>
Le mécanisme de prévisualisation HTML de l’outil présentait une faille permettant à un code JavaScript malveillant d’accéder aux fichiers locaux et d’exfiltrer les informations d’identification du cloud.
endif; ?>
Selon une nouvelle découverte de Noma Security, le simple fait de demander à Claude Code d’Anthropic d’examiner un fichier HTML pourrait permettre aux attaquants d’accéder à la machine d’un développeur, aux informations d’identification cloud et à l’environnement de développement logiciel.
Les chercheurs de Noma ont découvert une vulnérabilité affectant l’application Claude Code Desktop d’Anthropic qui pourrait permettre à un code JavaScript malveillant intégré dans un fichier HTML de s’exécuter sans autre interaction de l’utilisateur, exposant potentiellement des fichiers hôtes sensibles. La faille, appelée SneakPeek, affectait spécifiquement le volet de prévisualisation automatisé de l’application, qui restitue les fichiers HTML générés ou modifiés par Claude.
« C’est un bon exemple de la manière dont les technologies émergentes remodèlent la surface d’attaque », a déclaré Ronald Lewis, responsable de la gouvernance de la cybersécurité chez Black Duck. « Les attaquants ciblent de plus en plus l’écosystème de l’IA, exploitant les relations de confiance implicites entre les modèles, les agents, les outils, les sources de données et les services connectés. »
Une fois le fichier rendu par l’application, le script pouvait lire les fichiers locaux et exfiltrer les données sensibles, notamment les informations d’identification AWS, les secrets GitHub et les clés privées SSH, vers un serveur distant.
La faille s’est vu attribuer un score CVSS de haute gravité de 8,7, alors qu’un identifiant CVE n’est pas encore disponible. Noma affirme qu’Anthropic a collaboré avec Noma Labs pendant le processus de divulgation et a entièrement résolu le problème.
Un seuil de 256 Ko permettait la fuite de fichiers locaux
Noma a retracé SneakPeek jusqu’à trois lacunes architecturales dans le mécanisme de prévisualisation de Claude Code Desktop, qui utilise un panneau de rendu Chromium basé sur Electron pour afficher le contenu HTML.
Le premier impliquait un seuil de taille de fichier qui modifiait la façon dont l’application traitait les documents HTML. Les fichiers de moins de 256 Ko ont été convertis en données codées en base64 : des URL avec une politique de sécurité du contenu (CSP) stricte qui bloquait l’exécution du script. Les fichiers dépassant ce seuil étaient plutôt écrits sur le disque et chargés directement en tant qu’URL « file:// », contournant les protections CSP appliquées aux fichiers plus petits.
Le deuxième problème était l’origine attribuée au contenu rendu. Le chargement des fichiers plus volumineux via file:// a permis au moteur de rendu d’aperçu d’accéder au système de fichiers local dans Chromium plutôt que de le confiner à une origine isolée et opaque, ont indiqué les chercheurs.
La troisième faiblesse était un filtre de requêtes inactif. Bien que l’application dispose d’un mécanisme destiné à bloquer l’accès à file: //, Noma a constaté que le filtre n’était pas actif lors du rendu de fichiers statiques, y compris lorsque les développeurs examinaient les rapports de tests de code local.
« S’appuyer sur des seuils basés sur la taille ou sur des filtres côté client pour les limites de sécurité est intrinsèquement fragile », a déclaré Lewis. « Les machines de développement détiennent des secrets opérationnels de grande valeur : clés privées SSH, informations d’identification AWS, configurations Kubernetes et jetons de session OAuth. »
Compromettre le poste de travail local d’un développeur est en fait une voie directe vers l’infrastructure cloud de l’entreprise, a-t-il averti.
Noma a découvert que le correctif initial d’Anthropic pouvait être contourné. « Le correctif initial empêchait le volet d’aperçu d’effectuer des demandes de lecture directe de fichiers à partir du contexte de la page principale, mais nous avons constaté qu’en déplaçant le code de lecture de fichiers dans un Web Worker, un fil d’arrière-plan que les navigateurs exécutent séparément de la page principale, les demandes provenaient d’un contexte que le correctif ne couvrait pas », a expliqué Ainhorn.
Les chercheurs ont signalé le contournement, ce qui a entraîné une correction architecturale plus approfondie avant que la vulnérabilité ne soit entièrement résolue.
Risque au-delà du modèle d’IA
Le script malveillant s’est exécuté dans le processus de rendu du volet d’aperçu, plutôt que comme une action effectuée par l’agent IA lui-même. Cela va à l’encontre de l’hypothèse selon laquelle les contrôles de sécurité destinés au modèle protègent tous les flux de travail de l’IA.
« Les protections étaient réelles, mais elles ne couvraient pas tous les chemins », a déclaré Ainhorn. « Les organisations doivent maintenir à jour les outils de codage de l’IA, cesser de laisser des informations d’identification de longue durée sur les machines des développeurs et utiliser des jetons limités et de courte durée lorsque cela est possible. Cela seul aurait limité ce que cet exploit pourrait récupérer. »
Selon Crystal Morin, stratège principale en cybersécurité de Sysdig, les journaux au niveau de l’agent ne capturent pas nécessairement l’exécution. Les lectures de fichiers et les connexions réseau sortantes seraient plutôt visibles au niveau de la couche d’exécution, où les défenseurs ont besoin d’une surveillance appropriée, a déclaré Morin. « Le point final est le point de départ des agents d’IA, mais leur rayon d’action s’étend jusqu’au cloud », a-t-elle ajouté, avertissant que le travail de routine avec les outils d’IA peut exposer les informations d’identification avec des conséquences bien au-delà du poste de travail.
