Détection de l'exploit Log4J (CVE-2021-44228)

Si vous lisez ceci, je suppose que vous avez déjà entendu parler de CVE-2021-44228, la vulnérabilité d'exécution de code à distance (RCE) affectant Apache Log4j, la bibliothèque de journalisation Java qu'une grande partie de l'internet utilise sur ses serveurs web. Alors que de nombreux blogs et commentaires ont publié des méthodes pour déterminer si vos serveurs/sites web sont vulnérables, il y a peu d'informations sur la façon de détecter facilement si votre serveur web a effectivement été exploité et infecté. Mais tout d'abord, un bref résumé :

CVE-2021-44228 RCE Apache Log4J

• Tout d'abord, comme le disent la plupart des twittos et des experts en sécurité : cette vulnérabilité est mauvaise. Vraiment mauvaise. De nombreux sites web importants utilisent ce logger.

• RCE = Remote Code Execution (exécution de code à distance). L'attaquant peut exécuter n'importe quel code (par exemple un logiciel malveillant) sur votre serveur web en envoyant une requête web à votre site web avec rien de plus qu'une chaîne "magique" + un lien vers le code qu'il veut exécuter.

• Affecte le serveur web Apache utilisant des versions vulnérables du logger log4j (le module de journalisation java le plus populaire pour les sites web utilisant java).

• Versions vulnérables : 2.0 - 2.14.1 (Nous vous recommandons de passer à la version 2.17.0)

Quelqu'un a-t-il essayé d'exploiter mon serveur web ?

Les comportements typiques auxquels il faut s'attendre si votre serveur est exploité par un attaquant sont l'installation d'un nouveau webshell (logiciel malveillant de site web qui donne un accès administrateur au serveur par le biais d'une interface administrateur cachée). Apache exécute des commandes curl ou wget pour extraire le webshell ou d'autres logiciels malveillants qu'il souhaite installer.

Heureusement, il existe quelques moyens de détecter les tentatives d'exploitation tout en surveillant le serveur pour découvrir les tentatives d'exploitation précédentes :

1. Consultez les fichiers journaux d'Apache pour jndi:ldap, jndi:rmi ou jndi:dns. Ce sont ces chaînes de caractères « magiques » qui provoquent un dysfonctionnement du logger et l'amènent à suivre/exécuter l'URL qui les suit.
2. Numériser /var/log les signatures de Yara correspondant à certains de ces indicateurs.
3. Scanner le serveur web pour les webshells génériques.
4. Si vous disposez d'un EDR sur le serveur web, surveillez les commandes curl, wget ou autres commandes suspectes. Il est probable que le code qu'ils essaient d'exécuter en premier à la suite de l'exploitation soit celui qui permet au système d'atteindre le serveur de commande et de contrôle à l'aide d'utilitaires intégrés tels que ceux-ci.

NOTE : Si le serveur est exploité par des scanners automatisés (les bons gars les utilisent), il est possible que vous obteniez un indicateur d'exploitation sans logiciel malveillant ou webshell. Certains scanners de recherche exploitent la vulnérabilité et demandent au système d'envoyer une simple requête ping ou dns pour informer le chercheur de la vulnérabilité.

Partenaires Datto : composant RMM

Datto a publié à la fois un composant « Datto RMM » destiné à ses partenaires et un script communautaire destiné à tous les MSP. Ces outils vous aideront à tirer parti de la puissance et de la portée de votre solution RMM, quel que soit le fournisseur, pour recenser les systèmes potentiellement vulnérables et ceux qui ont potentiellement subi une attaque. L'outil peut également tenter de vous protéger contre des attaques ultérieures en appliquant une solution de contournement connue.

N'hésitez pas à contacter notre équipe d'experts pour obtenir de l'aide.

MISE À JOUR 12/22 :

Au cours de la semaine dernière, nous avons vu beaucoup d'activités d'analyse de la part des scanners de sécurité, des activités d'exploitation à grande échelle à partir de l'espace IP russe et ukrainien, et de nombreux exploits de systèmes allant des serveurs Elastic aux services web personnalisés.

Nous avons mis à jour notre analyseur log4shells afin d'inclure une meilleure couverture des méthodes d'obscurcissement et nous avons également déprécié les options d'atténuation désormais défuntes qu'Apache recommandait auparavant. La variable d'environnement LOG4J_FORMAT_MSG_NO_LOOKUPS ou l'argument cli de log4j2.formatMsgNoLookups=True n'arrêtera pas de nombreux vecteurs d'attaque.

En outre, nous avons étendu l'analyse pour examiner tous les lecteurs (pas seulement les lecteurs système ou ceux où log4j est installé) et nous recommandons de l'exécuter à nouveau si vous ne l'avez pas fait récemment.

1. Recherche tous les fichiers .jar contenant le fichier JndiLookup.class problématique
2. Analyse le système à la recherche de fichiers .log compressés et non compressés présentant des indicateurs d'exploitation liés à la faille log4shells.
— Le chemin d’accès principal sous Linux et macOS est : /var/log
— Sous Windows, les chemins d’accès principaux incluent $env:SystemDrive\logs\, $env:SystemDrive\inetpub\, ainsi que tous les dossiers contenant les termes « java », « log4j » ou « apache ».
3. Utilise également des signatures Yara open source sur les fichiers journaux.

En raison du grand nombre d'implémentations de log4j intégrées dans divers produits, il n'est pas toujours facile de trouver la version de l'extension log4j. La façon la plus simple est de regarder le nom du fichier ou du dossier du fichier .jar trouvé avec JndiLookup.class, mais ce n'est pas toujours le cas. Certains produits nécessitent des instructions spécifiques de la part du fournisseur.

MISE À JOUR 12/14 :

Des attaques continuent d'être lancées contre des serveurs Apache vulnérables, mais cette fois-ci avec de plus en plus d'obscurcissement. Les attaquants semblent examiner les recommandations publiées et tester leurs attaques en fonction de celles-ci. Nous avons mis à jour notre extension de détection des exploits log4shells/log4j de manière significative afin de manœuvrer en amont.

La correspondance Regex dans les logs peut être difficile à obtenir lorsque les acteurs obscurcissent, mais c'est toujours l'une des méthodes les plus efficaces basées sur l'hôte pour trouver l'activité d'un exploit comme celui-ci. L'illustration ci-dessus montre les différentes obscurcissements que nous avons vus et notre logique de correspondance les couvre tous. Notre approche des règles de ce type consiste à disposer d'une règle spécifique et très précise avec peu de faux positifs et d'une autre règle plus générique qui s'efforce de minimiser les faux négatifs au détriment des faux positifs. Nos chasseurs se chargent généralement de trier les résultats génériques pour le compte de nos clients.

En outre, la surveillance comportementale générique continue d'être une capacité primaire ne nécessitant aucune mise à jour. Si apache commence à exécuter de nouvelles commandes curl ou wget (activité standard de la deuxième étape), elle sera examinée.

Nous continuerons à surveiller l'évolution de la situation et nous recommandons d'ajouter l'extension log4j à vos analyses planifiées.

MISE À JOUR 12/12 :

Nous avons travaillé avec quelques uns de nos partenaires hier soir et avons mis à jour notre extension pour les serveurs Apache basés sur Windows :

L'un des problèmes liés à l'analyse des fichiers journaux sur les serveurs Apache sous Windows réside dans le fait que l'emplacement du dossier contenant ces fichiers n'est pas standard. Notre extension va donc rechercher ces fichiers dans <em>[DriveLetter]</em>:\logs\ (alias C:\logs\) en premier lieu, car il s'agit d'un dossier commun, mais si Apache/httpd sont en cours d'exécution et que le fichier ne s'y trouve pas, le reste du disque sera parcouru.

On vérifie également s’il existe des fichiers .jar qui importent le code vulnérable. Des suggestions émanant de partenaires sur le terrain souhaitant rechercher une variable d’environnement nommée log4j2.formatMsgNoLookups On ne peut s'empêcher de constater qu'il existe de nombreuses implémentations dans lesquelles cette valeur pourrait être codée en dur et ne pas figurer dans une variable d'environnement.

IMPORTANT : Une grande partie de l'activité que nous avons observée provient de scanners automatisés (qu'ils soient utilisés par des chercheurs ou non) qui ne donnent pas lieu à l'injection de webshells ou de logiciels malveillants, ni à des conséquences concrètes. La facilité d'exploitation de cette faille peut rendre ce processus très « bruyant » ; nous invitons donc vivement toutes les personnes cherchant à exploiter cette faille à rechercher d'autres indicateurs de compromission avant de signaler un incident sur la base d'une correspondance positive dans les journaux. N'hésitez pas à nous contacter si vous rencontrez des difficultés à cette étape.

Vous n'êtes pas encore partenaire de Datto ? Contactez-nous dès aujourd'hui pour demander une démonstration.