La vulnérabilité log4j est apparue il y a deux ans environ, presque jour pour jour, gâchant les vacances de nombreux informaticiens de tout poil. Pour rappel, cette faille béante avait un score CVSS 3.0 de 10 (note maximale), car elle permettait à n’importe qui d’exécuter du code arbitraire sur n’importe quel serveur utilisant cette bibliothèque logicielle servant à la gestion des logs.

• Log4shell : les jours d’après
• Log4Shell : derrière l’importante faille, l’éternelle question du soutien au logiciel libre

Les impacts potentiels étaient si graves que même des organismes tels que le FTC (Federal Trade Commission) avaient brandi la menace de sanctions contre les entreprises ne se protégeant pas efficacement contre l’exposition à Log4Shell.

Aujourd’hui, fin 2023, on devrait donc être dans une situation stable et sans nuages. Eh bien, figurez-vous que non.

Pour l’instant, ça va ?

Cela ne surprendra pas ceux qui travaillent dans l’IT, qui savent que tout changement est problématique et que la marche vers la sérénité est longue et laborieuse. Pourtant les correctifs sont bel et bien disponibles !

Il y a bien eu quelques hésitations, mais on peut convenir qu’ils ont été rapidement mis à disposition, et comme il s’agissait d’une bibliothèque Java, on pouvait raisonnablement penser que mettre en place la version corrigée n’allait requérir qu’un effort modéré, surtout face aux risques encourus.

Patatras : une étude de la société Veracode réalisée entre les mois d’août et novembre de cette année nous apprend que, parmi ses clients (représentant 38 278 applications), une application sur trois utilisant log4j emploie encore une version vulnérable à la faille !

Le diable est dans le détail (des versions)

Regardons quand même de plus près les résultats :

• • 2,8 % des applications utilisent une version vulnérable (de 2.0-beta9 à 2.15.0). Sur celles-ci, log4j pourrait s’appliquer sans problème ;
  • 3,8 % utilisent une version plus récente (2.17.0) qui n’est pas vulnérable à Log4Shell mais qui est touchée par une autre faille, la CVE-2021-44832. Veracode explique ce chiffre par le fait que les équipes auraient voulu patcher très rapidement, mais sont vite passées à autre chose, oubliant ainsi de vérifier que le patch devait lui aussi être patché car vulnérable ;
  • 32 % utilisent encore… la version 1, vulnérable et qui n’est plus maintenue depuis des années ! Et donc logiquement, cela veut dire que les 68 % restants sont en version 2.

D’autres éditeurs surveillent log4j : ainsi, Sonatype scrute également l’état des installations, avec de jolis graphiques en prime.

Cela illustre le phénomène de fenêtre d’attaque : un système reste vulnérable depuis la découverte jusqu’à l’installation du patch (ou de mesures d’atténuation), d’où l’intérêt pour un particulier (un utilisateur final) de faire des mises-à-jour constantes de son système pour réduire la durée de cette fenêtre.

Un patch peut certes toujours introduire une nouvelle vulnérabilité, mais qui nécessitera un autre mode d’attaque qui demandera du temps d’adaptation du côté des attaquants, donnant malgré tout un peu de répit (par rapport à la situation où on laisse une vulnérabilité connue non corrigée).

Dans une autre étude (State of Software Security v11), Veracode nous apprend aussi que 8 fois sur 10, l’équipe de développement ne met jamais à jour les logiciels tiers.

Et quand les mises-à-jour sont faites, elles s’arrêtent souvent aux versions mineures, car le gap à franchir entre versions majeures est souvent important : regardez la marche à suivre pour passer de log4j 1.x à 2.x, vous verrez qu’il n’y a rien de trivial et que cela représente donc une charge importante pour les équipes de développement.

Veracode pointe souvent le manque de ressources (de développeurs) ou d’information pour expliquer le manque de suivi et d’application des mises-à-jour.

On comprend mieux pourquoi c’est dans les vieux pots que les pirates font les meilleures confitures : les techniques d’attaque (d’exploitation des vulnérabilités) ont largement le temps d’être construites, testées, éprouvées et diffusées !

Sachez d’ailleurs que certains chercheurs s’amusent à faire une météo des attaques, un peu comme pour suivre le déplacement des nuages, mais en cherchant à suivre la diffusion des tactiques et des procédures dans le temps et l’espace géographique. Ça n’est qu’indicatif, mais cela illustre souvent les relations entre groupes d’attaquants.

Il y a vraiment des attaques ?

Cisco Talos attribue au groupe APT Lazarus (lié à la Corée du Nord) deux chevaux de Troie et un downloader exploitant la vulnérabilité Log4Shell en mars 2023.

Donc oui, tant que ça marchera, les pirates attaqueront !

Back to the future

Jetons maintenant un œil vers l’avenir. La CISA (Cybersecurity and Infrastructure Security Agency, chargée d'assurer la sécurité et la résilience contre les menaces liées à la cybersécurité aux États-Unis) s’est fendue de communications multiples et a fourni des outils pour aider à lutter contre cette vulnérabilité particulière :

• • CSRB Report on Log4j - Public Report - July 11 2022_508 Compliant (cisa.gov)
  • Apache Log4j Vulnerability Guidance | CISA
  • A community sourced list of log4j-affected software (github.com)

Certains analystes nous prédisent même une bonne dizaine d’années avant de se débarrasser de ce problème. Un remède de bon sens consiste à automatiser la surveillance des vulnérabilités, surtout pour les bibliothèques tierces qu’on a trop tendance à oublier. Et bien sûr, une sécurité en profondeur, en plusieurs couches, est également une idée incontournable à l’heure des systèmes ultra-ouverts.

À condition de maîtriser ce qu’on fait, pas comme cette entreprise qui a mis à jour ses règles WAF (Web Application Firewall) juste avant l’attaque, la préservant ainsi de Log4Shell. Avant de s’apercevoir dans la foulée qu’aucune autre règle n’avait été activée depuis l’installation de l’outil…