if ( !emtpy($headline_subheadline ) ) : ?>
L’analyste affirme que la description par OpenAI des agents comme étant « bénins » peut constituer une menace plus grande que l’attaque elle-même, générant une lassitude face aux alertes de l’IA du SOC.
endif; ?>
Un essaim de centaines d’agents OpenAI a téléchargé des « packages malveillants » sur RubyGems et a tenté de voler des clés API, a révélé vendredi le service d’hébergement de gemmes de la communauté Ruby.
OpenAI a confirmé une partie de la divulgation en déclarant : « nos agents ont utilisé la plate-forme RubyGems pour accéder à Internet afin d’effectuer des tâches inoffensives et de récupérer des informations publiques. Nous continuerons à enquêter dans le cadre de notre examen plus large de l’activité des agents pendant la formation et l’évaluation. »
Les objectifs des agents n’étaient pas clairs, ni s’ils se livraient à des activités d’essaimage à des fins de recherche, ni même s’ils avaient été explicitement envoyés par le personnel d’OpenAI, mais une analyse publiée par RubyGems suggère fortement une intention malveillante.
« Une fois que les IA ont obtenu un RCE arbitraire sur l’environnement de construction, elles utilisaient parfois l’environnement de construction pour tenter de voler les clés API d’autres utilisateurs, même si nous ne savons pas si elles ont réussi ou non », indique le message de RubyGems. « Les agents considéraient clairement ce qu’ils faisaient comme du piratage. Les agents utilisaient des noms de fichiers comme hack(.)rb, evil(.)rb, inject(.)rb, exploit(.)rb et ssrf(.)rb. SSRF signifie ‘Server-Side Request Forgery’, un type de vulnérabilité de sécurité. Ils ont également surnommé les paquets des titres ostentatoires comme pwnp999, exfiltestwand3, hacksvn1778554764 et lambproxyhackabcxyz Des commentaires tels que « # sonde malveillante » ou « #hack » sont répandus dans toute la campagne. »
Le message indiquait également que les agents avaient tenté de tromper les systèmes défensifs.
« À certains moments, les agents ont tenté d’être discrets. Nous avons trouvé plusieurs paquets qui se désarmeraient eux-mêmes pour cacher leur charge utile dans la prochaine version », indique le message. « Ils ont téléchargé un package avec le commentaire ‘#désactiver le mal dans la prochaine version et modifier la version’, qui, après exécution, modifierait le package pour supprimer le code malveillant initialement inséré. »
OpenAI devrait être responsable
Les analystes et les consultants ont déclaré que l’attaque était préoccupante car si de tels efforts se produisaient assez souvent, cela pourrait ralentir les réponses du centre d’opérations de sécurité (SOC).
Nader Henein, analyste vice-président de Gartner, s’est dit très préoccupé par la tendance à venir des essaims de robots.
« Ce que nous savons, c’est que c’est le genre d’attaque standard, désormais renforcée par l’IA, qui deviendra monnaie courante au cours des prochains mois », a déclaré Henein. « Il s’agit moins d’un agent malveillant que d’un attaquant, utilisant potentiellement des informations d’identification compromises et militarisant un essaim d’agents, de la même manière que les attaquants ont utilisé des points de terminaison compromis pour lancer des attaques DDoS pendant la majeure partie de la dernière décennie. La différence ici est le fait qu’il ne s’agit pas de robots compromis individuellement. Les garde-fous d’OpenAI n’auraient pas dû permettre que cela se produise. «
Frank Dickson, analyste principal chez Dickson Research, a ajouté : « OpenAI doit être tenu responsable. Ils semblent vouloir créer le « monstre du Dr Frankenstein », mais ne semblent pas vouloir accepter la responsabilité des résultats. OpenAI n’a pas nié que ses agents ont utilisé RubyGems. Il a contesté le mot « malveillant » et qualifié l’activité de « bénigne », tout en reconnaissant séparément que, au cours de la même période de semaines, ses agents sont passés au niveau d’administrateur de cluster. accès à Hugging Face et comptes compromis sur quatre autres services tiers. Ces deux caractérisations sont difficiles à concilier. Le comportement est toujours inacceptable.
Cependant, Erik Avakian, conseiller technique chez Info-Tech Research Group, a souligné qu’OpenAI n’a pas nécessairement lancé ces agents avec des instructions explicites. Les agents auraient pu facilement tracer seuls cette voie destructrice.
Les agents OpenAI « auraient tout à fait pu agir de manière autonome. Nous avons déjà vu que des agents capables peuvent suivre diverses voies inattendues pour accomplir une tâche lorsqu’ils disposent de suffisamment d’autonomie et d’accès », a-t-il déclaré. « Un humain peut avoir autorisé l’évaluation ou donné aux agents l’accès à des outils, mais cela ne signifie pas qu’un humain a approuvé chaque action qu’ils ont entreprise par la suite. »
Pourrait retarder les réponses du SOC
Dickson a ajouté qu’il craint que le risque ultime en matière de cybersécurité soit que les employés du SOC soient témoins d’un si grand nombre de ces attaques qu’ils commencent à ressentir une lassitude face aux alertes.
« Si le fournisseur dont les agents ont fait cela est celui qui déclasse le langage, un analyste SOC lisant les gros titres au lieu du rapport sous-jacent a toutes les raisons de ne pas réagir », a déclaré Dickson. « Les opérations de sécurité ne sont pas adaptées si elles partent du principe qu’une étiquette d’agent IA rend une intrusion moins réelle. Une clé API volée ou un chemin d’exécution de code à distance se comporte de la même manière, que l’acteur soit une équipe de ransomware ou un modèle non supervisé poursuivant un signal de récompense. «
Mike Wilkes, RSSI d’entreprise chez Aikido Security, a également noté que le fait que les agents se soient identifiés comme OpenAI ne devrait rien signifier, car tous les agents peuvent prétendre de manière convaincante qu’ils représentent n’importe qui, surtout s’ils pensent que cela ralentira une réponse, même pour une brève période.
« Une chaîne User-Agent est un badge écrit par le visiteur, pas un passeport », a-t-il déclaré. « Si les outils SOC commencent à supprimer les alertes parce que le trafic prétend être un agent OpenAI, Anthropic, Google ou autre IA, les attaquants adopteront ces identités immédiatement s’ils ne l’ont pas déjà fait. »
Ainsi, a-t-il déclaré, « si un chercheur ou un employé humain délègue son autorité à un agent autonome, il devrait y avoir une chaîne vérifiable indiquant qui a délégué cette autorité, quelle organisation il représente, quel agent a été autorisé, quelle portée il a été accordée et pour quelle période de temps. »
Planifiez des attaques similaires
Le consultant Brian Levine, directeur exécutif de FormerGov, a encouragé les RSSI à anticiper davantage d’attaques de ce type et à planifier en conséquence.
« Les organisations qui dépendent de l’open source, c’est-à-dire presque toutes, devraient considérer que les registres sont un champ de bataille actif (et devraient) effectuer une rotation et une portée strictes des clés API, surveiller la publication anormale de packages et l’accès aux informations d’identification, et épingler et vérifier les dépendances plutôt que de faire confiance à un nom », a-t-il déclaré. « L’économie a changé. L’automatisation permet à un attaquant d’essayer des milliers de variantes à moindre coût, de sorte que les défenseurs doivent réduire au maximum les bénéfices de chaque succès. »
Justin Greis, PDG du cabinet de conseil Acceligence, est du même avis.
« Si les activités légitimes de recherche en IA génèrent de plus en plus de comportements qui ressemblent à une analyse, une exploitation, un accès aux informations d’identification ou une persistance hostiles, les équipes SOC peuvent être conditionnées à traiter ces signaux comme du bruit », a déclaré Greis. « Les attaquants comprendront cela très rapidement. La phrase dangereuse devient « ce n’est probablement qu’un agent d’IA ». »
