D’après un document intitulé « 2022 Telemetry Report » publié par Trustwave SpiderLabs, le nombre de CVE ajoutés cette année pourrait être jusqu'à 35 % plus élevé que celui de l’année 2021. Même si, par rapport à l'année précédente, les entreprises semblent plus sensibilisées à la nécessité de gérer efficacement les correctifs, le nombre total de CVE publiés en 2022 dépassera celui de 2021, si les tendances actuelles se poursuivent. Le rapport s’est aussi intéressé à des vulnérabilités hautement critiques et à leur persistance.

Des CVE d’injection de commandes et RCE persistantes

Dans son rapport, SpiderLabs estime qu'au 16 juin, le nombre de CVE publiées en 2022 est supérieur d'environ 6 à 35 % à celui de l'année dernière. « En 2022, trois vulnérabilités sont couramment retrouvées dans la liste CWE (base de données des vulnérabilités gérée par MITRE) : CWE-79, CWE-89 et CWE-787 », ajoute le rapport. « Ces trois CWE sont communes aux vulnérabilités d'injection de commande et d'exécution de code à distance (Remote Code Execution, RCE) ». Les données du moteur de recherche Shodan, issues du balayage de ports massifs du réseau Internet, ont également montré que certaines failles très médiatisées étaient encore répandues », a déclaré l’éditeur. Les hackers éthiques (White Hat) et les pirates (Black Hat) scannent tous deux l'Internet pour recueillir des informations sur ces vulnérabilités.

Log4Shell et Spring4Sehll restent très utilisées

Alors que la vuln Log4Shell (CVE-2021-44228) a été découverte il y a six mois, l’éditeur a trouvé 1 467 instances vulnérables à la date du 9 juin 2022. Elles ont été majoritairement localisées en Russie, les États-Unis et l’Allemagne avec 266 (18 %), 215 (15 %) et 205 (15 %) hôtes, respectivement. SpiderLabs a déclaré que « tous les produits affectés ne sont pas abordés par ce rapport » et il n'a évalué que des échantillons des services affectés les plus populaires. « Des acteurs essayent toujours d'exploiter cette vulnérabilité » et, d’après le réseau de capteurs GreyNoise6, sur lequel elle s’appuie, SpiderLabs a estimé que sur 30 jours, 667 adresses IP uniques avaient essayé d'utiliser Log4Shell sur Internet.

Toujours selon SpiderLabs, les instances exposées à Spring4Shell (CVE-2022-22965), apparue à la fin du premier trimestre 2022, sont actuellement peu nombreuses. « Sur les 452 520 instances examinées, seulement 0,0758 % sont vulnérables. Au 12 juin 2022, les pays ayant le plus grand nombre d'instances vulnérables étaient la Chine, les États-Unis et l'Irlande, avec respectivement 122 (36 %), 93 (27 %) et 18 (5 %) ». Selon le rapport, Spring4Shell est toujours exploité, mais pas aussi activement que Log4Shell, avec une moyenne de 15 à 20 IP tentant d'exploiter Spring4Shell par jour. Malgré une faible empreinte sur Shodan, des instances vulnérables relatives à l'exploit d'exécution de commande dans l'interface F5 BIG-IP via iControl REST (CVE-2022-1388), publié en mai 2022, ont été détectées par SpiderLabs. « Heureusement, seulement 2,73% des 1 719 instances sont vulnérables », indique l’entreprise de sécurité, ajoutant qu’avec 26% du total, les États-Unis concentraient le plus grand nombre d'instances exposées. « Cette vulnérabilité est revisitée de temps en temps, mais il y a des jours où aucune tentative d'exploitation n'est enregistrée », précise le rapport.

La faille d'Atlassian concernant l'exécution de code à distance sur Confluence pour serveur et datacenter  (CVE-2022-26134) a été publiée au début du mois de juin 2022 et, au 11 juin, seuls 4,44 % des 7 074 hôtes trouvés sur Shodan étaient exposés, selon SpiderLabs. « La Chine, les États-Unis et la Russie concentrent le nombre le plus élevé de CVE-2022-26134, avec 120 (38 %), 37 (12 %) et 27 (9 %) instances affaiblies ». Au 19 juin, 2 398 adresses IP uniques ont été détectées tentant d'exploiter la brèche, avec un pic de 607 adresses IP uniques observées le 6 juin, indique encore le rapport. Il est intéressant de noter que certaines adresses IP uniques identifiées par SpiderLabs ont tenté d'exploiter trois des quatre vulnérabilités mentionnées ci-dessus, dont 525 adresses IP croisées essayant d'exploiter à la fois les failles Log4Shell et Atlassian Confluence RCE.

Vulnérabilités non corrigées : des risques variables selon les entreprises

Qui plus est, en évaluant les instances faillibles soit à CVE-2021-44228, soit à CVE-2022-22965, soit à CVE-2022-1388, soit à CVE-2022-26134, SpiderLabs a constaté que certaines d'entre elles sont encore attaquables à des CVE remontant à 2016, la plus courante étant la vulnérabilité CVE-2017-15906 affectant OpenSSH. Ce qui pourrait indiquer que des entreprises vulnérables à des failles plus récentes ont peut-être omis, aussi, de corriger des exploits vieux de plusieurs années. D’après Ziv Mador, vice-président de la recherche sur la sécurité chez Trustwave SpiderLabs, certains scénarios peuvent expliquer pourquoi des entreprises ne corrigent pas les vulnérabilités rapidement, voire pas du tout. « Certaines entreprises appliquent des correctifs, mais ça leur prend du temps. Par exemple, elles peuvent vouloir tester les correctifs dans leur environnement de pré-production avant de les déployer en production. D’autres entreprises peuvent prendre leur temps parce qu'elles ne comprennent simplement pas l'urgence d’appliquer les correctifs ».

« À l'inverse, il arrive que certaines entreprises n’appliquent pas de correctifs du tout parce que celui-ci aborde une vulnérabilité qui (selon elles) n'est pas exploitable dans leur configuration/environnement spécifique », a ajouté M. Mador. « Mais il se peut aussi qu'une entreprise n'installe pas de correctif parce que son processus est défaillant, ou qu'elle ignore le risque ». Dans certains environnements, les correctifs ne sont pas installés « car cela peut invalider la certification de systèmes spécifiques », a ajouté Ziv Mador. « C'est fréquent avec les terminaux utilisés dans les environnements de santé. Dans ce scénario, les entreprises n'appliquent pas de correctifs parce qu'elles considèrent que la menace n'est pas assez importante », a poursuivi Ziv Mador. « En effet, certaines failles ne sont pas exploitables dans certaines configurations, et la décision de ne pas appliquer de correctif peut être légitime dans ces cas », reconnaît le dirigeant. « Il est cependant essentiel que l'équipe de sécurité s’en assure formellement ».