Votre IBM i est-il vulnérable aux cyberattaques Log4j ? 

Log4Shell pose la vulnérabilité la plus grave

Le logiciel est utilisé pour enregistrer toutes sortes d’activités qui se déroulent sous le capot dans une large gamme de systèmes informatiques, y compris l’IBM i.

Jen Easterly, directrice de la U.S. Cybersecurity & Infrastructure Security Agency, a qualifié Log4Shell de vulnérabilité la plus grave qu’elle ait vue dans sa carrière, tout comme l’un de nos meilleurs collègues sur la sécurité, Bruce F. Bading. Il y a déjà eu des centaines de milliers, peut-être des millions, de tentatives d’exploitation de la vulnérabilité.

 

Que fait Log4j ?

Log4j enregistre les événements – erreurs et opérations système de routine – et communique des messages de diagnostic à leur sujet aux administrateurs système et aux utilisateurs. C’est un logiciel open source fourni par Apache Software Foundation.

 

Comment fonctionne Log4Shell ?

Log4Shell fonctionne en abusant d’une fonctionnalité de Log4j qui permet aux utilisateurs de spécifier un code personnalisé pour formater un message de journal. Cette fonctionnalité permet à Log4j, par exemple, de consigner non seulement le nom d’utilisateur associé à chaque tentative de connexion au serveur, mais également le vrai nom de la personne, si un serveur séparé contient un répertoire reliant les noms d’utilisateur et les vrais noms. Pour ce faire, le serveur Log4j doit communiquer avec le serveur détenant les vrais noms.

 

Log4j ouvre la porte aux « pirates » et aux failles de sécurité

Malheureusement, ce type de code peut être utilisé pour plus que le simple formatage des messages de journal. Les versions vulnérables de Log4j permettent aux serveurs tiers de soumettre un code logiciel capable d’effectuer toutes sortes d’actions sur l’ordinateur ciblé. Cela ouvre la porte à des activités néfastes telles que le vol d’informations sensibles, la prise de contrôle total du système ciblé et le transfert de contenu malveillant à d’autres utilisateurs communiquant avec le serveur concerné.

 

Log4Shell est facile à exploiter

Il est relativement simple d’exploiter Log4Shell. J’ai pu reproduire le problème dans ma copie de Ghidra, un cadre de rétro-ingénierie pour les chercheurs en sécurité, en quelques minutes seulement. Il y a une barre très basse pour utiliser cet exploit, ce qui signifie qu’un plus grand nombre de personnes ayant des intentions malveillantes peuvent l’utiliser.

 

Log4j est partout – y compris IBM i

L’une des principales préoccupations concernant Log4Shell est la position de Log4j dans l’écosystème logiciel. La journalisation est une fonctionnalité fondamentale de la plupart des logiciels, ce qui rend Log4j très répandu. Il est utilisé dans IBM WebSphere (WAS), IBM i Navigator, Apache HTTP, les logiciels IBM i HA, les services cloud comme Apple iCloud et Amazon Web Services, ainsi qu’une large gamme de programmes allant des outils de développement logiciel aux outils de sécurité de la chaîne d’approvisionnement et toute version d’IBM i Client Solutions antérieure à 1.8.8.7.

Cela signifie que les pirates ont le choix entre un large éventail de cibles : les utilisateurs d’IBM i, les fournisseurs de services, les développeurs de code source et même les chercheurs en sécurité. Ainsi, alors que de grandes entreprises comme IBM et Amazon peuvent rapidement corriger leurs services Web pour empêcher les pirates de les exploiter, de nombreuses autres organisations mettront plus de temps à corriger leurs systèmes, et certaines pourraient même ne pas savoir qu’elles en ont besoin.

 

Les dégâts qui peuvent être causés

Les pirates parcourent Internet pour trouver des serveurs vulnérables et configurent des machines capables de fournir des charges utiles malveillantes. Pour mener une attaque, ils interrogent des services (par exemple, des serveurs Web) et tentent de déclencher un message de journal (par exemple, une erreur 404). La requête inclut du texte construit de manière malveillante, que Log4j traite comme des instructions.

Ces instructions peuvent créer un shell inversé, qui permet au serveur attaquant de contrôler à distance le serveur ciblé, ou elles peuvent intégrer le serveur cible à un botnet. Les botnets utilisent plusieurs ordinateurs piratés pour mener des actions coordonnées au nom des pirates.

 

Les pirates abusent déjà de Log4Shell… Et de nouvelles manières. Aïe !

Un grand nombre de pirates tentent déjà d’abuser de Log4Shell. Ceux-ci vont des gangs de rançongiciels aux groupes de hackers essayant de miner du bitcoin et les hackers associés à la Chine et à la Corée du Nord essayant d’accéder aux informations sensibles de leurs rivaux géopolitiques. Le ministère belge de la Défense a signalé que ses ordinateurs étaient attaqués à l’aide de Log4Shell.

Bien que la vulnérabilité ait fait l’objet d’une attention généralisée pour la première fois le 9 décembre 2021, les gens continuent d’identifier de nouvelles façons de causer des dommages par le biais de ce mécanisme.

 

Comment arrêter le saignement Log4j ?

Il est difficile de savoir si Log4j est utilisé dans un système logiciel donné, car il est souvent intégré à d’autres logiciels. Cela oblige les administrateurs système à inventorier leur logiciel pour identifier sa présence. Si certaines personnes ne savent même pas qu’elles ont un problème, il est d’autant plus difficile d’éradiquer la vulnérabilité et vous ne pouvez pas vous défendre contre ce que vous ne savez pas.

Une autre conséquence des diverses utilisations de Log4j est qu’il n’existe pas de solution unique pour le corriger. Selon la façon dont Log4j a été intégré dans un système donné, le correctif nécessitera différentes approches. Cela pourrait nécessiter une mise à jour générale des systèmes, comme cela se fait pour certains routeurs Cisco, ou une mise à jour vers une nouvelle version du logiciel, ou la suppression manuelle du code vulnérable pour ceux qui ne peuvent pas mettre à jour le logiciel.

Log4Shell fait partie de la chaîne d’approvisionnement des logiciels. Comme les objets physiques que les gens achètent, les logiciels voyagent à travers différentes organisations et progiciels avant de se retrouver dans un produit final. Lorsque quelque chose ne va pas, plutôt que de passer par un processus de rappel, le logiciel est généralement « patché », c’est-à-dire corrigé sur place.

 

Les correctifs Log4Shell peuvent être retardés

Cependant, étant donné que Log4j est présent de différentes manières dans les produits logiciels, la propagation d’un correctif nécessite la coordination des développeurs Log4j, des développeurs de logiciels qui utilisent Log4j, des distributeurs de logiciels, des opérateurs système et des utilisateurs. Habituellement, cela introduit un délai entre la disponibilité du correctif dans le code Log4j et le fait que les ordinateurs des utilisateurs ferment la porte à la vulnérabilité.

Certaines estimations du temps de réparation des logiciels varient généralement de quelques semaines à plusieurs mois. Cependant, si le comportement passé est indicatif des performances futures, il est probable que la vulnérabilité Log4j surgira dans les années à venir.

En tant qu’utilisateur, vous vous demandez probablement ce que vous pouvez faire à propos de tout cela. Malheureusement, il est difficile de savoir si un produit logiciel que vous utilisez inclut Log4j et s’il utilise des versions vulnérables du logiciel.

 

Que pouvez-vous faire MAINTENANT pour vous protéger des vulnérabilités de Log4Shell

Cependant, vous pouvez aider en tenant compte du refrain commun des experts en sécurité informatique :

• Assurez-vous que tous vos logiciels sont à jour.
• Contactez vos fournisseurs tiers pour les mises à jour.
• Supprimez ou désactivez toute version vulnérable dès que possible

Ceci est particulièrement important si vous utilisez une version de niveau antérieur ou de fin de support (EOS) d’IBM i (antérieure à V7.3 ou V7.4).

Les analyses de chaque système IBM i, y compris les anciens systèmes d’exploitation hors support, trouvent des dizaines de fichiers log4j vulnérables dans l’IFS. Aucun système n’est à l’abri et plus il est âgé, plus il est vulnérable.

Bien que les premières attaques contre les versions vulnérables de log4j se soient concentrées sur les serveurs LDAP distants, l’attention s’est déplacée à la mi-décembre sur Java Virtual Machine (JVM) Remote Method Invocation (RMI).

 

Cela signifie que tout serveur, y compris IBM i exécutant JVM RMI, est vulnérable à une attaque catastrophique.

Ce schéma montre le déroulement de l’attaque.

 

Toute version de log4j antérieure à 2.17.1 est vulnérable.

The Center of Internet Security dispose des informations les plus récentes disponibles. Le meilleur conseil que nous puissions vous donner est de faire attention à l’endroit où vous obtenez vos informations, cela peut vous rendre vulnérable aux attaques.

La meilleure chose à faire est de scanner maintenant, avant qu’il ne soit trop tard.

Log4j Zero-Day Vulnerability Response (cisecurity.org) – Article original de Bob Losey : https://cutt.ly/DPAcTSM

Vous avez des questions ou des projets concernant la vulanérabilité log4j ?  Nos équipes sont à votre écoute. Contactez-nous au 01 88 32 12 34, ou via le formulaire de contact.