Featured image of post Evaluation automatisée des plugins WordPress basée sur l’OSINT
Intelligence

Evaluation automatisée des plugins WordPress basée sur l’OSINT

Création d'un solution pour évaluer les plugins WordPress avec l’OSINT

ABSTRACT

La sécurité des sites WordPress constitue un défi technique majeur, cette plateforme alimentant 43% du web mondial. Le rapport Patchstack 2024 révèle une augmentation significative de 24% des vulnérabilités découvertes en 2023, dont 92% sont liées aux plugins tiers. Cette problématique découle de l’architecture ouverte de WordPress, dans laquelle des extensions (plugins), développées par des contributeurs externes, échappent à des processus stricts de validation de sécurité. Notre recherche présente OSS Sentinel, une approche novatrice d’évaluation automatisée des plugins WordPress basée sur l’OSINT (Open Source Intelligence). Contrairement aux méthodes traditionnelles de détection post-installation, notre système implémente une analyse préventive en intégrant trois composantes : l’exploitation des techniques d’OSINT pour l’évaluation des contributeurs et de leurs infrastructures, l’interrogation systématique des bases de données de vulnérabilités, et l’analyse statique du code source et de ses dépendances. Déployée dans un environnement virtualisé Proxmox assurant isolation et reproductibilité, la solution applique un algorithme de scoring pondéré aux données collectées. L’expérimentation menée sur plusieurs dizaines de plugins démontre la capacité d’OSS Sentinel à générer une évaluation fiable des risques potentiels avant installation. Cette approche proactive constitue une avancée significative dans la sécurisation automatisée de l’écosystème WordPress, particulièrement pertinente pour les environnements ne disposant pas d’expertise approfondie en cybersécurité.

Additional Key Words and Phrases: sécurité, OSINT, WordPress, sites web, vulnérabilités, reconnaissance, plugins, api

Glossaire

  • CVE : Common Vulnerability and Exposures, vulnérabilité identifiée, publiée par MITRE.
  • CVSS : Common Vulnerability Severity Score, nombre entre 1 et 10 indiquant la dangerosité de la vulnérabilité qu’il qualifie.
  • OSINT (Open Source Intelligence) : Collecte et analyse d’informations accessibles publiquement, souvent utilisées à des fins de renseignement.
  • Supply Chain Attack : Attaque de la chaîne d’approvisionnement, type d’attaque ciblant des composants externes utilisés dans un système informatique, tels que des plugins tiers.
  • VM : Virtual Machine, en français Machine Virtuelle, soit un environnement logiciel simulé qui permet d’exécuter un système d’exploitation ou une application comme s’ils fonctionnaient sur un matériel physique distinct.
  • Vulnérabilité 0-day Vulnérabilité n’ayant pas été identifiée et publiée (CVE). Cela ne veut pas dire qu’elle n’est pas exploitée.
  • Vulnérabilité 1-day Vulnérabilité identifiée mais n’ayant pas encore été corrigée. Les systèmes qu’elle touche sont toujours vulnérables.
  • CMS : Content Management System, un système de gestion de contenu qui permet de créer, gérer et publier du contenu sur un site web.
  • WordPress : Un système de gestion de contenu (CMS) open source utilisé pour créer et gérer des sites web sans compétences en programmation web.
  • Thème (WordPress) : Modèle préfabriqué de site web, utilisable tel quel pour les environnements WordPress.
  • Plugin (WordPress) : Code à ajouter à un environnement WordPress permettant d’ajouter des fonctionnalités à ce dernier.

Recueil et analyse du besoin du marché

WordPress domine le paysage du web mondial avec 43 % de parts de marché, s’imposant comme une plateforme de référence pour la création de sites web grâce à sa facilité d’utilisation et son vaste écosystème de plugins et de thèmes (65 % des CMS sont basés sur WordPress). Cependant, si ces extensions offrent des possibilités étendues de personnalisation, elles constituent paradoxalement le maillon faible de la sécurité des sites. Développés majoritairement par des contributeurs externes, les plugins tiers échappent souvent aux processus rigoureux de validation de sécurité, de mise à jour et de maintenance. De ce fait, ils sont particulièrement vulnérables aux cyberattaques. Cette situation, conjuguée à l’absence de contrôles stricts dans l’écosystème WordPress, en fait une cible privilégiée pour les cybercriminels.

Le rapport Patchstack 2024 [19] illustre l’ampleur croissante du problème, relevant une hausse de 24 % des vulnérabilités découvertes en 2023, avec l’ajout de près de 6 000 nouvelles failles à leur base de données. Les incidents récents témoignent de la diversité et de la gravité des menaces : une vulnérabilité d’inclusion de fichiers locaux dans le plugin Umbrella [? ] permet l’exécution de code arbitraire par des attaquants non authentifiés ; une faille critique dans WPForms autorise la manipulation frauduleuse de l’API Stripe [1, 16] pour effectuer des remboursements ou annulations non autorisés ; l’exploitation du plugin Hunk Companion facilite le déploiement de backdoors via l’installation d’extensions obsolètes [13, 38] ; une injection d’objet PHP dans UpdraftPlus rend possible le vol ou la destruction de données sensibles [7, 36] ; l’exposition d’un journal de dégogage dans LiteSpeed Cache [5, 35] permet à des visiteurs non authentifiés de prendre le contrôle de comptes, et d’obtenir un accès administrateur. Des attaques peuvent également viser plusieurs plugins en parallèle [11]. Même les plugins dédiés à la sécurité sont affectés, montrant le mauvais exemple. En novembre

2024, une faille de sécurité a été découverte dans Really Simple Security [3] qui permettait à un attaquant à distance d’obtenir un accès administrateur complet. Cette liste est loin d’être exhaustive (voir la veille active de certains éditeurs [30]) et de nouvelles vulnérabilités sont régulièrement découvertes.

Un article récent révèle que 149 252 sites WordPress ont été compromis par des malwares malgré la présence de plugins de sécurité. Cette découverte souligne l’inefficacité des solutions actuelles, principalement réactives, qui échouent à traiter les vulnérabilités à leur source [22]. Dans ce contexte, l’émergence d’outils innovants comme DeepTective, exploitant des réseaux neuronaux hybrides, a permis d’identifier de nouvelles failles critiques dans des plugins populaires - notamment des injections SQL et des scripts intersites (XSS) - démontrant les lacunes des méthodes traditionnelles de détection [21].

La problématique des vulnérabilités dans les plugins révèle un enjeu systémique. Une analyse approfondie démontre que 92 % des failles WordPress proviennent des plugins, avec des vulnérabilités qui persistent parfois durant des années [15]. Une étude de 2019 sur plugins de sauvegarde a notamment mis en évidence des faiblesses critiques : chiffrement insuffisant, fichiers de sauvegarde exposés, compromettant directement la sécurité des données [6].

L’inefficacité des solutions actuelles est particulièrement frappante face à l’évolution des menaces. En 2023, les malwares ont démontré une sophistication croissante, certains parvenant même à neutraliser des solutions de sécurité réputées comme WordFence [? ]. Les administrateurs se retrouvent ainsi piégés dans un cycle perpétuel d’infection, nettoyage et réinfection, soulignant la nécessité d’un changement d’approche dans la sécurisation de WordPress.

La situation est aggravée par le manque de formation en cybersécurité des utilisateurs WordPress. Ne pouvant pas évaluer efficacement les risques liés aux plugins tiers ou d’identifier les pratiques de développement dangereuses, ils basent souvent leurs choix sur des critères inadaptés, comme les évaluations utilisateurs ou le nombre de téléchargements. Cette confiance mal placée expose leurs sites à des vulnérabilités critiques, même lorsque les plugins semblent bénéficier d’une bonne réputation. Paradoxalement en effet, les plugins les plus téléchargés s’avèrent souvent les plus vulnérables, leur popularité en faisant des cibles privilégiées pour les attaquants [24]. WordPress, par ailleurs, ne contrôle pas strictement les contributions à son environnement, laissant chaque utilisateur libre d’ajouter des plugins, qu’ils proviennent ou non du magasin officiel.

Face à la popularité de WordPress et aux failles de sécurité récurrentes associées aux plugins, une solution novatrice s’impose : un outil d’analyse préventive des plugins WordPress. C’est pourquoi notre objectif est de fournir un outil simple et automatisé qui aidera les utilisateurs à identifier les risques de sécurité avant même qu’ils n’affectent leur site.

Cet outil est en mesure de :

  • Détecter proactivement les vulnérabilités dans les plugins installés ou envisagés, grâce à des techniques d’OSINT (Open Source Intelligence).
  • Identifier les pratiques de développement à risque, en fournissant des informations sur les développeurs, notamment leurs antécédents et d’éventuelles fuites de données associées (emails ou mots de passe compromis).
  • Fournir un score de sécurité (“cyber score”) sur les solutions tierces basé sur les données collectées, permettant aux administrateurs de prendre des décisions éclairées quant à l’utilisation ou non d’un plugin.

La solution est livrée sous la forme d’un plugin WordPress, permettant une visualisation claire des résultats et une gestion des alertes pour une meilleure réactivité face aux menaces.

Analyse du retentissement sur un territoire/collectivité/entreprise

Notre solution s’adresse à tout utilisateur de site WordPress, particulier comme professionnel. Elle pourra être appliquée par toute personne qui crée ou administre un site, mais également par les contributeurs eux-mêmes, pour s’assurer de la fiabilité du plugin ou du thème qu’ils proposent.

Impacts positifs visés

  • Renforcer la sécurité des sites WordPress utilisés par les particuliers comme les professionnels : en prévenant l’installation de plugins ou de thèmes soupçonnés d’être vulnérables voire malveillants, notre solution vise à limiter les failles sur les sites WP.
  • Réduire les cyberattaques : en identifiant les vulnérabilités potentielles avant même l’installation des contributions, cette solution diminue le risque d’attaques sur les sites qui l’ont installée.
  • Gagner en transparence : améliorer la connaissance “cyber” des contributions WordPress, à travers la surveillance et la mise à disposition d’informations claires et détaillées, sur leurs failles potentielles et sur les auteurs et contributeurs.
  • Démocratiser l’accès à la cybersécurité des sites web : pour les PME ou les collectivités locales ayant des ressources limitées, cette solution permettrait d’accéder à des évaluations de sécurité automatisées sans nécessiter d’équipe spécialisée en cybersécurité.

Externalités positives

  • Amélioration de la qualité des plugins et thèmes de manière générale : si notre solution est largement connue et adoptée, elle pourrait inciter les développeurs de plugins à améliorer la qualité et la sécurité de leurs produits, un mauvais score cyber pouvant leur porter préjudice (réputation ou commercialement).
  • Réduction des coûts liés aux cyberattaques pour les utilisateurs de la solution : notre solution permettant d’éviter les attaques sur les sites WordPress, elle aura pour corollaire de réduire les pertes financières directes (rançongiciels, vol sur les sites de vente en ligne, fraudes) ou les coûts liés à des interruptions d’activité et à la gestion des incidents.
  • Amélioration de la réputation des sites WordPress utilisant la solution : les organisations utilisant notre solution pourraient afficher leur engagement pour la cybersécurité, ce qui renforcerait la confiance des usagers, clients ou partenaires.

Externalités négatives

  • Impacts sur les développeurs de plugins (nuisance aux développeurs fiables) : des faux positifs pénaliseraient les développeurs fiables. Si nos critères de sécurité sont trop stricts, des plugins innovants mais non conventionnels pourraient être rejetés, ce qui à terme, pourrait décourager certains développeurs.
  • Impacts sur la cybersécurité liés à une “surconfiance” (nuisance aux utilisateurs de WordPress) : une surconfiance dans la solution pourrait amener les utilisateurs à négliger les règles de sécurité de base. Or, certaines failles de sécurité pourraient ne pas être détectées par notre solution, donnant une fausse impression de sécurité.
  • Risques sur la confidentialité : selon la manière dont notre API collecte et analyse les données, pourront se poser des questions sur la confidentialité des informations des développeurs (noms, adresses mail).

Les émissions de CO par le serveur Kimsufi pour 6 mois sont de 47,58 kg CO eq. En ce qui concerne nos ordinateurs (500 heures de fonctionnement), on arrive à 2 kg CO eq. Les émissions liées au stockage et transferts de données sont estimées à 10,80 kg CO eq suite à une considération des visioconférences, mails, téléchargements de données, navigation internet, streaming vidéo et stockage des VMs.

  1. Mise en production hypothétique de la solution

Il faudrait utiliser un serveur plus puissant que celui que nous avons utilisé pour le projet, dont les performances étaient suffisantes pour notre usage :

  • Impact annuel selon OVH : 360 à 500 kg CO eq. (fabrication, électricité et opérations).
  • Comparaison ADEME : 500 kg CO eq. pour un serveur plus puissant.
  • Choix d’estimation moyenne : 450 kg CO eq.

Il faudrait également considérer les émissions dégagées par les déplacement pour la promotion (3,6 kg CO eq.), les supports marketing numériques (0,921 kg CO eq.) et la participation à des forums en ligne (négligeable).

  1. Utilisation d’OSS Sentinel par le public

Les émissions liées au téléchargement du plugin seront faibles car ce dernier fait moins d’un Mo. Pour 500 téléchargements, nous arriverions à 0,0025 kg CO eq. Les émissions liées aux fonctionnalités, sur une moyenne de 20 analyses par an par utilisateur, génèreraient un impact carbone équivalent à 10,24 kg CO eq. En prévoyant un SAV et une maintenance, qui engendreraient l’utilisation de nos ordinateurs, nous retrouvons la valeur de 2 kg CO eq.

  1. Arrêt de la solution (fin de support)

Puisque nous utilisons un serveur dans le Cloud, ce serait serait simplement réaffecté, n’engendrant aucun impact carbone. En ce qui concerne nos ordinateurs, ils ne sont pas dédiés uniquement à la solution, et par conséquent ne seraient pas non plus concernés par un processus de destruction.

Cette analyse met en évidence que l’impact environnemental du projet reste modéré grâce à l’utilisation d’un hébergement cloud optimisé, alimenté en partie par des énergies renouvelables. En cas d’évolution du projet nécessitant une augmentation des ressources pour répondre à une demande croissante, nous mettrons en place des bonnes pratiques visant à réduire l’impact environnemental tout en garantissant la performance et la flexibilité du serveur.

État de l’art et positionnement par rapport à l’existant

Études sur la sécurité des plugins WordPress

Dans le domaine de la cybersécurité, de nombreuses recherches ont récemment exploré des approches innovantes pour identifier et atténuer les vulnérabilités des applications web, notamment celles qui concernent l’écosystème WordPress. Ces travaux s’appuient sur des méthodologies avancées, combinant intelligence artificielle, analyse comportementale et outils d’intelligence open-source (OSINT), afin de proposer des solutions proactives capables de contrer des menaces de plus en plus sophistiquées.

Parmi ces études, “AlgoXSSF: Detection and Analysis of Cross-Site Request Forgery (XSRF) and Cross-Site Scripting (XSS) Attacks via Machine Learning Algorithms” [12] propose une approche axée sur l’intelligence artificielle pour identifier et analyser les failles XSS et XSRF. En exploitant des algorithmes d’apprentissage automatique, cette méthode cible les comportements anormaux des applications web, permettant une détection plus rapide et précise des attaques.

Une autre contribution significative est celle de “Phuzz: A Coverage-Guided Fuzzer for PHP Web Applications” [17], qui adopte une approche proactive. Ce fuzzer guide son exploration en couvrant les chemins critiques des applications

PHP, y compris les plugins WordPress, dans le but d’identifier des vulnérabilités avant qu’elles ne soient exploitées. Cette méthodologie offre une vision anticipative pour renforcer la sécurité des applications PHP.

L’étude “DeepTective: Detection of PHP Vulnerabilities Using Hybrid Graph Neural Networks” [21] introduit quant à elle une méthode hybride combinant des Gated Recurrent Units (GRU) et des Graph Convolutional Networks (GCN) pour détecter des vulnérabilités critiques telles que les injections SQL (SQLi), les scripts intersites (XSS) ou encore les commandes système non sécurisées (OSCI). Cette approche a permis de découvrir quatre nouvelles failles dans des plugins WordPress, soulignant l’efficacité des modèles hybrides dans l’analyse de systèmes complexes.

Enfin, “Securing the Web: A Study on Look-Alike Domain Detection Using Open-Source Intelligence Tools” [27] aborde une problématique complémentaire : la détection de domaines ressemblants (look-alike), souvent utilisés dans des campagnes de phishing ou pour distribuer des malwares. En utilisant des outils OSINT, les chercheurs ont identifié 1 598 domaines sosies, illustrant ainsi l’efficacité de cette approche pour prévenir les attaques ciblant les utilisateurs finaux.

Analyse de l’existant et positionnement de notre solution

Afin de développer une solution novatrice et adaptée à ces enjeux, nous avons étudié l’environnement technologique actuel à travers trois axes :

  • Plugins de sécurité Wordpress existants : Nous avons analysé les plugins de sécurité WordPress actuellement disponibles sur le marché afin d’identifier les axes d’amélioration ou d’évolution possibles. En nous inspirant de leurs méthodes et fonctionnalités, nous avons cherché à développer un outil innovant et pertinent.
  • Outils de recherche OSINT existants : La force de notre outil repose sur l’utilisation de l’OSINT (Open Source Intelligence), une discipline largement adoptée par une communauté active. De nombreuses ressources existantes, continuellement mises à jour, permettent d’automatiser la recherche d’informations liées à un sujet (personne, URL, etc.). Ces ressources jouent un rôle clé dans l’évaluation des contributeurs des plugins, rendant l’étude de cet écosystème indispensable pour notre projet.
  • Outils de recherche et bases de données de vulnérabilités existants : Pour garantir un score de sécurité fiable pour les plugins, il est essentiel d’identifier les vulnérabilités qui leur sont associées. Ces vulnérabilités, centrales dans le domaine de la cybersécurité, sont documentées dans plusieurs bases de données et outils spécialisés. Afin de compléter notre démarche, nous avons élargi notre analyse à des outils d’examen de code et de dépendances, renforçant ainsi la précision et la pertinence de notre évaluation.
  1. Il existe plusieurs plugins de sécurité WordPress, tels que All-In-One Security [26], Secupress [25] ou encore Patchstack [18]. Ces derniers offrent une protection des environnements WordPress sur lesquels ils sont installés, au niveau réseau (attaques de déni de service, pare-feu, …), virus (scanner de malwares, …), et autres (attaques par force brute, scanners de vulnérabilités, sauvegardes, …). Certains outils surveillent les autres plugins et thèmes, directement ou non, via le monitoring de l’activité sur l’environnement WordPress ou encore des vulnérabilités affectant les plugins et thèmes installés. Cependant, ces protections ciblent exclusivement les éléments déjà installés sur un environnement WordPress. En outre, ces solutions requièrent souvent des permissions système avancées pour surveiller les événements du site. Ce niveau d’accès élargi augmente la surface d’attaque et, paradoxalement, peut introduire des risques d’intrusion via les propres outils de sécurité.

Nous avons toutefois identifié un plugin déterminant un score pour les plugins et thèmes WordPress : Wordfence [? ]. Après des recherches plus approfondies, il s’avère que ce score est en réalité le CVSS associé aux CVE, et ne reflète donc qu’un score considérant la vulnérabilité (publiée, et donc au moins 1-day) dans le code. Son objectif est de produire un score rapidement pour tous les plugins et thèmes, ce qui ne reflète pas notre sujet, qui comprend également l’identification des vulnérabilités 0-day et la sécurité des contributeurs des plugins et thèmes.

  1. L’Open Source Intelligence (OSINT) constitue un pilier essentiel pour évaluer la sécurité des contributeurs de plugins et thèmes WordPress. Cette discipline exploite des informations librement accessibles sur Internet pour profiler des individus, des organisations ou des infrastructures. La recherche d’informations automatisée est possible via de nombreux outils, certains ayant des fonctionnalités similaires. Par exemple, en partant d’un pseudonyme ou d’une adresse e-mail, il est possible de retrouver des mots de passe compromis [20], des données de navigation, ou encore des pseudonymes reliés (liens avec des amis, collègues, ou membres de la famille). Certains outils, comme Maltego [34], vont plus loin en cartographiant les relations entre des individus ou des entités, fournissant ainsi une vue d’ensemble des informations disponibles sur une cible. Ces informations, bien qu’éparses, sont déjà disponibles en ligne et peuvent être collectées via des requêtes spécifiques, combinées à une expertise sur “où chercher”. Elles permettent d’évaluer indirectement l’importance accordée à la sécurité par un contributeur. Un développeur avec une “hygiène numérique” rigoureuse est moins susceptible de produire un code vulnérable. À l’inverse, des pratiques négligentes, comme des identifiants compromis, peuvent être révélatrices de failles dans les processus de développement. Cette approche contribuera à enrichir l’évaluation de la sécurité des plugins considérés, leur sécurité dépendant bien des personnes qui contribuent.

Nos recherches ont mis en évidence des outils distincts ciblant chacun un domaine. Par exemple Shodan [28] enquête sur des IP et noms de domaine, tandis que Skymem [29] se spécialise dans la recherche d’adresses mail. Hudson Rock [23], quant à lui, est axé sur la détection d’identités compromises et de données sensibles ayant fuité sur le dark web. Par ailleurs, AbuseIPDB [4] permet d’évaluer la réputation d’une adresse IP grâce à une base collaborative alimentée par la communauté. Cependant, nous avons également identifié des frameworks plus polyvalents, comme SpiderFoot [14]. Cet outil open-source, doté de plus de 200 modules, intègre plusieurs solutions pour collecter des informations sur des IP, noms de domaine, réseaux sociaux, adresses e-mail, pseudonymes, et bien plus encore. En centralisant les recherches, il permet de multiplier les sources et d’augmenter les chances de corrélation, tout en optimisant le temps nécessaire pour formuler et redistribuer les requêtes.

Il nous est apparu que malgré le nombre élevé d’outils disponibles pour rechercher des informations sur des éléments réseau ou des personnes, il était préférable d’utiliser un outil qui agrège plusieurs modules. De cette manière, nous multiplions les moteurs de recherche et donc les chances de corrélation. De plus, nous gagnons du temps en ne formulant qu’une requête à l’outil principal, qui la redispatche ensuite.

  1. La détection des vulnérabilités constitue une étape clé dans l’évaluation de la sécurité des plugins. En effet, même en l’absence d’informations sur les contributeurs, il est possible d’évaluer la qualité du code et de ses dépendances.

Il peut arriver que, malgré une hygiène numérique déplorable, le code produit soit correct en termes de sécurité. Ainsi, nous avons effectué des recherches sur des outils nous permettant de qualifier la sécurité des plugins par analyse de code, comme SonarQube [33].

L’analyse des dépendances est également importante, car un plugin peut inclure des bibliothèques tierces vulnérables, qui ne seraient pas détectées par un simple audit de code. Par exemple, des failles comme celles liées à Log4J [9] ont démontré l’importance de surveiller ces éléments. Seuls Snyk Scanning (CLI) [31] et OWASP Dependency Check (avec intégration SonarQube) apportent les fonctionnalités que nous recherchons. Ils établissent la liste des dépendances directes ou indirectes du plugin évalué et recherchent les vulnérabilités associées dans leurs bases de données.

Enfin, l’historique des CVE associée au plugin ou à ses librairies constitue un élément clé de notre analyse. En effet, un plugin ayant eu de nombreuses vulnérabilités et ce, de manière récurrente, n’est pas gage de sécurité. Pour cette raison, nous avons également cherché des outils mettant à disposition des bases de données de vulnérabilités permettant d’identifier celles ayant touché des plugins particuliers.

Nous avons identifié quatre outils mettant en avant leur base de données des vulnérabilités concernant WordPress :

  • WPScan (Plugin) [37], avec une base de 54 952 vulnérabilités spécifiques à WordPress,
  • Patchstack (site web et API) [18], qui recense 21 141 vulnérabilités,
  • CVE Details (site web) [10], qui se concentre uniquement sur les CVE publiques.

Leur sources sont différentes et ils ne les citent pas toutes (sauf CVE Details qui ne s’occupe que des CVE). Cependant, Patchstack et WPScan se distinguent par leur capacité à intégrer des vulnérabilités signalées de manière exclusive par des tiers, ce qui leur confèrent un avantage important dans la course à la mise à jour corrective. Comme aucun des deux ne communique ses sources, il est difficile de les comparer. Nous notons toutefois qu’ils annoncent tous les deux faire “vérifier” par un professionnel de WordPress la plupart des vulnérabilités présentes dans leurs bases.

Ainsi, notre solution se veut novatrice en adoptant une approche multidimensionnelle, prenant en compte la sécurité du code et des dépendances, ainsi que l’hygiène numérique des contributeurs, pour fournir un score de sécurité exhaustif.

Proposition d’une solution fondée d’après l’état de l’art et les contraintes métier et répondant à la problématique

Nous avons identifié trois catégories d’outils existants sur lesquels notre solution se base : les outils d’OSINT, les bases de données de vulnérabilités et les outils d’analyse de code et de dépendances. Nous avons démontré que leur combinaison permettrait de proposer une solution de sécurité WordPress répondant à la problématique de la compromission par chaîne d’approvisionnement (Supply Chain). Notre objectif étant d’aider les administrateurs de sites à identifier les plugins Wordpress vulnérables, nous avons développé un outil facile d’utilisation, permettant d’analyser un plugin avant son installation et présentant son score de sécurité. L’affichage est intégré à l’environnement WordPress du client, et s’inspire de l’étude des plugins de sécurité WordPress existants (voir 7). Ce score est calculé par l’agrégation de plusieurs indicateurs, basés sur les données collectées sur le plugin visé, comme nous le présentons ci-après (voir Démarche de notation et constitution du score de sécurité).

Collecte d’informations via les outils d’OSINT

Les informations disponibles en sources ouvertes sont, d’une part, recueillies à l’aide d’outils OSINT existants, comme WhoIs, Hunter.io ou encore Have I Been Pwned (HIBP), et d’autre part, récupérées via des API propriétaires, notamment le Store WordPress. En effet, les informations concernant les plugins sont disponibles via des routes spécifiques dispensées par les éditeurs eux-mêmes.

Ces quatre outils ont été sélectionnés pour leur complémentarité dans l’évaluation de la fiabilité des auteurs de plugins :

• WhoIs Cet outil fournit des informations sur le registrant et le registrar du domaine de l’éditeur. Il permet d’évaluer la réputation du domaine et, par extension, celle de l’éditeur.

  • AbuseIPDB Il évalue la réputation d’une adresse IP (dans notre cas, celle associée au domaine). Il permet de détecter si l’IP a été impliquée dans des activités malveillantes, sur la base des signalements de la communauté.
  • Hunter.io Bien qu’à l’origine conçu pour le marketing, cet outil génère une liste d’adresses e-mail professionnelles associées à un domaine. Il fournit également des informations sur les propriétaires de ces adresses, notamment leurs fonctions.
  • HIBP Cet outil vérifie si les adresses e-mail identifiées sont présentes dans des bases de données issues de fuites. Une inclusion dans ces bases peut révéler des risques potentiels, comme l’exploitation des données compromises pour mener des actions malveillantes, y compris des attaques de type supply chain ciblant les plugins.

D’autres outils OSINT prometteurs comme Hudson Rock (pour la détection de compromissions), Shodan (pour l’analyse d’infrastructures) et VirusTotal (pour la détection de malwares) ont été explorés mais n’ont pas pu être intégrés par contrainte de temps. Leur intégration future représente une perspective d’amélioration intéressante pour enrichir notre analyse.

Recherche sur les bases de données de vulnérabilités

Une autre information, collectée depuis des bases de données disponibles sur Internet, est indispensable : il s’agit des vulnérabilités affectant des plugins dans des versions spécifiques. A ce titre, nous avons décidé d’intégrer celle de WPVulnerability [? ], un éditeur réalisant également un plugin de sécurité WordPress éponyme. Il est intéressant car il regroupe plusieurs sources (CVE, JVN (Japan Vulnerability Notes), Patchstack et Wordfence), permettant une exhaustivité des vulnérabilités connues. La récupération des données relatives à un plugin et à une version spécifique est automatisable et nous permet de récupérer des éléments essentiels pour établir notre score de sécurité. Plus encore, cette base de données nous permet également de mesurer la criticité des vulnérabilités en fournissant également le CVSS associé, et ce même pour des vulnérabilités ayant affecté une version précédente du plugin. Cela permet de mesurer l’historique du sujet en termes de sécurité. Dans sa version gratuite, cette API ne permet pas d’obtenir les dernières mises à jour. Elle constitue néanmoins un socle solide pour appuyer notre système de scoring. De plus, elle est complétée par notre troisième pilier.

Analyse du code et de ses dépendances

La troisième force de notre solution réside dans l’analyse du code et des dépendances qui lui sont associées. Suite à notre état de l’art, nous avons décidé d’utiliser la référence dans le domaine, SonarQube, pour ce faire.

Cet outil identifie les points suivants :

  • Score de sécurité du code
    • A = 0 vulnerability
    • B = at least one minor vulnerability
  • C = at least one major vulnerability
  • D = at least one critical vulnerability
  • E = at least one blocker vulnerability
  • Nombre de vulnérabilités par criticité
  • Nombre de portions de code critiques (security hotspots)

Nous avons choisi d’intégrer deux de ces statistiques directement dans notre système de scoring du plugin. En effet, la méthode de détermination du score de sécurité par SonarQube nous semble assez représentative de la robustesse

du code. Cependant, nous avons également choisi de considérer le nombre de vulnérabilités par criticité, car toute vulnérabilité présente dans le code reste mauvaise ; aussi il convient de considérer les cas où un code pourrait contenir de nombreuses vulnérabilités mineures et qu’il serait évalué à “B” selon SonarQube.

Le nombre de portions de code sensibles à la sécurité, “security hotposts” [32], est également important dans l’implémentation d’un code robuste. Cependant, SonarQube n’est pas capable de déterminer si ces portions stratégiques sont implémentées de manière sécurisée ou non. Ainsi, nous avons choisi de ne pas considérer cette information dans notre scoring. Nous la toutefois conservons toutefois dans notre base de données et la présentons à l’utilisateur : il pourrait en effet être intéressant de s’interroger sur la légitimité d’un plugin très simple qui contiendrait de nombreux pans de code critiques, de la même manière qu’une application d’horloge ne devrait pas demander de permission d’accès à la caméra sur un téléphone.

Associée à l’analyse statique du code des plugins, l’analyse de leurs dépendances clôture les fonctionnalités de notre solution. Peu d’outils existants le permettent. Nous avons décidé d’adopter l’outil d’OWASP Dependency Check [8] en raison de son intégration possible avec SonarQube. Cette intégration ne concerne finalement que la partie “lecture” du rapport généré par OWASP DC, mais nous avons choisi de garder cet outil. En effet, sa mise à jour automatique de la base NIST est reconnue et son utilisation est facile. Étant également relativement léger, il s’interface bien avec notre solution.

Ainsi, l’outil permet de relever les statistiques suivantes sur les dépendances du projet :

  • le nombre de dépendances
  • la présence d’un fichier de gestion des dépendances (exemple : package.json)

S’il peut avoir accès à ce fichier, OWASP DC analyse :

  • le nombre de dépendances vulnérables
  • le nombre de vulnérabilités
  • le CVSS le plus élevé lié à chaque dépendance vulnérable

Les outils d’analyse de dépendances se basent sur la présence du fichier de gestion des dépendances. Après avoir étudié plusieurs plugins, nous avons remarqué qu’ils n’en avaient pas tous. Cependant, se passer de cette analyse nuirait à l’établissement de notre score, et la connaissance du nombre de dépendances reste tout à fait pertinente pour les utilisateurs, car si ce nombre est élevé, la surface d’attaque est étendue. Nous avons donc choisi d’intégrer les résultats de l’analyse d’OWASP DC dans notre solution, en notifiant l’utilisateur lorsque les statistiques liées aux vulnérabilités des dépendances sont impossibles à obtenir (en l’absence de fichier de gestion des dépendances).

Les informations collectées via des sources OSINT, des bases de données de vulnérabilités et des outils d’analyse de code et de dépendances sont intégrées de manière coordonnée et se complètent. L’agrégation, puis le traitement de ces données permet de produire, de manière automatisée, un score de sécurité analytique accompagné de rapports détaillés, fournissant ainsi une évaluation approfondie des risques de sécurité associés aux plugins. Notre solution se veut être un outil opérationnel pour les administrateurs de sites WordPress, leur permettant d’identifier et de gérer proactivement les risques de sécurité et de prendre des décisions éclairées.

Démarche de notation et constitution du score de sécurité

Notre méthodologie repose sur une analyse de risques préalable, qui a permis d’identifier les principales menaces et chemins d’attaques ciblant les plugins WordPress. À partir de ces analyses, nous avons sélectionné les données pertinentes à collecter et élaboré des indicateurs spécifiques pour répondre à des objectifs de sécurité précis. Ces indicateurs visent notamment à prévenir les risques d’usurpation de domaine, d’infrastructures compromises, de compromission de comptes (force brute, phishing) et d’exploitation de dépendances vulnérables. Ils permettent également de détecter les plugins contrefaits ou malveillants, de surveiller les failles liées aux versions obsolètes ou non mises à jour, et d’évaluer la conformité des plugins avec les licences.

Les informations nécessaires à l’évaluation des plugins sont collectées :

  • Avec le Store WordPress, WhoIs, Hunter.io et HIBP : OSINT et techniques de scraping pour enrichir les données disponibles
  • Avec WPVulnerability, OWASP DC : récupération des vulnérabilités pour identifier les failles connues sur les plugins ou leurs librairies.
  • Avec SonarQube : analyse de code pour évaluer la qualité du code source et détecter des failles potentielles.

Liste des données collectées :

  • Développement du plugin (Caractéristiques générales et gestion du plugin) :

    • Nom du plugin (Store WP)
    • Date d’inscription de l’auteur sur WP (Store WP)
    • Pays de l’auteur (Store WP)
    • Site web créé par l’auteur (Store WP)
    • Lien vers le site officiel du plugin (Store WP)
    • Nom(s) du ou des 3 plus gros contributeurs (Store WP)
    • Date de création du plugin (Store WP)
    • Date de dernière mise à jour du plugin (Store WP)
    • Licence sous laquelle le plugin est publié, souvent General Public License (Store WP)
    • Nombre d’installations actives, soient de téléchargements (Store WP)
    • Note de confiance donnée par les utilisateurs, de 1 à 5 étoiles (Store WP)
    • Nombre de notations de confiance (Store WP)
    • Temps de réponse du contributeur aux questions des utilisateurs dans la catégorie “support” (Store WP)
    • Pourcentage de tickets résolus dans le support (Store WP)

  • Auteur et son infrastructure (Informations sur l’auteur, son domaine, et la fiabilité de son infrastructure) :

    • Nom du détenteur d’un domaine (WhoIs)
    • Dates de création et d’expiration du domaine (WhoIs)
    • Registrar (organisme auprès duquel le domaine a été enregistré) (AbuseIPDB)
    • Recherche d’e-mails professionnels (Hunter.io)
    • Recherche d’adresses e-mail associées à un domaine et informations sur la réputation du domaine (Hunter.io)
    • Fuite d’adresses e-mail / d’identifiants avec date de la fuite et détails des données volées (HIBP)

  • Sécurité du code (Qualité et sécurité du code source, y compris les dépendances) :

    • Métriques générales sur le code : score de sécurité du projet (SonarQube)

  • Analyse des dépendances transitives, soient les bibliothèques qui sont indirectement incluses dans le projet via d’autres bibliothèques (OWASP DC)

  • Surveillance des failles (Identification des vulnérabilités spécifiques aux plugins, thèmes, ou dépendances) :

    • Identification des vulnérabilités de criticité (score CVSS) élevée et critique dans les plugins et thèmes (WPVulnerability)
    • Métriques générales sur le code : nombre de vulnérabilités (SonarQube)
    • Métriques générales sur le code : nombre de vulnérabilités critiques (SonarQube)
    • Identification des vulnérabilités des dépendances (java, node.js, python, ruby, .net, PHP, etc.) par un scan et une comparaison avec des bases de données de vulnérabilités connues (CVE, NVD) (OWASP DC)
    • Indication du plus haut score CVSS des CVE d’une dépendance (OWASP DC)

Une fois collectées, ces données sont organisées et stockées dans une base de données centralisée. Chaque type d’information est associée à un indicateur spécifique correspondant à un critère d’évaluation.

Elaboration, notation des critères d’évaluation et pondération.

• Notation des critères :

Chaque critère est noté individuellement en fonction d’un système de notation prédéfini. Cette notation s’appuie sur des règles claires, établies à partir de l’analyse des données collectées, et reflète les connaissances et compétences des auteurs en cybersécurité.

Par exemple, un critère basé sur le nombre de vulnérabilités critiques dans un plugin utilise la base WPVulnerability :

  • Aucune vulnérabilité détectée : 5 points.
  • Une ou plusieurs vulnérabilités détectées : 0 point.

Pour la variable collectée “Nombre de fuites (leaks) associées à l’adresse e-mail” d’un contributeur, nous avons utilisé l’indicateur suivant : “L’adresse e-mail du contributeur a-t-elle été exposée dans des fuites de données ? (oui/non)”. La notation associée était la suivante :

  • Non exposée = 5 points.
  • Exposée = 0 point.

La plupart de ces données sont évaluées car elles sont quantifiables et ont un caractère indiscutable sur la sécurité liée à l’environnement de développement du plugin.

Néanmoins, certaines données, comme la nationalité des développeurs, ne permettent pas de tirer de conclusions directes sur la sécurité et ne sont pas notées. Ces informations sont néanmoins incluses dans un rapport complémentaire, pour offrir une transparence maximale à l’utilisateur.

• Pondération des critères :

Les critères notés sont ensuite pondérés en fonction de leur importance relative pour le calcul du score global. Cette pondération reflète la pertinence des critères dans l’évaluation de la sécurité et s’appuie sur une analyse de risques approfondie. Les scores sont multipliés par des coefficients de 0.5, 1 ou 3.

  • Pondération faible (0.5) : Critères informatifs ou secondaires (aucun n’a été pondéré faiblement à ce jour)
  • Pondération standard (1) : Critères importants mais non critiques (exemple : réactivité aux tickets de support)
  • Pondération élevée (3) : Critères essentiels pour la sécurité (exemples : hébergement suspect, vulnérabilités critiques).

• Caractéristiques des indicateurs :

Chaque indicateur est conçu pour être :

  • Mesurable : exprimé en termes numériques (1 à 5) ou binaires (oui/non).
  • Pertinent : aligné avec les objectifs et des risques de sécurité identifiés.
  • Comparable : permttant une comparaison entre les plugins ou différentes versions d’un même plugin
  • Fiable : basé sur une méthode reproductible et transparente.
  • Actionnable : contribuant directement au calcul du score cyber final.

Analyse fonctionnelle et opérationnelle

Choix de l’environnement Proxmox

La solution est déployée dans un environnement de type Proxmox, un hyperviseur, qui permet la gestion de machines virtuelles (VM) en vue d’une meilleure évolutivité, d’une isolation des différents processus, ainsi que d’une gestion facilitée de la sécurité et des performances. Cet environnement multi-VM apporte la résilience et la robustesse nécessaires à la solution dans la mesure où chaque composant clé est isolé sur sa propre machine virtuelle, minimisant ainsi les risques de propagation d’une faille et facilitant la maintenance.

L’infrastructure de Proxmox permet également une grande flexibilité en termes de maintenance et de mise à jour des différents composants. Chaque machine virtuelle est indépendante, ce qui facilitera l’évolution de la solution, notamment si nous souhaitons ajouter de nouvelles sources d’OSINT ou intégrer des outils d’analyse supplémentaires, sans perturber l’environnement de production. Cette architecture, répartie sur différentes VM, assure une haute disponibilité et permet de faire évoluer la capacité de traitement pour répondre à des demandes croissantes. L’approche est conçue pour être à la fois réactive et proactive, à travers l’analyse continue des plugins et la mise à jour des informations sur les vulnérabilités dès qu’elles deviennent disponibles.

Description fonctionnelle

Sur le plan fonctionnel, la solution se base sur la collecte, l’analyse et l’évaluation des informations relatives aux contributeurs, au code source et aux dépendances des plugins, comme décrit précédemment. La collecte de données s’appuie sur les sources OSINT, intégrant les informations obtenues par le biais d’appels aux API disponibles et par des techniques de scraping ciblé (notamment pour OWASP DC). Ces différentes informations sont agrégées dans une base de données centralisée. Elles sont notées une à une, en fonction de critères pré-établis, et un score de sécurité est calculé à partir de ces multiples notes.

Fig. 3. Schéma de l’architecture fonctionnelle V2

Description de l’architecture technique

Les données collectées sont traitées dans un environnement de production composé de trois machines virtuelles principales sur Proxmox.

  • La première machine virtuelle (VM 1) est dédiée au processus de scraping. Cette VM collecte les données relatives aux plugins en interrogeant les différentes sources externes.
  • La seconde machine virtuelle (VM 2) est consacrée à l’analyse statique des plugins, notamment via les outils SonarQube et OWASP DC, afin de vérifier la qualité du code, d’identifier les failles potentielles et de procéder à une analyse des dépendances. Ces deux VM sont lancées simultanément dès que le nom et la version d’un plugin sont envoyés, ce qui permet de paralléliser les processus de collecte et d’analyse pour accélérer le traitement.
  • La troisième machine virtuelle (VM 3) joue le rôle de base de données, regroupant et organisant les informations collectées pour permettre leur analyse, le calcul des scores de sécurité et leur mise à disposition des utilisateurs.

L’API centrale déployée sur une autre VM sert de passerelle entre les différentes composantes du système et l’interface utilisateur WordPress. Cette API est responsable à la fois de la coordination entre les différentes machines virtuelles et de l’interaction avec l’utilisateur final.

Description du processus à partir la requête du client

Lorsque l’utilisateur d’un site WordPress envoie une requête, l’API commence par vérifier si les informations recherchées existent déjà dans la base de données (VM 3). Si les informations sont disponibles, elles sont renvoyées directement à l’utilisateur ; sinon, l’API enclenche simultanément le processus de scraping et d’analyse. Le fait d’avoir chaque processus sur une VM différente permet de distribuer la charge de travail et d’optimiser l’utilisation des ressources en fonction des besoins, tout en assurant une meilleure étanchéité des différentes opérations.

L’analyse des plugins s’effectue à partir des données agrégées et collectées par ces différents processus, chaque donnée étant associée à un critère et une note. La moyenne pondérée de ces notes fournit un score de sécurité ou “cyber score”.

Calcul du score

Une fois les différents critères notés (voir le tableau des indicateurs en annexe 16), un score global est calculé pour chaque plugin. Ce score est obtenu par la moyenne pondérée des notes attribuées aux différents indicateurs. Ce calcul est automatisé grâce à un déclencheur (trigger), qui prend en compte toutes les notes des différents indicateurs et applique les pondérations définies.

Délai de traitement et automatisation du score.

Lors de la mise en place de notre processus d’analyse des plugins, nous avons rencontré un obstacle conséquent : le délai d’obtention des informations fournies par SonarQube. Bien que les autres outils impliqués (scraping, vérification de domaines, recherche de vulnérabilités, etc) exécutent leurs tâches dans un délai raisonnable et relativement constant, SonarQube s’est avéré beaucoup plus chronophage. Ce délai est principalement dû au fait que SonarQube est fortement influencé par le nombre de lignes de code du plugin à analyser. Cependant, nous avons remarqué que, même pour un plugin simple contenant seulement cinq lignes de code, le temps d’analyse de SonarQube restait significativement supérieur à celui des autres outils.

Ce décalage dans les temps de traitement représentait un frein important à l’automatisation fluide du calcul du score final. Pour surmonter cet obstacle, nous avons adapté les modalités du déclencheur (trigger). Le trigger s’active donc automatiquement après chaque INSERT dans la table SonarQube, une fois que les autres tables ont été remplies avec les informations issues des autres outils. Nous nous assurons ainsi que :

  • l’analyse du plugin soit terminée : chaque fois qu’un enregistrement est inséré dans la table SonarQube (ce qui correspond à la fin de l’analyse d’un plugin par l’outil le plus chronophage), le déclencheur est immédiatement activé.
  • toutes les tables soient remplies : avant d’exécuter ses opérations, le déclencheur vérifie les tables contenant les résultats d’analyse des outils.

La vérification repose sur la clé primaire plugin_nom_version, qui identifie de manière unique chaque plugin et sa version. Si certaines tables nécessaires ne contiennent pas encore les données attendues, le déclencheur attend une nouvelle exécution (ou reporte le calcul final pour éviter des scores incomplets).

En résumé, le fonctionnement du déclencheur est le suivant :

  • (1) Sur la base de la clé primaire [plugin_nom_version], il récupère les données collectées par les autres outils.
  • (2) Si des calculs supplémentaires sont nécessaires (par exemple, vérifier si un domaine est expiré en comparant sa date d’expiration à la date actuelle), le déclencheur effectue ces opérations directement.

Modification de la base de données pour gérer les valeurs nulles.

Lors des analyses, certaines données collectées peuvent être manquantes ou incomplètes, notamment lorsque des informations spécifiques ne sont pas accessibles via les outils d’OSINT ou les API utilisées (par exemple, des métadonnées absentes concernant un plugin ou son auteur). Pour éviter que ces lacunes ne perturbent le calcul du score ou n’entraînent des erreurs dans les requêtes, la structure initiale de la base de données a été modifiée :

  • Les champs concernés par des données potentiellement nulles ont été adaptés pour accepter ces cas sans provoquer d’incohérences dans les calculs.
  • Une logique conditionnelle a été intégrée pour ignorer les champs vides.
  • L’annexe “Base de données” (E) illustre ces éléments.

Enrichissements

Avec l’intégration de nouvelles analyses et de nouveaux outils au cours de notre développement, il a été nécessaire d’enrichir les données stockées dans la base de données pour refléter ces apports. Le trigger a été amélioré également pour intégrer les nouvelles données et aux changements dans les critères d’évaluation.

Affichage du score dans l’environnement WordPress.

Le score global calculé est directement intégré à l’environnement WordPress de l’utilisateur et présenté de manière simple et intuitive, pour lui permettre d’évaluer rapidement la sécurité d’un plugin avant de l’installer.

Ce score est accessible via notre plugin WordPress, OSS Sentinel, spécialement conçu pour cette solution. Ce plugin affiche à la fois le score et un rapport détaillé, dans un souci de transparence. Il joue un rôle central dans l’expérience utilisateur en aidant même les utilisateurs peu familiers avec les enjeux de cybersécurité à identifier et éviter les plugins à risque.

Fig. 4. Schéma de l’architecture technique V1

Plugin OSS Sentinel (mise en oeuvre de la solution)

Afin de répondre au besoin de lisibilité et de simplicité des utilisateurs de Wordpress, nous avons développé une interface sous la forme d’un plugin. Par la fonction “analyse” (un bouton, un clic), ce plugin affiche le score de sécurité du plugin scanné, ainsi qu’un rapport détaillé contenant les informations liées à la sécurité les plus pertinentes.

Une fois le plugin installé sur un site WordPress, l’interface est accessible via le menu d’administration. L’utilisateur pourra analyser le plugin de son choix avant de l’installer sur son site. Sur l’interface, il retrouvera toutes les informations nécessaires à une prise de décision éclairée.

Explication du code PHP

Notre solution utilise une combinaison de PHP, SQL, et JavaScript pour collecter et afficher les informations sur les plugins. Voici pour exemple une partie clé du code PHP qui permet de récupérer les informations d’un plugin à partir de la base de données :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

1 global $ wpdb ;
2 $ plugin_id = intval ( $ _GET ['plugin_id ']) ;
3 $ plugin_data = $ wpdb - > get_row (
4 $ wpdb - > prepare (
5 " SELECT ␣*␣ FROM ␣`wp_plugin_analysis `␣ WHERE ␣id␣=␣%d",
6 $ plugin_id
7 ) ,
8 ARRAY_A
9 ) ;
10 if (! $ plugin_data ) {
11 echo '<div ␣ class =" wrap " > <h1 > Plugin ␣ Not ␣Found </h1 >
12 ␣␣␣␣␣␣␣␣␣␣<p>The␣ plugin ␣you␣are␣ looking ␣ for ␣ does ␣ not ␣ exist . </p > </div >';
13 return ;
14 }

La fonction get_row() de $wpdb permet de récupérer les données du plugin spécifié par l’ID passé en paramètre dans l’URL. En utilisant la méthode prepare(), nous nous assurons que la requête SQL est sécurisée et évite les injections SQL. Les informations récupérées sont ensuite stockées dans $plugin_data et affichées sur la page d’administration.

Présentation de l’interface d’analyse

Écran 1 : Page de résultats d’analyse.

Cette page regroupe les informations de sécurité collectées pour chaque plugin, telles que le nom de l’auteur, la note de sécurité, le nombre de téléchargements, et la date de dernière mise à jour. Ces informations permettent en un coup d’œil d’estimer la fiabilité des plugins et d’identifier les risques potentiels.

Fig. 6. Résultats de l’analyse des plugins, montrant des informations détaillées telles que le nom de l’auteur, le nombre de téléchargements, les mises à jour récentes, et les notes de sécurité.

Écran 2 : Détails du plugin sélectionné.

Enfin, cet écran fournit des informations approfondies sur un plugin spécifique, incluant des données sur le propriétaire (adresse IP, pays), les vulnérabilités identifiées par SonarQube, et d’autres informations de sécurité collectées à l’aide d’outils d’OSINT. Elles permettent à l’utilisateur de s’informer sur les éléments essentiels qui ont contribué au score de cybersécurité attribué au plugin

Fig. 7. Détails d’un plugin spécifique, incluant des informations sur le propriétaire, les vulnérabilités identifiées, les contributeurs, et une analyse SonarQube.

Analyse de la maturation des démonstrateurs

Le démonstrateur est désormais finalisé et fonctionnel, intégrant efficacement les outils prévus et validés lors des phases de test. Les éléments suivants ont été implémentés :

• Store WordPress, WhoIs, Hunter.io, Have I Been Pwned : données publiques sur les plugins, leurs auteurs et leurs infrastructures à l’aide de techniques d’OSINT.

• WPVulnerability, OWASP Dependency Check : informations sur les vulnérabilités connues des plugins et de leurs dépendances.

• SonarQube : analyse approfondie de la qualité et de la sécurité du code source des plugins.

Ces outils, combinés dans un workflow cohérent, permettent une analyse complète et fiable de la sécurité des plugins WordPress.

Résultats obtenus

Les résultats obtenus démontrent que le démonstrateur répond pleinement aux objectifs fixés. Les tests réalisés sur plusieurs plugins WordPress ont permis de valider la qualité des données collectées, la pertinence des analyses effectuées et la présentation des résultats pour l’utilisateur.

Collecte et enrichissement des données.

Les outils d’OSINT jouent un rôle clé dans l’enrichissement des données. Nous parvenons actuellement à récupérer toutes les données listées au chapitre Les informations nécessaires à l’évaluation des plugins sont collectées :. Elles permettent d’évaluer les auteurs et contributeurs des plugins considérés, ainsi que les sites web et domaines rattachés.

Identification des vulnérabilités.

Grâce à WPVulnerability et OWASP Dependency Check, le démonstrateur permet d’identifier les vulnérabilités connues des plugins et de leurs dépendances.

Les données récupérées par notre API depuis WPVulnerability incluent :

  • les informations générales sur la vulnérabilité : nom, score CVSS, gravité (High ou Critical),
  • les impacts détaillés : confidentialité, intégrité, disponibilité, interactions utilisateur requise, complexité d’accès, privilèges nécessaires,
  • les versions concernées : versions minimales et maximales affectées, permettant de vérifier précisément si une version donnée d’un plugin est vulnérable,
  • et l’exploitabilité : pour les vulnérabilités exploitables, le champ exploitable est collecté lorsqu’il est disponible (peu utilisé aujourd’hui).

Parmi les vulnérabilités détectées, on retrouve :

  • Cross-Site Scripting (XSS) : Failles permettant d’injecter des scripts malveillants, souvent via des entrées utilisateur non sécurisées.
  • Injection SQL (SQLi) : Exploitation d’entrées pour manipuler ou voler des données dans une base SQL.
  • Escalade de privilèges : Failles où des utilisateurs non autorisés obtiennent des privilèges admin.
  • Fuites de données : Impact majeur sur la confidentialité en cas de mauvaise gestion des informations sensibles.
  • Failles d’intégration : Vulnérabilités sur des APIs ou des services externes intégrés dans le plugin.

Les vulnérabilités identifiées respectent les standards de l’industrie en matière d’évaluation de sécurité :

  • Le format CVSS (norme 3.1) est utilisé pour noter la criticité des vulnérabilités. Il inclut des informations sur les vecteurs d’attaque (par exemple, Network, Local), l’interaction utilisateur requise et l’impact global.
  • Les champs min_version et max_version permettent d’identifier précisément les versions affectées, une pratique essentielle dans la gestion des risques.
  • Les informations collectées sont exploitables pour un suivi précis et une mitigation efficace des vulnérabilités.

Analyse du code source.

Le démonstrateur intègre SonarQube pour évaluer la qualité et la sécurité du code source des plugins. Les résultats obtenus incluent :

  • la détection des vulnérabilités présentes dans le code (failles critiques, moyennes, faibles),
  • une classification des failles détectées selon leur criticité,
  • une analyse des dépendances pour identifier les bibliothèques tierces vulnérables incluses dans les plugins.

Calcul du score final.

Le score de sécurité calculé par le démonstrateur repose sur une pondération des critères collectés à partir des outils intégrés. Tout au long du projet, des ajustements et améliorations ont été réalisés au niveau de la base de données et des processus associés au calcul du score. Ces améliorations ont permis de mieux traiter les données issues des analyses,

d’intégrer de nouvelles informations, d’optimiser les mécanismes de mise à jour des scores et d’en améliorer la résilience. Le trigger (voir Calcul du score fonctionne bien et les scores obtenus semblent cohérents. Par exemple : les versions antérieures des plugins obtiennent pour la plupart un score inférieur à la version actuelle. Le calcul de score s’appuie sur toutes les dimensions que nous avions identifiées. Il permet donc la prise en compte de toutes les dimensions pour l’évaluation de la sécurité des plugins : de l’hygiène informatique de son auteur jusqu’aux vulnérabilités connues qui l’affectent.

Fonctionnalités disponibles.

Le démonstrateur offre toutes les fonctionnalités prévues. Lorsqu’un utilisateur utilise notre plugin WordPress, une requête est envoyée via l’API, par exemple à l’URL suivante : http://192.168.2.100:5000/plugin/elementor_2.6.5, la solution fournit bien un résultat exhaustif contenant des informations sur :

  • (1) Le scraping des informations relatives au plugin :
    • Données sur le plugin trouvées sur le store WordPress (date de création, mise à jour, licence, note moyenne, etc.).
    • Analyse des champs pertinents pour le calcul du score cyber, tels que le nombre de téléchargements, la réputation des contributeurs, et les avis utilisateurs.
  • (2) Le scraping des informations relatives à l’auteur :
    • Détails sur les auteurs trouvés sur le store WordPress (pays, liste des plugins créés, badges, etc.).
    • Analyse de l’activité de l’auteur pour évaluer sa crédibilité et son implication dans la communauté WordPress.
  • (3) L’analyse WhoIs et Abuseipdb :
    • Données collectées sur le domaine associé au plugin (email de contact, pays, IP, hébergeur, dates de création et d’expiration du domaine).
    • Utilisation des outils AbuseIPDB pour évaluer la fiabilité du domaine.
  • (4) L’analyse SonarQube :
    • Identification des vulnérabilités dans le code source du plugin.
    • Classification des failles selon leur criticité (failles critiques, moyennes, faibles).
  • (5) Utilisation de Hunter.io et Have I Been Pwned (HIBP) :
    • Extraction d’adresses e-mail à partir d’un nom de domaine à l’aide de Hunter.io. Cette étape permet d’identifier les adresses e-mail associées à un site ou une organisation.
    • Analyse des adresses e-mail récupérées via Have I Been Pwned (HIBP) pour vérifier leur présence dans des bases de données de fuites.
  • (6) Base de données et calcul du score cyber :

{

  • Les données collectées sont ajoutées à une base de données organisée, permettant une mise à jour continue.
  • Dans la base de données, le mécanisme de trigger décrit ci-dessus calcule un score pour chaque plugin analysé. Ce score est ensuite retourné dans le fichier .json de réponse, par exemple :
1
2
3
4
5

"notre_analyse_data": {
    "Notre_score": "78.00",
    "Plugin_nom_version": "elementor_2.6.5"
}
...

}

(7) Plugin WordPress client

  • Un plugin est téléchargeable par les utilisateurs finaux et intégrable à leur environnement WordPress
  • L’interface permet d’afficher les données retournées par l’API (score et informations complémentaires sur le plugin visé par l’analyse)
  • Cette fonctionnalité a été développée et fournit toutes les informations prévues à l’utilisateur final.

Validation des performances

Stabilité et qualité.

Les tests effectués sur une dizaine de plugins WordPress et une trentaine de versions différentes ont permis de valider la stabilité et la qualité du démonstrateur. Les fonctionnalités prévues ont été intégrées avec succès, et les résultats obtenus respectent les spécifications initiales :

  • Le démonstrateur fournit des analyses cohérentes et fiables, même sur des plugins complexes ou volumineux.
  • Aucune erreur majeure de score n’a été relevée lors des tests, démontrant la robustesse de la solution.
  • Les scores obtenus sont différents d’un plugin à l’autre, montrant que les critères retenus apportent une finesse d’analyse suffisante.

Bien que le démonstrateur fournisse des analyses précises et pertinentes dans la majorité des cas, certains bémols ont été identifiés.

Certains plugins déclenchent des erreurs, lorsqu’ils présentent des caractéristiques particulières ou de données manquantes. Par exemple :

  • Plugins avec un trop grand nombre d’auteurs : Lorsqu’un plugin est développé par une équipe très importante, le traitement des données associées à chaque contributeur peut entraîner des erreurs ou des ralentissements, en particulier si les contributeurs ne disposent pas de profils bien renseignés.
  • Absence de données sur WhoIs : Certains plugins n’ont pas de domaine associé ou leur domaine est mal répertorié dans les bases WhoIs. Cette absence d’information empêche l’analyse complète de certains paramètres, comme la validation de la légitimité du site ou des infrastructures associées.

Un autre point à noter concerne un biais inhérent à l’utilisation des connaissances actuelles sur les vulnérabilités (CVE – Common Vulnerabilities and Exposures). Le score d’un plugin peut être fortement influencé par les vulnérabilités répertoriées à un moment donné. Cela peut entraîner une situation où un plugin dans sa version actuelle obtient un score plus faible que des versions antérieures, simplement parce que de nouvelles vulnérabilités ont été découvertes et ajoutées à la base CVE.

Une solution pourrait être de travailler à des ajustements dans le calcul du score (voir ci-après).

Temps de traitement.

Notre solution actuelle optimise l’allocation des ressources des machines virtuelles dédiées à aux processus de scraping et d’analyse. Par exemple, la mémoire de la machine exécutant l’analyse SonarQube, particulièrement chronophage, a été augmentée. Nous avons également mis en place une parallélisation des tâches, avec l’exécution simultanée des analyses indépendantes. De plus, les analyses effectuées sont sauvegardées dans la base de données et “requêtables”.

Ainsi, lorsqu’un plugin (et une version donnée) est déjà analysé, les requêtes récupèrent directement les résultats existants, évitant toute répétition inutile de l’analyse.

  • Le temps de traitement des analyses dépend de la taille et de la complexité des plugins :
  • Pour des plugins simples, l’analyse complète est réalisée en quelques secondes.
  • Pour des plugins volumineux, notamment lors de l’analyse statique du code avec SonarQube, le temps peut atteindre 3 à 4 minutes.

Bien que ces délais soient acceptables pour une utilisation classique de la soluion, des optimisations sont envisagées pour réduire davantage le temps nécessaire, en particulier pour les analyses impliquant SonarQube (voir ci-après).

Résultats exploitables

Le démonstrateur fournit des résultats exploitables directement dans l’environnement WordPress de l’utilisateur, par l’intermédiaire de notre plugin OSS Sentinel. Le principal atout d’OSS Sentinel réside dans sa simplicité d’utilisation : une analyse peut être lancée en un seul clic, et les résultats sont rapidement accessibles. De plus, le plugin reste “léger”, ce qui garantit un impact minimal sur les performances globales de l’installation WordPress. Pour l’utilisateur final :

  • Les rapports générés sont clairs et lisibles, présentant une évaluation rapide des plugins.
  • Le score global est intégré à l’interface WordPress, et donne un aperçu immédiat des risques avant l’installation d’un plugin.

Perspectives d’évolution d’OSS Sentinel

Bien que le démonstrateur atteigne les objectifs établis en début de projet, diverses pistes d’amélioration ont été repérées pour améliorer ses performances, élargir ses caractéristiques et assurer sa robustesse face à une augmentation prévisionnelle du nombre d’utilisateurs. L’objectif de ces progrès est d’améliorer l’efficacité, la fiabilité et la pertinence des analyses proposées.

Optimisation des performances.

L’un des principaux axes d’amélioration concerne l’optimisation des performances pour réduire le temps de traitement des analyses et limiter l’impact sur les ressources système. Dans l’infrastructure actuelle (de test), un grand nombre de requêtes simultanées peut temporairement rendre certaines machines virtuelles indisponibles ou ralentir considérablement leur performance.

Certaines étapes sont particulièrement chronophages, en raison de la taille et de la complexité des plugins analysés. Malgré les optimisations de notre infrastructure, l’analyse d’un plugin important comme Elementor par SonarQube dure environ 3 minutes.

Un passage à l’échelle supérieure avec mise à disposition publique de notre plugin impliquerait donc certaines modifications et précautions :

  • utiliser un serveur plus performant (actuellement le KS17-Kimsufi de chez OVH est limité),
  • mettre en place un système de limitation des requêtes par utilisateur dans un premier temps,
  • préparer des analyses des plugins les plus utilisés sur le marché afin qu’elles soient disponibles dans la base de données préalablement aux requêtes,
  • et implémenter une file d’attente pour les requêtes excédentaires pour maintenir une exécution ordonnée des analyses sans compromettre la disponibilité du système.

Intégration de nouveaux outils d’OSINT.

Pour enrichir les capacités d’analyse et fournir des résultats encore plus complets, l’intégration de nouveaux outils d’OSINT (Open Source Intelligence) est envisagée. Ces outils permettraient d’élargir le spectre des données collectées, notamment en explorant des risques liés à l’infrastructure, aux contributeurs, et aux comportements malveillants.

Shodan pourrait être intégré pour analyser les infrastructures associées aux plugins ou à leurs auteurs, en identifiant les systèmes exposés sur Internet et les éventuelles vulnérabilités réseau. Cet outil serait particulièrement utile pour détecter des configurations de serveurs ou de domaines mal sécurisées.

VirusTotal, quant à lui, fournirait des capacités supplémentaires pour analyser les fichiers ou les liens associés aux plugins. En détectant des comportements malveillants ou des fichiers suspectés de contenir des logiciels malveillants, il renforcerait la capacité du démonstrateur à évaluer les risques liés à l’installation des plugins.

GitHub pourrait également être exploité pour analyser l’activité des contributeurs. En examinant les dépôts publics, les threads de support ou les alertes de sécurité dans les discussions, il serait possible d’évaluer la réactivité et la transparence des développeurs. Les informations sur les “watchers” et les contributeurs actifs permettraient de mieux cerner la communauté autour d’un plugin.

L’intégration d’Hudson Rock et de Skymem permettrait de compléter et vérifier les informations de WhoIs et d’Hunter.io sur les contributeurs ou les entreprises derrière les plugins. Cela renforcerait le volet de détection des menaces avancées (malwares), des comportements douteux ou des fuites d’informations sensibles.

Enfin, Recorded Future pourrait être ajouté pour fournir une analyse contextuelle en temps réel des menaces identifiées. Cet outil, basé sur l’intelligence artificielle, pourrait enrichir l’analyse en identifiant des schémas ou tendances de menaces dans les bases de données publiques.

Amélioration du score cyber.

Le score de sécurité actuel, bien qu’efficace, pourrait être ajusté pour mieux refléter les risques identifiés et intégrer les nouvelles données collectées.

Afin de mieux gérer l’impact des connaissances évolutives sur les vulnérabilités, nous avons déjà envisagé des ajustements possibles dans le calcul du score. Par exemple, intégrer un critère qui valorise les versions plus récentes de plugins, en tenant compte des efforts de mise à jour et de correction réalisés par les développeurs. Cela permettrait de corriger le biais qui favorise les versions plus anciennes simplement par manque de documentation sur leurs vulnérabilités.

Aujourd’hui, les pondérations utilisées dans le calcul sont fixes, mais une approche plus dynamique, tenant compte du contexte ou des priorités spécifiques des utilisateurs, pourrait être envisagée. Par exemple, pour un site e-commerce, un poids plus important pourrait être accordé aux vulnérabilités critiques (intégrité des données) ou aux dépendances non sécurisées. Les plugins très populaires, utilisés sur de nombreux sites, pourraient être évalués plus strictement, car une vulnérabilité aurait un impact plus important, comme vu dans notre introduction. Les plugins mis à jour régulièrement pourraient recevoir un bonus dans leur score, réduisant l’impact des vulnérabilités historiques si elles ont été corrigées rapidement.

Une autre piste d’évolution consisterait à offrir une personnalisation du score. Les utilisateurs pourraient ajuster eux-mêmes les pondérations ou sélectionner les critères qui leur semblent les plus pertinents, en fonction de leurs besoins spécifiques (par exemple, un site gouvernemental pourrait privilégier l’intégrité et la confidentialité, tandis qu’un site de e-commerce la disponibilité). Il pourrait également être intéressant de permettre la relance d’analyses sur les plugins dont l’analyse date d’il y a quelques jours/semaines. Cela permettrait de mettre à jour la partie sur

les vulnérabilités publiées, qui a peut-être été modifiée. Cette nouvelle analyse devra prendre en compte l’absence de nécessité d’observation du code, puisque le code n’aura lui, pas changé (sinon la version du plugin aurait elle aussi changé).

Poursuite des tests et validations.

Pour garantir la robustesse et la fiabilité du démonstrateur, des tests approfondis devront être menés régulièrement, notamment si nous ajoutons de nouvelles fonctionnalités. Ces tests viseraient à valider la précision des scores, la stabilité du système et la cohérence des résultats avec les attentes des utilisateurs.

Des tests d’intégration devront être effectués pour vérifier que chaque nouvel outil ou fonctionnalité s’intègre correctement dans l’architecture existante. Cela garantira que l’ajout de nouveaux paramètres au calcul du score ou l’intégration d’outils comme Shodan ou VirusTotal ne perturbe pas les processus actuels.

Des tests comparatifs pourraient être réalisés en confrontant les scores calculés par le démonstrateur avec ceux générés par d’autres outils du marché tels que Wordfence ou SecuPress. Cela permettrait de vérifier que les résultats fournis sont compétitifs et pertinents, bien que les scores de ces derniers ne démontrent pas une démarche de notation élaborée (ce n’est pas leur fonctionnalité première). Par ailleurs, des études de cas sur des plugins connus pour leur sécurité ou leurs vulnérabilités pourraient confirmer la fiabilité des analyses.

Des tests de charge seront également nécessaires pour évaluer la performance du démonstrateur sous une utilisation intensive, comme vu précédemment. En simulant des scénarios de forte affluence, il sera possible d’identifier les éventuels goulots d’étranglement et de renforcer les composants les plus sollicités, comme les bases de données ou les appels aux API, et ainsi d’adapter notre infrastructure en conséquence.

Améliorations de l’interface.

Le plugin actuel présente une interface simple et intuitive, affichant toutes les informations sélectionnées ainsi que le score cyber des plugins analysés. Cependant, nous pourrions améliorer “l’expérience utilisateur” de plusieurs manières :

(1) Utiliser des couleurs pour indiquer le niveau de sécurité en fonction du score

  • Vert : pour un score élevé (80-100), indiquant un niveau de sécurité très satisfaisant.
  • Jaune : pour un score modéré (50-79), signalant des améliorations possibles ou des risques mineurs.
  • Rouge : pour un score faible (0-49), mettant en évidence des risques critiques.
  • (2) Ajouter des informations sur les risques encourus liés aux mauvaises notes de certains critères, par exemple :
    • Dépendances obsolètes : “Ce plugin utilise des bibliothèques tierces obsolètes, ce qui augmente le risque d’exploitation par des attaquants. Pensez à vérifier si une mise à jour est disponible.”
    • Failles critiques : “Une vulnérabilité critique a été détectée dans le code source. L’utilisation de ce plugin pourrait exposer votre site à des attaques majeures.”
  • (3) Ajouter des messages de sensibilisation généraux sur les bonnes pratiques en cybersécurité
    • “Assurez-vous toujours que vos plugins sont régulièrement mis à jour pour corriger les éventuelles failles decurité.”
    • “Évitez d’installer des plugins provenant de sources non officielles ou peu fiables.”
    • “Supprimez les plugins inutilisés pour réduire la surface d’attaque de votre site.”
  • (4) Ajouter des alertes lorsque les plugins installés n’ont pas été scannés depuis quelques temps (si l’amélioration du calcul du score est implémenté (voir8.3.3) :
    • “Le plugin X n’a pas été analysé depuis 30 jours. Cliquez ici pour lancer une nouvelle analyse.”

Citations et bibliographie

References

OSINT
Licensed under CC BY-NC-SA 4.0
Dernière mise à jour le janv. 13, 2025 00:00 UTC
© 2020 - 2025 Blog - Mattéo
Généré avec Hugo
Thème Stack conçu par Jimmy