Le calme avant la tempête, analyse Sean Gallagher, de Sophos. La déferlante viendra de partout. Faut-il revoir le mode de conception  open source ?

Il a fallu deux semaines à Apache Software Foundation pour développer et publier le correctif qui corrige avec succès la vulnérabilité. Cependant, jusqu’à présent, près d’un million de tentatives de violation par des organisations malveillantes connues ont été détectées. Et personne ne peut dire avec certitude combien d’autres acteurs de la menace inconnus se cachent dans l’ombre. Pour Sean Gallagherr, Senior Threat Researcher, Sophos, « nous sommes dans une accalmie avant la tempête. »

Nous parlons d’un bogue qui met en danger tous les serveurs et programmes basés sur Java. Il est donc très difficile de concevoir les proportions des dommages -d’autant plus que les mises à jour logicielles sur le Web prennent du temps à mettre en œuvre. Aucun ransomware ou infection similaire n’a été signalé jusqu’à présent, mais ils sont attendus dans les prochaines semaines. L’industrie soupçonne que les pirates informatiques analysent et stockent déjà en masse des données pour leurs futures cyberattaques…

Une infrastructure à l’échelle mondiale

Depuis que la première vulnérabilité de l’outil de journalisation Log4j a été révélée le 10 décembre, trois ensembles de correctifs de la bibliothèque Java ont été publiés. Cette itération rapide des correctifs a obligé les développeurs et les organisations du monde entier à se démener pour évaluer et atténuer leur exposition avec des conseils qui changent presque quotidiennement. Entre-temps, nous avons vu des tentatives de détection ou d’exploitation de la vulnérabilité se poursuivre sans interruption.

« Le trafic que nous avons observé comprend des analyses bénignes par des chercheurs en sécurité et des testeurs d’intrusion, commente Sean Gallagher. Il ne reflète pas directement l’état des tentatives des criminels et des acteurs étatiques d’exploiter la vulnérabilité. Mais à partir de certaines parties des données, nous en savons assez sur les demandes pour avoir un aperçu de l’infrastructure impliquée dans ces tentatives et, dans certains cas, de l’intention qui les sous-tend. »

Ce qui est certain, c’est qu’il n’y a pas eu de réduction significative des tentatives d’exploit depuis le pic du 15 décembre. Ces sondes et exploits proviennent d’une infrastructure distribuée à l’échelle mondiale. Dans certains cas, une demande provient d’une adresse IP dans une région géographique, avec des URL intégrées pour Log4j qui se connectent à des serveurs ailleurs, parfois plusieurs serveurs différents. Sophos a vu des millions de tentatives entrantes d’exploiter Log4j dans la télémétrie client. La tempête ne peut que suivre.

Russie et Chine dans le collimateur

« Bien que nous ne puissions pas distinguer l’intention de chaque demande, le segment de notre télémétrie qui a fourni les détails du trafic fournit un instantané de l’infrastructure impliquée dans l’abus de Log4j. En regardant la source des tentatives de paquets abusifs jusqu’à présent, la grande majorité provient d’adresses IP en Russie et en Chine. Cela n’inclut pas le trafic qui dissimule sa source en utilisant des réseaux privés virtuels. Une quantité statistiquement significative de trafic a été acheminée via le point de sortie de NordVPN au Panama, par exemple… »

11 % provenaient d’une seule adresse IP en Russie : 195[.]54[.]160[.]149. Cette adresse IP a été associée au botnet Kinsing cryptocoin-mining.

En raison de la façon dont les exploits Log4j fonctionnent -en invitant des « recherches » vers des serveurs distants via LDAP, DNS et d’autres protocoles pris en charge par Java Name and Directory Interface (JNDI)- les demandes de recherche peuvent être dirigées vers un emplacement différent de celui de la source de l’exploit. Par exemple, une requête acheminée via le point de sortie Panama de NordVPN (94[.]140[.]9[.]194) a utilisé une URL de requête redirigée vers une URL au Kenya (41[.]169[.]130[.] 19:8443/api/login).

Près des deux tiers de ces demandes avaient des URL d’infrastructure en Inde. Et plus de 40 % avaient des URL dirigées vers des infrastructures aux États-Unis. Plus de 7 % des demandes d’exploitation ont été dirigées vers le domaine de l’outil Interactsh, soit 18 % de tout le trafic vers l’infrastructure américaine.

La tempête à venir réclame des efforts combinés

Les experts en cybersécurité du monde entier essaient avec diligence de détecter toute exploitation potentielle. Il est à craindre qu’ils n’aient pu qu’effleurer la surface d’un problème beaucoup plus important. Il devient clair maintenant que l’ensemble du système de conception de logiciels open source de volontariat a besoin d’une réévaluation et d’une approche plus systématique, avec les mesures de protection nécessaires en vigueur.

En attendant, on ne soulignera jamais assez l’importance des mises à jour régulières. Le traitement de la vulnérabilité Log4J nécessite une défense en profondeur, insiste Sophos. Les entreprises doivent déployer des règles pour bloquer le trafic lié à une éventuelle exploitation au niveau de tous les services Internet -Sophos IPS bloque actuellement le trafic correspondant aux signatures d’exploitation Log4J connues. Mais la protection à long terme nécessitera l’identification et la mise à jour des instances de Log4J ou la mitigation du problème en modifiant les paramètres de Log4J (soit via des fichiers de configuration XML ou YAML à la racine des paramètres du chemin de Log4J, soit par programmation). Cette mesure peut nécessiter des modifications de code dans les produits où Log4J est intégré.