Ce que vous ne savez pas sur qui, quand et comment la vulnérabilité Log4Shell du produit Log4j a été détectée pour la première fois.
Une vulnérabilité zero-day CVE-2021-44228 a été découverte dans la célèbre bibliothèque (Java library) de journalisation Apache Log4j.
Cette vulnérabilité permet à un hacker l’execution de code à distance ‘’remote code execution’’
La vulnérabilité a été découverte par des chercheurs de l’équipe de sécurité d’Alibaba Cloud qui ont notifié la Fondation Apache le 24 novembre 2021.
Les chercheurs ont souligné qu’Apache Struts2, Apache Solr, Apache Druid, Apache Flink sont tous affectés par cette vulnérabilité.
Par la suite, la vulnérabilité a été publiée pour la première fois lorsqu’un chercheur (chinois) avec le pseudo « p0rz9 » a partagé sur Twitter un lien GitHub d’une preuve de concept (PoC) de l’exploitation de cette vulnérabilité zero-day.
Aussi, Cisco Talos a déclaré dans un article qu’il avait repéré pour la première fois une activité de menace liée à la vulnérabilité le 2 décembre 2021, bien avant la divulgation publique.
Cela signifie que cette vulnérabilité a été identifiée et exploitée bien avant la publication du CVE-2021-44228 et qu’il y a déjà eu des cas d’utilisation active de cette vulnérabilité «in the wild» envers certaines entreprises et organisations.
Criticité
Selon les experts, la vulnérabilité est facile à exploiter et ne nécessite pas de configuration particulière, pour cette raison, elle a reçu un score CVSSv3 de 10/10.
Le CVSS est le le “Common Vulnerability Scoring System (CVSS)” et L’échelle est de 1 à 10.
10 étant le plus haut niveau de criticité.
Risques
Exécution de code à distance [Remote Code Execution]
Systèmes affectés
- Toutes les versions Apache Log4j de 2.0 à 2.14.1
- Apache Log4j versions 1.x, si le composant JMS Appenders est configuré pour prendre en compte JNDI.
- Les produits utilisant une version vulnérable de Apache Log4j.
Tout projet utilisant log4j est potentiellement vulnérable, une analyse rapide a révélé que la vulnérabilité affecte potentiellement tout logiciel utilisant cette bibliothèque.
Non seulement la vulnérabilité affecte des milliers de programmes, mais l’exploitation de cette vulnérabilité est très simple.
De ce fait, les hackers commencent déjà à lancer des attaques à grande échelle et la grande variété de systèmes vulnérables aggrave encore la situation.
Solutions
La problématique et l’enjeu aujourd’hui est d’obtenir des correctives pour ces milliers de produits impactés.
Dans l’attente des correctives, il faut agir efficacement avec les moyens du bord.
Par conséquent, il est fortement recommandé de :
- Élaborer un inventaire des solutions qui utilisent log4j.
- Se référer aux communications (notamment bulletin de sécurité) des éditeurs (sinon contactez-les) pour vérifier si les solutions/produits que vous utilisez sont exposés à cette vulnérabilité.
- Mettre à jour Log4J vers la version
2.15.0. 2.12.2 pour Java 7 et 2.16.0 pour Java 8 et versions ultérieures. - S’assurer de la viabilité des configurations appliquer au niveau de vos équipements réseau et sécurité (WAF, FW, etc…) frontaux (In/out vers internet).
- Suspendre la publication sur internet de tout service impacté (au moins jusqu’à l’application de Workaround).
- Appliquer dans les plus brefs délais la solution de contournement (workaround) communiquée par l’éditeur.
- Appliquer les mises à jour une fois publiées par les éditeurs (la publication des correctifs prend généralement un peu de temps pour les vulnérabilités zero-day).
Informations complémentaires
- Des exemples de cette vulnérabilité sont publiés sur GitHub : URL
- Québec a fermé préventivement près de 4 000 sites Web gouvernementaux : URL
- p0rz9 a mentionné que le PoC a révélé que la vulnérabilité ne peut être exploitée que si l’option log4j2.formatMsgNoLookups est définie sur false.
