La conteneurisation se développe rapidement et intéresse de facto les cybercriminels. Les experts de Cado Security ont observé une campagne menée par un botnet nommé OracleIV, spécialisé dans les attaques en déni de service. Elle a la particularité de s'attaquer aux environnements se servant de l'API Docker Engine à travers une image malveillante. « L'hébergement du conteneur malveillant dans Dockerhub, la bibliothèque d'images de conteneurs de Docker, rationalise encore davantage ce processus », souligne les chercheurs dans un rapport.

Image OracleIV malveillante

L'attaque observée par Cado commence par une requête HTTP POST " /images/create" sur l'instance de l'API Docker non protégée. Ensuite, des paramètres pointent vers une image appelée oracleiv_latest, téléchargée sur Docker Hub par un utilisateur nommé robbertignacio328832. Cette requête équivaut à une commande docker pull qui télécharge l'image du conteneur et l'installe localement, suivie d'une commande de démarrage du conteneur. Le ciblage des API de Docker Engine exposées publiquement et non protégées n'est pas nouveau. Plusieurs groupes d'attaquants recherchent de telles instances et déploient généralement des malwares de cryptojacking.

C'est le cas d'un groupe appelé TeamTNT qui s’attaque principalement aux environnements cloud. Ce groupe est à l'origine d'un ver baptisé Silentbob, lancé au début de l'année, qui ciblait des instances Docker et Jupyter Notebook non sécurisées et volait des informations d'identification AWS. Comme pour cette attaque, TeamTNT a hébergé ses images de conteneurs malveillants sur Dockerhub à partir de plusieurs comptes. L'image OracleIV trouvée par Cado était régulièrement mise à jour et comptait plus de 3 000 téléchargements, ce qui laisse penser que la campagne a été active et réussie.

Réseau de zombies DDoS et cryptojacking

Une fois lancée, l'image du conteneur compromis exécute un binaire ELF appelé oracle.sh, suivi de commandes wget qui attirent et exécutent une variante du cryptomineur XMRig avec une configuration personnalisée. L'instance XMRig n'est pas réellement utilisée, et ces attaquants sont bien plus intéressés par le détournement des ressources du serveur pour des attaques DDoS. L'exécutable oracle.sh a été écrit à l'origine en code Python et compilé avec Cython (C-Extensions for Python). Le code met en œuvre plusieurs méthodes DDoS différentes, notamment les inondations de paquets TCP, UDP et SYN, ainsi que des variantes spécifiques visant à déjouer diverses défenses. Par exemple, l'inondation UDP standard implique des paquets de 40 000 octets, fragmentés en raison de la limite de taille des paquets de l'UDP, ce qui crée une surcharge de calcul sur la cible pour réassembler les fragments. Cependant, le botnet met également en œuvre des débordements UDP avec des paquets de 18, 20 et 8 octets. Ceux-ci sont lancés avec les commandes appelées FIVE, VSE et OVH et semblent viser les serveurs FiveM, le moteur de jeu Source de Valve et le fournisseur de cloud français OVH.

Le botnet met aussi en œuvre une attaque de type Slowloris qui consiste à ouvrir de nombreuses connexions à un serveur et à envoyer continuellement de petites quantités de données pour maintenir ces connexions ouvertes. Le client du bot se connecte à un serveur de commande et de contrôle en utilisant une authentification ordinaire basée sur une clé codée en dur, envoie des informations de base sur le système hôte et écoute les commandes. « La portabilité qu'apporte la conteneurisation permet aux charges utiles malveillantes d'être exécutées de manière déterministe sur les hôtes Docker, quelle que soit la configuration de l'hôte lui-même », ont expliqué les chercheurs de Cado. « Même si OracleIV n’est pas techniquement une attaque de la supply chain, les utilisateurs de Docker Hub doivent savoir que des images de conteneurs malveillants existent effectivement dans la bibliothèque d'images de Docker, un problème qui ne sera semble-t-il pas corrigé dans un avenir proche. L'entreprise de sécurité conseille aux entreprises d'évaluer périodiquement les images Docker qu'elles tirent de Docker Hub pour s'assurer qu'elles n'ont pas été transformées en chevaux de Troie. En outre, elles devraient s'assurer que toutes les API et interfaces de gestion des technologies cloud comme Jupyter, Docker et Redis sont sécurisées par une authentification et protégées par des règles de pare-feu.