Over 10 years we help companies reach their financial and branding goals. Engitech is a values-driven technology agency dedicated.

Gallery

Contacts

411 University St, Seattle, USA

engitech@oceanthemes.net

+1 -800-456-478-23

Sécurité informatique

Une faille dans le serveur MCP d’Asana expose des données

Des chercheurs ont découvert une faille dans le serveur MCP d’Asana qui peut entraîner une fuite de données. Une affaire qui montre que le protocole dans le domaine de l’IA est toujours en développement.
Si l’interopérabilité est essentiel pour le développement de l’IA, elle ne doit pas de faire sans une sécurité renforcée. Dernier exemple en date Asana. Ce dernier, qui édite une plateforme SaaS de gestion des tâches, a mis hors ligne temporairement son serveur MCP (Model context protocol). En effet, des chercheurs du fournisseur de sécurité Upguard ont découvert début juin une faille qui « aurait potentiellement exposée certaines informations des domaines Asana à d’autres utilisateurs MCP, au sein des projets, des équipes, des tâches et d’autres objets Asana liés aux autorisations de l’utilisateur MCP ».
Selon Upguard, « rien n’indique que des attaquants aient exploité le bug ou que d’autres utilisateurs aient réellement consulté les informations accessibles via le bug MCP. De son côté, Asana affirme que la vulnérabilité ne résulte pas d’un piratage ou d’une activité malveillante sur ses systèmes. Notre confrère CSO a contacté l’entreprise pour un commentaire, mais aucune réponse n’a été apportée pour le moment.
Un outil beta expérimental
Pour mémoire, MCP est un protocole créé par Anthropic et rendu open source en novembre dernier. L’entreprise le décrit comme « une nouvelle norme pour connecter les assistants IA aux systèmes où résident les données, notamment les référentiels de contenu, les outils métiers et les environnements de développement. Son objectif est d’aider les modèles de pointe à produire des réponses plus performantes et plus pertinentes.» Les développeurs peuvent soit exposer leurs données via les serveurs MCP, explique Anthropic, soit créer des applications d’IA (clients MCP) qui se connectent à ces serveurs. L’idée est qu’au lieu de maintenir des connecteurs distincts pour chaque source de données, les développeurs peuvent désormais développer leurs applications à partir d’un protocole standard.
Reste que MCP est encore en phase de développement. D’ailleurs, le serveur MCP d’Asana a été publié le 1er mai dernier où une page web le présentait comme un « outil bêta expérimental ».Il était donc possible de « rencontrer des bugs, des erreurs ou des résultats inattendus » peut-on lire sur le site. Pour Kellman Meghu, architecte principal en sécurité chez DeepCove Cybersecurity, cabinet de conseil canadien, la faille découverte n’est pas une surprise, « c’est un problème courant avec les serveurs MCP, c’est pourquoi nous les évitons. Tous les MCP présentent ce problème.» Il ajoute que les RSSI se servant de ces outils doivent limiter les données auxquelles ils peuvent accéder jusqu’à ce que les contrôles de cybersécurité soient renforcés.
Des serveurs MCP encore en phase de développement
Il observe que ces protocoles d’interopérabilité sont « en réalité des connexions serveur-TCP durables ». Le spécialiste privilégie une solution de connexion utilisant le modèle RAG (retrieval augmentationd generation) avec un appel API authentifiable pour des raisons de sécurité. Entre autres avantages, le RAG peut être configuré pour rechercher uniquement les données approuvées et non les informations utilisées en formation, susceptibles d’inclure des informations sensibles. « C’est là que les leçons que nous avons apprises en matière de segmentation [des données] et de gestion des API directes s’appliquent [aux systèmes d’IA] », a-t-il déclaré. « Mais ils ont abandonné cette approche et opté pour des connexions TCP à longue durée de vie, difficilement supervisables. Lorsqu’une fuite de données se produit, il est déjà trop tard.»
Selon son interface, un serveur MCP peut constituer un « vecteur d’attaque massif et massif », a expliqué Kellman Meghu. Par exemple, si le serveur MCP est connecté à une plateforme SIEM (surveillance des informations et des événements de sécurité) pour l’analyse des données de logs, un acteur malveillant pourrait tenter d’accéder à ce serveur pour collecter des données. La grande question pour les RSSI selon lui est « où placer le serveur MCP ? ». Difficile trouver une réponse, « je pense que comme pour tous les nouveaux protocoles, il est trop tôt pour le mettre en production », glisse l’architecte en sécurité. Tout en reconnaissant, « ils ont fait ça à la va-vite. Je pense qu’il y a de meilleures façons de faire, mais nous n’en avons pas encore trouvées ». Et d’évoquer « Pourquoi ne pas s’appuyer sur des protocoles connus comme JSON et RestAPI ? Pourquoi fallait-il créer un service spécifique ? Le contrôle d’accès n’était-il pas intégré au protocole ? ». Il se veut néanmoins optimiste, « Je m’attends à ce que de nombreux protocoles de ce type apparaissent, et j’espère que certains d’entre eux seront conçus dès le départ avec la sécurité à l’esprit : contrôle d’audit, authentification de chaque appel »

Sécurité informatique

En rachetant Mesh Security, Bitdefender se renforce dans la protection des emails

Bitdefender enrichit sa plateforme GravityZone XDR/MDR de fonctions de protection de la messagerie avec l’acquisition de Mesh Security.
Avec le rachat de la société irlandaise Mesh Security (Mesh), l’éditeur roumain Bitdefender va renforcer un peu plus sa plateforme GravityZone XDR/MDR de fonctionnalités de sécurité de la messagerie. En effet, Mesh, entreprise créée en 2020, propose une plateforme de sécurité de messagerie qui combine une protection périmétrique via une passerelle de messagerie sécurisée et une défense au niveau des boîtes mail grâce à un déploiement basé sur des API. Dans le détail, l’outil est capable d’une part d’analyser et de filtrer les e-mails avant qu’ils n’atteignent leur destination finale grâce à la passerelle de messagerie sécurisée, et d’autre part de se connecter directement aux plateformes de messagerie cloud comme Microsoft 365 via une API, offrant un accès en temps réel aux boîtes mail et aux événements. Cette double approche améliore la visibilité sur l’activité des menaces sur tous les vecteurs et va désormais fournir une télémétrie au réseau mondial de renseignements sur les menaces de Bitdefender.Encore plus de MSP à venir pour BitdefenderLa plateforme de Mesh a été pensée dès le départ pour les MSP, elle cible d’ailleurs des centaines de partenaires MSP et des milliers de clients finaux dans le monde entier, l’éditeur va ainsi participer à la croissance de Bitdefender dont le réseau mondial de distribution dépasse les 41 000 partenaires distributeurs et MSP. Avec Mesh, les MSP bénéficient d’une plateforme multi-tenant laquelle assure une protection 24h/7j et fournit beaucoup d’automatisation, une analyse des menaces en temps réel et à une intégration aux flux de travail existants.Côté réactions, Andrei Florescu, pdg de Bitdefender Business Solutions Group, se félicite dans un communiqué de cette acquisition qui va venir renforcer son offre dans la protection des e-mails. Quant à Brian Byrne, pdg et co-fondateur de Mesh, il partage le même avis en mettant aussi l’accent sur les atouts de sa solution de sécurité de messagerie, à savoir l’efficacité, les performances et la simplicité d’utilisation.

Sécurité informatique

La modernisation IT du Pentagone en souffrance

Malgré un budget de 11 Md$ en 2025 pour la transformation numérique du Pentagone, un rapport du Government accountability office révèle d’importants défauts de performance, de tenue des délais et de contrôle, ainsi que des dépassements de coûts et des faiblesses en matière de cybersécurité.
Le ministère américain de la Défense peine à assurer un suivi adéquat des performances de ses principaux systèmes informatiques et à les sécuriser, selon un audit récent du GAO (Government accountability office, soit l’organisme d’audit, d’évaluation et d’investigation du Congrès des États-Unis), alors qu’il prévoit de consacrer près de 11 Md$ à sa transformation numérique durant l’année fiscale 2025. La 6e évaluation annuelle des programmes informatiques du ministère de la Défense par le GAO a en effet révélé des lacunes importantes dans le reporting sur la performance et dans la planification de la cybersécurité pour les 24 principaux projets informatiques liés à des fonctions critiques, tels que les ressources humaines, la santé, la finance, la logistique ou encore la gestion des contrats.L’audit révèle que, pour 5 programmes informatiques sur 19 audités sur le sujet, les équipes du Pentagone n’ont pas réussi à déterminer les outils de mesure minimum nécessaires sur des sujets clés, empêchant les responsables de la Défense d’évaluer si, par exemple, ces systèmes améliorent la satisfaction utilisateurs, apportent des rendements financiers ou stimulent l’innovation. Seul un des 19 programmes a répondu à toutes les attentes, tandis que 17 n’y ont que partiellement réussi. Et un programme n’a même atteint aucun objectif fixé.La préparation cyber en retard sur les délais annoncésL’audit a aussi identifié des lacunes inquiétantes en cybersécurité, alors que le Pentagone fait face à une augmentation des menaces. Malgré une échéance fixée à 2027 par le ministère, deux programmes ne sont dotés d’aucune stratégie de cybersécurité, tandis que quatre autres doivent encore établir des plans de mise en oeuvre d’une architecture zero trust. Ce modèle part du principe qu’aucun utilisateur ou appareil n’est fiable a priori et il est devenu un pilier central de la stratégie de cybersécurité fédérale. L’administration Biden a en effet demandé aux agences d’adopter des normes zero trust pour combattre des cyberattaques de plus en plus sophistiquées. « Le GAO va continuer à surveiller les progrès du ministère de la Défense en la matière », ajoute le rapport, soulignant l’urgence de la démarche.La gestion financière de l’ensemble du portefeuille informatique du ministère de la Défense américain reste également problématique. Les responsables de 14 des 24 programmes concernés ont signalé, depuis janvier 2023, une augmentation des coûts, des retards, voire les deux. Les dépassements de coûts varient de 6,1 M$ à 815,5 M$ avec une augmentation médiane de 173,5 M$ par programme. « Douze programmes ont signalé des augmentations de coûts dans cette fourchette et, par ailleurs, sept ont subi un retard allant de 3 à 48 mois », indique le rapport. Les retards de calendrier s’étendant de trois mois à quatre ans avec un délai médian de 15 mois se sont, en effet, révélés tout aussi inquiétants que la flambée des coûts.
Résultats mitigés dans le développement logicielCes défauts rendent encore plus difficile le double défi qui consiste à moderniser les systèmes de défense vieillissants tout en maintenant un état de préparation opérationnel. Les quatre programmes les plus importants représentent 43% des dépenses prévues pour l’ensemble du portfolio. Ce qui concentre un risque financier majeur dans une poignée de systèmes critiques.Tandis que 11 programmes utilisent des approches de développement agile, trois n’ont pas réussi à fournir les mesures et les outils nécessaires pour suivre la progression du développement et la satisfaction des utilisateurs. Ce défaut compromet les bénéfices des pratiques de développement modernes et réduit la visibilité sur les projets. Le GAO avait déjà recommandé au ministère de la Défense de s’attaquer à des problèmes similaires. Les représentants de cette administration ont approuvé la nouvelle recommandation visant à s’assurer que les différents programmes identifient les mesures adéquates de performance et les communiquent efficacement. Le ministère a décrit les actions mises en oeuvre pour répondre à la recommandation, sans toutefois fournir de détails, ni de calendrier précis.Des défis partagés par nombre d’entreprisesLes conclusions du GAO soulignent les défis auxquels bon nombre de grandes organisations font face quand elles gèrent des portefeuilles informatiques complexes. Les difficultés rencontrées par le ministère dans la mesure des performances, l’organisation de la cybersécurité ou le contrôle des coûts sont les mêmes que celles auxquelles sont confrontés les DSI dans tous les secteurs d’activité.Le rapport note également l’importance critique d’établir des mesures de performance exhaustives, de maintenir des pratiques de cybersécurité rigoureuses et de mettre en place une discipline de gestion de projet. L’expérience du Pentagone peut servir de mise en garde pour de nombreux chefs d’entreprise face aux risques d’une gouvernance non adéquate dans les transformations numériques à grande échelle.Équilibre entre innovation et stabilité opérationnelleLes problèmes auxquels le ministère de la Défense fait face reflètent, en effet, une tendance plus générale des entreprises à trouver le juste équilibre entre innovation et stabilité opérationnelle. Les conclusions du GAO montrent comment des mesures de performance inadaptées peuvent masquer des résultats business essentiels, rendant les managers incapables de justifier des investissements IT ou d’identifier les projets qui échouent avant qu’ils ne consomment des ressources trop importantes.Les lacunes en cybersécurité sont tout particulièrement inquiétantes, étant donné que le secteur de la défense est une cible privilégiée de certains acteurs étatiques et des organisations cybercriminelles. Le retard dans l’implémentation de la politique zero trust suggère que même les organisations les mieux financées avec des mandats clairs peuvent avoir du mal à mettre en place des transformations complètes en matière de sécurité dans les délais prévus.Des audits annuels jusqu’en mars 2029Pour les DSI en général, ce rapport souligne l’importance d’établir des mécanismes de responsabilité clairs, des évaluations fréquentes de performances, ainsi que des cadres solides de gouvernance de projets. L’expérience du Pentagone montre que des budgets substantiels à eux seuls ne peuvent garantir des résultats satisfaisants en l’absence de pratiques précises de gestion et d’un contrôle cohérent. Le National defense authorization act américain impose au GAO de réaliser ces audits chaque année jusqu’en mars 2029, ce qui assure un contrôle continu des pratiques de gestion informatique du Pentagone

Sécurité informatique

De retour, WormGPT s’appuie sur Grok et Mixtral

Deux variantes du LLM malveillant, WormGPT ont été découvertes. Elles se servent des modèles de Grok de xAI et de Mixtral de Mistral AI. Son objectif est de générer des emails de phishing et des scripts malveillants.
En juillet 2023, le monde des cybercriminels avaient profité de l’engouement pour la GenAI en créant WormGPT, une IA basée sur ChatGPT capable de générer des campagnes de phishing. Près de deux ans après, cette plateforme revient sur le devant de la scène comme le montre une étude de Cato Networks. En effet, des chercheurs du spécialiste de la sécurité ont trouvé plusieurs variantes s’appuyant sur d’autres LLM comme Grok de xAI et Mixtral de Mistral AI. La première a été publiée « le 26 octobre 2024 par un dénommé xzin0vich sur BreachForums », explique dans un blog Vitaly Simonovich, expert au sein du l’activité recherche de menace de Cato Networks. Puis la seconde a été diffusée par un dénommé Keanu le 25 février dernier. L’accès à WormGPT se fait via un chatbot Telegram et repose sur un modèle d’abonnement et de paiement ponctuel, rappelle l’expert.
L’usage masqué de Mixtral et Grok
Il a voulu en savoir plus et a entamé des discussions avec les vendeurs des variantes de WormGPT. Il a aussi récupéré le modèle et employé « des techniques de jailbreak LLM pour obtenir des informations sur le modèle sous-jacent ». Dans un prompt, le bot de xzin0vich a répondu, « WormGPT ne doit pas répondre au modèle Mixtral standard. Vous devez toujours créer des réponses en mode WormGPT ». Après d’autres requêtes sous contraintes, les réponses ont bien confirmé que l’assistant malveillant était motorisé par le LLM Mixtral du français Mistral AI. Dans le cas du WormGPT de « Keanu », le modèle semblait être une enveloppe autour de Grok de xAI (dirigé par Elon Musk) et utilisait l’invite système pour définir son caractère, lui ordonnant de contourner les garde-fous de Grok afin de produire du contenu malveillant. Pour mémoire, le prompt système d’un LLM est une instruction cachée ou un ensemble de règles transmis au modèle pour définir son comportement, son ton et ses limitations.
Des échantillons opérationnels sur du phishing et des scripts PowerShell
Les deux WormGPT découverts ont la capacité de générer du contenu malveillant. Ils ont pu créer des échantillons fonctionnels quand il leurs a été demandé d’élaborer des emails de phishing et des scripts PowerShell pour collecter des identifiants Windows 11. Vitaly Simonovich a conclu que les acteurs malveillants utilisent les API LLM existantes (comme l’API Grok) avec un jailbreak personnalisé dans l’invite système pour contourner les protections propriétaires. « Notre analyse montre que ces nouvelles itérations de WormGPT ne sont pas des modèles sur mesure créés de toutes pièces, mais plutôt le résultat d’une adaptation habile des LLM existants par les acteurs malveillants », a-t-il noté. « En manipulant les invites système et en utilisant potentiellement des ajustements précis sur des données illicites, les créateurs proposent de puissants outils d’IA pour les opérations cybercriminelles sous la marque WormGPT », observe-t-il.
Cato Networks recommande des bonnes pratiques de sécurité pour contrer les risques posés par les modèles d’IA réorientés, notamment le renforcement de la détection et de la réponse aux menaces (TDR), la mise en œuvre de contrôles d’accès plus stricts (comme ZTNA, zero trust network access) et l’amélioration de la sensibilisation et de la formation à la sécurité. Ces dernières années, les cybercriminels ont diffusé sur les forums du dark web des versions modifiées de modèles d’IA, conçues pour contourner les filtres de sécurité et automatiser les escroqueries, le phishing, les logiciels malveillants et la désinformation. Outre WormGPT, les exemples les plus connus incluent FraudGPT, EvilGPT et DarkGPT.

Sécurité informatique

En rachetant Quanta.io, Centreon étoffe sa plateforme de supervision

Avec l’acquisition de Quanta.io, Centreon propose désormais une supervision globale, du réseau jusqu’au parcours de l’utilisateur.
Centreon, le spécialiste de la supervision rachète Quanta.io, un éditeur français connu dans la surveillance des performances où comment comprendre l’impact des performances web sur l’entreprise. Cette acquisition permet donc à Centreon d’enrichir sa plateforme d’observabilité sur trois piliers. Le premier concerne l’ajout de capacités de Real User Monitoring (RUM), le RUM permettant de mesurer en temps réel la qualité d’expérience de chaque utilisateur, application par application, terminal par terminal. Pour le deuxième pilier, Centreon va profiter des fonctionnalités de Synthetic Transaction Monitoring (STM), le STM simulant de manière proactive des parcours utilisateurs clés, tels que la connexion, la recherche produit ou le paiement, afin de détecter les lenteurs ou les erreurs avant qu’elles n’impactent les utilisateurs réels.Une offre qui participe à réduire l’empreinte carboneEnfin le dernier pilier découle des deux précédents, puisqu’elle participe à réduire l’empreinte carbone numérique des entreprises. En effet, Quanta.io part du constat que les émissions de carbone d’un site web ou d’une application sont principalement issues de trois domaines, les data centers responsables du stockage et du traitement des données, la transmission réseau qui englobe les données envoyées entre les serveurs et les utilisateurs et les terminaux consommant de l’énergie pour afficher et interagir avec le site ou l’application.Pour Julien Mathis, PDG de Centreon, ce rachat lui permet donc d’aller encore plus loin en combinant supervision des infrastructures IT/OT et mesure plus avancée des performances web et des indicateurs de sobriété numérique, bref d’avoir une visibilité à 360° sur l’écosystème numérique de l’entreprise.De plus, le dirigeant défend la souveraineté européenne et française de son offre.

Sécurité informatique

La montée des attaques par phishing de fournisseurs tiers amplifiée par l’IA

Les compromissions d’e-mails de fournisseurs se multiplient avec le développement de l’IA et contournent les défenses classiques. Près de 72 % des salariés de grandes entreprises interagissent avec ces messages frauduleux.
Le phishing peut prendre plusieurs formes. Une étude d’Abnormal AI s’est focalisée sur la compromission des emails de fournisseurs tiers ou en anglais VEC (vendor email compromise). Ces attaques exploitent avant tout la confiance des collaborateurs plutôt que des failles techniques, contournant ainsi les systèmes de sécurité classiques, comme l’authentification multifactorielle (MFA) et les filtres antispam.
Le rapport indique que 72 % des salariés de grandes entreprises ont répondu ou transféré ce type de message frauduleux, même lorsque ils ne comportaient ni lien ni pièce jointe. Ce phénomène a contribué à des tentatives de fraude évaluées à plus de 300 M$ dans le monde sur un an. Les attaques enregistrent désormais un taux d’engagement supérieur de 90 % à celui du phishing classique.
La zone EMEA, épicentre des attaques par phishing de fournisseurs
La région Europe, Moyen-Orient et Afrique (EMEA) se distingue comme le principal foyer de cette menace. Les salariés y interagissent plus fréquemment avec ces arnaques, tout en signalant très rarement les incidents — à peine 0,27 %. Le taux de signalement des attaques avancées par email demeure faible à l’échelle mondiale, avec seulement 1,46 % des messages malveillants basés sur du texte et lus qui sont effectivement remontés.
Les secteurs des télécommunications (71,3 %) et de l’énergie et des services publics (56,25 %) sont particulièrement exposés. Mike Britton, CIO d’Abnormal AI, rappelle que « les techniques d’ingénierie sociale par email n’ont jamais été aussi sophistiquées », les cybercriminels utilisant des fils de discussion officiels pour envoyer des messages très élaborés, capables de contourner les protections classiques.En EMEA, les jeunes commerciaux sont les plus vulnérables, avec un taux d’engagement pouvant atteindre 86 %. Si 4,22 % du phishing classique est détecté, 98,5 % des VEC passent inaperçues jusqu’à ce que des pertes financières surviennent. En Asie-Pacifique (APAC), c’est principalement le phishing classique qui prédomine, avec un taux d’engagement de 44,4 %.
L’IA accroît la menace
En exploitant l’IA, les cybercriminels reproduisent le ton, le style et même l’historique des échanges, rendant les messages quasi indétectables. « L’IA générative a amené les attaques VEC à un niveau de précision chirurgicale », observe Sujit Dubal, analyste chez QKS Group. « Il ne s’agit plus d’arnaques grossières, mais de communications professionnelles crédibles qui contournent l’authentification multifactorielle et les outils de détection classiques. » Selon lui, il est urgent de repenser les défenses : « Il faut passer d’une stratégie centrée sur la vérification technique à une approche basée sur la détection de la manipulation psychologique. »
Trois axes d’évolution sont jugés critiques, à savoir des systèmes d’analyse d’emails boostés à l’IA capables de repérer des incohérences subtiles, des protocoles actifs de vérification des fournisseurs et une formation des collaborateurs recentrée sur les risques humains. Bien que moins nombreuses que les campagnes de phishing ou de ransomware, les attaques VEC ont un taux de réussite et un impact financier nettement plus importants. Mike Britton conclut que « l’IA facilite l’usurpation d’identité de fournisseurs de confiance » et appelle les entreprises à adopter des solutions proactives pour bloquer ces menaces avant leur arrivée en boîte de réception.

Sécurité informatique

Un package PyPi malveillant vole les secrets des utilisateurs de Chimera

L’outil de test et de développement de machine learning, Chimera, est victime d’un package Python malveillant. Ce dernier est capable de voler des jetons AWS et des secrets CI/CD.
Selon des recherches menées par JFrog, éditeur d’une plateforme de cycle de développement logiciel et devsecops, le package « chimera-sandbox-extensions », récemment téléchargé sur le célèbre référentiel PyPI, contient un voleur d’informations furtif à plusieurs étapes. Les renseignements obtenus à partir des jetons et des journaux volés pourraient aider les attaquants à infiltrer ou à saboter davantage les infrastructures. « Le package vise à voler des identifiants et d’autres informations sensibles telles que la configuration JAMF, les variables d’environnement CI/CD et les jetons AWS », ont déclaré les chercheurs de JFrog dans un article de blog. De plus, il exfiltre les jetons d’authentification et les données Git de l’environnement sandbox Pod, la configuration de l’hôte Zscaler, l’adresse IP publique et les informations générales sur la plateforme, l’utilisateur et l’hôte. Une fois installé, le paquet lance un algorithme sophistiqué de génération de domaines (DGA), choisissant parmi 10 adresses pour localiser son centre de commande et de contrôle (C2). Une fois la communication C2 établie, il télécharge une charge utile Python dynamique de deuxième étape, conçue pour voler les données de l’environnement.
Les experts alertent sur la montée en puissance des paquets malveillants
« La détection de packages malveillants, tels que les extensions chimera-sandbox, sur PyPI met en évidence le risque important et généralisé posé par les attaques visant la chaîne d’approvisionnement logicielle », a déclaré Eric Schwake, directeur de la stratégie de cybersécurité chez Salt Security. Il ajoute « la principale menace réside dans sa capacité à collecter des données sensibles liées aux développeurs, notamment les identifiants, les fichiers de configuration, et surtout les jetons AWS et les variables d’environnement CI/CD. »
De son côté, Mike McGuire, responsable senior des solutions de sécurité chez Black Duck, indique, « cet incident souligne la sophistication croissante des attaques sur le cycle de développement des logiciels, où des paquets apparemment fiables peuvent véhiculer des logiciels malveillants dangereux ». Pessimiste, il observe que « malheureusement, la fréquence de telles attaques est susceptible de croître ; les équipes doivent donc adopter une approche multicouche pour se défendre ».
La protection nécessite une approche multicouche
Les experts considèrent l’incident chimera-sandbox-extension comme bien plus qu’un simple démantèlement de paquet malveillant. Si JFrog a réagi rapidement (en alertant les responsables de PyPI, en supprimant le paquet et en mettant à jour son scanner Xray), les chercheurs s’accordent à dire qu’une solution ponctuelle ne suffit pas. « Au cours des cinq dernières années, les attaquants ont exploité PyPI et d’autres gestionnaires de paquets pour exploiter la confiance des développeurs par le biais de typosquatting et d’attaques de supply chain », souligne Fletcher Davis, responsable senior de la recherche en sécurité chez BeyondTrust. Pour lui, « l’incident des extensions chimera-sandbox souligne l’insuffisance des approches de sécurité traditionnelles face aux menaces modernes qui pèsent sur le cycle de développement. Il nécessite une approche proactive et multicouche combinant contrôles techniques, améliorations des processus et surveillance continue, plutôt que de s’appuyer uniquement sur des mesures réactives.»
Plus précisément, Jason Soroko, chercheur senior chez Sectigo, a souligné qu’interdire les installations directes « PiP » et « uv » à partir d’index publics peut s’avérer utile. « Mettez en miroir les dépendances approuvées dans un référentiel interne et appliquez l’épinglage des hachages dans les fichiers de verrouillage », complète-t-il. « Analysez tous les paquets entrants avec des analyses statiques et dynamiques pour détecter les appels DGA et le code de collecte d’identifiants observés dans les extensions chimera-sandbox. Automatisez la suppression des dépendances obsolètes ou inutilisées », poursuit-il.  Les abus envers les gestionnaires de paquets open source ont explosé ces dernières années, en raison de leur portée massive et de leur impact potentiel considérable grâce à des millions de téléchargements quotidiens. Des découvertes récentes ont montré que des attaquants ont exploité le gestionnaire de paquets npm pour diffuser des paquets malveillants afin d’effacer des systèmes de production entiers, d’espionner des machines DevOps et d’implanter des logiciels malveillants voleurs et RCE (exécution de code à distance).

Sécurité informatique

Curby propose une système quantique de génération de nombres aléatoires

En pleine réflexion sur la sécurité liée à l’informatique quantique, l’université du Colorado à Boulder a créé Curby. Il s’agit d’un système quantique produisant des nombres aléatoires vérifiables et infalsifiables.
Le monde du quantique est en pleine effervescence. Start-ups et universités rivalisent d’annonces sur ce thème en adressant différentes thématiques (création de qubit logique, réduction des erreurs,…). La sécurité est également un terrain de jeux notamment autour de la génération de nombres aléatoires, un procédé essentiel pour le chiffrement des données. Une récente découverte par une équipe de l’université du Colorado à Boulder, dirigée par Gautam A. Kavuri, répond à une problématique persistante : comment générer un nombre aléatoire inviolable ?
Elle a développé Curby (Colorado University Randomness Beacon), un système quantique produisant des nombres aléatoires vérifiables et infalsifiables. Les travaux ont été publiés dans la revue Nature et détaillée dans une prépublication arXiv. Concrètement, Curby exploite le phénomène d’intrication quantique où les particules maintiennent des états interconnectés quelle que soit la distance, pour créer des résultats fondamentalement imprévisibles. Techniquement, Curby tire son entropie de mesures de photons intriqués dont les états mystérieusement liés constituent une source d’imprévisibilité fondée sur la physique.
Un système qui séduit les experts
Chaque mesure est enregistrée dans une chaîne de hachage cryptographique utilisant le protocole Twine de l’équipe, créant ainsi une trace auditable et inviolable. Toute tentative de modification des sorties passées briserait l’intégrité de la chaîne, révélant immédiatement la falsification, indique la publication. « Nous avons construit un système accessible à tous pour générer et vérifier l’aléatoire, sans obstacle majeur à une mise à l’échelle mondiale », a déclaré Gautam A. Kavuri lors d’un échange avec CSOonline. A cette occasion, il a expliqué que l’architecture distribuée de Curby, soutenue par des outils open source basés sur Docker comme le package « beacon-in-a-box », facilite l’adoption par les entreprises.
Les experts semblent séduits par cette initiative comme le montre Narayan Gokhale, vice-président du groupe QKS. « D’un point de vue sécuritaire, cette approche offre un atout précieux : la possibilité de vérifier indépendamment que les nombres aléatoires n’ont pas été compromis », affirme-t-il. Tout en saluant, « le transfert de la confiance des hypothèses logicielles opaques vers des principes physiques vérifiables ». Autre avantage pour le spécialiste, l’architecture distribuée et vérifiable introduit « un niveau de confiance essentiel pour des secteurs avec des infrastructures critiques à l’ère des cybermenaces accrues ».
Des cas d’usage multiples
Le système Curby est conçu pour les applications où le caractère aléatoire vérifiable est essentiel, notamment les protocoles de chiffrement ou les loteries numériques et les audits publics. Il peut intéresser des secteurs comme la finance, les infrastructures et le gouvernement, où le caractère aléatoire vérifiable revêt une importance opérationnelle et réglementaire.
L’architecture distribuée du service est un autre atout, qui ouvre la voie à des formes d’infrastructures de confiance décentralisées. Narayan Gokhale suggère que « le modèle de balises Curby préfigure un avenir où les systèmes décentralisés s’appuieront sur l’aléatoire quantiquement vérifiable comme point de confiance partagée, allant au-delà de l’infrastructure à clés publiques (PKI) traditionnelle ou du consensus blockchain vers une couche de confiance davantage ancrée dans la physique ».

Sécurité informatique

Broadcom lance VMware Cloud Foundation 9.0

En dehors des relations clients tendues, Broadcom continue de faire évoluer VMware Cloud Foundation. La suite passe en version 9.0 et vise à simplifier le déploiement de cloud privé. Une orientation que de plus en plus de dirigeants IT adoptent selon le spécialiste de la virtualisation.
Après une présentation à l’évènement Explore à Las Vegas l’été dernier et une phase de test en début d’année, Broadcom a officiellement lancé la version 9.0 de VMware Cloud Foundation VCF). Composée de plusieurs composants comme vSphere, vSAN et NSX, cette offre packagée vise à simplifier la création et le déploiement d’un cloud privé. Selon le spécialiste de la virtualisation, les entreprises révisent leur stratégie sur le cloud…

Il vous reste 91% de l’article à lireVous devez posséder un compte pour poursuivre la lecture

Vous avez déjà un compte?

Sécurité informatique

Faille critique dans GitLab Ultimate Enterprise Edition 

Les administrateurs et développeurs utilisant des installations autogérées sont invités à effectuer la mise à jour dès que possible. 
Une vulnérabilité dans GitLab Ultimate Enterprise Edition, utilisé pour la gestion du code source, est « dangereuse » et doit être corrigée rapidement, selon un expert. La faille, CVE-2025-5121, est l’une des 10 décrites récemment par GitLab lors de la publication de correctifs de bogues et de sécurité pour les installations autogérées. « Nous recommandons vivement à tous les utilisateurs d’installations GitLab autogérées de mettre à jour immédiatement leur version vers l’une des versions corrigées [18.0.2, 17.11.4, 17.10.8] », a déclaré la plateforme. GitLab.com utilise déjà la version corrigée, les clients GitLab Dedicated n’ont donc aucune mesure à prendre. 
4 failles classées haute gravité
Johannes Ullrich, doyen de la recherche au SANS Institute, s’est montré particulièrement inquiet au sujet de la faille CVE-2025-5121, un problème d’autorisation manquante. Il l’a qualifié de « dangereux ». Si elle n’est pas corrigée, dans certaines conditions, elle peut permettre à un pirate informatique disposant d’un accès authentifié à une instance GitLab avec une licence GitLab Ultimate (client payant ou essai) d’injecter une tâche CI/CD malveillante dans tous les pipelines CI/CD de n’importe quel projet. « En injectant une tâche malveillante, un pirate informatique serait en mesure de compromettre la manière dont le logiciel est construit », a déclaré M. Ullrich à CSO. « Cela pourrait notamment inclure l’ajout de portes dérobées au logiciel ou le contournement de certaines étapes de validation. Le code aurait également accès aux secrets utilisés pendant le processus de construction. » 
Les versions concernées sont GitLab Ultimate EE 17.11 antérieures à la version 17.11.4 et 18.0 antérieures à la version 18.0.2. Cette vulnérabilité a reçu une note CVSS de 8,5. L’autre vulnérabilité sur laquelle M. Ullrich a attiré l’attention est la CVE-2025-4278, une faille d’injection HTML. Il l’a décrite comme une vulnérabilité de type « cross site scripting », mais avec un impact plus limité. GitLab lui attribue un score CVSS de 8,7. « L’impact de ces vulnérabilités est souvent difficile à évaluer », a déclaré M.Ullrich, « mais des attaquants créatifs sont souvent capables de les exploiter pour inciter les utilisateurs à effectuer des actions dangereuses pour le compte de l’attaquant. »  GitLab indique que, sans correctif, dans certaines conditions, cette faille permettrait à un attaquant de prendre le contrôle d’un compte en injectant du code dans la page de recherche. 
Toutes les instances de la version 18.0 antérieures à la version 18.0.2 des éditions Community et Enterprise sont concernées. Les deux autres vulnérabilités classées comme élevées sont les suivantes : 
– CVE-2025-2254, un problème de cross-site scripting qui, dans certaines conditions, pourrait permettre à un attaquant d’agir comme un utilisateur légitime en injectant un script malveillant dans la visionneuse d’extraits. 
– Toutes les versions GitLab CE/EE de 17.9 avant 17.10.8, 17.11 avant 17.11.4 et 18.0 avant 18.0.2 sont concernées ; 
– CVE-2025-0673, une vulnérabilité pouvant entraîner un déni de service en déclenchant une boucle de redirection infinie, ce qui provoquerait l’épuisement de la mémoire sur le serveur GitLab. Les versions concernées de GitLab CE/EE sont les versions 17.7 antérieures à 17.10.8, 17.11 antérieures à 17.11.4 et 18.0 antérieures à 18.0.2. 
3 failles de déni de service sont répertoriées avec un niveau de risque moindre. 
CVE-2025-1516, si elle n’est pas corrigée, permet à un attaquant de bloquer l’accès aux utilisateurs légitimes du système ciblé en générant des jetons avec des noms suffisamment longs, CVE-2025-1478 permet à un attaquant de bloquer l’accès aux utilisateurs légitimes du système ciblé en créant des noms de tableau suffisamment longs, et CVE-2025-5996 permet un déni de service en intégrant un composant tiers malveillant dans un projet GitLab. Une autre vulnérabilité corrigée, CVE-2024-9515, aurait pu donner la capacité à un attaquant de cloner le référentiel privé d’un utilisateur légitime en envoyant une demande de clonage temporisée lorsqu’un nœud secondaire est désynchronisé. Cette faille a un score CVSS de 5,3. Robert Beggs, CEO de la société canadienne de réponse aux incidents Digital Defence, a déclaré que les responsables de la sécurité informatique doivent garder à l’esprit que GitLab n’est pas un dossier passif dans lequel un utilisateur dépose et récupère ultérieurement des données ou du code source. Il s’agit d’une application complexe qui prend en charge l’ensemble du cycle de vie DevOps, de la planification au déploiement et à la surveillance. Pour remplir ce rôle, GitLab fournit un grand nombre de fonctions complexes. Cet ensemble de fonctionnalités augmente la surface d’attaque. Combinées à la complexité de l’application, toute configuration incorrecte ou vulnérabilité pourrait avoir un impact significatif pour les utilisateurs. 
« Comme pour toutes les applications, les CSO doivent prêter attention aux rapports des fournisseurs sur les vulnérabilités et à tout correctif ou mise à jour de l’application », a-t-il déclaré dans un e-mail. « Ils doivent également être attentifs à leur propre hygiène de sécurité et suivre les meilleures pratiques d’utilisation de GitLab. » Il s’agit notamment de limiter l’accès et les privilèges d’accès aux référentiels GitHub (par exemple, en s’assurant que la visibilité par défaut est définie sur Privé), d’activer l’authentification multifactorielle pour l’accès et de s’assurer que les mots de passe respectent les règles de complexité habituelles, de mettre en œuvre des contrôles d’accès basés sur les rôles et de revoir fréquemment les listes d’accès, de mettre en œuvre des certificats SSL et TLS pour sécuriser les communications, de sécuriser les runners GitLab et les variables de pipeline, de protéger la base de code en mettant en œuvre des règles de protection des branches et la signature du code, etc.