Archives par mot-clé : sécurité cloud

OVHcloud expose le piratage de son outil de commande

OVHcloud a détaillé une attaque visant son outil de commande. Des téléchargements officiels piégés ont exposé les secrets des utilisateurs, déclenchant une réponse publique et documentée.

Une page officielle peut distribuer un logiciel malveillant lorsque sa publication est détournée. OVHcloud en a fait l’expérience avec son interface en ligne de commande, utilisée pour administrer des ressources cloud depuis un terminal. Un compte GitHub compromis a permis de remplacer les fichiers de cinq versions existantes, sans modifier leur code source. L’entreprise européenne a communiqué publiquement, retiré les exécutables concernés et documenté l’incident. L’exposition dépend du téléchargement effectué pendant la fenêtre d’attaque et de l’exécution du programme. Pour les utilisateurs concernés, réinstaller une version saine ne suffit pas : les secrets accessibles sur leur poste doivent également être révoqués.

Des archives officielles remplacées après publication

Le piège reposait sur une confiance quotidienne : télécharger un outil depuis le dépôt de son éditeur. Les utilisateurs retrouvaient le projet attendu, ses versions habituelles et des fichiers portant des noms familiers. Pourtant, certaines archives avaient été remplacées après leur publication initiale.

Cinq versions étaient concernées, de la 0.11.0 à la 0.15.0. Selon la reconstitution d’OpenSourceMalware, l’attaquant a utilisé les accès d’un contributeur disposant des permissions nécessaires pour modifier les fichiers associés aux versions publiées. Le détournement portait sur les exécutables distribués. Le code source et la chaîne de compilation n’avaient pas été altérés.

L’opération s’accompagnait du remplacement de checksums.txt, le fichier contenant les empreintes utilisées pour contrôler les téléchargements. Les nouvelles valeurs correspondaient aux archives piégées. Un utilisateur comparant son téléchargement avec cette référence modifiée pouvait donc obtenir un résultat rassurant. La vérification perdait son utilité puisque le fichier contrôlé et sa référence avaient été remplacés ensemble.

L’alerte est venue d’un client ayant conservé une empreinte SHA-256 attendue dans sa chaîne d’intégration. Lorsque l’archive Linux ARM a changé, le contrôle a échoué. Cette différence a conduit à un signalement public sur GitHub. Une référence enregistrée avant l’attaque a ainsi révélé une modification que les pages de téléchargement ne rendaient pas immédiatement visible.

La chronologie officielle situe la disponibilité des fichiers malveillants le 19 octobre 2026, entre 14 h 47 et 16 h 21, heure de Paris. OVHcloud a retiré les exécutables concernés puis publié la version 0.16.0, accompagnée d’une étiquette signée et de fichiers rendus immuables. Cette configuration empêche leur remplacement ultérieur au sein de la même publication.

La transparence d’OVHcloud se mesure ici à des éléments concrets : échanges publics avec l’auteur du signalement, horaires d’intervention, identification du défaut de configuration et publication d’un avis technique le 20 octobre. Le rapport annoncé dans les premières communications est désormais disponible. L’entreprise y décrit également les corrections appliquées et les mesures de renforcement envisagées.

Des secrets à révoquer sur les postes exposés

Le numéro de version, pris isolément, ne permet pas de déterminer l’exposition. Une copie légitime téléchargée avant le remplacement des archives reste différente d’un exécutable malveillant distribué ensuite sous la même référence. Il faut donc examiner la provenance du fichier et le moment de son acquisition.

Les téléchargements directs depuis GitHub, le script d’installation officiel et Homebrew pouvaient récupérer les archives remplacées. Une chaîne d’intégration automatisée pouvait également les télécharger sans intervention manuelle. Selon OpenSourceMalware, les compilations réalisées depuis le code source, notamment avec go install, échappaient à ce détournement. L’analyse distingue aussi l’image Docker construite en interne des exécutables substitués sur GitHub.

Le danger apparaît lorsque le programme piégé est lancé. L’avis officiel demande de considérer comme compromis les secrets présents sur un ordinateur ayant exécuté une copie concernée. Il recommande de vérifier les empreintes des fichiers suspects sans les lancer. Exécuter ovhcloud version pour obtenir un diagnostic ferait précisément démarrer le programme dont on cherche à établir l’innocuité.

Les accès à examiner dépassent le seul compte OVHcloud. Le texte initial cite notamment les clés d’API, la configuration ovh.conf, les clés SSH et les accès Kubernetes. Un poste d’administration peut concentrer des moyens de connexion à plusieurs environnements. La portée de l’incident dépend donc aussi des secrets effectivement accessibles sur chaque machine.

Depuis un ordinateur sain, les utilisateurs concernés doivent révoquer ou renouveler ces accès, puis remplacer l’exécutable compromis par une distribution propre. Supprimer le fichier malveillant ne retire aucune valeur aux identifiants déjà copiés. Tant qu’un secret reste valide, son détenteur peut tenter de l’utiliser.

L’attribution appelle une précision comparable. OpenSourceMalware rapproche la compromission ancienne du compte de l’écosystème GlassWorm, notamment à partir de traces dans des dépôts personnels et d’un portefeuille Solana connu. Son analyse initiale distingue toutefois ces indices de la preuve qu’un même opérateur aurait conduit toutes les étapes. Cette réserve évite de transformer un rapprochement technique en certitude.

Barracuda Networks nomme Rohit Ghai comme nouveau CEO

Barracuda Networks choisit Rohit Ghai pour succéder à Hatem Naguib, ouvrant une nouvelle étape stratégique pour le spécialiste mondial de la cybersécurité et des solutions cloud.

Le fournisseur de cybersécurité Barracuda Networks annonce la nomination de Rohit Ghai au poste de CEO. Dirigeant expérimenté, il a occupé des responsabilités majeures chez RSA, EMC, Symantec et CA Technologies. Il succède à Hatem Naguib, en poste depuis 2021, qui a marqué son mandat par le lancement de BarracudaONE, une plateforme de cybersécurité pilotée par intelligence artificielle. En plus de ses nouvelles fonctions, Ghai intègre le conseil d’administration de Barracuda et siège déjà dans plusieurs autres organisations technologiques. Sa nomination illustre la volonté de l’entreprise d’accélérer sa croissance et de renforcer son rôle dans la protection numérique face aux menaces émergentes.

Un virage stratégique pour Barracuda

Barracuda Networks confie sa direction à Rohit Ghai. Fort de plus de vingt ans de carrière dans la cybersécurité et les technologies SaaS, il a occupé des postes de direction dans des sociétés de premier plan. Son expérience chez RSA, où il fut également CEO, ainsi que son passage par EMC, Symantec et CA Technologies, confère à son profil une légitimité reconnue dans le secteur. Sa nomination s’inscrit dans un contexte où Barracuda veut consolider sa position sur un marché marqué par une intensification des menaces numériques et une concurrence accrue.

En prenant la direction de Barracuda, Ghai rejoint aussi son conseil d’administration. Il occupe déjà plusieurs sièges stratégiques, notamment chez Pegasystems, D-Wave Systems et MHC Software, et a précédemment été membre du conseil d’Everbridge. Cette implication multiforme illustre sa connaissance des écosystèmes technologiques et de l’innovation numérique. Le communiqué de l’entreprise le décrit comme un dirigeant reconnu pour « sa vision stratégique et son expertise sectorielle ». L’objectif affiché est de tirer parti de son expérience pour engager Barracuda dans une nouvelle phase de croissance et d’innovation.

L’héritage de Hatem Naguib

Le départ d’Hatem Naguib clôt une période de quatre ans à la tête de l’entreprise. Entré chez Barracuda à des postes de direction, il fut notamment COO, puis vice-président senior et directeur général de la division sécurité, avant de devenir CEO en 2021. Sous sa direction, Barracuda lança BarracudaONE, une plateforme intégrant intelligence artificielle et cybersécurité, considérée comme une avancée majeure dans l’offre de l’entreprise. Avant de quitter ses fonctions, il a salué son successeur : « Je transmets le flambeau à Rohit, car j’ai pleinement confiance en sa capacité à faire entrer Barracuda dans une nouvelle ère ».

Une vulnérabilité Streamlit menace les marchés financiers

Une faille critique dans Streamlit expose des dashboards boursiers aux manipulations, facilitant la prise de contrôle de comptes cloud mal configurés et déstabilisant potentiellement les marchés.

 

Rejoignez-nous sur les réseaux sociaux

Aucun spam – Désinscription en un clic – Vie privée respectée

 

Cato Networks révèle une faille grave dans le widget st.file_uploader de Streamlit : l’absence de validation côté serveur permet d’exploiter cette vulnérabilité pour prendre le contrôle d’instances cloud mal configurées. À travers une démonstration, les chercheurs montrent comment cette faille peut être utilisée pour falsifier des tableaux de bord financiers en temps réel et déclencher des chocs artificiels sur les marchés. Bien que patchée dans la version 1.43.2, cette vulnérabilité souligne les risques liés à de mauvaises pratiques de configuration en environnement cloud. Vigilance, compartimentation et corrections rapides sont essentielles pour éviter tout scénario de manipulation malveillante.

Origine et nature de la vulnérabilité Streamlit

Streamlit, outil open source largement adopté pour la visualisation de données, intègre une fonction de téléchargement de fichiers, st.file_uploader, censée restreindre les types de fichiers acceptés. Or, cette vérification était uniquement exécutée côté client, dans le navigateur. Une faille majeure : en interceptant la requête, un attaquant pouvait facilement modifier l’extension du fichier envoyé, contournant ainsi la sécurité supposée.

L’équipe de Cato CTRL a mis en lumière cette vulnérabilité en février 2025. Elle permettait, entre autres, d’envoyer un fichier Python masqué sous une extension autorisée (ex. .txt), puis exécuté à distance. Cette négligence de validation côté serveur est d’autant plus critique qu’elle concerne un outil utilisé dans de nombreux dashboards de monitoring, y compris dans le secteur financier.

Scénario d’exploitation et conséquences financières

Imaginez une interface de trading qui affiche des données fausses en temps réel : cours erronés, signaux d’achat déclenchés artificiellement, volatilité non justifiée. C’est exactement ce que la démonstration de Cato a mis en scène.

En chargeant un fichier piégé dans une instance Streamlit exposée sans protections réseau (pare-feu, authentification, segmentation), l’attaquant peut obtenir un shell, escalader les privilèges et altérer les données affichées aux analystes financiers. Dans des conditions réelles, cela pourrait provoquer des prises de décisions erronées par des investisseurs, avec des impacts économiques significatifs, voire des déclenchements d’ordres automatiques sur les marchés.

La faille a été corrigée dans la version 1.43.2 de Streamlit en mars 2025. Pourtant, la plateforme a refusé de la qualifier de vulnérabilité de sécurité, estimant que la responsabilité de validation incombait aux développeurs d’applications, et non au framework. Cato Networks a donc tenté de faire enregistrer une CVE via MITRE – en vain jusqu’à aujourd’hui.

Cette faille met en lumière une vérité souvent négligée dans les environnements cloud : la configuration est aussi critique que le code. La vulnérabilité n’exploitait pas une faille dans l’infrastructure cloud sous-jacente (AWS, Azure, GCP), mais dans le déploiement de l’application elle-même. Dans le modèle de responsabilité partagée, c’est bien au client qu’incombe la protection de ses assets.

Il faut donc :

Isoler les instances Streamlit derrière des contrôles d’accès forts ;

Appliquer le principe du moindre privilège dans les autorisations ;

Mettre à jour systématiquement les dépendances open source ;

Effectuer des tests de sécurité sur les entrées utilisateur, y compris les fichiers.

Cato Networks recommande en outre d’utiliser des solutions capables de détecter les comportements anormaux dans les processus cloud, comme les accès non légitimes ou les modifications suspectes de fichiers backend. Ce cas rappelle que même une fonction d’apparence banale peut devenir un vecteur d’attaque dévastateur, surtout dans un contexte de finance algorithmique et de visualisation temps réel. L’ingénierie logicielle ne peut se permettre de reléguer la sécurité à un second plan.