Pour renforcer la sécurité des applications avec des fonctionnalités dédiées aux API, F5 Networks met à profit la technologie issue du rachat de Wib Security.
L’équipementier F5 renforce la sécurité des applications en ajoutant un service à son package principal Distributed Cloud Service. Lancé en 2023, ce dernier est une plateforme SaaS permettant la gestion des applications, la gestion de l’infrastructure et les services de sécurité sur les sites cloud publics, cloud privés et edge des clients. Le service de découverte et de protection des API du fournisseur vise à offrir aux clients un moyen simple de découvrir les points d’extrémité des API, de surveiller le trafic à la recherche de vulnérabilités, de fournir des tests et de protéger les applications. “L’objectif principal est de protéger les entreprises de l’exfiltration de données par le biais d’API non surveillées, mal implémentées ou mal configurées”, a déclaré Kara Sprague, vice-présidente exécutive et directrice des produits chez F5. “Le service offre aux entreprises une vision beaucoup plus claire des API qu’elles ont exposées au public et du type de données que ces API échangent, afin qu’elles puissent sécuriser beaucoup plus facilement ces données.”
L’ère des applications monolithiques, traditionnelles client-serveur à trois niveaux, est révolue, a déclaré Mme Sprague. Selon l’étude 2024 State of Application Strategy de F5, 88% des organisations déploient leurs applications et leurs API dans des environnements hybrides qui englobent les sites sur site et dans le cloud, et près de 40% des organisations exploitent des applications et des API dans six environnements différents. “Les nouvelles applications d’aujourd’hui sont basées sur des conteneurs et des microservices, et ces applications natives de conteneurs et de microservices sont toutes dotées d’API qui constituent en fait les portes d’entrée vers la logique applicative moderne et qui sont désormais la principale cible des cyberattaques”, a déclaré Mme Sprague.
Wib Security assure une visibilité complète des API
Le service F5 utilise la technologie de sécurité des API issue du récent rachat de la start-up israélienne Wib Security (10 millions de dollars environ). Cette dernière comprend des fonctionnalités d’analyse de code, de détection des vulnérabilités et d’évaluation des risques qui permettent aux clients de surveiller les processus de développement des applications afin d’atténuer les menaces et de repérer les problèmes, peu importe où ils se trouvent, avant qu’ils ne pénètrent sur le réseau de l’entreprise. “La sécurité des applications devient de plus en plus importante dans le secteur. Les entreprises sont contraintes – par les interactions avec les fournisseurs, les considérations relatives à la chaîne d’approvisionnement et/ou les contrôles de conformité réglementaire – d’examiner et de documenter la manière dont leurs applications sont utilisées, développées et sécurisées”, a déclaré Christopher Steffen, directeur de recherche chez Enterprise Management Associates.
“Les entreprises se rendent compte que nombre de leurs applications sont multigénérationnelles. Ce qui signifie qu’il est possible, voire probable, que les applications utilisées aient été développées sur une base qui a plusieurs générations techniques de retard”, a souligné M. Steffen. “La technologie est tellement obsolète que vous avez souvent besoin d’un spécialiste pour refactoriser l’application en quelque chose de plus moderne et utilisable. C’est extrêmement coûteux, et même avec un réaménagement, la sécurité est souvent une considération secondaire ou tertiaire dans le processus.” Alors que de nombreuses fonctions existaient en tant qu’offres indépendantes et autonomes, F5 a maintenant combiné les outils en une plateforme holistique, ce qui devrait être intéressant à la fois pour les développeurs et les gestionnaires, a indiqué M. Steffen. “Lorsque les développeurs disposent d’un outil unique conçu en fonction de leurs processus, qui leur fournit des informations exploitables au lieu d’un vague message “c’est cassé”, ils sont beaucoup plus susceptibles de l’utiliser”, a déclaré M. Steffen.
Plus d’automatisation
“En l’état actuel des choses, un ingénieur de développement doit utiliser une suite d’outils vaguement intégrés pour accomplir un grand nombre des mêmes fonctions que la solution F5 pourra accomplir pour lui en une seule fois. Les équipes de développement recherchent les meilleurs outils de sécurité qui non seulement répondent à leurs exigences en matière de sécurité, mais qui créent également le moins de friction possible dans leurs processus. Je pense que F5 a fait un grand pas dans cette direction”, a poursuivi M. Steffen. En plus de son service API, F5 promet d’intégrer de l’IA à son service cloud distribué. Par exemple, plus tard cette année, le fournisseur prévoit d’introduire un assistant IA basé sur le langage naturel pour aider les équipes de sécurité informatique à identifier plus facilement les anomalies, à interroger et à générer des configurations de politiques, et à appliquer des mesures correctives, a rapporté M. Sprague. « L’assistant fera partie de la console Distributed Cloud et permettra aux utilisateurs d’interroger leurs ensembles de données pour obtenir des recommandations sur les mesures et les capacités de sécurité qu’ils devraient appliquer à leurs diverses applications et API, entre autres cas d’utilisation ».
L’assistant IA fera partie d’un service plus large basé sur l’IA appelé AI Data Fabric, qui agrègera les données des Distributed Cloud Services ainsi que du système de support d’application NGinx de F5 et du portefeuille de produits réseau BIG-IP. À partir de ces données, la société prévoit de fournir des rapports et des analyses, voire de former et de déployer des modèles de machine learning pour exécuter des inférences afin de mieux sécuriser et optimiser les applications, a précisé M. Sprague. « L’idée derrière AI Data Fabric sera de fournir des services intelligents qui permettront aux entreprises de répondre aux menaces en temps réel, de générer des recommandations pour les aider à prendre des décisions plus éclairées et à prendre des mesures rapides telles que la correction », a assuré M. Sprague.
Incubé au sein de l’entité Outshift, le service cloud Motific vient aider les entreprises à créer rapidement et avec plus de sécurité des applications exploitant des ressources IA génératives.
Au sein de Cisco, une entité particulièrement innovante a récemment été baptisée : il s’agit de l’incubateur maison qui porte désormais le nom d’Outshift. ” Nous travaillons sur les nouvelles technologies dans les domaines qui peuvent avoir un impact majeur pour Cisco en termes de futurs produits », nous a expliqué Guillaume Sauvage de St Marc, vice-président engineering chez Outshift by Cisco. Après Calisti (application de gestion de services mesh basée sur Istio), Panoptica (suite de sécurité pour les apps nativement cloud mélangeant des conteneurs et des API), Kubeclarity (scanners de vulnérabilités), APIclarity (inventaire des API), l’incubateur de Cisco a mis en avant Motific à l’occasion de sa convention Europe annuelle (à Amsterdam de nouveau du 5 au 7 février). ” Le seul point de connexion avec Panoptica c’est que ce sont les mêmes modules de sécurité sur la partie LLM mais rebaptisés Motific. L’idée est de simplifier, et d’accélérer l’adoption de la GenAI dans les entreprises en supportant des moteurs comme OpenAI ou Mistral AI”. Le même problème se pose dans toutes les entreprises : pour que les résultats soient pertinents, il est nécessaire de donner un accès aux données propre à l’entreprise. Les GenAI ont un savoir très généraliste, mais les employés ont besoin de plus.
Cisco propose donc un service en mode cloud qui apporte aux entreprises un hub centralisé pour gérer les éléments d’IA génératives tels que les modèles de langage étendu (LLM), les contrôles de sécurité, les API et bien plus encore. Motific vient rationaliser et accélérer la création, le déploiement et la gestion d’applications génératives basées sur l’IA pour l’entreprise. « Considérez Motific comme un guichet unique où une tonne de personnages – grands modèles de langage, ChatGPT, etc. – se réunissent avec des politiques et des sources de données spécifiques à l’organisation de l’entreprise pour faciliter la création et le déploiement d’applications d’IA génératives de manière sûre et sécurisée », a indiqué Vijoy Pandey, vice-président senior d’Outshift.
Des modules Panoptica sont réutilisées dans le service cloud Motific. (Crédit S.L.)
Réduire le temps de développement des apps GenAI
Les entreprises souhaitent standardiser et modéliser les éléments de base couramment utilisés dans les applications GenAI, tels que les assistants, les API, les modèles de base, les bases de connaissances pour la génération augmentée par récupération (RAG) et les contrôles politiques, et Motific répond à ces besoins, a déclaré M. Pandey. Le RAG est un cadre d’IA qui augmente généralement la qualité des réponses LLM en incluant des ressources provenant de divers endroits afin de renforcer l’exactitude, la crédibilité et la pertinence contextuelle de ces réponses. Une fois en place, Motific découvre toutes les ressources d’IA générative dans l’entreprise et permet aux clients de définir des modèles et des politiques pour des applications spécifiques. « Par exemple, si un client souhaite créer un assistant financier pour le directeur financier, il crée le modèle qui définirait les politiques, les contrôles d’identité et d’accès dont il aurait besoin, ainsi que les LLM dont il dispose pour développer cet assistant, et Motific vient contrôler et surveiller ce développement”, a précisé Vijoy Pandey.
L’idée est de réduire le temps de développement des applications GenAI de quelques mois à quelques jours. Motific propose en outre des contrôles de conformité pour la surutilisation, les dépassements de dépenses et l’intégration de sources de données spécifiques à l’entreprise, a-t-il déclaré. Il suit également les processus métier et génère des informations d’utilisation avec une analyse du retour sur investissement et des coûts, y compris des pistes d’audit de surveillance consolidées et un suivi des indicateurs clés de toutes les demandes des utilisateurs. « Motific utilise une tonne de technologie d’IA générative sous le capot lui-même. Par exemple, il utilise une « unité de traitement rapide » pour fournir des informations qui minimisent les hallucinations et la toxicité de l’IA dans le processus de développement », a déclaré Pandey.
Plus de sécurité
Les entreprises peuvent utiliser les contrôles de politique intégrés de Motific – pour gérer la conformité, les données sensibles, la sécurité et l’accès, par exemple – ou les personnaliser en fonction de leurs propres politiques internes. Côté sécurité, la première version de Motific implémente les outils et technologies de l’Open Worldwide Application Security Project (OWASP) pour sécuriser les applications. “Motific informera les équipes de sécurité s’il y a un problème de sécurité et indiquera où cela se produit, puis les laissera mettre en quarantaine le chemin d’attaque concerné”, a ajouté le dirigeant. “Le système peut également générer un code de correction pour aider à résoudre le problème.” Motific sera disponible en juin prochain.
Le gouvernement chinois a validé une quarantaine de modèle d’IA pour une usage public au cours des six derniers mois. Une manière de montrer aux Etats-Unis l’inefficacité des restrictions imposées à la Chine.
La Chine accélère dans le domaine de l’IA et en particulier sur les modèles d’IA. Selon le journal étatique Securities Times, le pays a déjà approuvé pas moins de 40 LLM à usage public au cours des six derniers mois. Depuis le mois d’août dernier, Pékin a décidé de valider par lot ces modèles. Récemment, les autorités ont retenu 14 modèles dont ceux de Xiaomi, 4Paradigm et 01.AI.
Le premier lot a validé les LLM d’Alibaba, Baidu et ByteDance. Les deuxièmes et troisième tranches ont été attribuées en novembre et décembre. L’an dernier, les instituts de recherche publics chinois ont indiqué que les entreprises IT avaient lancé 79 grands modèles de langage (LLM). Le gouvernement chinois n’a pas révélé le nombre réel d’autorisations d’IA qu’il a accordées à ce jour. Ce chiffre est d’autant plus important que la Chine est engagée dans une bataille pour la suprématie dans le secteur technologique avec les États-Unis, qui a vu les deux pays déployer des stratégies visant à contrecarrer les progrès de l’autre.
Les Etats-Unis montent leur surveillance
L’information sur les LLM chinois arrive à un moment où les États-Unis préparent un décret pour surveiller les modèles d’IA formés sur les fournisseurs de services cloud, comme Microsoft, Google et AWS, afin de prendre des mesures supplémentaires pour faire face à « l’urgence nationale en ce qui concerne les activités cybermalveillantes importantes ». Cependant, l’an dernier, lors de l’UK AI Safety Summit, le sommet britannique sur la sécurité de l’IA, les deux pays ont signé la Déclaration de Bletchley, un accord de coopération entre plusieurs pays, dont les États-Unis et la Chine, pour mener une réflexion commune sur l’évolution de l’IA et garantir que la technologie progresse en toute sécurité.
À l’instar du mécanisme d’approbation de l’IA mis en place par Pékin, le président américain Joe Biden a publié en octobre de l’année dernière un décret établissant des règles claires et des mesures de surveillance afin de garantir que l’IA reste sous contrôle, tout en lui ouvrant des voies de développement.
Récemment, Solarwinds a demandé à la justice de rejeter les accusations de la SEC concernant la mauvaise gestion interne de la cyberattaque Sunburst de 2020. La société souhaite l’abandon des poursuites.
Dans le contentieux opposant Solarwinds à la SEC sur la cyberattaque de 2020, la société a nié les accusations du gendarme américain de la bourse de mauvaise gestion interne. C’est ce qui ressort d’une requête en annulation déposée auprès du tribunal du district sud de New York. L’entreprise conteste les poursuites engagées par la SEC en octobre 2023 pour « divulgation insuffisante ». Dans sa requête, Solarwinds demande le rejet de toutes les accusations à son encontre, mais aussi contre son CISO, Timothy G .Brown.
La SEC leur reproche notamment d’avoir trompé les investisseurs en ne divulguant pas les « risques connus », d’avoir violé les règles sur les contrôles de divulgation et d’avoir présenté de manière inexacte les mesures de cybersécurité de l’entreprise pendant et avant l’attaque de cyber-espionnage soutenue par la Russie. « La SEC cherche à victimiser la victime en portant des accusations de fraude sur la sécurité et les contrôles contre l’entreprise et son CISO, Tim Brown », a déclaré Solarwinds dans le document déposé au tribunal. « L’affaire est fondamentalement lacunaire et devrait être rejetée dans son intégralité », a ajouté la firme qui considère ces accusations totalement « infondées », ajoutant qu’elle a, « rapidement et de manière transparente, informé sur l’attaque et les investisseurs au fur et à mesure de l’avancement de son enquête ».
Des accusations inexplicables, selon Solarwinds
Dans sa requête, le spécialiste de la gestion de l’IT maintient que les allégations de la SEC sont erronées et ne relèvent pas de son domaine d’expertise. Il estime qu’il s’agit d’un stratagème du régulateur en vue d’établir un mandat pour des réglementations de sécurité qui n’existent pas actuellement. « En ce qui concerne les accusations relatives aux contrôles, la SEC ne parvient pas à identifier les contrôles de divulgation dont l’élaboration aurait été déraisonnable », a déclaré Solarwinds. « Et sa théorie sur les violations des « contrôles internes » équivaut à une réécriture complète de la loi. L’agence cherche à transformer le concept de responsabilité sur les contrôles internes en un vaste mandat lui permettant de réglementer les contrôles de cybersécurité des entreprises publiques, un rôle pour lequel la SEC n’a pas l’autorisation du Congrès ou l’expertise nécessaire », ajoute la plainte.
Toujours selon la société, « outre l’absence de « preuves matérielles » à l’appui de ses allégations de fraude, les accusations de violation de l’obligation d’information portées par la SEC dans le dossier d’octobre étaient irréalistes et illégales ». L’entreprise ajoute qu’elle avait prévenu ses parties prenantes que ses systèmes étaient « vulnérables à des acteurs sophistiqués soutenus par des États-nations ». « La SEC se plaint que ces informations sont insuffisantes, affirmant que les entreprises doivent divulguer des informations détaillées sur les vulnérabilités dans leurs notifications », poursuit SolarWinds dans sa plainte. « Mais ce n’est pas la loi, et pour une bonne raison : diffuser de tels détails serait inutile pour les investisseurs, peu pratique pour les entreprises, et néfaste pour les deux, car ils dévoileraient des feuilles de route aux attaquants ».
Les responsabilités du RSSI en point de mire
L’affaire a été suivie de près par le secteur car elle devrait créer de nombreux précédents, notamment sur la responsabilité du CISO. C’est la première fois qu’un RSSI d’entreprise est cité dans des accusations de la SEC pour non-divulgation. La procédure devrait permettre au CISO de faire l’objet d’un examen plus approfondi et d’assumer de nouvelles responsabilités. « Comme on pouvait s’y attendre, Solarwinds se défend en disant qu’elle a informé les investisseurs de manière adéquate », a déclaré Pareekh Jain, analyste en chef chez Pareekh Consulting. « La question est de savoir si cette information était suffisante ou s’il aurait fallu en faire plus. C’est la première fois qu’une enquête est menée sur la communication d’informations relatives à la cybersécurité à la SEC. Le jugement rendu dans cette affaire servira de principes directeurs aux RSSI pour les futures notifications de cybersécurité au régulateur », a-t-il ajouté.
Alors que Timothy G. Brown est accusé par la SEC d’avoir fait des déclarations publiques et signé des documents de sécurité internes qui, selon l’agence fédérale, ont contribué à tromper les investisseurs, Solarwinds qualifie ces accusations d’« injustifiées » et d’« inexplicables ». « La SEC ne parvient pas à articuler une théorie cohérente de complicité à l’encontre de Monsieur Brown », ajoute le document. Il est « un professionnel expérimenté et respecté qui a simplement fait son travail pendant les événements en question (et l’a bien fait). Les accusations gratuites de la SEC à son encontre doivent être rejetées ». Avant cette demande officielle de rejet des accusations de la SEC, le CEO de Solarwinds, Sudhakar Ramakrishna, avait publié les réponses de l’entreprise le même jour que le dépôt auprès de la SEC, qualifiant les accusations de « peu judicieuses » et représentatives d’un « ensemble régressif de points de vue et d’actions » incompatibles avec la manière dont doit progresser l’industrie.
Plusieurs vulnérabilités ont été identifiées dans le runtime de container runc exposant Docker mais aussi d’autres systèmes d’exécution de conteneurs. Principal risque : la couche d’isolation entre le conteneur et le système d’exploitation hôte peut être rompue.
Des chercheurs en sécurité ont découvert quatre vulnérabilités dans des composants de Docker qui pourraient permettre à des attaquants d’accéder à des systèmes d’exploitation hôtes à partir de conteneurs. L’une de ces vulnérabilités se trouve dans runc, un outil de ligne de commande permettant de créer et d’exécuter des conteneurs sous Linux, qui est à la base de plusieurs moteurs de conteneurs, et pas seulement de Docker. Ce n’est pas la première fois que ce runtime de container est touché par des failles de sécurité. Les vulnérabilités ont été découvertes par Rory McNamara, un chercheur de la société de sécurité informatique Snyk, qui les a collectivement baptisées « Leaky Vessels », car elles permettent de rompre la couche d’isolation critique entre les conteneurs et le système d’exploitation hôte. « Ces évasions de conteneurs pourraient permettre à un attaquant d’obtenir un accès non autorisé au système d’exploitation hôte sous-jacent à partir du conteneur et potentiellement permettre l’accès à des données sensibles (identifiants, informations sur les clients, etc.), et lancer d’autres attaques, en particulier lorsque l’accès obtenu comprend des privilèges de super-utilisateur », a déclaré Snyk dans un billet de blog.
De multiples voies d’attaque à partir de runc
Runc peut être considéré comme la tuyauterie qui relie la plupart des moteurs de gestion de conteneurs tels que Docker, containerd, Podman et CRI-O aux fonctionnalités de sandboxing du noyau Linux : groupes de contrôle, espaces de noms, seccomp, apparmor, etc. Il prend en charge plusieurs commandes pour démarrer, arrêter, suspendre, mettre en pause et répertorier les conteneurs, ainsi que pour exécuter des processus à l’intérieur des conteneurs. La faille dans runc découverte par Rory McNamara, répertoriée sous le nom de CVE-2024-21626, provient d’un descripteur de fichier divulgué par inadvertance en interne au sein de runc, y compris un handle vers le groupe /sys/fs/c de l’hôte. Ceci peut être exploité de plusieurs façons : une repérée par McNamara et trois autres trouvées par les mainteneurs de runc. « Si le conteneur a été configuré pour que process.cwd soit défini sur /proc/self/fd/7/ (le fd réel peut changer en fonction de l’ordre d’ouverture des fichiers dans runc), le processus pid1 résultant aura un répertoire de travail dans l’espace de noms de montage de l’hôte et le processus engendré pourra donc accéder à l’ensemble du système de fichiers de l’hôte », avertissent les responsables de runc dans une note d’information. « Cela ne constitue pas en soi un exploit contre runc. Cependant, une image malveillante pourrait faire de n’importe quel chemin non-/ d’apparence inoffensive un lien symbolique vers /proc/self/fd/7/ et ainsi tromper un utilisateur en lui faisant démarrer un conteneur dont le binaire a accès au système de fichiers de l’hôte ». Cet exploit cible la commande runc run, qui est utilisée pour créer et démarrer un conteneur à partir d’une image. De nombreux conteneurs sont démarrés à partir d’images téléchargées à partir de dépôts publics tels que Docker Hub et des images malveillantes ont été téléchargées dans le registre au fil du temps.
Une autre variante de l’attaque concerne runc exec utilisé pour démarrer un processus à l’intérieur d’un conteneur existant. Pour ce faire, l’attaquant doit savoir qu’un processus administratif appelle runc exec avec l’argument -cwd et un chemin spécifique, puis remplacer ce chemin par un lien symbolique vers le descripteur de fichier /proc/self/fd/7. Une troisième attaque consiste à utiliser la technique runc run ou runc exec pour écraser les binaires du système d’exploitation hôte, tels que /bin/bash – l’interpréteur de commandes de Linux. Ces deux variantes sont connues sous le nom d’attaques 3a et 3b. « Alors que l’attaque 3a est la plus grave du point de vue de CVSS, les attaques 2 et 3b sont sans doute plus dangereuses en pratique car elles permettent une évasion depuis l’intérieur d’un conteneur plutôt que d’exiger qu’un utilisateur exécute une image malveillante », ont prévenu les responsables de runc. Cependant, cela dépend du contexte. Par exemple, dans les systèmes d’exécution de niveau supérieur comme Docker ou Kubernetes, toute personne ayant les droits de démarrer une image de conteneur peut exécuter l’exploit à distance. L’attaque peut également être lancée en utilisant la fonction ONBUILD dans les fichiers Docker. Bien que runc soit probablement le runtime de conteneur le plus populaire et le plus utilisé en raison de son association avec Docker, ce n’est pas le seul disponible. Les responsables de runc préviennent que d’autres runtimes sont potentiellement vulnérables à des attaques similaires ou ne disposent pas d’une protection suffisante contre celles-ci.
Comment atténuer la vulnérabilité runc de Docker
En plus du trou de sécurité runc, corrigé dans la dernière version 1.1.12, Rory McNamara a également trouvé des vulnérabilités d’échappement de conteneur dans d’autres composants Docker tels que BuildKit (CVE-2024-23652 et CVE-2024-23653) et une condition de course de cache (CVE-2024-23651).
« Recherchez les annonces du fournisseur de vos systèmes de déploiement et d’orchestration de conteneurs concernant les mises à jour pour résoudre le problème ou les déclarations dans les cas où ils ne sont pas affectés », ont déclaré les chercheurs de Snyk. « Cela signifie probablement que vous devez mettre à jour vos Docker Daemon et vos déploiements Kubernetes, ainsi que tous les outils de construction de conteneurs que vous utilisez dans les pipelines CI/CD, sur les serveurs de construction et sur les postes de travail de vos développeurs ». Snyk a également développé deux outils open source qui permettent aux utilisateurs de surveiller leurs conteneurs pour détecter les signes de tentatives d’exploitation. L’un est un scanner d’exécution qui utilise des crochets eBPF pour surveiller les invocations suspectes de commandes de construction et d’exécution de conteneurs qui correspondent aux modèles de cet exploit, et l’autre est un scanner statique pour les fichiers et les images Docker.
Plusieurs vulnérabilités ont été identifiées dans le runtime de container runc exposant Docker mais aussi d’autres systèmes d’exécution de conteneurs. Principal risque : la couche d’isolation entre le conteneur et le système d’exploitation hôte peut être rompue.
Des chercheurs en sécurité ont découvert quatre vulnérabilités dans des composants de Docker qui pourraient permettre à des attaquants d’accéder à des systèmes d’exploitation hôtes à partir de conteneurs. L’une de ces vulnérabilités se trouve dans runc, un outil de ligne de commande permettant de créer et d’exécuter des conteneurs sous Linux, qui est à la base de plusieurs moteurs de conteneurs, et pas seulement de Docker. Ce n’est pas la première fois que ce runtime de container est touché par des failles de sécurité. Les vulnérabilités ont été découvertes par Rory McNamara, un chercheur de la société de sécurité informatique Snyk, qui les a collectivement baptisées « Leaky Vessels », car elles permettent de rompre la couche d’isolation critique entre les conteneurs et le système d’exploitation hôte. « Ces évasions de conteneurs pourraient permettre à un attaquant d’obtenir un accès non autorisé au système d’exploitation hôte sous-jacent à partir du conteneur et potentiellement permettre l’accès à des données sensibles (identifiants, informations sur les clients, etc.), et lancer d’autres attaques, en particulier lorsque l’accès obtenu comprend des privilèges de super-utilisateur », a déclaré Snyk dans un billet de blog.
De multiples voies d’attaque à partir de runc
Runc peut être considéré comme la tuyauterie qui relie la plupart des moteurs de gestion de conteneurs tels que Docker, containerd, Podman et CRI-O aux fonctionnalités de sandboxing du noyau Linux : groupes de contrôle, espaces de noms, seccomp, apparmor, etc. Il prend en charge plusieurs commandes pour démarrer, arrêter, suspendre, mettre en pause et répertorier les conteneurs, ainsi que pour exécuter des processus à l’intérieur des conteneurs. La faille dans runc découverte par Rory McNamara, répertoriée sous le nom de CVE-2024-21626, provient d’un descripteur de fichier divulgué par inadvertance en interne au sein de runc, y compris un handle vers le groupe /sys/fs/c de l’hôte. Ceci peut être exploité de plusieurs façons : une repérée par McNamara et trois autres trouvées par les mainteneurs de runc. « Si le conteneur a été configuré pour que process.cwd soit défini sur /proc/self/fd/7/ (le fd réel peut changer en fonction de l’ordre d’ouverture des fichiers dans runc), le processus pid1 résultant aura un répertoire de travail dans l’espace de noms de montage de l’hôte et le processus engendré pourra donc accéder à l’ensemble du système de fichiers de l’hôte », avertissent les responsables de runc dans une note d’information. « Cela ne constitue pas en soi un exploit contre runc. Cependant, une image malveillante pourrait faire de n’importe quel chemin non-/ d’apparence inoffensive un lien symbolique vers /proc/self/fd/7/ et ainsi tromper un utilisateur en lui faisant démarrer un conteneur dont le binaire a accès au système de fichiers de l’hôte ». Cet exploit cible la commande runc run, qui est utilisée pour créer et démarrer un conteneur à partir d’une image. De nombreux conteneurs sont démarrés à partir d’images téléchargées à partir de dépôts publics tels que Docker Hub et des images malveillantes ont été téléchargées dans le registre au fil du temps.
Une autre variante de l’attaque concerne runc exec utilisé pour démarrer un processus à l’intérieur d’un conteneur existant. Pour ce faire, l’attaquant doit savoir qu’un processus administratif appelle runc exec avec l’argument -cwd et un chemin spécifique, puis remplacer ce chemin par un lien symbolique vers le descripteur de fichier /proc/self/fd/7. Une troisième attaque consiste à utiliser la technique runc run ou runc exec pour écraser les binaires du système d’exploitation hôte, tels que /bin/bash – l’interpréteur de commandes de Linux. Ces deux variantes sont connues sous le nom d’attaques 3a et 3b. « Alors que l’attaque 3a est la plus grave du point de vue de CVSS, les attaques 2 et 3b sont sans doute plus dangereuses en pratique car elles permettent une évasion depuis l’intérieur d’un conteneur plutôt que d’exiger qu’un utilisateur exécute une image malveillante », ont prévenu les responsables de runc. Cependant, cela dépend du contexte. Par exemple, dans les systèmes d’exécution de niveau supérieur comme Docker ou Kubernetes, toute personne ayant les droits de démarrer une image de conteneur peut exécuter l’exploit à distance. L’attaque peut également être lancée en utilisant la fonction ONBUILD dans les fichiers Docker. Bien que runc soit probablement le runtime de conteneur le plus populaire et le plus utilisé en raison de son association avec Docker, ce n’est pas le seul disponible. Les responsables de runc préviennent que d’autres runtimes sont potentiellement vulnérables à des attaques similaires ou ne disposent pas d’une protection suffisante contre celles-ci.
Comment atténuer la vulnérabilité runc de Docker
En plus du trou de sécurité runc, corrigé dans la dernière version 1.1.12, Rory McNamara a également trouvé des vulnérabilités d’échappement de conteneur dans d’autres composants Docker tels que BuildKit (CVE-2024-23652 et CVE-2024-23653) et une condition de course de cache (CVE-2024-23651).
« Recherchez les annonces du fournisseur de vos systèmes de déploiement et d’orchestration de conteneurs concernant les mises à jour pour résoudre le problème ou les déclarations dans les cas où ils ne sont pas affectés », ont déclaré les chercheurs de Snyk. « Cela signifie probablement que vous devez mettre à jour vos Docker Daemon et vos déploiements Kubernetes, ainsi que tous les outils de construction de conteneurs que vous utilisez dans les pipelines CI/CD, sur les serveurs de construction et sur les postes de travail de vos développeurs ». Snyk a également développé deux outils open source qui permettent aux utilisateurs de surveiller leurs conteneurs pour détecter les signes de tentatives d’exploitation. L’un est un scanner d’exécution qui utilise des crochets eBPF pour surveiller les invocations suspectes de commandes de construction et d’exécution de conteneurs qui correspondent aux modèles de cet exploit, et l’autre est un scanner statique pour les fichiers et les images Docker.
Les méthodes d’accès à la mémoire de la classe sun.misc.Unsafe vieille de 20 ans dans Java pour effectuer des opérations de bas niveau seront prochainement supprimées. Leurs remplaçants java.lang.invoke dans JDK 9 et java.lang.foreign dans JDK 22 sont à privilégier.
Les méthodes d’accès à la mémoire de la classe sun.misc.Unsafe de Java seraient dépréciées pour être supprimées dans une prochaine version de la plateforme, dans le cadre d’une proposition d’amélioration du JDK (JEP) préparée par la communauté OpenJDK. Sur les 87 méthodes de la classe, 79 seraient supprimées. Ces méthodes non prises en charge ont des remplaçants suppportés depuis le JDK 9, pour l’accès à la mémoire on-heap, et le JDK 22, pour l’accès à la mémoire off-heap, selon la proposition. Les développeurs de bibliothèques sont fortement encouragés à migrer de sun.misc.Unsafe vers ces alternatives. La proposition vise notamment à préparer la suppression de ces méthodes d’accès à la mémoire dans une prochaine version de Java et à aider les développeurs à savoir quand leurs applications s’appuient sur ces méthodes. A noter qu’elle ne vise pas à supprimer entièrement la classe sun.misc.Unsafe, car un petit nombre de ses méthodes ne sont pas utilisées pour l’accès à la mémoire et resteront non dépréciées.
le document ne cite pas de version spécifique de Java qui rendrait ces méthodes obsolètes. La prochaine itération de Java standard, JDK 22, prévue pour mars, a déjà gelé ses fonctionnalités. Mais le JDK 23, qui devrait être publié en septembre, pourrait être une cible possible. Dans le passé, le code non sécurisé était considéré comme nécessaire à la programmation de bas niveau. La classe sun.misc.Unsafe a été introduite en 2002 pour permettre aux classes Java du JDK d’effectuer des opérations de bas niveau. Ses méthodes d’accès à la mémoire, comme le nom de la classe l’indique, ne sont pas sûres et peuvent entraîner un comportement indéfini, c’est pourquoi elles n’ont pas été exposées en tant qu’API standard. Elles ont été introduites en partant du principe qu’elles étaient exclusivement réservées au JDK, que les appelants au sein du JDK effectueraient des contrôles de sécurité exhaustifs avant de les utiliser et que des API standard sûres pour cette fonctionnalité seraient ajoutées à la plateforme Java, selon la proposition.
Un risque avéré de défaillance et de plantage
Mais comme, il n’existait en 2002 aucun moyen d’empêcher sun.misc.Unsafe d’être utilisé en dehors du JDK, ses méthodes d’accès à la mémoire sont devenues un couteau suisse pour les développeurs de bibliothèques qui souhaitaient disposer de plus de puissance et de performances que celle fournie les API standard. Malheureusement, toutes les bibliothèques n’effectuent pas de contrôles de sécurité avant d’appeler ces méthodes, ce qui présente un risque de défaillances et de plantages dans les applications. Au cours des dernières années, deux API standard ont été introduites pour remplacer les méthodes d’accès à la mémoire dans sun.misc.Unsafe. Il s’agit de java.lang.invoke du JDK 9 et de java.lang.foreign du JDK 22.
La découverte d’une faille dans la solution de CI/CD Jenkins n’aura pas mis longtemps à être exploitée avec la publication de PoC sur GitHub. Les cybercriminels se sont empressés de scanner Internet à la recherche de serveurs Jenkins vulnérables.
Le temps presse pour corriger une faille découverte dans Jenkins, la solution de déploiement continu à l’intention des développeurs. En effet, à peine trouvée, la vulnérabilité fait l’objet de plusieurs exploits disponibles sur GitHub ouvrant ainsi la voie à une multiplication d’attaques. D’après les analyses effectuées par le service Shodan, plus de 75 000 serveurs Jenkins sont exposés à Internet. Ce service est couramment utilisé pour l’intégration continue et de la livraison continue (CI/CD), car il permet d’automatiser la construction, le test et le déploiement du code.
Compte tenu de ses nombreuses intégrations avec d’autres services et outils, Jenkins est très populaire dans toutes les entreprises de développement. Sa part de marché est estimée à environ 44%. Qualifiée de critique, la vulnérabilité, référencée CVE-2024-23897, résulte d’un problème de lecture arbitraire de fichier que les attaquants peuvent exploiter pour lire des fichiers binaires entiers ou partiels à partir du système de fichiers. Ils peuvent ainsi extraire des clés secrètes et les utiliser pour élever leurs privilèges au niveau administrateur et exécuter du code malveillant. Ce problème a été corrigé dans les versions 2.442 et LTS 2.426.3 de Jenkins, en même temps que plusieurs autres failles de gravité élevée et moyenne.
Des lignes de commandes exposent des secrets
La faille provient de l’utilisation par Jenkins de la bibliothèque args4j pour analyser les arguments de commande (command line argument parsing), et les options lors du traitement des commandes envoyées via l’interface de ligne de commande (CLI) de Jenkins. L’analyseur remplace le caractère @ suivi d’un chemin d’accès à un fichier dans un argument de commande par le contenu du fichier, exposant ainsi potentiellement des secrets. Selon les chercheurs de SonarSource, qui ont découvert et signalé la vulnérabilité, les attaquants non authentifiés peuvent l’exploiter s’ils obtiennent l’autorisation de lecture sur le serveur. Ce qui est possible dans plusieurs configurations : si le serveur a une autorisation en mode legacy activée, si il est configuré avec « Allow anonymous read access » coché dans le mode d’autorisation « logged-in users can do anything », ou si la fonction signup est activée et permet à n’importe qui de créer un compte sur le serveur.
Même si aucune de ces conditions n’est remplie, les utilisateurs non authentifiés peuvent toujours lire les premières lignes des fichiers au lieu de leur contenu intégral. « Un attaquant pourrait tirer parti de cette situation en trouvant une commande qui prend un nombre arbitraire d’arguments et les affiche à l’utilisateur », expliquent les chercheurs dans un billet de blog. « Étant donné que les arguments sont tirés du contenu du fichier, un pirate pourrait faire fuiter le contenu du fichier de cette manière. Selon nos recherches, la commande connect-to-node est un bon candidat : elle reçoit une liste de chaînes comme argument et tente de se connecter à chacune d’entre elles. En cas d’échec, un message d’erreur est généré avec le nom du nœud connecté qui a échoué ». Parmi les fichiers du serveur susceptibles d’intéresser un pirate, on peut citer les clés SSH, le fichier /etc/passwd, le fichier /etc/shadow, les secrets et les informations d’identification du projet, le code source et les artefacts de construction, etc. L’équipe de sécurité de Jenkins documente plusieurs chemins d’attaque pour obtenir l’exécution de code à distance et d’autres vols de secrets avec cette vulnérabilité. Il s’agit notamment de l’utilisation abusive de la fonctionnalité « Resource Root URL », de la falsification des cookies « Remember me », de l’insertion d’attaques XSS (Cross-Site Scripting) dans les journaux de build, de la falsification des jetons de protection contre la falsification des requêtes intersites, du décryptage des secrets binaires et du téléchargement d’un dump mémoire Java.
Atténuer la vulnérabilité du serveur CI/CD Jenkins
Le correctif consiste à désactiver l’analyseur de commandes qui expose le contenu des fichiers. Cela peut poser des problèmes pour certains déploiements, auquel cas un mécanisme est disponible pour l’annuler. Cependant, son utilisation est fortement déconseillée sur les instances Jenkins accessibles sur le réseau par des non-administrateurs.
Un autre moyen d’atténuer la menace consiste à désactiver complètement l’accès à l’interface CLI de Jenkins jusqu’à ce que les correctifs puissent être appliqués. Des chercheurs en sécurité ont averti vendredi dernier que plusieurs exploits de preuve de concept pour cette vulnérabilité avaient déjà été publiés sur GitHub et d’autres ont déjà signalé des exploitations de la faille dans la nature.
Les services managés de Kyndryl s’étoffent avec l’arrivée de la plateforme Secure Access de Cisco, qui comprend un accès réseau Zero Trust (ZTNA), une passerelle web sécurisée (SWG) et un pare-feu en tant que service (FWaaS).
Cisco et la SSII Kyndryl étendent un peu plus leur partenariat en proposant aux entreprises deux services SaaS pour connecter en toute sécurité des ressources cloud, privées et edge. Appelé Kyndryl Consult Security Services Edge (SSE) with Cisco Secure Access, le premier service aide les clients à concevoir et à mettre en œuvre des environnements Secure Services Edge (SSE) et à définir des politiques. Quant au second service appelé Kyndryl Managed SSE with Cisco Secure Access, il fournit une implémentation SSE basée sur le cloud, entièrement managée par Kyndryl, en utilisant la technologie Cisco.
Les deux services intègrent la plateforme SSE Secure Access de l’équipementier, qui comprend un accès réseau Zero Trust (Zero-Trust Network Access, ZTNA), une passerelle web sécurisée (Secure Web Gateway, SWG), un courtier en sécurité d’accès au cloud (Cloud Access Security Broker, CASB), un pare-feu en tant que service (Firewall as a service, FWaaS), la sécurité DNS, l’isolation du navigateur distant (Remote Browser Isolation, RBI) et d’autres capacités de sécurité. « La plateforme peut sécuriser n’importe quelle application via n’importe quel port ou protocole, et elle peut optimiser les performances et vérifier et accorder la confiance en continu à partir d’un tableau de bord unique managé dans le cloud », a déclaré Kyndryl. « Elle authentifie les utilisateurs via un tunnel sécurisé et crypté, de sorte que les utilisateurs ne voient que les applications et services auxquels ils ont le droit d’accéder », a déclaré Cisco.
Un partenariat renforcé
Selon la définition de Gartner, les services SSE comprennent le contrôle d’accès, la protection contre les menaces, la sécurité des données, la surveillance de la sécurité et le contrôle de l’utilisation acceptable mis en œuvre par une intégration basée sur le réseau et l’API (le SSE est l’équivalent d’un SASE sans le SD-WAN, selon le cabinet d’analystes). Le SSE est principalement fourni en tant que service basé sur le cloud, et il peut inclure des composants sur site ou basés sur des agents. « Grâce à cette collaboration avec Cisco, nous pouvons aider nos clients à mieux anticiper les incidents de sécurité en utilisant les bons outils et des capacités alignés sur le framework de cyberrésilience de Kyndryl », a déclaré Michelle Weston, vice-présidente des offres mondiales pour la sécurité et la résilience chez Kyndryl, dans un communiqué.
Les services SSE s’appuient sur une alliance existante entre Cisco et Kyndryl. En août dernier, la SSII a renforcé sa propre offre de cyberrésilience avec la plateforme Security Cloud de Cisco, qui comprend des composants de sécurité comme le contrôle d’accès Duo, des fonctions étendues de détection et de réponse (Extended Detection and Response, XDR), et le Multicloud Defense, qui orchestre la sécurité et la politique à travers les clouds privés et publics. « Security Cloud fonctionne comme une couche au-dessus de l’infrastructure des services cloud d’un client, y compris Azure, AWS, GCP et les clouds des centres de données privés, pour protéger les applications de base », a indiqué l’équipementier. Il est doté d’un tableau de bord unifié, d’une prise en charge des politiques de confiance flexibles et d’API ouvertes pour encourager les intégrateurs tiers. « En corrélant les données et en employant l’intelligence artificielle et l’apprentissage machine, Cisco Security Cloud peut détecter les menaces et y remédier rapidement dans toute l’entreprise », a ajouté Cisco.
Annoncée en 2022, la première alliance entre Cisco et Kyndryl avait pour objectif d’aider les entreprises clientes à mettre en œuvre diverses technologies de connectivité, notamment le réseau défini par logiciel (SDN), le WAN et la 5G privée. Palo Alto Networks, également partenaire de la SSII, propose un certain nombre de services de sécurité managés, en particulier SD-WAN et SASE, intégrant les technologies de sécurité de Palo Alto.
Si les mesures règlementaires sur l’IA générative adoptées au niveau mondial couvrent des usages très divers, davantage d’orientations sur les utilisations autorisées de la technologie sont nécessaires. Selon l’Institut Aspen, c’est le cas de la cybersécurité où le temps presse.
Du particulier dans le général. De plus en plus de pays mettent en place des contraintes réglementaires sur l’IA et sa déclinaison générative, mais dans certains domaines comme la cybersécurité, le flou est présent. Dans un rapport de l’Institut Aspen (think tank de dirigeants), l’apport de ces technologies à la protection IT est indéniable, mais dans le même temps les cybercriminels s’en servent aussi de plus en plus.
Selon les auteurs, il incombe aux régulateurs et aux groupes industriels de veiller à ce que les avantages de l’IA générative ne soient pas ruinés par son utilisation abusive potentielle. « Les mesures prises aujourd’hui par les gouvernements, les entreprises et les administrations détermineront demain qui, des attaquants ou des défenseurs, bénéficiera le plus de cette capacité émergente », indique le rapport.
Une réponse variable sur l’encadrement de l’IA générative
L’approche réglementaire adoptée par les grandes nations comme les États-Unis, le Royaume-Uni et le Japon a été différente, tout comme celle des Nations unies et de l’Union européenne. Selon l’Aspen Institute, l’ONU a mis l’accent sur la sécurité, la responsabilité et la transparence, par l’intermédiaire de divers sous-groupes comme l’Unesco, un groupe de travail inter-institutions sur l’IA et un organe consultatif de haut niveau placé sous l’autorité du secrétaire général. L’Union européenne s’est montrée particulièrement agressive dans ses efforts pour protéger la vie privée et répondre aux menaces de sécurité posées par l’IA générative, avec l’IA Act, adoptée en décembre 2023. Il contient de nombreuses dispositions relatives à la transparence, à la protection des données et aux règles concernant les données d’entraînement des modèles.
L’inaction législative aux États-Unis n’a pas empêché l’administration Biden de publier un décret sur l’IA, qui fournit « des orientations et des repères pour évaluer les capacités de l’IA », en mettant particulièrement l’accent sur les fonctionnalités de l’IA susceptibles de causer des dommages. « La CISA a également publié des orientations non contraignantes, en collaboration avec les régulateurs britanniques », indiquent aussi les auteurs. « Le Japon, en revanche, fournit l’exemple d’une approche plus souple de la réglementation de l’IA du point de vue de la cybersécurité, car elle se concentre davantage sur les canaux de divulgation et les boucles de rétroaction des développeurs que sur des règles strictes ou des évaluations des risques », a fait remarquer l’Aspen Institute.
Eviter de perdre confiance en l’IA
Le rapport souligne aussi que le temps presse. Les atteintes à la sécurité commises par l’IA générative ont un effet érosif sur la confiance du public et cette IA acquiert de nouvelles capacités qui pourraient être utilisées à des fins néfastes pratiquement chaque jour. « À mesure que cette confiance s’érode, nous risquons de perdre la possibilité qui nous est offerte d’avoir des débats proactifs sur les utilisations autorisées de l’IA générative dans la détection des menaces et d’examiner les dilemmes éthiques entourant les cyberdéfenses autonomes alors que le marché va de l’avant », indique le rapport.