Vulnérabilité Log4J : que se passe-t-il ensuite ? – Moniteur technique

Au cours de la semaine qui a suivi l’émergence de la vulnérabilité de sécurité Log4J, les éditeurs de logiciels et les organisations d’utilisateurs finaux se sont efforcés de corriger leurs systèmes, alors que les attaquants testaient les exploits et lançaient des centaines et des milliers d’attaques. Voici ce que nous avons appris sur la façon dont la vulnérabilité Log4J est exploitée, comment l’industrie technologique a réagi et comment les organisations doivent réagir à court et moyen terme.

Comment la vulnérabilité Log4J est-elle exploitée ?

Jeudi dernier, des détails ont émergé d’une nouvelle vulnérabilité dans Log4J, un outil de journalisation open source pour le langage de programmation Java. La nouvelle a déclenché une alarme dans le secteur de la cybersécurité en raison de l’omniprésence de Log4J et de la facilité avec laquelle la vulnérabilité peut être exploitée.

Même les pirates informatiques non avertis peuvent télécharger des outils pour rechercher sur Internet des serveurs non corrigés et utiliser des commandes copiées à partir de référentiels de code en ligne pour les exploiter, explique David Warshavski, vice-président de la sécurité d’entreprise chez Sygnia. Le dernier outil capable d’analyser toute la plage IP d’Internet et d’identifier les personnes potentiellement vulnérables [servers] en moins d’une journée.

Les exploits se propagent rapidement. La première tentative d’exploitation de la vulnérabilité a été enregistrée neuf minutes après sa publication. Après 12 heures, il avait été utilisé dans 40 000 tentatives de cyberattaques, selon le fournisseur de logiciels de sécurité CheckPoint. Après 72 heures, il y avait eu 830 000 tentatives d’attentats.

Peu de temps après que la vulnérabilité a été rendue publique, les criminels ont échangé des exploits de « preuve de concept » sur des babillards électroniques sur le Web sombre, a déclaré Chris Morgan, analyste principal du renseignement sur les cybermenaces chez Digital Shadows. Les affiches « se félicitaient mutuellement de la grande opportunité que ce serait dans un avenir prévisible », a déclaré Morgan.

Les exploits initiaux n’étaient pas sophistiqués, dit Warshavski, mais ont rapidement été suivis par des logiciels malveillants de cryptomineurs qui utilisent des serveurs compromis pour exploiter des crypto-monnaies. Ironiquement, dit-il, cela peut avoir été bénéfique, permettant aux entreprises de repérer qu’elles ont été compromises sans perte de données.

Depuis, d’autres exploits malveillants sont apparus. Beaucoup d’entre eux exploitent la vulnérabilité Log4J pour extraire des informations qui peuvent être utilisées dans de futures attaques plus pénétrantes. « La grande majorité des charges utiles que nous observons là-bas ont à voir avec l’exfiltration des données de configuration des applications », explique Warshavski.

Digital Shadows a vu des preuves de courtiers d’accès initiaux, qui compromettent les organisations cibles, puis vendent l’accès aux cybercriminels à utiliser dans des attaques de ransomware, « sautant sur » la vulnérabilité Log4J, dit Morgan.

Les chercheurs en sécurité ont également observé des attaquants soutenus par l’État, qui sont généralement plus sophistiqués que leurs homologues criminels, exploitant la vulnérabilité. CheckPoint, par exemple, a rapporté qu’un groupe iranien APT connu sous le nom de « Charming Kitten » avait tenté de l’utiliser pour compromettre des cibles en Israël.

Mardi, le fournisseur de CDN Cloudflare a signalé qu’il avait détecté des preuves de l’exploit en cours de test huit jours avant sa divulgation publique. « Étant donné qu’un vecteur très similaire a été identifié en 2016 et que la vulnérabilité existe depuis 2013 », dit Warshavski, « il est logique que des groupes d’États-nations plus sophistiqués l’utilisent, peut-être depuis des années.

Comment l’industrie technologique a réagi à la vulnérabilité Log4J

La Fondation Apache, qui soutient le projet open source Log4J, a publié le premier correctif pour la vulnérabilité nommée Log4J 2.15.0 le jour de sa publication. Mardi, des chercheurs en sécurité ont signalé que le correctif lui-même présentait une vulnérabilité de sécurité ; Apache a publié un nouveau correctif, la version 2.16.0.

Les organisations sont invitées à corriger dès que possible toute instance de Log4J dans leur infrastructure. Mais l’outil est si omniprésent qu’il est difficile pour les organisations de savoir quels systèmes l’intègrent, explique Warshavski.

Cela signifie qu’ils dépendent largement des fournisseurs de logiciels pour avertir leurs clients de la nécessité de corriger leurs produits, ajoute-t-il, mais la réponse de l’industrie jusqu’à présent a été mitigée. La liste des fournisseurs de logiciels avec des produits non corrigés comprend IBM, VMware et Cisco, selon un rapport de Reuters.

Log4J : Que se passe-t-il ensuite ?

Pour les grandes organisations, la mise à jour de toutes les instances de Log4J peut prendre des semaines, voire des mois, en raison de son omniprésence et de la difficulté d’identifier où il est utilisé. « Les entreprises sont là pour le long terme », dit Warshavski.

La tâche la plus urgente est d’identifier et de corriger les systèmes externes, car ils présentent le plus grand risque de compromission. Mais les systèmes internes devront également être corrigés, dit Warshavski, car ils peuvent être exploités par des pirates qui ont infiltré une organisation.

Morgan met en garde les leaders technologiques contre le « épuisement » de leurs équipes de sécurité dans la précipitation pour patcher Log4J. « Ce sera un marathon, pas un sprint », dit-il. Mais, ajoute-t-il, « ces prochaines semaines seront cruciales pour vous assurer de fermer ces portes avant qu’elles ne soient ouvertes ».

À plus long terme, la vulnérabilité Log4J souligne le besoin d’approches à jour de la gestion des risques de cybersécurité. Celles-ci incluent la tenue d’un registre des actifs logiciels afin que l’exposition d’une entreprise aux vulnérabilités puisse être rapidement évaluée, et les architectures de sécurité Zero Trust, explique Morgan.

Les logiciels open source sont-ils sécurisés ?

La vulnérabilité Log4J a rouvert le débat sur la sécurité des logiciels open source. Les partisans soutiennent que la transparence des projets open source signifie que les vulnérabilités sont plus susceptibles d’être identifiées. « C’est complètement faux », dit Warshavski.

Des projets tels que Log4J, qui sont omniprésents mais maintenus par une poignée de bénévoles non rémunérés, ne peuvent pas éliminer toutes les vulnérabilités de leur base de code, affirme Warshavski. En outre, affirme-t-il, des pirates informatiques sophistiqués sont connus pour identifier les développeurs qui écrivent du code non sécurisé pour des projets open source et traquer toutes leurs contributions pour identifier de nouvelles vulnérabilités.

Ce qu’il faut, soutient Warshavski, c’est que les organisations qui utilisent des logiciels open source soient tenues responsables de leur sécurité. « Vous voulez que les organisations soient en mesure d’auditer les logiciels qu’elles utilisent et ne dépendent pas de tiers », dit-il. « Mais ce n’est pas le cas. »