« La plus grande et la plus critique des vulnérabilités de la dernière décennie« , selon Amit Yoran, le DG de Tenable. Depuis quelques jours, des cybercriminels exploitent massivement une vulnérabilité d’Apache Log4j, un utilitaire de journalisation basé sur Java utilisé par des millions d’entreprises… La menace est à prendre très au sérieux, et le pire est à venir.
La description de François Tonic, de Datacenter Magazine
Log4j est un framework de journalisation open source qui permet aux développeurs de logiciels d’enregistrer diverses données au sein de leurs applications. Ces données peuvent également inclure une entrée utilisateur. Log4j est utilisé de manière omniprésente dans les applications Java, en particulier les logiciels d’entreprise. Log4j fait maintenant partie d’Apache Logging Services, un projet de l’Apache Software Foundation.
Une vulnérabilité critique dans Log4j, (CVE-2021-44228), baptisée Log4Shell, a été signalée le 9 décembre. Cette vulnérabilité, si exploitée, permet l’exécution de code arbitraire à distance sans aucune authentification. Et cette faille est déjà copieusement exploitée… et a déjà été exploitée avant le 9 décembre selon certaines sources.
Dire que cette vulnérabilité est critique semble très insuffisant. Il faudrait dire au moins extrêmement critique et même se perdre en superlatifs… Les spécialistes en cybersécurité ne mâchent pas leurs mots à ce sujet. Les chercheurs en sécurité de LunaSec, à qui revient la découverte de cette faille, la décrivent comme « un échec de conception de proportions catastrophiques« .
Tous les grands services clous sont touchés, dont Amazon AWS, Cloudflare, iCloud, l’édition Java de Minecraft (sur laquelle Log4Shell a été découverte), Steam, Tencent QQ, Struts2, Solr, Flink, ElasticSearch, Azure, Baidu, Druid.
Un correctif à cette vulnérabilités Log4Shelle existe, et pour en bénéficier, il faut mettre à jour Log4j vers la version 2.15.0.
Le bulletin d’alerte du CERT-FR (cliquer ici).
Les commentaires de Jérôme Warot, Vice-président, Technical Account Management, South EMEA chez Tanium :
La faille Apache Log4j est la vulnérabilité la plus redoutable que j’ai connue de toute ma carrière, en termes de nombre de personnes et d’organisations touchées et par conséquent de gravité de l’impact.
Étant donné l’exposition potentielle des systèmes, il est important de procéder avec méthode et de prioriser les sujets. Est-ce que toutes les entreprises utilisent Log4j ? Oui, probablement, mais les vraies questions sont : Que mettre en œuvre pour ralentir, minimiser ou remédier à cette vulnérabilité avant que quelqu’un ne tente de l’exploiter ? Quels sont les systèmes les plus critiques ou exposés ?
Commencer par mettre en œuvre les mécanismes de détection et de blocage sur tous les périmètres tournés vers l’extérieur est primordial. Ensuite, travailler sur l’inventaire de tous les systèmes utilisant cette librairie est essentiel. Enfin prioriser : quels systèmes, quels impacts, etc.
Dans la phase d’inventaire, l’une des erreurs à ne pas commettre, lors de l’analyse des applications et la mise à jour de la librairie, est de s’appuyer sur des outils traditionnels de gestion des vulnérabilités. En effet, ces outils analysent les applications installées à la recherche de problèmes éventuels, mais si un package comme Log4j a été renommé ou installé dans un chemin autre que celui défini par défaut, il est probable que ces outils ne le détecteront pas. Aussi, il est préférable d’utiliser des solutions à multiples types d’analyse, notamment celles qui permettent l’analyse des chaînes de configuration dans les fichiers.
Sur une approche à plus long terme, le secteur devra commencer à examiner de plus près les projets open-source comme Log4j. Ces cadres et ces outils sont largement adoptés par des milliers d’organisations, mais ils sont souvent gérés par des individus pendant leur temps libre, comme projet personnel. Il n’est généralement pas évident de savoir combien de ressources sont consacrées au maintien des normes de sécurité, mais je pense que les entreprises seront plus enclines à vérifier ce point avant d’utiliser des outils open-source à l’avenir.
Cette nouvelle faille nous rappelle une fois de plus l’importance de s’assurer d’une parfaite hygiène cyber et d’une bonne gestion de ses actifs IT. En respectant ces principes de base, vous êtes mieux préparé pour affronter une telle situation et en minimiser l’impact.
Les commentaires de Sean Gallagher, chercheur principal en menaces chez Sophos
À l’exception du cryptomining, nous observons une accalmie avant « la tempête » d’une activité plus néfaste concernant la vulnérabilité Log4Shell. Nous pensons que les cyberattaquants sont probablement en train de s’emparer d’un maximum d’accès à leur disposition afin de les monétiser et/ou de les exploiter ultérieurement.
La priorité immédiate pour les entreprises est de réduire leur exposition en appliquant des correctifs et des mesures d’atténuation dans l’ensemble de leur infrastructure et d’enquêter sur les systèmes exposés et potentiellement compromis. Cette vulnérabilité peut être partout.
Une fois que les systèmes ont été identifiés comme vulnérables, les défenseurs doivent mettre en place un processus de réponse aux incidents et surveiller les signes de chevaux de Troie en accès à distance tels que les rappels C2. Les informations stockées sur les systèmes exposés doivent également faire l’objet d’une rotation, en particulier s’ils se situent dans des variables d’environnement. Enfin, il faut tenir compte des fournisseurs tiers critiques qui peuvent également être à risque. »
Le conseils de Dan Piazza, technical product manager chez Stealthbits, une société Netwrix
Bien qu’aucune compromission n’ait été officiellement annoncée à la suite de la vulnérabilité log4j, les chercheurs en sécurité du monde entier voient déjà des tentatives pour l’exploiter activement. Par exemple, Cloudflare constate actuellement environ 1 000 tentatives d’exploitation de la vulnérabilité log4j par seconde.
Cette vulnérabilité aura, et a déjà, un effet significatif sur l’industrie. Log4j est en effet utilisé par des milliers d’applications, de bibliothèques et de frameworks, ce qui signifie que le nombre d’organisations potentiellement impactées est pharamineux. Et, alors que les cybercriminels scannent Internet pour trouver des cibles vulnérables, si les organisations n’ont pas déjà commencé à prendre des mesures d’atténuation adéquates, il est peut-être déjà trop tard.
Pour les organisations qui doivent contenir la vulnérabilité, il est conseillé de mettre à jour le package log4j lui-même, et non simplement Java. Il s’agissait ainsi d’une idée fausse, selon laquelle cela pourrait réduire la gravité de la vulnérabilité, mais ce n’est tout simplement pas le cas. Il est également conseillé de consulter les fournisseurs de logiciels, pour voir s’ils utilisent log4j de quelque manière que ce soit ; et, si c’est le cas, s’ils ont déjà apporté des correctifs à leurs produits.
Si une organisation utilise log4j, ou un logiciel qui inclut la bibliothèque, il est alors plus sûr de supposer une violation et d’examiner les applications potentiellement affectées pour identifier tout comportement suspect. De plus, si une organisation estime qu’elle a déjà été compromise, elle doit consulter une entreprise de réponse aux incidents et supprimer tout accès réseau physique au serveur concerné.
Malheureusement, le pire est à venir, car exploiter cette vulnérabilité est aussi simple que d’obtenir une application qui utilise log4j pour enregistrer une chaîne spécifique de caractères. Après cela, l’attaquant aura l’exécution de code à distance (RCE) sur un serveur entièrement piraté.
