L’acquisition de SolarWinds par le fonds d’investissement Turn/River Capital pour un montant de 4,4 milliards de dollars donne aux RSSI ce qu’ils veulent le moins : l’incertitude. Les analystes prévoient des réductions de dépenses importantes chez l’éditeur pour préparer une revente rapide.
Lorsque SolarWinds a annoncé vendredi dernier, le 7 février 2025, un accord de 4,4 milliards de dollars pour être acquis par le fonds d’investissement Turn/River Capital, les RSSI ont manifesté leur inquiétude face à ce qu’ils apprécient le moins : l’incertitude. “Chaque fois qu’une entreprise de sécurité est acquise par un fonds d’investissement, il ne faut jamais se féliciter”, a déclaré Frank Dickson, vice-président du groupe de recherche sur la sécurité et la confiance…
Il vous reste 95% de l’article à lireVous devez posséder un compte pour poursuivre la lecture
Vous avez déjà un compte?
Des chercheurs en sécurité ont identifié près de 150 buckets S3 d’AWS laissés à l’abandon mais remplis de fichiers malveillants prêts à être exécutés à l’insu de nombreuses entreprises. Avec à la clé des risques allant de la simple injection de code dans un site web jusqu’à la prise de contrôle d’un compte AWS.
Les codes de référence [aides au diagnostic aidant à déterminer l’origine d’un incident matériel ou logiciel, ndlr] relatifs à des ressources cloud inexistantes continuent de poser des risques de sécurité importants et le problème ne fait que s’aggraver. Des recherches récentes ont permis d’identifier environ 150 anciens buckets S3 [unité de stockage contenant des données sous forme d’objets, ndlr] chez AWS utilisés par différents projets logiciels pour héberger des scripts sensibles, des…
Il vous reste 95% de l’article à lireVous devez posséder un compte pour poursuivre la lecture
Vous avez déjà un compte?
Pour éviter les accès illégitimes aux entrepôts de données managés de Redshift, AWS a décidé de désactiver par défaut les accès publics et de renforcer le chiffrement des connexions et des données.
Si les experts en cybersécurité pointent régulièrement les problèmes de configuration des buckets S3 d’AWS, les entrepôts de données de Redshift constituent un point de vigilance. Dans ce cadre, le fournisseur de cloud a renforcé la protection de ce service cloud en désactivant l’accès public. Pour Loris Degioanni, directeur de la technologie chez Sysdig, cette évolution est la bienvenue et « nécessaire pour accompagner l’adoption accélérée du cloud dans les…
Il vous reste 94% de l’article à lireVous devez posséder un compte pour poursuivre la lecture
Vous avez déjà un compte?
Avec le succès de Deepseek, un cybercriminel n’a pas attendu longtemps pour proposer des paquets Python avec des noms quasi similaires à la start-up chinoise comprenant des infostealers.
L’onde de choc déclenchée par le lancement de DeepSeek n’a pas laissé indifférent les pirates comme le montre un rapport du centre de recherche de Positive Technologies, société de cybersécurité. Les experts ont en effet trouvé une campagne ciblant des développeurs peu méfiants, des ingénieurs en machine learning ou des passionnés d’IA cherchant à intégrer Deepseek dans leurs projets.
Le 29 janvier dernier, un pirate nommé « bvk » a posté deux paquets nommées deepseeek et deepseekai sur PyPi dépôt officiel des paquets Python. « Les fonctions utilisées dans ces paquets sont conçues pour collecter les données de l’utilisateur et voler des variables d’environnement », souligne les chercheurs. Les charges utiles de ces paquets sont des infostealers capables d’extraire des données sensibles comme les clés API pour S3, des identifiants de base de données et des autorisations d’accès à l’infrastructure. Le cybercriminel se sert en parallèle du logiciel Pipedream, plateforme cloud d’intégration et d’automatisation pour les développeurs, comme serveur de commande et contrôle (C2) pour récupérer les données volées.
Une action opportuniste d’un pirate inexpérimenté
Toujours dans leur analyse, les experts de Positive Technologies observent des signes d’inexpérience sur la création de la charge utile. En effet, le pirate s’est servi d’un assistant IA pour écrire le code malveillant. Les chercheurs l’ont déterminé grâce aux commentaires caractéristiques expliquant chaque ligne de code. De même, ils ont constaté que le compte « bvk » utilisé pour télécharger ces paquets était inactif depuis sa création en juin 2023. Selon Mike McGuire, responsable des solutions de sécurité chez Black Duck, ce fait aurait dû être un signe révélateur pour les développeurs.
Dans un commentaire adressé à nos confrères de CSO, le responsable a déclaré, « dans leur empressement à exploiter DeepSeek dans leurs tâches, de nombreux développeurs n’ont pas vu le « drapeau rouge » indiquant qu’ils téléchargeaient des paquets à partir d’un compte à la réputation limitée et médiocre, ce qui a eu pour conséquence de compromettre leurs variables d’environnement et leurs secrets. » Il ajoute, « bien que le nom DeepSeek ait été utilisé dans cette attaque, il est important de noter que cela n’a rien à voir avec l’entreprise, ni avec l’IA en général ». Il s’agit d’une action opportuniste. Les paquets ont été signalés « rapidement » aux administrateurs de PyPI, qui les ont depuis supprimés. Ils ont malheureusement été téléchargés plus de 200 fois, concluent les chercheurs.
Les modèles d’IA sont de plus en plus la cible de techniques pour leur faire dire de mauvaises réponses. Pour répondre à ce problème, Anthropic lance un framework capable de filtrer les contournements des garde-fous.
La mise en place de garde-fous dans les modèles d’IA n’est pas la réponse parfaite pour éviter de générer du mauvais contenu. Anthropic vient de s’attaquer à ce problème face à la multiplication des techniques pour contourner ces barrières. Ces méthodes aussi appelées jailbreak, « exploitent le LLM en l’inondant d’invites excessivement longues, tandis que d’autres manipulent le style d’entrée, par exemple en utilisant des majuscules inhabituelles », souligne la…
Il vous reste 90% de l’article à lireVous devez posséder un compte pour poursuivre la lecture
Vous avez déjà un compte?
Les modèles d’IA sont de plus en plus la cible de techniques pour leur faire dire de mauvaises réponses. Pour répondre à ce problème, Anthropic lance un framework capable de filtrer les contournements des garde-fous.
La mise en place de garde-fous dans les modèles d’IA n’est pas la réponse parfaite pour éviter de générer du mauvais contenu. Anthropic vient de s’attaquer à ce problème face à la multiplication des techniques pour contourner ces barrières. Ces méthodes aussi appelées jailbreak, « exploitent le LLM en l’inondant d’invites excessivement longues, tandis que d’autres manipulent le style d’entrée, par exemple en utilisant des majuscules inhabituelles », souligne la…
Il vous reste 90% de l’article à lireVous devez posséder un compte pour poursuivre la lecture
Vous avez déjà un compte?
A la fin janvier, Asus a divulgué la présence de failles dans le firmware des puces AMD Epyc. Le hic est que les correctifs n’étaient pas encore sortis. Ils sont maintenant disponibles, mais leur application devrait prendre du temps.
Le timing pour la publication des failles peut parfois tourner au casse-tête. Preuve en est avec AMD qui a mis à disposition en début de semaine des correctifs pour des failles de sécurité dans le micrologiciel des puces Epyc. La société a précisé que le problème pouvait entraîner la perte de la fonction Secure Encrypted Virtualization (SEV). L’inconvénient est que les détails de ces vulnérabilités ont été publiés par Asus dans le cadre d’une mise à jour bêta du Bios à la fin janvier. AMD n’était pas préparé et a mis un certain temps pour publier ses patchs.
Ce laps de temps aurait pu être préjudiciable à la cybersécurité des entreprises. Les spécialistes avaient exhorté les administrateurs à mettre en place des mesures d’isolement réseau et de blocage des mises à jour des correctifs en attendant la réponse d’AMD. Ce dernier avait relativisé la capacité à utiliser les brèches, « l’exécution de l’attaque nécessite un accès au système au niveau de l’administrateur local, ainsi que le développement et l’exécution d’un micrologiciel malveillant. »
Une application des patchs qui va prendre du temps
En raison de la nature des correctifs publiés, les utilisateurs doivent maintenant attendre que les OEM et d’autres partenaires mettent en œuvre les patchs dans le firmware spécifique de leur matériel. « Cette situation va peser sur les équipementiers des fournisseurs de matériel et cela peut entraîner un retard dans l’adoption », a déclaré John Price, CEO de la société de sécurité SubRosa, basée à Cleveland. Un avis partagé par Flavio Villanustre, responsable de la sécurité de LexisNexis Risk Solutions en estimant que les retards seront différents en fonction de la rapidité du fournisseur à appliquer les correctifs.
Matt Kimball, vice-président et analyste principal chez Moor Insights & Strategy considère lui qu’AMD a bien géré la situation. « Il est bon de voir AMD travailler avec sa communauté pour résoudre rapidement ces vulnérabilités. La quantité de travail nécessaire pour fournir un correctif – et le tester de manière approfondie – est considérable. Il s’agit d’une pression importante sur les ressources, d’où la bonne coordination de la part d’AMD », a-t-il déclaré.
Une longue liste de puces Epyc concernées
Flavio Villansutre insiste sur le fait que les administrateurs doivent se concentrer sur l’UEFI (unified extensible firmware interface), qui est l’interface entre l’OS et le microcode. « Si l’UEFI n’est pas mis à jour le problème du microcode reviendra à chaque démarrage des serveurs », souligne l’expert. « Cette situation montre à quel point les problèmes de firmware sont devenus un élément essentiel de l’informatique moderne », a déclaré John Price. « Cela va rendre les correctifs d’urgence plus difficiles à l’avenir. Ils nécessiteront des redémarrages complets du système », conclut le spécialiste.
A noter que le second correctif évite une attaque par canal latéral basée sur le cache, qui affecte également SEV. Ce problème concerne les « processeurs AMD Epyc de 1ère génération dont le nom de code était Naples, ceux de 2ème génération dont le nom de code était Rome, ceux de 3ème génération dont le nom de code était Milan et ceux de 4ème génération dont le nom de code était Gênes ». Le fournisseur ajoute à cette liste les puces Epyc embedded (3000, 7002, 7003 et 9004).
A la fin janvier, Asus a divulgué la présence de failles dans le firmware des puces AMD Epyc. Le hic est que les correctifs n’étaient pas encore sortis. Ils sont maintenant disponibles, mais leur application devrait prendre du temps.
Le timing pour la publication des failles peut parfois tourner au casse-tête. Preuve en est avec AMD qui a mis à disposition en début de semaine des correctifs pour des failles de sécurité dans le micrologiciel des puces Epyc. La société a précisé que le problème pouvait entraîner la perte de la fonction Secure Encrypted Virtualization (SEV). L’inconvénient est que les détails de ces vulnérabilités ont été publiés par Asus dans le cadre d’une mise à jour bêta du Bios à la fin janvier. AMD n’était pas préparé et a mis un certain temps pour publier ses patchs.
Ce laps de temps aurait pu être préjudiciable à la cybersécurité des entreprises. Les spécialistes avaient exhorté les administrateurs à mettre en place des mesures d’isolement réseau et de blocage des mises à jour des correctifs en attendant la réponse d’AMD. Ce dernier avait relativisé la capacité à utiliser les brèches, « l’exécution de l’attaque nécessite un accès au système au niveau de l’administrateur local, ainsi que le développement et l’exécution d’un micrologiciel malveillant. »
Une application des patchs qui va prendre du temps
En raison de la nature des correctifs publiés, les utilisateurs doivent maintenant attendre que les OEM et d’autres partenaires mettent en œuvre les patchs dans le firmware spécifique de leur matériel. « Cette situation va peser sur les équipementiers des fournisseurs de matériel et cela peut entraîner un retard dans l’adoption », a déclaré John Price, CEO de la société de sécurité SubRosa, basée à Cleveland. Un avis partagé par Flavio Villanustre, responsable de la sécurité de LexisNexis Risk Solutions en estimant que les retards seront différents en fonction de la rapidité du fournisseur à appliquer les correctifs.
Matt Kimball, vice-président et analyste principal chez Moor Insights & Strategy considère lui qu’AMD a bien géré la situation. « Il est bon de voir AMD travailler avec sa communauté pour résoudre rapidement ces vulnérabilités. La quantité de travail nécessaire pour fournir un correctif – et le tester de manière approfondie – est considérable. Il s’agit d’une pression importante sur les ressources, d’où la bonne coordination de la part d’AMD », a-t-il déclaré.
Une longue liste de puces Epyc concernées
Flavio Villansutre insiste sur le fait que les administrateurs doivent se concentrer sur l’UEFI (unified extensible firmware interface), qui est l’interface entre l’OS et le microcode. « Si l’UEFI n’est pas mis à jour le problème du microcode reviendra à chaque démarrage des serveurs », souligne l’expert. « Cette situation montre à quel point les problèmes de firmware sont devenus un élément essentiel de l’informatique moderne », a déclaré John Price. « Cela va rendre les correctifs d’urgence plus difficiles à l’avenir. Ils nécessiteront des redémarrages complets du système », conclut le spécialiste.
A noter que le second correctif évite une attaque par canal latéral basée sur le cache, qui affecte également SEV. Ce problème concerne les « processeurs AMD Epyc de 1ère génération dont le nom de code était Naples, ceux de 2ème génération dont le nom de code était Rome, ceux de 3ème génération dont le nom de code était Milan et ceux de 4ème génération dont le nom de code était Gênes ». Le fournisseur ajoute à cette liste les puces Epyc embedded (3000, 7002, 7003 et 9004).
Plusieurs réglementations internationales et en particulier l’Ofac aux Etats-Unis imposent aux développeurs open source de ne pas travailler avec des pays touchés par des sanctions. La Fondation Linux a publié un guide pour détailler ces différents cadres et les risques.
En octobre dernier, Greg Kroah-Hartman, responsable de la maintenance du noyau Linux stable et Linus Torvalds, fondateur de Linux ont annoncé que onze développeurs russes avaient été démis de leurs fonctions. La conséquence selon Linus Torvalds des « sanctions contre les russes ». Il fait référence aux sanctions prévues par l’Ofac (office assets control) et d’autres réglementations mondiales similaires. L’affaire est prise au sérieux par la Fondation Linux qui vient de publier un guide à l’attention des développeurs pour les aider à comprendre l’ensemble de ces cadres.
Dans un blog, l’organisme indique que les risques accrus en matière de cybersécurité et de conformité réglementaire imposent aux communautés open source des obligations dont elles doivent tenir compte. Le guide se nomme « Navigating Global Regulations and Open Source : US OFAC Sanctions ». Le focus sur la réglementation américaine est justifié par l’affaire du mois d’octobre sur le noyau Linux. « Les questions relatives aux programmes de sanctions de l’Ofac ne sont pas courantes, mais il est important d’en être conscient », explique la Fondation.
Une liste non exhaustive de pays, des régions et d’organisations
La violation des sanctions décidées par l’administration américaine peut avoir de graves conséquences, notamment d’importantes amendes et des sanctions pénales. Ces peines ne s’appliquent pas seulement aux transactions financières, mais souvent à presque toutes les interactions avec une cible de sanctions, y compris dans les espaces de la communauté open source. De nombreux autres pays ont également mis en place des programmes de sanctions similaires, notamment l’Union européenne, le Royaume-Uni, le Japon, l’Australie, la Suisse, la Chine et bien d’autres encore. Parmi les pays sanctionnés par l’Ofac figurent des pays qui font l’objet de sanctions globales comme la Russie, l’Iran, Cuba et la Corée du Nord, plus d’autres pays comme l’Irak, le Liban, le Venezuela et le Nicaragua.
Les américains publient une liste de ressortissants spécifiques (SDN) avec un moteur de recherche. Grâce à lui, un utilisateur peut vérifier si une entreprise ou une administration figurent sur la liste. Certaines sanctions s’appliquent à des pays entiers (par exemple, l’Iran), à des régions (par exemple, la Crimée en Ukraine) ou à des gouvernements (par exemple, le gouvernement du Venezuela). « La liste SDN de l’Ofac et l’outil de recherche ne sont pas non plus exhaustifs et toute analyse ne peut se fonder uniquement sur cette liste », précise la Fondation. Celle-ci ajoute « nous ne pouvons que regretter que la communauté open source ne puisse pas fonctionner indépendamment des programmes de sanctions internationales, mais elles sont la loi de chaque pays et ne sont pas optionnelles ».
Plusieurs réglementations internationales et en particulier l’Ofac aux Etats-Unis imposent aux développeurs open source de ne pas travailler avec des pays touchés par des sanctions. La Fondation Linux a publié un guide pour détailler ces différents cadres et les risques.
En octobre dernier, Greg Kroah-Hartman, responsable de la maintenance du noyau Linux stable et Linus Torvalds, fondateur de Linux ont annoncé que onze développeurs russes avaient été démis de leurs fonctions. La conséquence selon Linus Torvalds des « sanctions contre les russes ». Il fait référence aux sanctions prévues par l’Ofac (office assets control) et d’autres réglementations mondiales similaires. L’affaire est prise au sérieux par la Fondation Linux qui vient de publier un guide à l’attention des développeurs pour les aider à comprendre l’ensemble de ces cadres.
Dans un blog, l’organisme indique que les risques accrus en matière de cybersécurité et de conformité réglementaire imposent aux communautés open source des obligations dont elles doivent tenir compte. Le guide se nomme « Navigating Global Regulations and Open Source : US OFAC Sanctions ». Le focus sur la réglementation américaine est justifié par l’affaire du mois d’octobre sur le noyau Linux. « Les questions relatives aux programmes de sanctions de l’Ofac ne sont pas courantes, mais il est important d’en être conscient », explique la Fondation.
Une liste non exhaustive de pays, des régions et d’organisations
La violation des sanctions décidées par l’administration américaine peut avoir de graves conséquences, notamment d’importantes amendes et des sanctions pénales. Ces peines ne s’appliquent pas seulement aux transactions financières, mais souvent à presque toutes les interactions avec une cible de sanctions, y compris dans les espaces de la communauté open source. De nombreux autres pays ont également mis en place des programmes de sanctions similaires, notamment l’Union européenne, le Royaume-Uni, le Japon, l’Australie, la Suisse, la Chine et bien d’autres encore. Parmi les pays sanctionnés par l’Ofac figurent des pays qui font l’objet de sanctions globales comme la Russie, l’Iran, Cuba et la Corée du Nord, plus d’autres pays comme l’Irak, le Liban, le Venezuela et le Nicaragua.
Les américains publient une liste de ressortissants spécifiques (SDN) avec un moteur de recherche. Grâce à lui, un utilisateur peut vérifier si une entreprise ou une administration figurent sur la liste. Certaines sanctions s’appliquent à des pays entiers (par exemple, l’Iran), à des régions (par exemple, la Crimée en Ukraine) ou à des gouvernements (par exemple, le gouvernement du Venezuela). « La liste SDN de l’Ofac et l’outil de recherche ne sont pas non plus exhaustifs et toute analyse ne peut se fonder uniquement sur cette liste », précise la Fondation. Celle-ci ajoute « nous ne pouvons que regretter que la communauté open source ne puisse pas fonctionner indépendamment des programmes de sanctions internationales, mais elles sont la loi de chaque pays et ne sont pas optionnelles ».