« La propagation de malwares de cryptojacking a déjà été observée, mais c'est la première fois que nous voyons un ver de minage de cryptomonnaie se propager en utilisant comme vecteur les conteneurs de Docker Engine (Community Edition) », ont déclaré des chercheurs de l’Unité 42 de Palo Alto Networks dans un rapport publié hier. « Ce genre d'activité malveillante n’est pas toujours facile à détecter, car la plupart des logiciels de protection des endpoints n'inspectent pas les données et les opérations exécutées à l'intérieur des conteneurs », ont-ils ajouté.

Un botnet au comportement inhabituel

Baptisé Graboid (en référence au film d’horreur Tremors,  le ver a été distribué à partir de Docker Hub, un référentiel public d'images de conteneurs Docker. Les attaquants ont téléchargé des images contenant des scripts malveillants sur Docker Hub, qui, une fois exécutés, ont déployé le malware sur d'autres serveurs non sécurisés. Les chercheurs ont trouvé plusieurs images de conteneurs associées à l'attaque à différentes étapes de la chaîne d'infection. Ces conteneurs ont été retirés par le support de Docker Hub, après avoir été alerté par les chercheurs. Une des images de conteneur exécutant CentOS cherchait à se connecter à des serveurs de commande et de contrôle (C2) prédéfinis pour télécharger et exécuter quatre scripts shell. Elle contenait également un client Docker pour envoyer des commandes aux daemons Docker exposés.

L'un des scripts délivré par les serveurs C2 collectait des informations sur l'environnement compromis, en particulier le nombre de CPU disponibles, et renvoyait l'information aux attaquants. Un autre script a téléchargé une liste de plus de 2000 adresses IP de points d’extrémités API Docker non sécurisés. Le script a ensuite choisi une adresse IP au hasard et a utilisé le client Docker pour se connecter et déployer la même image de conteneur malveillante depuis Docker Hub, réalisant ainsi une auto-propagation. Un troisième script s'est connecté aléatoirement à l'un des hôtes Docker vulnérables de la liste et a déployé une deuxième image de Docker Hub qui contenait un binaire Xmrig en se faisant passer soit pour le serveur web nginx ou soit pour le serveur de base de données MySQL. Xmrig est une application open source qui utilise des CPU pour extraire des cryptomonnaies. Dans le cas de Graboid, il a été configuré pour exploiter Monero.

Enfin, un quatrième script, déclenché par une minuterie, s'est connecté aléatoirement à l'une des adresses IP de la liste et a arrêté les conteneurs Xmrig utilisés pour le minage, y compris ceux déployés par le botnet lui-même. Cela indique que l'activité de minage de cryptomonnaie réalisée sur chaque serveur n'était pas continue et que le botnet a constamment réinfecté de nouveaux hôtes, démarré et stoppé de nouveaux conteneurs. « Le mineur présent sur chaque hôte infecté est contrôlé au hasard par tous les autres hôtes infectés », ont expliqué les chercheurs. « On ne comprend pas très bien l’utilité de ce fonctionnement aléatoire. C’est peut-être un défaut de conception, ou alors c’est une technique d'évasion (peu efficace), ou bien cela permet au système d’être autosuffisant ou autre chose encore », ont constaté les chercheurs.

D’après leur analyse, ces derniers estiment que l'activité de minage de cryptomonnaie sur chaque hôte infecté a eu lieu à des intervalles de 250 secondes en moyenne et que chaque mineur n'était actif que 65 % du temps, ce qui n'est pas très efficace. Cela dit, l'image malveillante utilisée pour la propagation du ver a été téléchargée plus de 10 000 fois et celle contenant le binaire Xmrig plus de 6 500 fois. D'après les adresses IP de la liste de ciblage du ver, près de 60 % des déploiements Docker compromis sont localisés en Chine, 13 % aux États-Unis et le reste dans d'autres pays (0,9% en France).

Mieux sécuriser les déploiements Docker

« Même si le ver de cryptojacking Graboid ne met pas en œuvre des tactiques, des techniques ou des procédures sophistiquées, il peut périodiquement envoyer des scripts depuis les serveurs de commande et de contrôle, de sorte qu'il peut facilement se reconvertir en ransomware ou en tout autre malware pour compromettre totalement les hôtes en aval. C’est un aspect qu’il ne faut pas négliger », ont insisté les chercheurs. « Si un ver plus puissant adoptait une approche d'infiltration similaire, il pourrait causer beaucoup plus de dégâts. Les entreprises doivent donc impérativement protéger leurs hôtes Docker ».

Docker Hub est un projet communautaire géré par des bénévoles, si bien qu’il n'est pas facile à contrôler. Dans le passé, des pirates avaient réussi à télécharger dans ce référentiel des images de conteneurs contenant une porte dérobée et il a fallu des mois pour les découvrir et les supprimer. L'an dernier, des chercheurs de Kromtech ont identifié 17 images Docker malveillantes qui étaient restées stockées sur Docker Hub pendant environ un an. Certaines de ces images contenaient des scripts qui déployaient des shells inversés, des clés d'accès SSH malveillantes et des mineurs de cryptomonnaies.

Les chercheurs de Palo Alto conseillent aux entreprises de ne jamais exposer leurs daemons Docker directement à Internet sans une authentification appropriée. En fait, le Docker Engine n'est pas exposé à Internet par défaut, donc les déploiements non sécurisés exploités par ce ver ont été configurés manuellement pour être accessibles au public. Même lorsque Docker n'est pas directement exposé à Internet, les systèmes d'orchestration de conteneurs et de gestion d'API peuvent l'être, et ce qui introduit également un risque sérieux. Une étude réalisée l’an dernier par l’entreprise de sécurité Lacework avait révélé que plus de 22 000 tableaux de bord de gestion de conteneurs ou de clusters, dont Kubernetes, Docker Swarm, Swagger, Mesos Marathon et Red Hat OpenShift, étaient accessibles au public.

Les chercheurs de Palo Alto conseillent aux entreprises d'utiliser le SSH avec une authentification forte si elles doivent se connecter à distance à un daemon Docker et de combiner cela à des règles de pare-feu qui limitent les connexions à une liste d'adresses IP fiables. De plus, ils recommandent aux administrateurs de s'assurer qu'ils ne déploient jamais d'images de conteneurs Docker provenant de sources non-fiables sur Docker Hub et de vérifier fréquemment leurs déploiements Docker pour débusquer des conteneurs ou des images inconnues.