De nombreuses entreprises européennes dont en France Airbus, Dassault Systèmes, Orange et Renault craignent qu’un excès de réglementation sur l’IA ne fasse échouer les efforts visant à faire de l’Europe l’un des principaux acteurs de son développement. Et que cela leur demande aussi trop d’efforts.
Une proposition de loi dans les tuyaux depuis 2021 pour réglementer l’IA en Europe – et en cours de négociation depuis le 14 juin – est ciblée par de nombreuses critiques. En particulier des grandes entreprises privées européennes qui ont publié une lettre ouverte plaidant pour moins de restrictions et une approche moins bureaucratique. Des dirigeants de Siemens, Dassault, Heineken, Renault, Deutsche Telekom ou encore Airbus, soit au total 163 personnes, ont paraphé le document.
Les signataires ont exhorté l’UE à adopter une approche plus souple en matière de réglementation de l’IA, craignant que le projet de loi ne rende le continent moins compétitif dans ce domaine en plein essor. « Vouloir ancrer la réglementation de l’IA générative dans la loi et procéder à une logique de conformité rigide est une approche aussi bureaucratique qu’inefficace pour atteindre son objectif », peut-on lire dans la missive. « Dans un contexte où nous en savons très peu sur les risques réels, le modèle économique ou les applications de l’IA générative, le droit européen devrait se limiter à énoncer de grands principes dans le cadre d’une approche fondée sur les risques ».
Des coûts et de risques disproportionnés pointés du doigt
La lettre souligne l’importance de l’IA générative, la comparant à l’invention de la puce électronique ou de l’internet, et indique que la nécessité de se conformer à la loi pourrait entraîner la délocalisation hors d’Europe de grands innovateurs dans le domaine de l’IA. « Selon le projet de loi récemment adopté par le Parlement européen, les modèles de fondation, quels que soient leurs cas d’utilisation, seraient fortement réglementés, et les entreprises qui développent et mettent en œuvre de tels systèmes seraient confrontées à des coûts disproportionnés et à des risques de responsabilité disproportionnés », peut-on lire dans cet écrit.
La loi sur l’IA approuvée par le Parlement européen aura force de loi si elle est ratifiée par chaque pays de l’UE. Les dispositions comprennent une interdiction générale de l’utilisation de l’IA dans l’identification biométrique, une obligation d’étiquetage des contenus générés par l’IA et des mesures de protection contre l’IA et les contenus illégaux. La réglementation a été modifiée en avril afin de mieux encadrer l’IA générative, ce qui a suscité un débat sur les changements de dernière minute. En fin de compte, les législateurs sont parvenus à un consensus sur le fait que les grands modèles de langage tels que GPT doivent être réglementés afin de préserver les droits et les valeurs fondamentales de l’Union européenne, comme la liberté d’expression. Une disposition exigeant que tous les créateurs d’IA générative divulguent le matériel protégé par des droits d’auteur a également été incluse.
De nombreuses entreprises européennes dont en France Airbus, Dassault Systèmes, Orange et Renault craignent qu’un excès de réglementation sur l’IA ne fasse échouer les efforts visant à faire de l’Europe l’un des principaux acteurs de son développement. Et que cela leur demande aussi trop d’efforts.
Une proposition de loi dans les tuyaux depuis 2021 pour réglementer l’IA en Europe – et en cours de négociation depuis le 14 juin – est ciblée par de nombreuses critiques. En particulier des grandes entreprises privées européennes qui ont publié une lettre ouverte plaidant pour moins de restrictions et une approche moins bureaucratique. Des dirigeants de Siemens, Dassault, Heineken, Renault, Deutsche Telekom ou encore Airbus, soit au total 163 personnes, ont paraphé le document.
Les signataires ont exhorté l’UE à adopter une approche plus souple en matière de réglementation de l’IA, craignant que le projet de loi ne rende le continent moins compétitif dans ce domaine en plein essor. « Vouloir ancrer la réglementation de l’IA générative dans la loi et procéder à une logique de conformité rigide est une approche aussi bureaucratique qu’inefficace pour atteindre son objectif », peut-on lire dans la missive. « Dans un contexte où nous en savons très peu sur les risques réels, le modèle économique ou les applications de l’IA générative, le droit européen devrait se limiter à énoncer de grands principes dans le cadre d’une approche fondée sur les risques ».
Des coûts et de risques disproportionnés pointés du doigt
La lettre souligne l’importance de l’IA générative, la comparant à l’invention de la puce électronique ou de l’internet, et indique que la nécessité de se conformer à la loi pourrait entraîner la délocalisation hors d’Europe de grands innovateurs dans le domaine de l’IA. « Selon le projet de loi récemment adopté par le Parlement européen, les modèles de fondation, quels que soient leurs cas d’utilisation, seraient fortement réglementés, et les entreprises qui développent et mettent en œuvre de tels systèmes seraient confrontées à des coûts disproportionnés et à des risques de responsabilité disproportionnés », peut-on lire dans cet écrit.
La loi sur l’IA approuvée par le Parlement européen aura force de loi si elle est ratifiée par chaque pays de l’UE. Les dispositions comprennent une interdiction générale de l’utilisation de l’IA dans l’identification biométrique, une obligation d’étiquetage des contenus générés par l’IA et des mesures de protection contre l’IA et les contenus illégaux. La réglementation a été modifiée en avril afin de mieux encadrer l’IA générative, ce qui a suscité un débat sur les changements de dernière minute. En fin de compte, les législateurs sont parvenus à un consensus sur le fait que les grands modèles de langage tels que GPT doivent être réglementés afin de préserver les droits et les valeurs fondamentales de l’Union européenne, comme la liberté d’expression. Une disposition exigeant que tous les créateurs d’IA générative divulguent le matériel protégé par des droits d’auteur a également été incluse.
Une faille de sécurité frappant le registre npm compromet la fiabilité des paquets et ouvre la voie à l’exécution de scripts malveillants et à de la dissimulation de malwares dans les dépendances. Des attaques dites de confusion de fichiers manifest.
Utilisé pour automatiser l’installation, la mise à niveau et la configuration des paquets, le gestionnaire npm est à risque. Ce dernier présente en effet un bogue de conception que les attaquants pourraient exploiter pour dissimuler des dépendances et des scripts malveillants à l’intérieur de ses paquets. Le problème, appelé « confusion de manifest », provient du manque de cohérence entre les fichiers manifest qui accompagnent les paquets archivés et le fichier de métadonnées json inclus dans le paquet lui-même. Le bug a été révélé publiquement cette semaine par Darcy Clarke, un ancien responsable de l’ingénierie de l’équipe npm CLI. Ce dernier a quitté GitHub – qui possède npm – en décembre 2022 mais a déclaré que la société était au courant de ce problème depuis novembre dernier, et qu’il l’a notifié à nouveau en mars 2023. Après une recherche indépendante, il est arrivé à la conclusion que l’impact était plus important que ce que l’on pensait à l’origine.
Selon Darcy Clarke, la communauté part généralement du principe que les manifests publiés avec un paquet sur le registre npm correspondent au contenu du fichier de métadonnées package.json inclus dans le paquet lui-même, l’archive tarball téléchargée à partir du dépôt. Ce n’est pas le cas et les gestionnaires de paquets JavaScript côté client tels que npm – mais aussi les outils de sécurité qui analysent les paquets à partir des dépôts npm – ne valident pas correctement ces fichiers les uns par rapport aux autres. Cela signifie que les paquets peuvent avoir des dépendances cachées ou des scripts d’installation listés dans leurs fichiers package.json mais pas dans le fichier manifest séparé. Ces dépendances et ces scripts seront analysés et exécutés par des clients JavaScript tels que l’interface de ligne de commande (CLI) npm et d’autres, même s’ils ne sont pas répertoriés dans le manifest du paquet. « Il y a plusieurs façons dont ce bogue a un impact sur les consommateurs/utilisateurs finaux : Empoisonnement du cache (c’est-à-dire que le paquet sauvegardé peut ne pas correspondre au nom et à la spécification de version de ce paquet dans le registre/URI), installation de dépendances inconnues/non listées (tromper les outils de sécurité/audit) ; exécution de scripts inconnus/non listés (tromper les outils de sécurité/audit) ; attaque potentielle par rétrogradation (où la spécification de version sauvegardée dans les projets correspond à une version vulnérable non spécifiée du paquet) », a déclaré M. Clarke.
Une validation dans les mains des installateurs de paquets
À la base, ce problème est dû au fait qu’il n’existe pas de « source canonique de vérité » claire pour les métadonnées d’un paquet, comme le nom, la version, les dépendances, les scripts, la licence, etc. Ces éléments sont spécifiés dans le fichier package.json qui est inclus dans l’archive du paquet elle-même et qui prend en charge les valeurs de vérification de l’intégrité telles que les hachages cryptographiques. Cependant, certaines de ces données peuvent être spécifiées dans le fichier manifest du paquet lors de sa publication sur le registre npm et ce manifeste dicte les informations que le registre affichera. Par exemple, Darcy Clarke a créé un exemple de paquet dont le fichier package.json mentionne un autre paquet comme dépendance, mais lorsqu’il l’a publié, il n’a pas inclus la dépendance dans le manifest. En conséquence, l’entrée du paquet sur le référentiel npm.js liste le paquet avec 0 dépendance, parce que le registre utilise le manifest comme source unique de vérité.
Cependant, le registre lui-même ne valide pas que les informations du package.json qui correspondent à celles du manifest. Cette tâche est laissée au client qui installe le paquet. Mais il s’avère qu’ils n’effectuent pas vraiment cette validation non plus… Par exemple, la version 6 de npm (npm@6), livrée avec la version 14 du moteur d’exécution node.js (support à long terme), exécutera un script d’installation défini dans le fichier package.json même si le script n’est pas défini dans le manifest. Une dépendance listée dans package.json et absente du manifest ne sera ainsi pas déployée lors du première téléchargement et de la première installation de paquet. Toutefois, si celui-ci est mis en cache localement et installé ultérieurement à partir de la source locale avec les options de ligne de commande -prefer-offline et -no-package-lock, les dépendances cachées du fichier package.json seront installées. Npm version 9 (npm@9), la version stable actuelle de npm, installera de la même manière les dépendances référencées dans le package.json d’un paquet mis en cache lors de l’utilisation de la configuration -offline.
Yarn et pnpm aussi vulnérables
Les gestionnaires de paquets yarn et pnpm, qui sont des alternatives à npm, sont également vulnérables et exécuteront les scripts référencés dans le fichier package.json qui sont absents du manifest. Yarn préférera également la version du paquet définie dans package.json à celle-ci. Comme ces deux valeurs peuvent être différentes, cela ouvre la porte à une attaque par rétrogradation. Ces dernières sont dangereuses, car un paquet peut être remplacé par une version plus ancienne qui présente une vulnérabilité connue. Ces itérations présentant des failles ne manquent pas, même dans les projets activement maintenus. La semaine dernière, des chercheurs de Snyk et de Redhunt Labs ont publié les résultats d’un projet de recherche qui a consisté à analyser plus de 11 000 dépôts appartenant aux 1 000 premières entreprises sur GitHub. L’analyse a cherché des failles dans les dépendances listées dans ces projets couvrant plusieurs langages de programmation. Pour JavaScript (npm et yarn), l’équipe a extrait 1,9 million de dépendances et identifié environ 550 000 cas de trous de sécurité connus.
Darcy Clarke pense que ce problème relève de différentes catégories de failles. Il note qu’ « il y a une histoire qui repose fortement sur le client (aka le CLI de npm) pour faire le travail qui devrait être fait côté serveur ». Outre ces gestionnaires de paquets côté client, le problème touche également d’autres outils et registres de paquets tiers, y compris ceux axés sur la sécurité : Snyk, le miroir chinois NPM, le miroir CloudFlare npm CDN, le miroir UNPKG CDN, Skypack, JSPM, et même les dépôts locaux créés avec Artifactory de jFrog.
Pas de solution facile pour remédier à la vulnérabilité liée à la confusion des manifest
La résolution de ce problème et l’application soudaine de la validation n’est pas simple et pourrait prendre un certain temps jusqu’à ce que GitHub trouve une solution. Car il y a probablement de nombreux paquets qui présentent cette confusion, et ce n’est pas pour des raisons malveillantes. Darcy Clarke a noté que l’interface de programmation de npm elle-même provoque également de telles incohérences. Par exemple, lors de la publication d’un paquet via l’interface de commande npm où un fichier binding.gyp est situé à l’intérieur du projet, le client ajoutera une entrée au fichier manifest appelé : « node-gyp rebuild » scripts.install. Cette entrée ne sera pas présente dans le fichier package.json. « GitHub est logiquement dans une situation difficile », a déclaré le responsable. « Le fait que npmjs.com fonctionne de cette manière depuis plus de dix ans signifie que l’état actuel est assez codifié et susceptible de percer une défense de manière unique. Comme mentionné précédemment, l’interface de programmation npm elle-même repose sur ce comportement et il existe potentiellement d’autres utilisations non malveillantes dans la nature de ce comportement aujourd’hui ».
Les utilisateurs devraient contacter tous les auteurs connus d’outils qui s’appuient sur npm et leur demander de s’appuyer sur les informations du package.json plutôt que sur le manifest, à l’exception de la version et du nom qui peuvent être différents pour des raisons légitimes. Une autre option serait d’utiliser un proxy entre le client et le registre qui valide strictement les métadonnées des deux sources pour assurer la cohérence.
Dans le cadre de la cyberattaque de 2020, le responsable de la sécurité et le directeur financier de Solarwinds peuvent faire l’objet de poursuite par la SEC. Un avis qui provoque des remous au sein de la communauté cybersécurité.
Un avis qui a du mal à passer. Ainsi peut-on résumer le message de la SEC (Security and Exchange Commission) à destination de certains dirigeants de Solarwinds à la suite de la cyberattaque de 2020. En effet, le gendarme boursier a émis des avis Wells (une lettre adressée aux particuliers ou aux entreprises pour les alerter sur des violations potentielles des lois fédérales suite à l’enquête de la SEC et les mesures à prendre) qui prévoit la possibilité d’engager des poursuites contre les dirigeants de Solarwinds y compris le CFO (chief financial officer), Bart Kalsu et le CISO (chief information security officer), Tim Brown. Solarwinds essayer de temporiser en indiquant qu’un avis Wells « n’est ni une accusation formelle d’actes répréhensibles, ni la détermination finale que le destinataire a violé une loi ».
Cependant, si la SEC entame une action en justice et obtient gain de cause, cela pourrait avoir plusieurs conséquences. « Si elle devait autoriser une action contre l’une de ces personnes, elle pourrait demander une ordonnance leur interdisant à de violer à l’avenir les dispositions des lois fédérales sur la sécurité assujetties à ce type d’action, imposant des sanctions pécuniaires civiles et/ou une interdiction d’exercer en tant que dirigeant ou administrateur d’une société publique et prévoyant d’autres mesures équitables relevant de l’autorité de la SEC », a encore déclaré Solarwinds dans un document. Cette prise de position fait suite à un autre avis Wells contre la société elle-même où le régulateur alléguait « des violations de certaines dispositions de sécurité prévues par les lois fédérales américaines concernant nos informations sur la cybersécurité et nos déclarations publiques, ainsi que nos contrôles internes et nos contrôles et procédures de divulgation ». Dans un courriel, le CEO de SolarWinds, Sudhakar Ramakrishna, a expliqué à ses employés que, malgré les mesures extraordinaires prises pour coopérer avec la SEC et l’informer, l’agence continue de prendre des positions qui, selon SolarWinds, ne correspondent pas aux faits. « Nous continuerons à explorer d’autres voies pour résoudre cette affaire avant que la SEC ne prenne une décision finale. Et si la SEC décide finalement d’engager une action en justice, nous avons l’intention de nous défendre vigoureusement », a écrit le dirigeant dans le courriel, que l’entreprise a aussi envoyé à des médias.
Un débat sur la responsabilité des RSSI
Mais c’est le petit monde de la cybersécurité qui s’est le plus ému des derniers avis de la SEC ciblant le CISO. Une décision inhabituelle qui accroît la responsabilité des RSSI en cas d’incident. « Habituellement, un avis Wells vise un CEO ou un directeur financier en cas suspicion de combines à la Ponzi, de fraude comptable ou de manipulation du marché, mais il est peu probable que cela s’applique à un RSSI », déclare Jamil Farshchi, RSSI chez Equifax, dans un message publié sur LinkedIn, ajoutant que l’une des violations qu’un RSSI pourrait commettre ne concerne que la non-divulgation d’informations matérielles. « Par exemple, ne pas informer sur la gravité d’un incident (…) ou ne pas le faire en temps voulu, pourraient vraisemblablement entrer dans cette catégorie », poursuit-il. Agnidipta Sarkar, ancien RSSI du laboratoire pharmaceutique Biocon, estime que « même si cela ne signifie pas que le RSSI sera inculpé, c’est une nouvelle étape. À partir d’aujourd’hui, ils seront de plus en plus souvent tenus pour responsables des décisions qu’ils ont prises ou n’ont pas prises ».
« Cependant, attribuer la responsabilité uniquement au RSSI ou au directeur financier n’est pas toujours juste ou exact », indique pour sa part Ruby Mishra, RSSI chez KPMG Inde. « Pour gérer efficacement la cybersécurité, l’entreprise adopte une approche à plusieurs niveaux impliquant divers acteurs et départements. Tenir le RSSI ou le directeur financier pour seul responsable d’une cyberattaque peut faire oublier la responsabilité collective », glisse le responsable. Ce dernier fait remarquer qu’il est difficile pour les individus ou les entreprises de prévenir toutes les cyberattaques en raison des techniques sophistiquées et de l’évolution rapide du paysage des menaces. « Avant d’émettre l’avis, la SEC a peut-être pris en compte divers facteurs, y compris des circonstances spécifiques et des cadres juridiques, ou a peut-être démontré une négligence si le RSSI n’a pas mis en œuvre des mesures de sécurité adéquates, a négligé les politiques, les lignes directrices et les pratiques de la SEC, ou a ignoré des vulnérabilités connues » ajoute-t-il.
De son côté, SolarWinds a déclaré dans un communiqué envoyé aux médias que « Sunburst », nom donné par la firme à la violation, « était une attaque hautement sophistiquée et imprévisible qui, selon le gouvernement américain, a été menée par une superpuissance mondiale utilisant des techniques dans un type de menace que les experts en cybersécurité n’avaient jamais vu auparavant ». L’entreprise fait également remarquer que les poursuites judiciaires contre SolarWinds et ses employés pourraient avoir un effet « dissuasif » sur les divulgations de failles. « Le seul moyen de prévenir les attaques sophistiquées et généralisées par des Etats comme Sunburst est de mettre en place des partenariats public-privé avec le gouvernement », a déclaré la société.
Une enquête de Malwarebytes révèle que 81% des personnes sont préoccupées par les risques de sécurité posés par ChatGPT et l’IA générative, tandis que 7% seulement pensent qu’ils amélioreront la sécurité sur Internet.
Dans une enquête réalisée fin mai par Malwarebytes dans le cadre de laquelle le fournisseur californien de solutions de cybersécurité a recueilli du 29 au 31 mai 2023 un total de 1 449 réponses, 81 % des personnes interrogées (lecteurs de ses newsletters) se disent préoccupées par les risques de sécurité posés par ChatGPT et l’IA générative. Par ailleurs, 51 % d’entre elles se demandent si les outils d’IA peuvent améliorer la sécurité sur Internet et 63 % se méfient des informations fournies par ChatGPT. En outre, 52 % des personnes interrogées souhaitent une pause dans les développements de ChatGPT, le temps de la mise en place de réglementations. Seulement 7 % s’accordent pour dire que ChatGPT et d’autres outils d’IA peuvent améliorer la sécurité sur Internet.
En mars, un grand nombre de personnalités du monde de la technologie ont signé une lettre demandant à tous les laboratoires d’IA d’interrompre immédiatement, pendant six mois au moins, l’entrainement de systèmes d’IA plus puissants que GPT-4, le temps « de développer et de mettre en œuvre conjointement un ensemble de protocoles de sécurité communs pour la conception et le développement d’IA avancées, qui soient rigoureusement contrôlés et supervisés par des experts externes indépendants ». Le rapport cite les « risques profonds » posés par les « systèmes d’IA dotés d’une intelligence pouvant entrer en compétition avec l’intelligence humaine ».
Des informations issues des LLM pas toujours fiables
Les risques de sécurité potentiels relatifs à l’utilisation de l’IA générative par les entreprises sont bien documentés, tout comme l’impact connu des vulnérabilités sur les applications de grands modèles de langage (Large Language Model, LLM) qu’elles utilisent. Par ailleurs, les acteurs malveillants peuvent utiliser l’IA générative/les LLM pour renforcer leurs attaques. Malgré tout, certains cas d’usage de la technologie peuvent améliorer la cybersécurité, la détection et la réponse aux menaces, une tendance prédominante sur le marché de la cybersécurité, les fournisseurs s’appuyant sur l’IA générative et les LLM pour rendre leurs produits meilleurs, plus rapides et plus concis.
Dans l’enquête de Malwarebytes, seuls 12 % des répondants étaient d’accord avec l’affirmation « Les informations produites par ChatGPT sont exactes », et 55 % « pas d’accord », ce qui représente un écart important, selon le fournisseur. En outre, seulement 10 % des personnes interrogées étaient d’accord avec l’affirmation « J’ai confiance dans les informations produites par ChatGPT ». L’une des principales préoccupations concernant les données produites par les plateformes d’IA générative concerne le risque d’« hallucination » auquel exposent les modèles d’apprentissage machine.
Un risque de renforcer la crédibilité d’un faux positif
En effet, l’IA générative peut créer des URL, des références et même des bibliothèques de code et des fonctions qui n’ont aucune existence réelle. Ce qui devient un problème sérieux pour les entreprises si leur contenu est fortement utilisé pour prendre des décisions, en particulier celles relatives à la détection et à la réponse aux menaces. « Les LLM sont connus pour inventer des choses », a déclaré Rik Turner, analyste principal pour la cybersécurité chez Omdia. « Si l’IA dit n’importe quoi et qu’un ou une analyste peut facilement l’identifier comme tel, il ou elle pourra l’annuler et aider à mieux entrainer l’algorithme. Mais, que se passe-t-il si l’hallucination est très plausible et ressemble à la réalité ? En d’autres termes, le LLM pourrait-il renforcer la crédibilité d’un faux positif, avec des conséquences potentiellement désastreuses si, sur la base de ces données, l’analyste décide de mettre un système hors service ou de bloquer le compte d’un client pendant plusieurs heures ? », a-t-il demandé.
Akamai rapporte que près de 700 000 attaques et 27 000 de ses clients ont été scannés pour la vulnérabilité.
Selon l’alerte lancée par des chercheurs d’Akamai, une vulnérabilité corrigée ce mois-ci dans VMware Aria Operations for Networks, anciennement vRealize Network Insight, est maintenant exploitée en masse. Classée comme critique, la faille permet l’exécution de code à distance par injection de commande. « Les dernières données d’Akamai indiquent une analyse active des sites vulnérables à la faille référencée CVE-2023-20887, bien au-delà de ce qui avait été initialement signalé », ont déclaré des chercheurs d’Akamai par courriel. « Jusqu’à présent, nous avons comptabilité 695 072 attaques totales par 508 adresses IP uniques », ont-ils ajouté. Akamai a également observé que plus de 27 000 sites de ses clients étaient scannés.
D’autres failles dans VMware Aria Operations
VMware a publié le 7 juin des correctifs pour la vulnérabilité CVE-2023-20887, ainsi que des correctifs pour deux autres failles dans Aria Operations for Networks, dont l’une est également critique et peut conduire à l’exécution de code à distance. Alors que la vulnérabilité CVE-2023-20887 est une faille d’injection de commande, la seconde vulnérabilité, portant la référence CVE-2023-20888, résulte d’un problème de désérialisation. Dans les langages de programmation, la sérialisation est le processus de transformation des données en un flux d’octets pour la transmission à une autre application et la désérialisation est l’inverse de ce processus. Comme les routines de désérialisation impliquent l’analyse et l’interprétation de données contrôlées par l’utilisateur, elles sont à l’origine de nombreuses vulnérabilités. Les attaquants peuvent exploiter les vulnérabilités CVE-2023-20887 et CVE-2023-20888 s’ils disposent d’un accès réseau à l’application vulnérable. Cependant, cette dernière exige aussi que l’attaquant dispose des identifiants du « membre » pour effectuer l’attaque, ce qui complique son exploitation. La troisième vulnérabilité, référencée CVE-2023-20889, est une vulnérabilité d’injection de commande qui peut conduire à la divulgation d’informations sensibles. Elle est affectée du score 8.8 (élevé) sur l’échelle de gravité CVSS.
VMware conseille à ses clients de déployer les correctifs disponibles pour leur version respective dès que possible. Le fournisseur a mis à jour son avis le 13 juin pour avertir que le code d’exploitation pour la faille CVE-2023-20887 avait été publié, puis le 20 juin pour avertir qu’une exploitation active de cette faille avait lieu dans la nature. Selon Akamai et les données télémétriques du service de surveillance des attaques GreyNoise, le nombre d’attaques a augmenté depuis. L’agence américaine de cybersécurité et de sécurité des infrastructures (Cybersecurity and Infrastructure Security Agency, CISA) a ajouté la vulnérabilité référencée CVE-2023-20887 à son catalogue de vulnérabilités activement exploitées Actively Exploited Vulnerabilities, ainsi que les failles d’iOS exploitées dans le cadre de l’opération Triangulation et une faille d’injection de commande dans les dispositifs de stockage en réseau de Zyxel. Une faille de contournement de l’authentification dans VMware Tools (CVE-2023-20867) a également été ajoutée au catalogue après avoir été exploitée en tant que zero-day par un acteur chinois de cyberespionnage pour exécuter des commandes à l’intérieur de machines virtuelles invitées à partir d’un hôte compromis.
Plusieurs failles corrigées dans vCenter
La semaine dernière, VMware a par ailleurs publié des correctifs pour cinq vulnérabilités identifiées dans son produit vCenter Server qui permet aux administrateurs de gérer l’infrastructure virtuelle : CVE-2023-20892, CVE-2023-20893, CVE-2023-20894, CVE-2023-20895 et CVE-2023-20896. Classées avec un niveau de gravité de 8.1 (élevé) sur l’échelle CVSS, les quatre premières failles peuvent conduire à l’exécution de code arbitraire, à la corruption de la mémoire et au contournement de l’authentification. Quant à la cinquième faille, affectée du score de gravité de 5,9, son exploitation peut entraîner un déni de service. Même si aucun rapport n’indique que ces vulnérabilités ont été exploitées dans la nature, les attaquants ont ciblé des failles dans les produits VMware. Les utilisateurs de l’éditeur sont invités à déployer les correctifs disponibles dès que possible.
Les attaquants pourraient élever leurs privilèges sur les systèmes équipés des clients Cisco vulnérables et non corrigés, et en prendre éventuellement le contrôle total.
La semaine dernière, un exploit, facile à mettre en œuvre, a été rendu public pour une vulnérabilité corrigée affectant les applications Cisco AnyConnect Secure Mobility Client et Secure Client pour Windows, largement utilisées. Les attaquants pourraient tirer parti de cet exploit pour élever leurs privilèges sur le système d’une victime et en prendre le contrôle total. Connue sous le nom d’AnyConnect Secure Mobility Client avant la version 5.0, l’application Secure Client pour Windows s’intègre à plusieurs plateformes et technologies de sécurité et de gestion des points terminaux de l’équipementier, notamment la plateforme AnyConnect VPN et Zero-Trust Network Access (ZTNA), très prisée par les entreprises. Cette popularité du logiciel en a déjà fait une cible pour les attaquants. En octobre 2022, Cisco a mis à jour ses avis concernant deux vulnérabilités d’escalade de privilèges, initialement corrigées dans le client AnyConnect en 2020, pour alerter les clients sur leur exploitation dans la nature. Au même moment, l’agence américaine de cybersécurité et de sécurité des infrastructures (Cybersecurity and Infrastructure Security Agency, CISA) avait ajouté les failles CVE-2020-3433 et CVE-2020-3153 à son catalogue de vulnérabilités connues et exploitées, en demandant à toutes les agences gouvernementales de les corriger dans les plus brefs délais.
Les vulnérabilités d’escalade des privilèges locaux ne sont pas considérées comme très critiques car il faut que l’attaquant dispose déjà d’un certain accès pour exécuter du code sur le système d’exploitation. Cela ne signifie pas pour autant qu’elles ne sont pas sérieuses ou utiles, en particulier dans le cadre d’un mouvement latéral. Généralement, les employés qui utilisent le client AnyConnect sur leurs ordinateurs professionnels pour accéder au réseau de l’entreprise par VPN n’ont pas de privilèges d’administrateur sur leurs systèmes. Si les attaquants parviennent à inciter un utilisateur à exécuter un programme malveillant, ce code s’exécutera avec leurs privilèges limités. Cela peut suffire pour voler des données de base dans les applications de l’utilisateur, mais ne permet pas de mener des attaques plus sophistiquées comme le dumping d’identifiants locales stockées dans Windows, qui pourraient permettre à l’utilisateur d’accéder à d’autres systèmes. Or c’est là que les failles d’escalade des privilèges locaux peuvent devenir intéressantes.
L’exploit CVE-2023-20178
Répertoriée sous la référence CVE-2023-20178, la vulnérabilité d’escalade des privilèges corrigée par Cisco au début du mois se situe dans le mécanisme de mise à jour d’AnyConnect Secure Mobility Client et de Secure Client for Windows. Comme l’explique le chercheur Filip Dragovic, qui a trouvé et signalé la faille à Cisco, dans son exploit de preuve de concept posté sur GitHub, chaque fois qu’un utilisateur établit une connexion VPN, le logiciel client exécute un fichier appelé vpndownloader.exe. Ce processus crée un répertoire dans le dossier c:³windows³temp avec les autorisations par défaut et vérifie s’il contient des fichiers, provenant par exemple d’une mise à jour précédente. Si des fichiers sont trouvés, il les supprime, mais cette action est effectuée avec le compte NT AuthoritySYSTEM, c’est-à-dire le compte ayant le plus de privilèges sur les systèmes Windows. Les attaquants peuvent facilement exploiter cette action en utilisant des liens symboliques (raccourcis) vers d’autres fichiers qu’ils créent, ce qui entraîne un problème de suppression de fichier arbitraire, la suppression de fichier se transformant en exécution de fichier. Cette action est possible, en abusant d’une fonctionnalité peu connue du service Windows Installer.
En mars 2022, les chercheurs de la Zero Day Initiative de Trend Micro ont décrit cette technique en détail qu’ils ont attribuée à un chercheur nommé Abdelhamid Naceri. C’est ce même chercheur qui avait découvert et signalé une vulnérabilité différente dans le service Windows User Profile Service qui conduisait de la même manière à la suppression arbitraire de fichiers avec les privilèges SYSTEM. « Cet exploit est largement applicable dans les cas où une primitive supprime, déplace ou renomme un dossier vide arbitraire dans le contexte du SYSTEM ou d’un administrateur », avaient déclaré à l’époque les chercheurs de Trend Micro. Dans la mise à jour de son avis sur la vulnérabilité CVE-2023-20178, Cisco indique aux utilisateurs qu’un programme d’exploitation public est désormais disponible. L’entreprise conseille vivement aux clients de mettre à niveau AnyConnect Secure Mobility Client pour Windows vers la version 4.10MR7 (4.10.07061) ou une version ultérieure, et Secure Client pour Windows vers la version 5.0MR2 (5.0.02075) ou une version ultérieure.
En proposant son index Defense Readiness, RangeForce propose d’évaluer la capacité d’une entreprise à répondre aux cyberattaques. Pour développer son offre, l’éditeur s’est notamment appuyé sur une collaboration avec le Département américain de la Défense et l’OTAN.
La société RangeForce, spécialisée dans l’amélioration de la cyberdéfense, a annoncé le lancement de l’indice Defense Readiness Index (DRI). L’outil doit permettre aux entreprises de mesurer et d’améliorer leurs capacités en matière de cybersécurité. « Intégré à la plateforme Threat Centric de RangeForce et mis en correspondance avec les frameworks ATT&CK et D3FEND de MITRE, l’indice DRI évalue l’état de préparation d’une entreprise à répondre aux cyberattaques », a indiqué l’entreprise. Le DRI vise aussi à améliorer les compétences en matière de cybersécurité en s’appuyant sur les formations du Département de la Défense des États-Unis et de l’OTAN afin d’aider les équipes à mieux se préparer aux menaces.
Beaucoup d’entreprises ne disposent pas des ressources nécessaires pour se préparer efficacement à la cybersécurité. Le dernier indice Cisco Cybersecurity Readiness Index, qui classe les entreprises selon quatre niveaux de préparation à la cybersécurité (débutant, en formation, en évolution et mature), a révélé que plus de la moitié des entreprises se trouvent dans la catégorie « débutant » ou « en formation », et que seulement 15 % d’entre elles se trouvent dans la catégorie « mature ». La gestion des identités est considérée comme le domaine le plus critique, 58 % des entreprises se situant dans la catégorie « en formation » ou « débutant », tandis que 56 % des entreprises se situent au bas de l’échelle en matière de protection des réseaux.
Un indice sur une échelle de 1 à 5
« En fonction des faiblesses dans les capacités de cybersécurité d’une entreprise, l’indice DRI évalue les lacunes en matière de compétences et fait des recommandations stratégiques pour les combler », a déclaré RangeForce. Par ailleurs, les mesures objectives de l’indice donnent aux cadres dirigeants une visibilité sur l’état de préparation de leurs équipes de cybersécurité. « Le DRI affecte les entreprises d’un score de 1 à 5 en fonction d’un ensemble de contrôles et de pratiques propres afin d’offrir une visibilité sur la posture et la compétence des équipes pour défendre l’entreprise contre les cyberattaques », a encore déclaré RangeForce.
De plus, l’indice révèle les compétences effectives d’une équipe en fonction de ses capacités à détecter et à bloquer les menaces, sa capacité à collaborer sur les enquêtes, ses lacunes et les coûts associés. Une feuille de route indique aux entreprises quelles compétences renforcer en priorité pour passer au niveau supérieur (ou rester au même niveau selon l’évolution du paysage des menaces), et aide les entreprises à mesurer les progrès accomplis à mesure de l’amélioration des mécanismes d’évaluation et de compte rendu.
Plus de 1 000 modules de formations à la demande en renfort
L’indice DRI s’appuie sur une collaboration avec le Département américain de la Défense (Department of Defense, DoD) et l’OTAN. « Ce dernier organise les plus grands exercices internationaux de cybersécurité au monde et se défend contre les attaques d’États-nations », a déclaré Taavi Must, cofondateur et CEO de RangeForce. « Mais nous avons constaté qu’en matière de défense, même leurs équipes devaient s’entraîner à utiliser de vrais outils, en temps réel, dans des conditions stressantes. Notre formation personnalisée a été conçue pour fournir une visibilité sur les lacunes en matière de compétences et identifier les domaines à améliorer. L’extension de notre plateforme et le lancement de RangeForce étend ces avantages à tout le monde », a ajouté Taavi Must.
« Sur la base des résultats de l’indice Defense Readiness Index, les équipes reçoivent un plan de formation personnalisé élaboré à partir de la bibliothèque de RangeForce, qui compte plus de 1 000 modules de formation à la demande », a expliqué pour sa part Tanner Howell, directeur mondial de l’ingénierie des solutions chez RangeForce. « Imaginons par exemple qu’une entreprise vise le niveau 4 du DRI, si à l’issue de l’exercice, son équipe n’est pas en mesure d’endiguer correctement le malware pour atténuer la menace, la plateforme RangeForce lui proposera un plan de formation avec des modules spécifiquement axés sur les techniques de remédiation des logiciels malveillants », a ajouté le responsable.
Après analyse d’un échantillon de 1% des dépôts GitHub, AquaSec a découvert qu’environ 37 000 d’entre eux sont vulnérables au repo jacking, une technique de piratage via le renommage des référentiels. Des dépôts comme ceux de Google et de Lyft sont concernés.
Les référentiels déposés sur les sites de partage de code sont une mine pour les cybercriminels en utilisant la technique de piratage dit de repo jacking. Des millions de dépôts GitHub sont potentiellement vulnérables et ouvre la voie aux attaquants afin d’exécuter du code sur les environnements internes des entreprises ou ceux de leurs clients. Tel est le constat de l’éditeur AquaSec après avoir analysé un échantillon d’1,25 million de dépôts GitHub et a constaté qu’environ 3% d’entre eux étaient vulnérables, y compris des dépôts appartenant à des entreprises telles que Google et Lyft.
Sur GitHub, les entreprises ont des noms d’utilisateur et de dépôt. En cas de changement de direction ou de marque, la société peut modifier ces noms. Cela crée une redirection pour éviter de briser les dépendances nécessaires à certains projets. Cependant, si quelqu’un enregistre l’ancien nom, cette redirection devient invalide. Un cybercriminel peut alors acquérir l’ancien nom du dépôt pour créer des dépendances malveillantes, cela s’appelle le repo jacking. GitHub a mis en place certaines restrictions pour empêcher l’attaquant d’ouvrir l’ancien nom du dépôt. « Cependant, elles ne s’appliquent qu’aux dépôts populaires qui étaient populaires avant le changement de nom, et les chercheurs ont récemment trouvé de nombreux moyens de contourner ces restrictions, donnant la capacité aux attaquants d’ouvrir tous les dépôts qu’ils souhaitent », a expliqué AquaSec.
Des risques d’exploits bien réels
Le fournisseur a téléchargé tous les journaux de GHTorrent du dépôt GitHub pour le mois de juin 2019 et a compilé une liste de 125 millions de noms de référentiels uniques. Ils ont ensuite échantillonné 1% (1,25 million de noms de dépôts) et vérifié chacun d’entre eux pour voir s’il était vulnérable au repo jacking. « Nous avons découvert que 36 983 dépôts l’étaient ! Cela représente un taux de réussite de 2,95 % », a déclaré AquaSec. GHTorrent est un site web qui fournit un historique complet des dépôts GitHub.
La société a constaté que des entreprises, dont Google et Lyft, contenaient des dépôts sensibles et a expliqué l’exploitation possible dans leurs cas. Pour Google, AquaSec a trouvé un fichier readme contenant des instructions sur la construction d’un projet appelé Mathsteps pointant vers un dépôt GitHub appartenant à Socratic, une société que Google a acquise en 2018 et qui n’existe plus. En utilisant la vulnérabilité, un attaquant peut cloner ce dépôt pour casser la redirection. Cela peut conduire les utilisateurs à accéder à un fichier contenant un code malveillant que l’attaquant a inséré. La société de cybersécurité a également observé que les instructions comprenaient une commande d’installation pour la dépendance. Le code de l’attaquant peut exécuter un code arbitraire sur les terminaux des utilisateurs qui ne se doutent de rien. Pour Lyft, AquaSec a trouvé un script d’installation sur le référentiel de l’entreprise qui récupère une archive ZIP d’un autre référentiel, qui était vulnérable au repo jacking. Cela signifie que les attaquants pouvaient injecter leur code malveillant automatiquement dans n’importe quel script d’installation de Lyft. Google et Lyft ont tous deux corrigé le problème.
Un nombre d’entreprises exposées sans doute plus élevé
AquaSec conseille aux entreprises de vérifier régulièrement leurs dépôts pour tout lien qui pourrait récupérer des ressources à partir de répertoires GitHub externes, car les références à des projets tels que le module Go peuvent changer de nom à tout moment. « Si vous changez le nom de votre société, assurez-vous que vous possédez toujours le nom précédent, même en tant que placeholder, afin d’empêcher les attaquants de le créer », prévient AquaSec. Les chercheurs préviennent que de nombreuses autres organisations qu’ils n’ont pas analysées pourraient également être touchées. « Il est important de noter que notre analyse ne couvre qu’une partie des données disponibles, ce qui signifie qu’il y a beaucoup plus d’entreprises vulnérables, y compris la vôtre », a déclaré AquaSec.
Pour garantir ses intérêts technologiques et protéger ses membres contre les interférences extérieures incluant aussi bien l’espionnage industriel que les attaques d’infrastructures, l’Union européenne enclenche un projet stratégique.
L’UE envisage d’imposer des contrôles à l’exportation sur les technologies critiques et protéger contre les risques pouvant affecter ses chaînes d’approvisionnement, qu’il s’agisse d’espionnage industriel, de problèmes de sécurité énergétique ou d’attaques d’infrastructures. Bien qu’elle ne nomme pas explicitement ce pays, cette stratégie est largement motivée par les menaces potentielles posées par la Chine. Les commentaires de Margrethe Vestager, commissaire à la concurrence de la Commission européenne, pointent assez clairement vers la Chine comme menace pour la sécurité technologique et la propriété intellectuelle de l’Europe. « Nous concevons cette stratégie de manière à ce qu’elle ne tienne pas compte des pays », a déclaré Margrethe Vestager lors d’une conférence de presse tenue mardi à Bruxelles. « Cela dit, nous nous appuierons sur un filtre géopolitique pour évaluer les risques. Nous ne pouvons pas traiter une dépendance d’approvisionnement vis-à-vis d’un rival systémique de la même manière que nous le ferions vis-à-vis d’un allié », a-t-elle ajouté.
Ce projet met en évidence quatre grandes catégories de risques : les chaînes d’approvisionnement, les infrastructures critiques, la sécurité technologique et la coercition économique. Les risques liés à la chaîne d’approvisionnement, qui incluent la sécurité énergétique, couvrent les risques de flambée des prix et d’indisponibilité des composants essentiels. La sécurité des infrastructures couvre le câblage sous-marin, les oléoducs et les gazoducs, ainsi que d’autres éléments économiques importants. La sécurité technologique vise à empêcher que des technologies particulièrement avancées ne tombent entre de mauvaises mains, en mentionnant spécifiquement l’informatique quantique, les semi-conducteurs avancés et l’intelligence artificielle. Enfin, la coercition économique prend en compte la possibilité que des pays extérieurs imposent des changements de politique en fonction de la dépendance d’un État membre à leur égard. Pour faire face à ces risques, le projet se concentre sur la promotion de la compétitivité européenne, la protection de la sécurité économique et le partenariat avec les pays extérieurs. Des mesures similaires aux lois américaines Chips et Science Act – l’UE a sa propre loi sur les microprocesseurs – ont déjà été prises, ce qui contribue à promouvoir plusieurs de ces objectifs en localisant la capacité de production de semi-conducteurs à l’intérieur des frontières de l’Union.
Un plan de surveillance aussi dans les réseaux 5G
Cette annonce suit de près une annonce similaire concernant les réseaux 5G. Dans un discours prononcé la semaine dernière, Thierry Breton, commissaire chargé du marché intérieur à la Commission européenne, a exposé les restrictions sévères imposées à l’utilisation d’équipements provenant de « fournisseurs à haut risque » dans les nœuds des réseaux centraux et d’accès radio, en citant spécifiquement Huawei et ZTE. « La Commission appliquera les principes de la boîte à outils de la 5G à ses propres achats de services de télécommunications, afin d’éviter toute exposition à Huawei et ZTE », a déclaré M. Breton. « Nous ne pouvons pas nous permettre de maintenir des dépendances critiques qui pourraient devenir une « arme » contre nos intérêts », a-t-il ajouté. Selon Mme Vestager, la Commission proposera une liste de technologies à double usage pour l’évaluation des risques qui pourrait être adoptée par le Conseil européen – une composante de la branche exécutive de l’UE – d’ici septembre 2023. Cela signifie probablement que les règles définitives seront mises en place l’année prochaine.