Outre sa plus grande capacité, la plateforme Secure Network Analytics (SNA) de Cisco prend en charge plus de flux de données et génère des alertes de sécurité plus détaillées.
La dernière version 7.4.2 du logiciel Secure Network Analytics (SNA) dévoilée par Cisco permet de suivre un plus grand nombre de flux de données et d’agir plus rapidement sur les alertes de sécurité pertinentes. Parmi les améliorations apportées par le logiciel d’analyse de la sécurité, le fournisseur met en avant la possibilité de collecter, de traiter et de stocker des données de manière plus efficace, des capacités de détection avancées, une meilleure prise en charge de la télémétrie et la possibilité de fonctionner sur le matériel UCS M6 haute performance du fournisseur. Selon un billet de blog de Jay Bethea, responsable du marketing des produits au sein du groupe de messagerie sécurisée de Cisco, le logiciel d’analyse du réseau exploite les données de télémétrie provenant de sources multiples et fournit des informations sur le comportement du réseau afin d’identifier les risques de manière proactive et d’aider les entreprises à détecter et à répondre aux menaces de sécurité.
La version 7.4.2 de SNA est particulièrement évolutive et performante. « Le logiciel traite facilement 3 millions de flux par seconde et améliore de 94 % les performances en matière de rapports et de requêtes », a déclaré Crystal Storar, directrice de la gestion des produits chez Cisco Security. Selon l’équipementier, « c’est plus du double de la version précédente ». SNA 7.4.2 enrichit les capacités de stockage centralisé des données apparues pour la première fois dans la version 7.3 du logiciel. À la différence de la version précédente où les données de télémétrie étaient stockées sur des collecteurs de flux Flow Collectors individuels et distribués (le système de surveillance qui recueille les paquets de trafic de données du réseau), le système de stockage est centralisé, une base de données centrale traitant désormais les flux provenant de ces appareils. Cisco affirme que, « grâce à ce stockage centralisé des données, le système peut traiter de grandes quantités de données très rapidement, ce qui signifie que les requêtes de Cisco Analytics peuvent être traitées plus rapidement que si les données étaient stockées sur des collecteurs de flux Flow Collectors individuels ». Toujours selon le fournisseur, ce logiciel permet également de conserver les données des collecteurs de flux pendant des périodes d’un an ou plus, ce qui améliore la détection des tendances et l’analyse historique.
Détection des flux réseau AWS et Azure
Parmi les autres caractéristiques importantes de SNA 7.4, la firme de San José cite les options de livraison sur site, la prise en charge étendue de la télémétrie et les améliorations apportées à son moteur de détection des menaces. « SNA 7.4 intègre les nouvelles détections cartographiées par Mitre, la modélisation des entités et la classification automatique basée sur les rôles de notre modèle de livraison ‘cloud-first’ dans les versions logicielles sur site », a déclaré Mme Storar. Secure Network Analytics s’enrichit aussi de nouvelles sources de données pour alimenter ses résultats en matière de détection et de réponse réseau : c’est le cas des journaux de flux AWS et Azure qui couvrent l’infrastructure de cloud public ; des journaux de Secure Client Network Visibility qui couvrent les terminaux et les travailleurs distants; et des journaux de Next Generation Firewall qui offrent une vue plus approfondie sur le trafic réseau », a encore déclaré Mme Storar.
L’architecture SNA est telle qu’elle rend possible l’ingestion évolutive de la télémétrie. « Elle prend actuellement en charge la télémétrie NetFlow, NVM, FTD et du pare-feu ASA et prendra en charge d’autres types de télémétrie à l’avenir », a déclaré le fournisseur. En particulier, Cisco et d’autres cherchent à développer et à implémenter le système OpenTelemetry, un ensemble d’outils, d’API et de SDK utilisés pour instrumenter, générer, collecter et exporter des données de télémétrie afin d’analyser les performances et le comportement des logiciels. OpenTelemetry est développé dans le cadre de la Cloud Native Foundation par des contributeurs d’AWS, Azure, Cisco, F5, Google Cloud et VMware, entre autres. Selon Crystal Storar de Cisco Security, OpenTelemetry est « à l’étude en vue de son introduction dans une prochaine version ». L’équipementier prend déjà en charge OpenTelemetry dans sa Full-Stack Observability Platform, qui sert à collecter et à corréler les données provenant des applications, du réseau, de l’infrastructure, de la sécurité et du cloud afin de fournir une vue claire de ce qui se passe dans l’entreprise et repérer plus facilement les anomalies, anticiper et résoudre les problèmes de performance et améliorer l’atténuation des menaces.S’intégrer aux solutions du marché
Selon un blog de Claudio Lener, chef de produit pour Cisco Secure Analytics, « le logiciel SNA prend également en charge un moteur de détection des menaces plus efficace. De plus, les informations de la base de données centralisée sont utilisées pour créer des alertes fiables et pertinentes. « Par rapport aux premières alarmes SNA, celles-ci sont beaucoup plus discrètes et plus en phase avec ce qui se passe en temps réel, en fournissant un contexte basé sur le réseau et des analyses comportementales avancées », a écrit M. Lener. En d’autres termes, SNA crée une base de référence instantanée, apprend quel comportement est considéré comme « normal » au fil du temps et ne déclenche une alerte que si un utilisateur oublie de suivre une tendance. « Par ailleurs, SNA s’intègre désormais à la dernière appliance matérielle M6, ce qui permet d’améliorer les taux d’ingestion du Flow Collector, d’accélérer les requêtes de recherche de flux et d’augmenter globalement le débit des capteurs de flux », a encore écrit M. Lener.
Autre question essentielle pour les entreprises clientes, celle de la prise en charge des produits tiers par le système. « Nous disposons d’un vaste écosystème de partenaires prêts à aider à la mise en oeuvre, à l’intégration et à la gestion de la solution pour le compte de nos clients », a déclaré Mme Storar. « Nous collaborons avec beaucoup de partenaires techniques qui servent à la fois de fournisseurs de sources de données – comme Baracuda, Checkpoint, Gigamon, IXIA, Palo Alto, TripWire et d’autres – et de destinataires pour nos résultats, de façon à ce qu’ils s’intègrent de manière transparente dans les flux de travail existants de nos clients. Splunk, QRadar, ArcSight, ServiceNow et bien d’autres font partie de ces destinataires notables », a ajouté Mme Storar.
Renforcer OpenTelemetry
Dans un récent rapport de Forrester Research sur l’analyse et la visibilité du réseau offerts par divers systèmes, dont SNA 7.4, le cabinet d’études a déclaré : « L’écosystème Cisco fournit une quantité impressionnante de données télémétriques sur tous les aspects du réseau, depuis les utilisateurs finaux jusqu’au cloud et partout entre les deux, à condition que l’entreprise soit une boutique Cisco importante. Secure Network Analytics (SNA) est un puissant outil de chasse aux menaces qui fournit des informations complètes sur l’activité du réseau grâce aux communications enregistrées et aux enregistrements dédupliqués. Son interface conviviale permet d’accéder rapidement aux informations essentielles pour améliorer la réponse aux incidents et les opérations de sécurité du réseau ». SNA 7.4.2 est disponible et peut être déployé sur des machines virtuelles, comme VMware et KVM, ou sur des appliances Cisco UCS dédiées.
Govulncheck est un utilitaire en ligne de commande qui se sert de la base de données des failles dans Go pour les dénicher dans le code source et les binaires du langage.
Présenté le 13 juillet dernier, Govulncheck passe en version 1.0.0 et a pour ambition d’analyser les binaires et le code source de Go à la recherche de failles. Pour cela, l’utilitaire en ligne de commande réduit le bruit en s’appuyant sur une base de données des bugs dans les modules publics de Go. Il utilise l’analyse statique du code source ou de la table des symboles d’un binaire pour limiter ses rapports aux seules vulnérabilités susceptibles d’affecter une application particulière.
Govulncheck doit être construit avec Go 1.18 ou une version ultérieure. Go 1.20 est la version de production actuelle du langage de programmation. Il recherche les vulnérabilités en utilisant une configuration de compilation spécifique. Pour le code source, la configuration est la version de Go spécifiée par la commande « go » trouvée sur le chemin. Pour les binaires, la configuration est celle utilisée pour construire le code.
L’utilitaire avertit sur quelques limitations. Par exemple, il analyse les pointeurs de fonction et les appels d’interface de manière conservatrice, ce qui peut entraîner des faux positifs ou des des stacks d’appels inexacts. De même, il n’y a pas de support pour rendre secret les découvertes de vulnérabilités. L’outil doit être perfectionné au fil du temps. Il est possible de l’installer avec go install. (go install golang.org/x/vuln/cmd/govulncheck@latest).
Ce rachat s’ajoute aux autres acquisitions réalisées par Cisco en 2023, à savoir Accedian pour la surveillance de la performance des réseaux, Armorblox pour les grands modèles de langages et SamKnows pour la surveillance des réseaux à large bande.
L’équipementier Cisco poursuit ses achats estivaux avec l’acquisition de la start-up de sécurité Oort pour un montant qui n’a pas été rendu public. Spécialisée dans la sécurité des entreprises, Oort propose une plateforme de détection et de réponse aux menaces ciblant les identités. Fondée en 2019, Oort a levé 15 millions de dollars en financement de série A, dans lequel figurent des fonds provenant de la branche de capital-risque de Cisco. « Pilotée par API, native du cloud et sans agent, la plateforme d’Oort répond aux insuffisances en matière de visibilité de l’identité à travers des sources de données disparates, détecte les mauvaises configurations, vérifie les vulnérabilités de sécurité et offre une analyse prédictive de l’identité pour stopper les attaques de manière proactive », a écrit Raj Chopra, vice-président senior et chef de produit pour Cisco Security, dans un blog sur l’acquisition. « Grâce au système Oort, les entreprises peuvent aussi appréhender de manière claire la portée d’un incident lié à l’identité et y remédier plus rapidement », a ajouté M. Chopra. « Par exemple, si un attaquant a volé les identifiants d’un employé, avec lesquels il pourrait accéder à vingt systèmes différents, Oort peut identifier les quatre systèmes réellement compromis et qui nécessitent des mesures correctives supplémentaires », a expliqué M. Chopra.
La technologie centrée sur l’identité d’Oort fera partie de l’offre globale Security Cloud de Cisco, laquelle comprend les portefeuilles de gestion des identités et des accès Duo Identity Access Management (IAM) et de détection et de réponse étendue Extended Detection and Response (XDR). Dans son propre blog sur l’acquisition, le CEO d’Oort Mat Caulfield, a écrit : « L’identité est fondamentale pour la sécurité. Avec l’avènement du XDR, il est plus important que jamais de corréler la télémétrie des systèmes IAM avec les signaux de l’EDR (Endpoint Detection and Response) et de la sécurité du réseau. Avec la montée en puissance du ZTNA (Zero Trust Network Access), l’authentification forte et l’analyse continue sont les conditions préalables à une architecture de sécurité d’entreprise solide ». Outre sa technologie, Oort entretient des relations étendues avec des fournisseurs tiers, notamment Google, Microsoft, Okta et Auth0.
7e acquisition pour Cisco cette année
Cette acquisition, qui devrait être finalisée d’ici à la fin du mois d’octobre, est la troisième de Cisco depuis le mois de juin et la septième cette année. Plus récemment, la firme de San José a fait part de son intention d’acquérir l’entreprise privée SamKnows, spécialisée dans la surveillance des réseaux à large bande, pour un montant non divulgué. SamKnows utilise un réseau mondial d’agents logiciels dispersés dans les systèmes domestiques, les appareils mobiles et les réseaux des fournisseurs de services, pour mesurer en temps réel les performances de l’Internet et l’expérience des clients. Grâce à un tableau de bord central, l’entreprise peut analyser les résultats, repérer les défaillances et identifier les causes profondes des problèmes afin d’y remédier. En juin, Cisco a également conclu un accord en vue d’acquérir Accedian Networks pour un montant non divulgué. La plateforme d’analyse et de surveillance des performances d’Accedian, qui s’adresse aussi bien aux fournisseurs de services mobiles, de datacenters, qu’à des fournisseurs de services et de connectivité cloud, offre une visibilité sur le réseau, diagnostique les problèmes et recommande des mesures correctives. Parmi les autres acquisitions réalisées par Cisco cette année, on peut encore citer Armorblox pour les grands modèles de langage, Smartlook pour la surveillance des applications mobiles, Lightspin pour la sécurité cloud et Valtix pour la sécurité des réseaux cloud.
Un référentiel sur GitHub contenant un prototype d’exploit de vulnérabilité cachait en réalité une backdoor capable de voler des données. Un défi supplémentaire pour les experts en cybersécurité et la qualité de leurs sources d’information.
La vigilance est de mise sur le partage d’informations concernant des failles. Une étude d’Uptycs a découvert un dépôt sur GitHub prétendant être un PoC (proof of concept) de vulnérabilité. En réalité, il caché une backdoor pour voler des données. « Cette backdoor a particulièrement affecté la communauté de la recherche en cybersécurité, car les chercheurs s’appuient sur les PoC pour comprendre les vulnérabilités potentielles », a déclaré le spécialiste en cybersécurité. « Dans le cas présent, le PoC est un loup déguisé en agneau, qui dissimule des intentions malveillantes sous l’apparence d’un outil d’apprentissage inoffensif », poursuit-il.
La porte dérobée fonctionne comme un téléchargeur qui exécute silencieusement un script bash Linux tout en masquant ses opérations en processus de niveau kernel. Elle dispose de vastes capacités de vol de données et peut exfiltrer des données très diverses qui vont du nom d’hôte et du nom d’utilisateur à une liste exhaustive du contenu du répertoire personnel. « Un attaquant peut obtenir un accès complet à un système cible en ajoutant sa clé ssh au fichier authorized_keys », a expliqué Uptycs. Même si le faux PoC a été retiré de GitHub, les chercheurs disent qu’il a été largement partagé et qu’il a suscité un intérêt significatif avant d’être exposé. « Pour ceux qui l’ont exécuté, la probabilité d’une compromission de leurs données est élevée », soulignent les experts.
Activités inhabituelles du PoC
Le faux PoC prétendait corriger une faille critique référencée CVE-2023-35829. Les chercheurs d’Uptycs ont découvert plusieurs activités inhabituelles qui auraient pu éveiller les soupçons sur le PoC. « L’activité suspecte comprenait des connexions réseau inattendues, des transferts de données inhabituels et des tentatives d’accès non autorisé au système », précisent les spécialistes. Après enquête, il s’est avéré que le PoC est une copie d’un ancien exploit légitime pour une autre vulnérabilité du noyau Linux référencée CVE-2022-34918. La seule différence concerne la présence d’un fichier supplémentaire src/aclocal.m4, qui servait de téléchargeur pour un script bash de Linux.
Le PoC est utilisé pour construire des exécutables à partir de fichiers de code source. Il exploite la commande make pour créer un fichier kworker et ajoute son chemin d’accès au fichier bashrc, ce qui permet au logiciel malveillant de fonctionner en permanence dans le système de la victime, une méthode de persistance jugée très astucieuse par les chercheurs. Ces derniers ont également observé que le même profil, ChriSander22 sur GitHub, faisait circuler un autre faux PoC pour VMware Fusion CVE-2023-20871. « Son contenu est identique à celui de la vulnérabilité CVE-2023-35829, avec le même fichier aclocal.m4 qui déclenche l’installation de la porte dérobée cachée », a déclaré le fournisseur.
Distinguer les PoC légitimes des PoC malveillants
Identifier un faux PoC n’est pas toujours facile. L’adoption de pratiques sûres, comme des tests dans des environnements isolés ou des machines virtuelles, peut assurer une couche de protection aux experts en sécurité. Dans ce cas particulier, Uptycs recommande de supprimer toutes les clés ssh non autorisées, de supprimer le fichier kworker, d’enlever le chemin kworker du fichier bashrc et de vérifier /tmp/.iCE-unix.pid pour les menaces potentielles. « Même si ce modus operandi n’est pas tout à fait nouveau, la diffusion de plus en plus fréquente de logiciels malveillants par le biais de PoC pose un problème important, et il est probable que l’on verra cette tactique continuer à évoluer », a déclaré Uptycs.
En mai, VulnCheck a signalé à GitHub des dépôts GitHub malveillants qui se présentaient comme zero day de Signal et de WhatsApp. Le fournisseur a déclaré que, récemment, l’acteur de la menace à l’origine de ces dépôts s’est efforcé de les faire paraître légitimes en créant un réseau de comptes. « L’attaquant a créé une demi-douzaine de comptes GitHub et quelques comptes Twitter associés. Les comptes prétendent tous appartenir à une entreprise de sécurité inexistante appelée High Sierra Cyber Security », met en garde VulnCheck dans son rapport.
De plus en plus d’éditeurs adoptent des techniques limitant le recours aux mots de passe. GitHub vient de franchir le pas avec l’usage en version beta des passkeys.
La tendance est au passwordless pour mieux sécuriser les accès aux différentes plateformes. La filiale de Microsoft, GitHub, vient d’épouser cette approche en lançant en beta publique de l’authentification par passkeys à la place des mots de passe. « En choisissant cette option, les développeurs peuvent utiliser les passkeys à la place de leurs mots de passe et des méthodes d’authentification 2FA », a indiqué la plateforme. En mai, Github avait mis en place de nouvelles mesures d’authentification 2FA pour tous les contributeurs. L’option des passkeys est la dernière étape vers la bascule dans le passwordless. Considérés comme l’alternative moderne aux mots de passe, les passkeys sont généralement plus sûrs et plus faciles à utiliser.
Les sociétés IT et les entreprises les adoptent de plus en plus souvent pour renforcer la sécurité de leurs systèmes d’authentifications et s’affranchir de la contrainte des mots de passe, dont le mauvais usage est à l’origine de la plupart des fuites de données. Depuis le mois de mai, le support des passkeys pour les comptes Google est progressivement déployé sur toutes les grandes plateformes. L’année dernière, plusieurs géants de la technologie ont annoncé leur soutien à un standard commun de connexion sans mot de passe créée par l’Alliance FIDO et le World Wide Web Consortium.
Les mots de passe, première cause de violations des données
« La plupart des failles de sécurité ne résultent pas d’attaques de type ‘zero-day’, mais plutôt d’attaques peu coûteuses basées sur l’ingénierie sociale, le vol d’identifiants ou des fuites qui offrent aux attaquants de diverses modalités d’accès aux comptes des victimes et aux ressources auxquelles elles ont accès », a écrit Hirsch Singhal, responsable produit chez GitHub, dans un blog. « En fait, les mots de passe, sur lesquels nous comptons tous, sont à l’origine de plus de 80 % des violations de données », a-t-il ajouté.
Les passkeys utilisent des clés de sécurité traditionnelles, mais leur configuration est plus facile et leur capacité de récupération bien meilleure. Au final, c’est une méthode sécurisée, privée et facile à utiliser pour protéger ses comptes tout en minimisant le risque de verrouillage », a-t-il ajouté. « Le plus intéressant, c’est que les passkeys nous rapprochent du passwordless, et contribuent à supprimer totalement les violations qui exploitent les faiblesses des identifiants », a encore déclaré Hirsch Singhal. « Sur GitHub, les passkeys nécessitent une vérification de l’utilisateur, ce qui signifie qu’ils concentrent deux facteurs d’authentification en un », écrit-il, une composante propre à l’utilisateur (une empreinte digitale, un visage ou un code PIN) et une composante physique (une clé de sécurité physique ou l’appareil) lui-même. « Les passkeys peuvent être utilisées sur tous les appareils en vérifiant la présence d’un téléphone, et certaines peuvent également être synchronisées entre les appareils pour s’assurer que les utilisateurs ne sont jamais privés de leur compte en cas de perte de la clé », a ajouté Hirsch Singhal.
La protection des comptes des développeurs, élément crucial de la supply chain
« Les comptes des développeurs sont des cibles fréquentes de l’ingénierie sociale et de la prise de contrôle des comptes (Account Take Over, ATO), et la protection des développeurs contre ces attaques est la première et la plus importante étape vers la sécurisation de la chaîne d’approvisionnement », a aussi expliqué M. Singhal. « Les passkeys offrent la meilleure combinaison de sécurité et de fiabilité et rendent les comptes des développeurs nettement plus sûrs sans compromettre l’accès, ce qui reste un problème avec d’autres méthodes 2FA comme le SMS, les mots de passe à usage unique basés sur le temps (Time based One Time Password, TOTP), et les clés de sécurité existantes pour un seul appareil », a-t-il ajouté. « En s’affranchissant des mots de passe, la sécurité renforcée des passkeys empêche le vol de mot de passe et l’ATO ».
A peine entériné par l’Union européenne, le Data Privacy Framework qui vient réguler le transfert transatlantiques des données personnelles interroge sur sa pérennité. Si Max Schrems s’est déclaré prêt à le contester devant la Cour de justice de l’UE, d’autres experts soulignent les faiblesses politiques et juridiques de ce texte.
En début de semaine, l’Union européenne par la voix de la présidente de la Commission européenne a annoncé la signature du Data Privacy Framework (DPF). Ce texte fixe le cadre du transfert des données entre les Etats-Unis et l’Europe. Il succède aux deux textes précédents (Safe Harbor et Privacy Shield) invalidés par la Cour de justice de l’UE après la saisine de l’avocat autrichien Max Schrems. Ce dernier a d’ailleurs, dès l’annonce de l’exécutif bruxellois, menacé d’une procédure pour annuler ce récent cadre. Un air de déjà vu qui interroge sur la fiabilité juridique et politique de cet accord.
Un risque politique avec les élections américaines
Sur le plan politique d’abord, le DPF a été l’objet de longues négociations entre l’administration américaine et la Commission européenne. Après l’invalidation du Privacy Shield, les deux parties ont tenté de trouver des moyens de garantir des capacités de recours et des garanties pour les citoyens européens sur leurs données personnelles vis-à-vis des agences américaines de renseignements. Joe Biden a signé un décret dans ce sens, mais les prochaines élections présidentielles pourraient changer la donne. Nader Henein, analyste chez Gartner, interrogé par nos confrères d’IDG, explique, « si la prochaine élection présidentielle américaine devait voir le poste le plus élevé revenir à un candidat républicain, il y a un risque très réel que ce décret soit annulé, ce qui couperait l’herbe sous le pied de l’accord ». Et de citer les nombreux exemples de traités ou d’accord invalidés par Donald Trump à son arrivée au pouvoir.
De son côté, le député modem Philippe Latombe questionne la première ministre sur le processus de discussion en France sur cet accord. Selon lui l’approbation de cet accord « ait été à l’initiative de la seule Chancellerie (NDLR : ministère de la Justice), sans qu’une réunion des ministres concernés ait été tenue ou le Parlement consulté ». Il demande des informations sur « le processus décisionnel suivi » et « de l’analyse juridique qui a conduit à une telle approbation ».
Un choc de culture juridique sur la protection des données personnelles
L’autre talon d’Achille du Data Privacy Framework, c’est sa faiblesse juridique. Jonathan Armstrong, avocat anglais spécialisé dans la conformité et la technologie chez Cordery, est même pessimiste sur sa pérennité, « nous nous attendons à ce qu’il soit invalidé d’ici deux à cinq ans ». Il apparente le texte à « une patate chaude » que les différentes administrations se transmettent au fil du temps. Il y a surtout un choc entre deux cultures juridiques sur la protection des données personnelles. Ainsi, la constitution américaine ne garantit pas la protection de la vie privée en tant que telle, les lois et réglementations en la matière devant être extraites des protections du quatrième amendement contre les perquisitions et saisies illégales.
Nader Henein, analyste chez Gartner, souligne, « il n’existe actuellement aucune loi fédérale régissant la manière dont les entreprises stockent et protègent les données personnelles, ce qui a conduit les États à adopter leur propre législation ». Le seul souci c’est que 13 Etats sur 50 se sont dotés de mesures en la matière. « il n’est pas facile de faire avancer la législation de manière à ce qu’elle ne couvre pas uniquement les citoyens américains, mais qu’elle régisse également les données relatives aux personnes vivant dans d’autres pays, une fois que ces données ont été légalement enregistrées aux États-Unis ». De son côté Max Schrems émet des doutes sur la création d’une « Cour de révision de la protection des données » (Data Protection Review Court), qui selon lui n’a rien d’une juridiction notamment par l’absence d’appel. Il souligne le caractère imprécis et nébuleux du décret de Joe Biden, sur l’aspect « proportionné » du FISA 702, une loi qui prévoit la surveillance de masse avec l’assistance imposée des fournisseurs de communications électroniques. Au final, le grands perdants de ces fragilités sont les entreprises qui n’arrivent toujours pas à avoir un cadre claire, lisible dans le temps sur le transfert des données.
Des chercheurs ont découvert une attaque via des malwares fileless en Python sur des charges de travail cloud. Pouvant échapper ainsi à la surveillance des outils de sécurité, elle met en place un mineur pour du cryptojacking.
Avec le déploiement croissant de solutions de sécurité sur les infrastructures cloud, les pirates ont commencé à adopter des tactiques innovantes pour cibler ces environnements. L’une d’elles consiste à utiliser des charges utiles fileless qui ne créent jamais de fichiers sur le disque et sont chargées directement dans la mémoire du système. Une technique capable d’échapper à la surveillance des outils de sécurité.
« Nous avons récemment détecté une attaque fileless ciblant des workload dans le cloud », ont déclaré dans leur rapport des chercheurs de Wiz, une entreprise spécialisée dans la sécurité du cloud. « L’attaque s’appuie sur un code Python qui charge un mineur XMRig directement dans la mémoire à l’aide de memfd, une technique sans fichier connue de Linux. À notre connaissance, c’est la première attaque fileless basée sur Python documentée publiquement et ciblant des charges de travail dans le cloud, et d’après nos preuves, cette attaque a été utilisée dans près de 200 cas pour le cryptominage », ont-ils ajouté.
Le malware PyLoose
En se basant sur les chaînes de caractères de l’URL à partir de laquelle les attaquants l’ont déployée, les experts ont baptisé cette charge utile du malware PyLoose. Elle a été trouvée sur des instances non protégées de Jupyter Notebook, une plateforme interactive basée sur le web qui peut être déployée sur des serveurs cloud et qui prend en charge plus de 40 langages de programmation, dont Python. Outre qu’elles sont accessibles au public, ces instances ne limitaient pas l’accès à certains modules Python comme os et subprocess, lesquels peuvent entraîner l’exécution de commandes système. Les attaquants ont utilisé le code Python pour télécharger et exécuter un script créé à l’aide d’un outil open source appelé fileless-elf-exec. Le script a importé des bibliothèques pour l’invocation directe de syscall, l’exécution de commandes os, les opérations base64 et la décompression zlib. Il a ensuite procédé au décodage et à la décompression d’une charge utile et a utilisé memfd pour créer une mémoire tampon, y écrire le contenu de la charge utile et l’invoquer directement depuis la mémoire.
La fonctionnalité memfd de Linux – abréviation de « memory file descriptors » (descripteurs de fichiers en mémoire) – stocke des objets de fichiers en mémoire pour les utiliser dans la communication inter-processus ou comme stockage temporaire. « Les cybercriminels abusent parfois de cette fonction de Linux pour exécuter des charges utiles sans les écrire sur le disque, et éviter ainsi les outils de sécurité traditionnels qui reposent sur des scans binaires », ont déclaré les chercheurs de Wiz. « Une fois que le payload est placé dans une section de mémoire créée par memfd, les attaquants peuvent invoquer l’un des syscalls exec sur ce contenu de mémoire, en le traitant comme s’il s’agissait d’un fichier normal sur le disque, et lancer ainsi un nouveau processus ». S’ils sont recherchés, les processus créés à partir de contenus memfd peuvent être assez facilement identifiés car les liens symboliques vers lesquels ils pointent ne sont pas des chemins de fichiers sur le disque, mais des entrées du type /memfd. Dans le cas présent, la charge utile exécutée à partir de la mémoire était une version précompilée de XMRig, un programme open-source pour le minage de crypto-monnaie couramment utilisé dans les attaques de cryptojacking qui consistent à détourner les ressources informatiques pour miner de la crypto-monnaie à l’insu du propriétaire.
Les attaques fileless sur Linux, plutôt rares
Les attaques sans fichier sur les serveurs Linux ne sont pas nouvelles, mais elles sont relativement rares pour les workload dans le cloud. L’avantage pour les attaquants est qu’elles sont plus difficiles à détecter sans solutions de sécurité basées sur le comportement et la surveillance de la mémoire. Ces attaques compliquent, par ailleurs, les enquêtes post-mortem après la compromission, car les charges utiles disparaissent de la mémoire quand les workload s’arrêtent et que les équipes de sécurité ne sont pas encore familiarisées avec ces techniques. L’un des rares cas documentés d’attaques sans fichier contre des serveurs Linux date de 2021 : un groupe de pirates connu sous le nom de TeamTNT avait déployé un malware écrit en langage Go en exploitant un outil de chargement de mémoire appelé Ezuri.
Avec PyLoose, « l’attaquant s’est donné beaucoup de mal pour se rendre intraçable : il a utilisé un service de partage de données ouvert pour héberger la charge utile Python, il a adapté la technique d’exécution sans fichier à Python et il a compilé un mineur XMRig pour intégrer sa configuration afin d’éviter de toucher le disque ou d’utiliser une ligne de commande pouvant révéler sa présence », ont déclaré les chercheurs de Wiz. « Toutes ces étapes suggèrent que l’adversaire dispose d’un niveau de sophistication rarement observé dans la plupart des attaques de charges de travail dans le cloud, documentées publiquement ». Les chercheurs conseillent aux entreprises d’éviter d’exposer publiquement des services comme Jupyter Notebook, d’utiliser l’authentification multifactorielle ou d’autres plateformes d’identité forte pour accéder à ces services, et de restreindre les fonctionnalités pouvant conduire à l’exécution de commandes système.
Après la découverte de Scarleteel en février dernier qui ciblait les environnements Kubernetes et AWS, le faux cryptomineur évolue dans ses techniques d’infection et d’exfiltration d’identifiants cloud.
Un malware du nom de Scarleteel poursuit son petit bonhomme de chemin et évolue dans sa tactique d’attaque. Découvert en mars dernier, le faux cryptomineur s’en prenait aux environnements cloud et Kubernetes. Aujourd’hui, il est entré dans une deuxième phase avec des tactiques d’infection et d’exfiltration plus évoluées. C’est ce qu’indique Sysdig dans un rapport. « L’automatisation, combinée à un examen manuel des données collectées, fait de cet attaquant une menace plus dangereuse », peut-on lire.
Les experts ajoutent, « Il ne s’agit pas d’un simple logiciel malveillant, comme on le pense souvent d’un mineur de crypto-monnaie, puisqu’ils examinent autant que possible l’environnement cible ». Les activités récentes de Scarleteel ont ciblé des environnements comme AWS Fargate et Kubernetes, indiquant une évolution claire du simple minage de crypto-monnaie vers d’autres exploits comme le vol de propriétés intellectuelles.
Une erreur mineure expose AWS Fargate et Kubernetes
Lors d’une récente attaque, Scarleteel a exploité une erreur mineure dans la politique d’AWS pour escalader les privilèges jusqu’à obtenir un accès administrateur et prendre le contrôle du compte Fargate. Ce piratage a également permis de cibler Kubernetes. « Une erreur du client – une faute de frappe d’un seul caractère – a offert aux attaquants de contourner l’une de leurs politiques », a expliqué Alessandro Brucato, ingénieur de recherche sur les menaces chez Sysdig. « Plus précisément, cette politique empêchait les attaquants de prendre le contrôle de tous les utilisateurs dont le nom contenait « admin ». Sauf que le champ utilisé dans la politique est sensible à la casse ». L’ingénieur a ajouté que l’un des noms d’utilisateur du compte client commençait par « admin », ce qui a permis aux pirates d’en prendre le contrôle.
L’attaquant a pu ensuite exploiter certains conteneurs Jupyter Notebook déployés dans un cluster Kubernetes et procéder dans la foulée à plusieurs types d’attaques, principalement pour voler des informations d’identification AWS pour exploiter plus en profondeur l’environnement cloud de la victime. « L’objectif de Scarleteel est d’obtenir la persistance dans une charge de travail Kubernetes vulnérable afin d’élever les privilèges du cloud, faire du minage insidieux de crypto-monnaie financièrement préjudiciable et voler de la propriété intellectuelle », a déclaré Jimmy Mesta, directeur de la technologie au Centre d’opérations de sécurité Kubernetes. « Une application web vulnérable ou, dans le cas de Scarleteel, un Jupyter Notebook, peut conduire à la compromission complète d’un compte AWS », a ajouté le dirigeant.
Scripts contextualisés et exfiltration évasive
Les scripts utilisés dans les attaques de vol d’informations semblaient savoir qu’ils se trouvaient dans un conteneur hébergé par Fargate et exécutaient les commandes appropriées pour collecter des identifiants. « Leurs scripts interrogent différents services pour recueillir des informations sur l’environnement », a encore expliqué Allesandro Brucato. « Ensuite, ils font progresser leur attaque en utilisant des outils qui ciblent des services spécifiques (par exemple, peirates dans les pods Kubernetes ou pacu après avoir volé des informations d’identification AWS) », a-t-il ajouté. Pacu et Peirates sont des outils d’attaque open source populaires généralement utilisés par les pentesteurs et les Red Teams pour évaluer la sécurité du cloud et de l’infrastructure Kubernetes. « Pacu a été utilisé dans l’attaque Scarleteel comme outil d’énumération post-exploitation pour évaluer rapidement plus de 20 chemins d’escalade de privilèges existants dans le compte AWS de la victime », a déclaré M. Mesta. « Quant à Peirates, il offre aux attaquants une interface de ligne de commande tout-en-un pour réaliser des exploits sur Kubernetes, notamment effectuer un mouvement latéral, voler les identifiants IAM (Identity and Access Management) du cloud ou obtenir la persistance par le biais d’un shell inversé ».
Scarleteel s’est également servie d’une technique d’exfiltration pour échapper à la détection. Au lieu d’utiliser des outils de ligne de commande courants comme ‘curl’ ou ‘wget’, les attaquants ont choisi une méthode plus furtive en utilisant des éléments intégrés au shell. « C’est souvent au moment de l’exfiltration que les attaquants sont détectés par les SIEM ou d’autres systèmes de surveillance, car la plupart des attaques utilisent des outils courants comme wget ou curl, tous deux considérés comme une anomalie », a déclaré Jimmy Mesta. « Scarleteel utilise un shell intégré pour effectuer des appels externes au réseau vers des adresses IP contrôlées par l’attaquant, de sorte que l’attaque semble « normale » pour la plupart des outils de surveillance de la sécurité non sophistiqués basés sur des signatures prédéfinies. L’attaquant a également utilisé le CLI AWS piraté pour télécharger et exécuter Pandora, un malware appartenant au botnet Mirai qui cible essentiellement les appareils IoT connectés à Internet pour planifier des attaques DDoS à grande échelle.
La société Hackrate a eu l’idée de créer une plateforme pour centraliser et contrôler les initiatives de piratage éthique comme les bug bounty ou les tests d’intrusion.
De plus en plus d’entreprises ont recours à des experts en sécurité extérieurs pour tester et éprouver leur SI en termes de sécurité. Il existe cependant beaucoup d’offres sur le marché et les responsables de la cybersécurité ont besoin d’un outil capable de gérer l’ensemble de ces programmes. En réponse à cette demande, la société Hackrate, spécialisée dans le pen testing et la gestion des bug bounty, a annoncé le lancement de Hackgate, une plateforme de monitoring de ces projets. « Disponible dès maintenant en tant que service autonome, la plateforme vise à aider les entreprises à mieux gérer et superviser les initiatives de tests de sécurité et de pénétration, en offrant un meilleur contrôle du projet et une meilleure cybersécurité », a déclaré l’entreprise dans un blog.
Le bug bounty et le pen testing peuvent s’avérer très utiles pour découvrir les vulnérabilités des systèmes et les sources potentielles de violations de données en contournant ou en craquant les protections de sécurité d’une manière sûre et contrôlée. Cependant, la surveillance efficace des initiatives de hacking éthique et une garantie sur la clarté des résultats des tests peuvent représenter un défi important pour de nombreuses entreprises, un autre problème étant celui de la transparence.
Intégration au SIEM et authentification forte des testeurs
« Hackgate utilise des « technologies avancées » et s’intègre à un SIEM (Security information and event management, SIEM) pour garantir une analyse totale du projet », affirme le fournisseur. « La plateforme est notamment capable d’identifier les types d’attaques, d’enregistrer les données de sécurité et de générer des rapports individuels de tests d’intrusion au format PDF cliquable », ajoute-t-il. « La solution sépare également les activités des testeurs de celle des attaquants réels en appliquant des méthodes d’authentification fortes avant d’accorder aux pirates éthiques l’accès au système informatique », a écrit par ailleurs Balázs Pózner, CEO et cofondateur de Hackrate, dans un blog.
« L’accès à un serveur web n’est possible qu’à partir des adresses IP de Hackgate, ce qui garantit que seuls les testeurs autorisés peuvent entrer, réduisant ainsi au minimum le risque d’accès non autorisé. L’outil enregistre aussi toutes les activités au cours du projet, ce qui permet aux entreprises de suivre et d’isoler tout intrus non autorisé. Cette séparation claire entre les testeurs et les attaques réelles renforce la sécurité globale de l’entreprise », a encore le dirigeant.
Présente dans les commutateurs Nexus 9000 de Cisco en mode ACI, la faille pourrait permettre à des attaquants de lire et de modifier le trafic chiffré.
Selon le fournisseur, en exploitant cette vulnérabilité de gravité élevée identifiée dans le matériel de commutation pour datacenter de Cisco, des acteurs de la menace pourraient lire et modifier le trafic crypté. L’avis de sécurité publié mercredi dernier par Cle fournisseur concerne une vulnérabilité de la fonction CloudSec multisite de l’infrastructure axée sur les applications (ACI) découverte dans une famille de commutateurs pour datacenter. « Cette vulnérabilité résulte d’un problème d’implémentation des algorithmes de chiffrement utilisés par la fonction de cryptage CloudSec sur les commutateurs concernés », a déclaré l’entreprise dans son avis. La faille, qui porte la référence CVE-2023-20185, est affectée du score 7,4 dans le système de notation des vulnérabilités CVSS.
La série Nexus 9000, affectée par la vulnérabilité
Cette faille concerne les commutateurs de la série Nexus 9000 fonctionnant en mode ACI à partir de la version 14.0. Elle affecte plus particulièrement les commutateurs dans une configuration multisite et dont la fonction de chiffrement CloudSec est activée. Cette famille de commutateurs modulaires et fixes pour datacenter de Cisco répond aux divers besoins de mise en réseau des datacenters modernes. Elle fonctionne sur deux systèmes d’exploitation différents, NX-OS et ACI. « Cisco a confirmé que cette vulnérabilité n’affectait pas les commutateurs de la série Nexus 9000 en mode NX-OS autonome », précise l’avis. Alors que les commutateurs NX-OS, plus traditionnels, disposent d’un panel complet de fonctions de mise en réseau, les commutateurs fonctionnant sous ACI font partie de la solution de mise en réseau définie par logiciel (SDN) de Cisco et offrent une automatisation centralisée basée sur des règles.
Pas encore de correctifs
« Cisco n’a pas encore publié de mises à jour logicielles pour remédier à la vulnérabilité et il n’existe pas non plus de solutions de contournement », a déclaré le fournisseur. « Les clients qui utilisent actuellement la fonction de chiffrage ACI Multi-Site CloudSec pour les commutateurs Nexus 9332C et Nexus 9364C et pour la Cisco Nexus N9K-X9736C-FX Line Card sont invités à la désactiver et à contacter le support technique de leur entreprise pour évaluer d’autres options », recommande encore l’avis. Dans ce même avis, Cisco détaille les étapes à suivre pour déterminer l’état de la fonction CloudSec sur ces appareils.