Log4 Shell, le colmatage des brèches
Examinons maintenant, les remèdes aux attaques qui exploitent les vulnérabilités de Log4J dont celle nommée Log4 Shell.
Les trois étapes consistent :
1) À parer au plus pressé, dans l’attente d’un correctif. La technique de Virtual Patching, qui s’appuie sur les pare-feu de nouvelle génération, nommés NGFW, offre un blindage temporaire plus ou moins efficace;
2) Trouver un correctif. Celui-ci fut rendu disponible, par la communauté Apache, une dizaine de jours après la publication des failles ;
3) Déployer le correctif avec une priorisation performante : les 500 dépendances directes prépondérantes, ensuite mobiliser pour les 7000 dépendances directes puis mobiliser la communauté des développeurs (éditeurs, communautés Open Source). A dire d’expert, plusieurs années seront nécessaires pour une immunité totale à cause des dépendances de second niveau.
Quelles leçons tirer de ces péripéties ?
Le virtual Patching
L’exploitation de la faille Struts, en 2017, nous avait déjà montré l’inefficacité des pare-feu pour application web pour protéger contre les attaques. Il ne faut pas compter sur une protection forte avec ses moyens. Il s’agit néanmoins d’un pis-aller à ne pas négliger faute de mieux.
L’éradication des faiblesses de code
En toute logique, les vulnérabilités exploitables résultent de faiblesses de code et de configurations erronées. En ce qui concerne le développement du nouveau code à valeur ajoutée, les développeurs prendront soin d’éliminer les faiblesses de code connues et documentées de la base de connaissances nommée Common Weakness Enumeration (CWE). Ces faiblesses détectées par des tests de sécurité statique sont en lien direct avec les dix risques majeurs des applications web, connus sous l’appellation Top 10 OWASP. Il s’agit d’éradiquer les causes des menaces – les faiblesses du code – afin de supprimer les symptômes – les vulnérabilités.
La faille Log4 Shell, le symptôme, identifiée par son numéro de vulnérabilité connue CVE-2021-44228, est causée par des faiblesses de code connues, les causes, identifiées par leurs codes : CWE-94 (Contrôle incorrect de la génération de code), CWE-917 (Neutralisation incorrecte des éléments spéciaux utilisés dans une déclaration de langage d’expression). Ces faiblesses de code source de la bibliothèque Log4J portent un risque majeur d’attaque par injection, identifié par l’institution nommée Open Web Application Security Project sous l’identifiant A03:2021 – Injection.
L’utilisation de composants préfabriqués sécurisés
Il est aussi essentiel de rappeler que la sécurité est une chasse au maillon faible. Ceci implique que, bien que des équipes de développement sécurisent consciencieusement leurs activités de développement, l’utilisation de tiers composants (Open Source ou commerciaux) non approuvés va ruiner la sécurité de l’application et la compromettre dans son ensemble.
Il est donc nécessaire de prendre au sérieux la réception sécurisée de tiers composants et de prévoir dès la conception une architecture logicielle modulaire qui permettra de les échanger facilement. Il va de soi qu’à l’instar d’une base de données d’inventaire du matériel, nommée CMDB, une base de données d’inventaire des briques logicielles doit être établie et tenue à jour en permanence tout au long du cycle de vie des applications. Ce SBOM (Software Bill Of Materials), une nomenclature des composants logiciels tiers est un facteur clé du pilotage par les risques de la sécurité des applications de toutes natures (cloud native ou monolithique).
