log4shell (CVE-2021-44228) – que faire ? – Blog de sécurité informatique Tec-Bite

À propos de cette offre

Une fois de plus, une faille informatique domine les gros titres des médias. Lorsque même les journaux quotidiens ordinaires en parlent, la confusion est généralement d'autant plus grande. Je souhaite ici expliquer à quel point c'est grave et comment on peut ou a pu se protéger.

Que s'est-il passé ?

Une exécution de code à distance (RCE) a été découverte dans le framework de journalisation Apache Log4j pour Java. La vulnérabilité est relativement facile à exploiter. La très large diffusion de Log4j dans de nombreux projets rend la situation si grave. Le framework est utilisé dans des milliers de projets logiciels. Un attaquant doit simplement envoyer une chaîne à l'application, qui sera ensuite enregistrée dans les logs. Le framework de journalisation interprète cette chaîne, se connecte ensuite à un serveur LDAP(s) et télécharge du code depuis celui-ci.

Est-ce vraiment si grave ?

Fondamentalement, il est dévastateur qu'une vulnérabilité aussi critique (score CVSS 10/10) soit restée non détectée pendant 7 ans dans un framework aussi largement utilisé. Malheureusement, il n'est pas exclu que des acteurs étatiques aient déjà connu la vulnérabilité depuis longtemps et l'aient utilisée pour des attaques. La liste des entreprises affectées, telles que Google, Apple ou Cloudflare, montre à quel point le framework est répandu. Log4shell relancera probablement le débat sur les revues de sécurité des logiciels open source. Pour être juste, il faut dire que les grandes entreprises informatiques font déjà beaucoup, mais manifestement pas encore assez. Cela soulève aussi la question de savoir si cela peut ou doit vraiment être laissé aux grandes entreprises technologiques.

La bonne nouvelle est que si des mesures de protection de base ont été mises en place, on ne devrait guère être affecté par log4shell. Cela ne doit cependant pas être mal compris : la probabilité que le composant vulnérable soit présent dans votre réseau est proche de 100 %. Vous devriez donc identifier et patcher les systèmes concernés. La mise en œuvre de quelques bonnes pratiques simples empêche cependant l'exploitation active de la faille.

Comment puis-je me protéger ?

C'est en fait assez simple. Les attaquants doivent charger du code via LDAP(s). Cela signifie automatiquement que si cela n'est pas possible, la vulnérabilité ne peut pas être exploitée activement. Ceux qui ne laissent pas leurs serveurs accessibles sur Internet, ou seulement via un proxy, peuvent déjà dormir beaucoup plus tranquilles. Ceux qui, par commodité, veulent absolument laisser leurs serveurs sur Internet devraient au moins restreindre les protocoles à HTTP(s). Je ne vois vraiment aucune raison pour qu'un serveur communique en LDAP avec le monde entier. Il est important que le pare-feu n'ouvre pas simplement les ports 80/443, mais qu'il effectue aussi une détection de protocole. Cela garantit qu'une session HTTP se déroule bien sur le port 80 et non du LDAP.

Un deuxième vecteur d'attaque passe par RMI (Remote Method Invocation). Cela peut être utilisé pour exécuter du code vulnérable d'un système sur un autre système. Ici, une segmentation réseau aide surtout. En général, il n'y a aucune raison pour qu'un système accessible depuis Internet puisse communiquer avec d'autres serveurs via RMI.

Il existe également plusieurs paramètres que l'on peut définir sur les systèmes affectés pour résoudre le problème. Il y a déjà beaucoup d'informations à ce sujet sur Internet, donc je n'en dirai pas plus ici.

Comment identifier les systèmes vulnérables ?

Il existe désormais de très bons scanners open source qui recherchent toutes les bibliothèques Java pour les versions vulnérables de Log4j. Les clients ont plus de succès avec une solution de gestion des vulnérabilités comme Tenable, par exemple. Ils ont reçu un rapport directement après le week-end avec une liste de tous les systèmes affectés. C'est peut-être le bon moment pour tester une telle solution.

Comment reconnaître les systèmes compromis ?

L'exploitation de la faille est relativement facile à détecter. Là aussi, il existe déjà beaucoup d'informations sur Internet. Le plus simple est de rechercher dans les logs des systèmes affectés. Alternativement, il existe aussi des listes IOC (indicateurs de compromission) disponibles gratuitement qui peuvent aider.

Conclusion

Il est clair que log4shell est une faille dévastatrice qui touchera de nombreuses entreprises. Cependant, ceux qui ont principalement suivi les bonnes pratiques devraient dormir beaucoup plus tranquillement que d'autres. Néanmoins, il est conseillé d'identifier rapidement les systèmes vulnérables et de résoudre durablement le problème.