Avis de vulnérabilité : fichier binaire Apache Log (Log4J)

22 décembre 2022 : Mises à jour des vulnérabilités Log4j et Log4Shell

La CISA vient de publier un nouvel avis : https://www.cisa.gov/uscert/ncas/alerts/aa21-356a

Je ne me souviens pas, en plus de 25 ans de carrière dans la cybersécurité, avoir eu à gérer autant de mises à jour pour un correctif critique qu'avec Log4j. Code Red, MS Blaster, SQL Slammer, Melissa et, plus récemment, HeartBleed ou Exchange Server 2021, ont-ils connu autant de tentatives infructueuses de correction ?

Historique des correctifs (10 derniers jours)

Peu après la sortie de log4j 2.15.0, des chercheurs ont découvert des failles de déni de service. Des recherches ultérieures ont montré que ces conditions DOS pouvaient en réalité être des failles d'exécution de code à distance (oups !). Cela a conduit à la sortie de la version 2.16.0, que les développeurs de logiciels se sont empressés de tester.

Le 22 décembre, une nouvelle condition DOS a été identifiée, ce qui a conduit à la publication de la version 2.17.0 pour Java 8. D'autres versions ont été publiées pour les versions plus anciennes de Java.

Exposition des fournisseurs tiers ?

À ce stade, 12 jours après le début de l'événement Log4j, si votre fournisseur n'a pas clairement indiqué qu'il ne présente aucun risque pour Log4j, vous devez supposer qu'il est exposé et qu'il s'efforce d'appliquer la dernière version 2.17. Où en est votre entreprise ?

Commencez à envisager la fermeture de ces services sur les applications potentiellement exposées. Recherchez les indicateurs de compromission. Consultez les conseils du RSSI dans son dernier avis (ici).

Recommandations CyberHoot :

Si votre entreprise est exposée à des vulnérabilités de Log4J, vous devez prendre en compte le fait que vos serveurs ont peut-être déjà été compromis. Conseil RSSI propose un certain nombre de recommandations à suivre, notamment la recherche d’indicateurs de compromission.

CyberHoot craint vivement que les pirates informatiques n'attendent les fêtes pour lancer leurs attaques de rançongiciels et autres, volant nos données et nos identités à notre insu. Il est temps de remédier à la situation, de corriger les failles et de rechercher les indicateurs de compromission. Bonne chance !

Publication originale de CyberHoot du 11 décembre

Une vulnérabilité d'un niveau de gravité de 10 (le plus élevé possible) est ciblée sur Internet. Ce risque critique, appelé « Log4Shell », a été découvert dans Apache Log4j (versions 2.0 à 2.14.1) et divulgué le 9 décembre 2021. Log4j est présent dans Apache Software Foundation, qui gère près d'un tiers des sites web. Log1Shell (CVE-2021-44228) permet l'exécution de code à distance sur des serveurs vulnérables.

Le processus de gestion des alertes de vulnérabilité (VAMP) de CyberHoot a évalué ce risque comme un événement de gravité 0 et l'a transmis à nos clients vCISO et MSP pour action. Nos propres serveurs ne sont pas menacés, car nous n'utilisons aucun code Java Log4j dans CyberHoot.

Comment répondre :

Les entreprises doivent vérifier qu'elles n'exécutent aucun code Java Log4j exposé. Voici une liste de logiciels tiers impactés Pour information. Si vous trouvez un serveur à risque, voici trois solutions possibles :

Trois solutions potentielles

1. Mise à niveau de Log4j : La mise à jour de log4j vers la version 2.15.0 et supérieure résout le risque mais nécessite l'accès au serveur Apache impacté et un redémarrage d'Apache.

2. Un changement de configuration : Dans la version Log4j (>=2.10), la vulnérabilité peut être atténuée en définissant la propriété système log4j2.formatMsgNoLookups à true ou en supprimant la classe JndiLookup du classpath. De plus, si le serveur possède des environnements d'exécution Java >= 8u121, les paramètres par défaut seront les suivants : com.sun.jndi.rmi.object.trustURLCodebase et com.sun.jndi.cosnaming.object.trustURLCodebase sont définis sur « faux », atténuant ainsi ce risque.

3. Utilisez un vaccin pour inoculer votre serveur: CyberRaison, une entreprise de cybersécurité, a publié un vaccin qui patche/inocule le serveur impacté éliminant ainsi la possibilité d'exploiter cette vulnérabilité.

Réflexions de clôture

Si votre entreprise ne dispose pas d'un flux de veille sur les menaces pour vous alerter en temps quasi réel de ces événements critiques, pensez à vous abonner à CyberHoot et nous vous tiendrons informé. Mieux encore, faites appel à des RSSI virtuels CyberHoot pour élaborer votre processus de gestion des alertes de vulnérabilités et le mettre en œuvre dans ces situations.

Articles sources :

Mitre CVE-2021-44228

Vaccin publié pour Apache Zero Day

Liste des fournisseurs concernés sur GitHub