Cela fait quatre mois que Log4Shell, une vulnérabilité critique du jour zéro dans la bibliothèque omniprésente Apache Log4j, a été découverte, et les analystes des menaces avertissent que l’application des correctifs disponibles est encore loin derrière.
Bien que l’intérêt public et l’attention de la communauté infosec se soient déplacés vers de nouvelles vulnérabilités et exploits, Log4Shell continue d’être un problème à grande échelle et un grave risque de sécurité.
La dernière fois que nous avons abordé le sujet de l’exploitation de Log4Shell, c’était il y a environ deux mois, lorsqu’un rapport de Barracuda a souligné que ce sont principalement les botnets qui l’ont exploité pour le DDoS et l’extraction de crypto-monnaie.
Cependant, un nouveau rapport publié aujourd’hui par Rezilion dresse un tableau désastreux, révélant une grande surface d’attaque sur une large gamme de produits logiciels.
Il s’agit d’un problème grave en raison de son impact potentiel (exécution de code à distance) et de la facilité d’exploitation (disponibilité des PoC).
Un problème qui est toujours là
Selon le rapport de Rezilion, qui présente des données de divers points, Log4Shell, suivi comme CVE-2021-44228, est toujours présent dans tant de produits logiciels qu’il est difficile de formuler une explication logique.
Par exemple, lorsqu’on examine Sonatype‘s Log4j Download Dashboard, nous constatons qu’un pourcentage stable de près de 40 % télécharge encore des versions vulnérables de Log4j même à la fin du mois d’avril.
Alors que cela était auparavant attribué aux chercheurs en sécurité, aux analystes ou même aux acteurs de la menace testant leurs exploits, la persistance du pourcentage à des niveaux élevés après tout ce temps exclut ces scénarios.
En examinant les données du service Open Source Insights de Google, Rezilion a découvert que sur les 17 840 packages open source utilisant Log4j comme dépendance, seuls 7 140 avaient été mis à niveau vers une version fixe. Ainsi, 60% d’entre eux restent vulnérables à Log4Shell.
Lors de la recherche de la catégorie particulière de conteneurs open source sur Shodan, Rezilion a trouvé plus de 90 000 applications Internet potentiellement vulnérables contenant des versions obsolètes de Log4j. Un exemple notable est Apache Solr, qui compte 1 657 déploiements publics et utilise toujours Log4j-core-2.16.0-jar.
Apache Storm et Apache skywalking-oap sont d’autres conteneurs populaires corrigés avec un retard massif en avril 2022, tandis que le gestionnaire d’API WSO2 a été corrigé en mars 2022.
De toute évidence, les dernières versions de conteneurs n’ont pas encore été adoptées par tous les utilisateurs, il existe donc encore des dizaines de milliers de déploiements vulnérables sur Internet.
Ensuite, il y a ceux qui utilisent Log4j 1.2.17, obsolète et qui n’est plus pris en charge, notamment Atlassian Crucible, Apache zeppelin, Bitnami Kafka et Bitnami Spark. Il existe une idée fausse selon laquelle Log4Shell n’a pas d’impact sur l’ancienne version de la branche, mais ce n’est pas vrai.
Enfin, en examinant les serveurs Minecraft, point de départ de la découverte de Log4Shell, Rezilion a découvert 68 000 serveurs potentiellement vulnérables.
Une explication possible
Rezilion suggère que l’état actuel des correctifs résulte de plusieurs facteurs qui contribuent au problème, notamment un manque de processus de gestion des vulnérabilités appropriés et une mauvaise visibilité.
Log4j est difficile à détecter dans les environnements de production, et les organisations ne réalisent pas toujours qu’elles l’utilisent via des logiciels tiers.
En résumé, les entreprises ne savent pas si elles l’utilisent, ne savent pas quelle version elles utilisent et ne savent pas quelles versions peuvent être utilisées en toute sécurité.
Ensuite, il y a divers cas particuliers, comme l’utilisation de politiques de mise à jour logicielle granulaires sur des environnements conteneurisés qui favorisent la stabilité opérationnelle et n’extraient pas les dernières mises à jour logicielles disponibles.
Les vieux défauts persistent
Comme les bulletins de la CISA sur l’exploitation active des failles l’ont souligné à plusieurs reprises, les pirates ne se soucient pas de l’âge d’une vulnérabilité tant qu’elle les fait pénétrer dans un appareil ciblé.
Il arrive souvent que l’on voit des bugs vieux de 10 ans encore activement exploités dans la nature, et Log4Shell apparaît comme un excellent candidat pour faciliter la poursuite de cette pratique.
Quatre mois après la découverte et l’application des correctifs, Log4Shell est toujours présent, alors analysez votre environnement, trouvez la version que vous utilisez, puis développez un plan de mise à niveau d’urgence.
Si vous constatez que vous utilisiez une version vulnérable pendant tout ce temps, supposez un compromis et continuez sur cette voie pour rechercher des signes d’activité malveillante et déraciner toute porte dérobée plantée.