Les attaques cyber visant les conteneurs et services Docker ne se limitent pas à des fins d'intrusion dans le SI et de vol de données. Elles peuvent aussi être exécutées pour du minage de monnaies virtuelles. Si de prime abord les conséquences apparaissent moins graves, elles sont toutefois très embêtantes. La raison ? En exploitant les ressources utilisées pour les environnements Docker cibles elles contribuent à ralentir voire à les empêcher de fonctionner correctement. C'est le cas avec le dernier type de campagne malveillante découverte par les chercheurs en sécurité de Cado Security. Elle a été découverte après une opération de routine de l'infrastructure honeypot du fournisseur et elle déploie deux conteneurs sur une instance vulnérable à savoir un mineur XMRig ainsi que l'application 9hits, utilisée ici comme payload, pour échanger du trafic redirigé vers son site contre des crédits via une session Chrome sans interface graphique.

La méthode exacte utilisée pour diffuser le malware aux hôtes Docker vulnérables n'a pour l'heure pas été clairement établie, mais Cado Security soupçonne qu'elle implique l'utilisation de moteurs de recherche comme Shodan pour rechercher des cibles potentielles. Une fois trouvées, les serveurs pirates déploient dessus deux containers malveillants via l'API Docker et récupèrent des images prêtes à l'emploi de la bibliothèque Docker Hub pour les logiciels 9Hits et XMRig. « Il s'agit d'un vecteur d'attaque courant pour les campagnes ciblant Docker, où au lieu de récupérer une image sur mesure pour leurs besoins, ils tirent une image générique de Docker Hub qui sera presque toujours accessible et l'exploitent pour leurs besoins », expliquent les chercheurs en sécurité. 

Contrôle de l'affichage de fenêtres contextuelles et de durée de mise en cache de données

Le déclenchement de l'infection est effectué via une commande exécutant le script nh.sh sur l'instance 9hits à laquelle l'attaquant a ajouté son jeton de session. « Cela permet à l'application 9hits de s'authentifier auprès de ses serveurs et d'en tirer une liste de sites à visiter. Une fois que l'application a visité le site, le propriétaire du jeton de session reçoit un crédit sur la plateforme de 9hits », indique Cado Security. « Il semble que 9hits ait conçu le système de jetons de session pour fonctionner dans des contextes non fiables. Il est impossible d'utiliser le jeton pour autre chose que l'exécution de l'application afin de générer des crédits pour le propriétaire du jeton, l'API et les jetons d'authentification étant un système distinct. Cela permet à l'application d'être utilisée dans des campagnes frauduleuses sans risque de compromettre le compte de l'attaquant ». L'opération s'appuie aussi sur le fait que 9hits se base sur une session Chrome sans interface graphique configuré pour autoriser la visite de sites pour adultes ou de sites affichant des fenêtres contextuelles, contrôler la durée de mise en cache des données, mais empêchant aussi de visiter des sites liés aux cryptomonnaies.

Sur l'autre conteneur déployé par l'attaquant embarquant XMRig, une commande bash est exécutée incluant l'option -0 pour spécifier la ressource de minage à utiliser. « La plupart des déploiements de XMRig utilisent un pool public et lui communiquent l'adresse du portefeuille du propriétaire, qui peut être fréquemment combinée avec les données publiques du pool pour voir combien de systèmes minent pour cette adresse, ainsi que les gains du propriétaire », fait savoir Cado Security. « Toutefois, dans le cas présent, il semblerait que le pool minier soit privé, ce qui nous empêche de trouver des statistiques sur la campagne. Le domaine dscloud est utilisé par Synology pour le DNS dynamique, où le serveur Synology maintient le domaine à jour avec l'IP actuelle de l'attaquant. En effectuant une recherche pour cette adresse au moment de la rédaction, nous pouvons voir qu'elle se résout en 27[.]36.82.56, la même IP qui a infecté le honeypot en premier lieu ».

Des conséquences à prendre au sérieux

« Le principal impact de cette campagne sur les hôtes compromis est l'épuisement des ressources, car le mineur XMRig utilisera toute la puissance CPU disponible, tandis que 9hits utilisera une grande quantité de bande passante, de mémoire et le peu de CPU restant », prévient Cado Security. « Il en résulte que les charges de travail légitimes sur les serveurs infectés ne peuvent pas fonctionner comme prévu. En outre, la campagne pourrait être mise à jour pour laisser un shell distant sur le système, ce qui pourrait entraîner une violation plus grave. Cela a déjà été observé avec mexals/diicot, un acteur roumain qui maintenait l'accès aux serveurs compromis en utilisant une clé SSH malveillante en plus de l'exécution de XMRig ».