Vous êtes dans : Accueil > Tribunes libres >

Avec un tel calendrier de l’avent, aucun RSSI n’aura envie d’ouvrir les cadeaux au pied du sapin cette année…

Charles Blanc-Rolin, MARDI 21 DéCEMBRE 2021

Après une nouvelle année assez éprouvante en termes de vulnérabilités, d’attaques subies et contenues, si vous pensiez vous relâcher en cette période de fêtes de fin d’année, je crains que vous ne soyez déçu…

Le calendrier de l’avent fait très mal cette année, et c’est avec angoisse que nous ouvrons chaque matin une nouvelle case.

Le 6 décembre, le CERT-FR de l’ANSSI mettait en garde contre des campagnes de phishing ciblant des entités françaises [1], opérées par le groupe Nobelium (UN2452) [2], le groupe ayant réussi à s’introduire dans de nombreux SI sur la planète en fin d’année dernière grâce à l’injection d’une backdoor dans la solution de supervision Orion, de la société SolarWinds, initialement compromise. Parmi les victimes, on compte notamment, une bonne partie des Ministères américains, Microsoft, Cisco, Intel, VMware ou encore la société FireEye, qui malgré les moqueries, avait découvert avant les autres, cette attaque de type « supply chain ».

Le même jour, un POC pour une vulnérabilité de type 0 day dans l’outil Grafana était dévoilé publiquement [3]. La vulnérabilité référencée CVE-2021-43798 permet à un attaquant non authentifié, de parcourir et récupérer des fichiers sur la machine (Path Taversal). Même si le tweet original a été supprimé, de nombreux POCs restent disponibles publiquement.

Le 8, c’est SonicWall qui indique que dans sa mise à jour du 30 novembre pour les appliances SMA, une jolie vulnérabilité pouvant permettre à un attaquant non authentifié d’exécuter du code arbitraire à distance a été corrigée [4]. Le score CVSS pour la CVE-2021-20038 est de 9,8/10.

Le 9 décembre, même si nous sommes nombreux à l’avoir appris le 10, est révélée la fameuse vulnérabilité Log4Shell [5], affectant la librairie Log4J, utilisée dans le traitement de logs de nombreuses solutions. Par « chance », cette vulnérabilité semble avoir été exploitée en premier lieu pour faire trembler des serveurs Minecraft, rien de bien méchant me direz-vous, oui mais, elle permet quand même de réaliser indirectement une exécution de code arbitraire à distance sur de très nombreuses solutions et notamment des solutions de sécurité ou de gestion d’infrastructure. On saluera le travail de recensement (actualisé régulièrement) des solutions impactées, réalisé par Swithak [6], puis repris notamment par le CERT des Pays Bas [7].

Ce qui est en plus assez dingue avec cette vulnérabilité, c’est qu’elle peut être exploitée de plein de manières différentes, il suffit juste qu’arrive dans les logs traités par une version vulnérable de Log4J, un chemin de type JNDI pointant vers un serveur LDAP / LDAPS, RMI ou encore DNS géré par l’attaquant. Un chemin JNDI peut être inséré, un peu n’importe où, si Log4J le traite, et que la connexion vers le serveur de l’attaquant peut s’établir, c’est gagné. Des chemins JNDI ont donc été saisis dans champs de formulaires sur des sites Web, dans des URL, dans des métadonnées de fichiers téléversés, dans des SSID Wifi…

Pour ma part, j’ai pu observer des tentatives d’exploitation de la vulnérabilité via un chemin JNDI inséré dans un SMTP EHLO émis vers un serveur de messagerie :

L’effervescence c’est poursuivi tout le week-end, de nombreux éditeurs communiquent pour indiquer les produits impactés, notamment VMware, qui annonce samedi 11, dans deux communications, une importante liste de produits impactés [8], après Cisco qui s’était déjà exprimé le 10 sur ce sujet [9].

Dès lundi 13, plusieurs éditeurs du secteur de la santé communiquent, impactés, pas impactés…
On notera au passage que les versions 1.X, sont impactées uniquement si le composant JMS Appender est configuré pour prendre en compte JNDI [10].

Dans la même journée, Google annonce avoir corrigé une seizième vulnérabilité de type 0 day depuis le début de l’année dans son navigateur Chrome [11]. Là encore nous sommes sur de l’exécution de code arbitraire à distance en cours d’exploitation.

Mardi 14, nous apprenons que la vulnérabilité CVE-2021-44228 n’est que partiellement corrigée dans la version 2.15 de Log4J et que la vulnérabilité CVE-2021-45046 affectant certaines configurations particulières n’est corrigée qu’en version 2.16 et 2.12.2. Initialement annoncée comme permettant un déni de service à distance, elle permet également une atteinte à la confidentialité des données et aussi et surtout, une exécution de code arbitraire à distance [12].

L’éditeur F-Secure publie un « correctif manuel » pour plusieurs de ses solutions vulnérables à Log4Shell [13].

Microsoft publie sont patch tuesday, par chance, rien sur Exchange, mais 6 vulnérabilités révélées publiquement dont une de type 0 day, sont corrigées. Sept vulnérabilités sont classées critiques car permettant une exécution de code arbitraire à distance, notamment dans le client RDP Windows et Microsoft Office.

Mercredi 15, Log4Shell est finalement exploité dans le cadre de déplacement latéraux pour compromettre des serveurs vCenter par le groupe UNC1878 [14].

Vendredi 17, un éditeur français certifié par l’ANSSI pour sa solution de PAM demande discrètement à certains de ses clients de vérifier si des adresses IP ne se sont pas connectées chez eux avec des comptes d’administration qu’ils se seraient certainement fait dérober.

Samedi 18, on remet ça avec Log4J, une nouvelle vulnérabilité (CVE-2021-45105) pouvant permettre à un attaquant de réaliser un déni de service à distance est corrigée en versions 2.17 et 2.12.3 [15].

Je crois que le mieux est d’arrêter d’ouvrir des cases cette semaine et demander un mot d’excuse pour esquiver l’ouverture des cadeaux ce week-end.

[1] https://www.cert.ssi.gouv.fr/cti/CERTFR-2021-CTI-010/ 

[2] https://malpedia.caad.fkie.fraunhofer.de/actor/unc2452 

[3] https://twitter.com/hacker_/status/1467880514489044993 

[4] https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2021-0026 

[5] https://www.lunasec.io/docs/blog/log4j-zero-day/ 

https://www.cert.ssi.gouv.fr/alerte/CERTFR-2021-ALE-022/ 

[6] https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592 

[7] https://github.com/NCSC-NL/log4shell/blob/main/software/README.md#software-overview

[8] https://www.vmware.com/security/advisories/VMSA-2021-0028.html 

[9] https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd#vp

[10] https://access.redhat.com/security/cve/CVE-2021-4104 

[11] https://chromereleases.googleblog.com/2021/12/stable-channel-update-for-desktop_13.html 

[12] https://nvd.nist.gov/vuln/detail/CVE-2021-45046 

[13] https://community.f-secure.com/common-business-en/kb/articles/9226-the-log4j-vulnerability-cve-2021-44228-which-f-secure-products-are-affected-what-it-means-what-steps-should-you-take#:~:text=Messaging%20Security%20Gateway%22.-,How%20to%20patch%20my%20F%2DSecure%20Policy%20Manager,-We%20have%20created

[14] https://www.advintel.io/post/ransomware-advisory-log4shell-exploitation-for-initial-access-lateral-movement 

[15] https://nvd.nist.gov/vuln/detail/CVE-2021-45105 

#rssi#ssi#cisco#dsih#microsoft