Threat Spotlight : les applications web sont activement menacées par des bugs Shellshock et des scripts de minage vieux de 10 ans

Les bugs de Shellshock (il existe six désignations CVE associées) ont le taux de gravité le plus élevé, soit 10. Ils existent dans le shell de commandes Unix Bash, qui est l'interface de ligne de commande par défaut sur tous les systèmes d'exploitation Linux, Unix et Mac. S'il est exploité avec succès, Shellshock pourrait permettre à un pirate d'amener Bash à exécuter des commandes arbitraires et d'accéder sans autorisation à de nombreux services connectés à Internet, tels que des serveurs Web, qui utilisent Bash pour traiter les demandes.

Logiciel vulnérable sous attaque active

Les trois principales vulnérabilités actuellement visées par les attaques Shellshock sont présentées dans le tableau ci-dessous. Il met en évidence comment des vulnérabilités peuvent rester cachées pendant des années sans être détectées dans la chaîne d'approvisionnement des logiciels.

Un appareil peut fonctionner avec la dernière version du firmware, mais être encore vulnérable, parce que les créateurs du logiciel n'ont pas mis à jour les bibliothèques de leur chaîne d'approvisionnement.

CVE-2019-7481 est une faille d'injection SQL classée 7.5 dans un service de sécurité pour laquelle un correctif existe. CVE-2021-42071 est une vulnérabilité critique classée 9.8 dans une application d'outil visuel qui pourrait permettre à un pirate non authentifié d'exécuter des commandes à distance.

Installation de variantes du botnet Mirai

CVE-2019-7481 a été ciblé depuis au moins 2021 par des pirates qui tentent d'installer des variantes du botnet Mirai, qui comprend un grand nombre d'appareils connectés (IoT) piratés et est principalement utilisé pour lancer des attaques DDoS.

Depuis que Mirai est apparu pour la première fois en août 2016, les chercheurs ont observé l'apparition de plusieurs variantes dans le paysage des menaces. Mirai cible principalement les appareils IoT basés sur Linux. La plupart des attaques commencent par le téléchargement d'un script shell qui télécharge ensuite plusieurs malwares binaires spécifiques à la plateforme et tente de les exécuter. Une fois infecté, l'appareil devient partie intégrante du botnet en pleine expansion.

Les deux premières variantes de Mirai que nous avons vues dans nos journaux concernaient l'interface Web LuCI pour les routeurs basés sur OpenWRT. Il s'agit d'une interface de gestion qui ne doit pas être exposée à Internet. Malheureusement, c'est souvent le cas et les pirates utilisent cela à leur avantage.

La première variante a été utilisée par des pirates tentant d'exécuter un script shell nommé « désolé.sh ».

Ce script n'est plus disponible. Selon URLhaus, il a été signalé et retiré. Cependant, l'analyse d'URLhaus montre clairement que cela fait partie d'une tentative d'infestation à Mirai/Gafgyt. Une description plus détaillée est disponible sur VirusTotal.

La deuxième variante est toujours active.

Les pirates utilisant cette variante suppriment tout ce qui se trouve dans le répertoire racine, puis téléchargent un script shell dans /tmp.

Lorsqu'il est exécuté, le script shell télécharge plusieurs binaires spécifiques à la plateforme et les exécute dans l'ordre.

Le développeur de ce script en particulier semble avoir le sens de l'humour. Les fichiers téléchargés sont renommés à l'aide d'une série croissante d'insultes (dûment censurées dans la capture d'écran).

Une autre variante de Mirai/Gafgyt ciblait une vulnérabilité d'exécution de commande à distance dans les routeurs Zyxel. L'entrée URLhaus indique qu'il s'agissait également d'un « infecteur » Mirai (huhu.mips) bien qu'il soit maintenant hors ligne. Si vous regardez l'entrée de l'adresse IP, elle sert actuellement le malware avec un nouveau nom (skyljne.mips).

Infections de mineurs de cryptomonnaies ciblant les vulnérabilités

Outre Shellshock, nous avons vu des pirates cibler des vulnérabilités pour installer des mineurs de cryptomonnaie.

En 2022, des mineurs de cryptomonnaie ont tenté d'exploiter la toute nouvelle vulnérabilité d'Atlassian Confluence. En février 2024, nous assistons à des tentatives actives visant à exploiter des vulnérabilités ThinkPHP vieilles de plusieurs années et à installer des mineurs XMRig.

Voici la première URL que nous avons vue :

En décodant le base64 partiel, nous trouvons la commande suivante :

Cela apparaît sur ANY.RUN en tant que mineur XMRig. Au moment de la rédaction de ce blog, le mineur est toujours en ligne.

Voici un autre exemple :

Ceci se traduit par :

L'analyse de ce script shell sur ANY.RUN montre qu'il télécharge également le binaire Redtail.

Autre exemple, le 45.x même IP servant un script différent :

Ceci se traduit par :

Selon VirusTotal, il s'agit probablement d'un mineur aussi.

Voici un dernier exemple de mineur :

Ceci se traduit par :

Dans ce cas, le nom du mineur n'est pas masqué et il est directement identifiable comme étant XMRig. Il est actuellement hors ligne.

Tous les exemples de mineurs ciblent d'anciennes vulnérabilités de ThinkPHP, à savoir des vulnérabilités d'exécution de code à distance (RCE) datant de 2018 et 2020 qui devraient être corrigées à juste titre dès maintenant.

Pour des applications sécurisées

Ces types d'attaques vont et viennent par vagues, chaque vague ciblant des vulnérabilités spécifiques dans les campagnes, à la fois pour Mirai et pour les mineurs de cryptomonnaies.

Il y a une dizaine d'années, les pirates recherchaient et exploitaient principalement de nouvelles vulnérabilités telles que les vulnérabilités de type zero-day pour tenter de pénétrer dans le réseau. Désormais, ils travaillent non pas davantage, mais plus intelligemment. Ils ont compris que les chaînes d'approvisionnement logicielles sont rarement totalement sécurisées et exploitent des vulnérabilités non corrigées à leur avantage.

Le problème de sécurité de la chaîne d'approvisionnement logicielle est assez difficile à résoudre. Vous pouvez déployer la dernière version de votre logiciel de transfert de fichiers, mais en cachette, ce logiciel utilise peut-être une version vulnérable de Log4J. Vous pensez que votre application est sécurisée, mais en fait elle présente une vulnérabilité connue. Et la seule façon de le savoir est d'effectuer régulièrement des analyses de vulnérabilité. Dans le cas de Log4J, vous êtes probablement en train de le faire. Mais que se passe-t-il si la vulnérabilité se trouve dans une bibliothèque relativement inconnue qui n'est utilisée que dans ce seul logiciel ?

Les anciens conseils de défense approfondie restent d'actualité. Il est essentiel de disposer d'un « oignon » défensif pour votre réseau et vos applications afin de prévenir les attaques avant qu'elles n'atteignent votre application. Cette approche vous permettra également de disposer d'un délai et d'une couverture aérienne lorsque vous n'avez pas encore été en mesure d'appliquer un correctif à un nouveau « zero day ».

La protection contre les attaques DDoS reste également essentielle. Les pirates utilisent des vulnérabilités vieilles de plusieurs années pour créer leurs botnets et effectuer de nouveaux types d'attaques DDoS, comme la réinitialisation rapide HTTP/2. Il est essentiel pour la continuité des activités de disposer d'une solution capable d'arrêter les anciennes attaques DDoS volumétriques et les nouvelles attaques DDoS applicatives plus subtiles.

Si vous examinez les vulnérabilités mentionnées ci-dessus et dans notre récent Threat Spotlight, vous constatez qu'en ce qui concerne les applications, la chaîne d'approvisionnement logicielle est un maillon faible qui a besoin et mérite une couche de protection importante.