VestaCP compromis dans une nouvelle attaque de la chaîne de commande

Au cours des derniers mois, de nombreux utilisateurs de VestaCP, une solution de panneau de contrôle d'hébergement, ont été avertis par leur fournisseur de services que leurs serveurs utilisaient une quantité anormale de bande passante. Nous savons aujourd'hui que ces serveurs ont en fait été utilisés pour lancer une attaque DDoS. L'analyse d'un serveur compromis a montré que le logiciel malveillant que nous appelons Linux/ChachaDDoS était installé sur ce système. Au même moment cette semaine, nous avons appris que le site Web du VestaCP a été compromis, ce qui a entraîné une attaque de la chaîne d'approvisionnement sur les nouvelles installations du VestaCP depuis au moins mai 2018. Linux/ChachaDDoS a quelques similitudes avec Xor.DDoS, mais à la différence de cette famille plus ancienne, il a plusieurs étapes et utilise Lua pour ses composants de deuxième et troisième niveau.

Vecteur d’infection

Selon l'utilisateur « Razza » du forum VestaCP, l'attaquant a tenté de lancer Linux/ChachaDDoS via SSH. La façon dont la charge utile a été déposée dans le répertoire `/var/tmp` reste à déterminer, mais en supposant que l'attaquant possède déjà le mot de passe administrateur, cette tâche se serait avérée triviale. Pendant l'installation, VestaCP crée un utilisateur nommé « admin », disposant des privilèges sudo. La question demeure néanmoins : comment l'attaquant aurait-il pu connaître le mot de passe de cet utilisateur admin?

Nous avons envisagé plusieurs hypothèses quant à la façon dont les informations d’accès ont été obtenues en premier lieu. Nous avons d'abord soupçonné une vulnérabilité dans l'interface web de VestaCP. En examinant le code, nous avons constaté que le mot de passe non chiffré est conservé dans `/root/.my.cnf`, mais que l'accès au contenu de ce fichier nécessiterait toujours que l'attaquant exploite une vulnérabilité d'inclusion de fichier local et d'escalade des privilèges. L'utilisateur « Falzo » a fouillé davantage dans le code et a découvert quelque chose de plus intéressant encore : certaines versions du script d'installation laissent échapper le mot de passe administrateur et le nom du serveur vers vestacp.com, le site officiel du VestaCP.

Comme « L4ky » l'a souligné, tout cela est dans l'historique Git du fichier `vst-install-ubuntu.sh`. Du 31 mai 18:15:53 2018 (UTC+3) (a3f0fa1) au 13 juin 17:08:36 2018 (ee03eff), la variable `$codename` contenait le mot de passe codé en base64 et le nom de domaine du serveur envoyé à test.com. Falzo dit qu'il a trouvé le hack dans la ligne 809 de l'installateur Debian. Néanmoins, et contrairement au cas de l'installateur Ubuntu, nous n'avons pas pu trouver de référence à celui-ci dans l'histoire de Git. Peut-être que l'installateur sur VestaCP différait de ce qui est visible sur GitHub.

Compte tenu de cette importante fuite de mot de passe, nous invitons fortement tous les administrateurs VestaCP à changer le mot de passe administrateur et de durcir l'accès à leurs serveurs. Les administrateurs sérieux devraient envisager un audit du code VestaCP.

Bien que ce résultat soit choquant, il n'y a aucune preuve que cette fuite de mot de passe soit la façon dont Linux/ChachaDDoS a été distribué en premier lieu. Il aurait pu se faufiler d’une autre façon.

Les responsables du VestaCP ont déclaré être compromis. Comment le code malveillant s'est retrouvé dans leur arbre Git demeure à éclaircir. Peut-être que l'auteur a modifié les scripts d'installation sur le serveur et cette version a été utilisée pour créer la prochaine version du fichier dans Git, mais seulement pour Ubuntu. Ceci impliquerait qu'ils aient été compromis depuis au moins mai 2018.

Analyse de Linux/ChachaDDoS

Le logiciel malveillant placé sur les serveurs compromis est une variante d'une nouvelle souche de logiciel malveillant DDoS que nous appelons ChachaDDoS. Il semble qu'il s'agisse d'une évolution de plusieurs logiciels malveillants DDoS existants. La première et la deuxième étape règlent le nom de leur processus sur[`kworker/1:1`]. C'est ce qui apparaîtrait dans les résultats ps.

Premier niveau

Mécanisme de persistance et liens avec Xor.DDoS

Le mécanisme de persistance utilisé par Linux/ChachaDDoS est en fait le même que celui de Linux/XorDDos, à part en ce qui a trait au nom de fichier, dhcprenew. Il est constitué des étapes suivantes :

1. Il se copie lui-même dans `/usr/bin/dhcprenew`.
2. Si un mécanisme de persistance lié au logiciel malveillant est déjà installé sur l'hôte, il le supprime.
3. Un nouveau service est ajouté à `/etc/init.d/dhcprenew`.

#!/bin/sh
# chkconfig: 12345 90 90
# description: dhcprenew
### BEGIN INIT INFO
# Provides:     dhcprenew
# Required-Start:
# Required-Stop:
# Default-Start: 1 2 3 4 5
# Default-Stop:    
# Short-Description: dhcprenew
### END INIT INFO
case $1 in
start)
   /usr/bin/dhcprenew
   ;;
stop)
   ;;
*)
   /usr/bin/dhcprenew
   ;;
esac

4. Un symlink à ce service est créé dans `/etc/rc[1-5].d/S90dhcprenew` et `/etc/rc.d/rc[1-5].d/S90dhcprenew`.
   
5. Il exécute les lignes de commande `chkconfig --add dhcprenew` et `update-rc.d dhcprenew` defaults, afin d’activer ce service.

Télécharger et déchiffrer le deuxième niveau

Une fois la persistance définie, la deuxième étape est périodiquement téléchargée à partir d'une URL codée en dur. Fait intéressant, à partir des différents échantillons que nous avons analysés, nous avons observé des caractéristiques similaires concernant la structure de l'URL :

• L’utilisation du port 8852
• Toutes les adresses IP appartiennent au sous-réseau 193.201.224.0/24 (AS25092, OPATELECOM PE Tetyana Mysyk, Ukraine)
• Le nom de la ressource de la deuxième étape semble pseudo-aléatoire, mais est toujours constitué d'une chaîne de 6 à 8 caractères en majuscules (tel que JHKDSAG ou ASDFRE)

L'URL suit le modèle `http://{C&C}:8852/{campaign}/{arch}`. Nous avons découvert que les binaires de deuxième niveau sont disponibles pour de multiples architectures dont x86, ARM, MIPS, PowerPC et même, s390x. Après avoir téléchargé le fichier ELF correspondant à l'architecture de l'hôte victime, il est déchiffré avec l'algorithme de chiffrement ChaCha. ChaCha est le successeur du chiffre du flux Salsa20. Les deux chiffres utilisent la même constante `expand 32-byte k`, pour régler l'état initial. L'image suivante montre le début de la fonction de déchiffrement :

Les différences entre les deux algorithmes sont constituées d’un réarrangement de l'état initial et une modification du quarter-round, qui est l'opération principale effectuée par les chiffres. Grâce aux rotations spécifiques utilisées dans son quarter-round, nous avons pu identifier l'utilisation de ChaCha, comme le montre l'extrait suivant :

La taille de clé utilisée pour le décryptage ChaCha est de 256 bits et parmi tous les échantillons recueillis, nous avons observé l'utilisation de la même clé. Afin d'éviter de réimplémenter l'algorithme de déchiffrement, nous avons développé un script basé sur Miasm pour émuler la fonction de décryptage.

Une fois que nous avons déchiffré le second niveau, nous avons obtenu comme résultat LZMA compressé. Nous avons donc extrait le binaire en utilisant `lzma -d < output > second_stage.elf`.

Deuxième niveau

Le binaire lui-même est beaucoup plus grand que la première étape; principalement parce que l'interpréteur Lua est intégré. Les logiciels malveillants dans Lua sont quelque chose que nous avons déjà observé dans le cas de Linux/Shishiga. Le but de la deuxième étape est d'exécuter une charge utile Lua codée en dur qui télécharge des tâches périodiquement. Nous considérons la tâche comme l’une de troisième étape, car une tâche est essentiellement du code Lua à interpréter. Dans toutes les variantes que nous avons observées, la deuxième étape utilise le même serveur C&C que la première étape. Cette deuxième étape intègre de nombreuses bibliothèques Lua (comme LuaSocket) pour communiquer avec le serveur C&C codé en dur, qui est le même que celui de la première étape.

Certaines fonctions natives du binaire sont liées pour pouvoir être appelées à partir du code Lua; la capture d'écran suivante montre la liaison pour certaines fonctions, comme la fonction de chiffrement ChaCha, par exemple.

La tâche téléchargée par la charge utile Lua est déchiffrée ChaCha (avec une clé de chiffrement différente) et exécutée par l'interpréteur Lua. Comme pour la deuxième étape, l'URL utilisée pour télécharger la tâche semble suivre un modèle spécifique, comme on peut l'observer à partir de l'extrait de code suivant :

De plus, la charge utile devrait envoyer des statistiques en utilisant l'URL spécifiée sur la capture d'écran ci-dessus concernant l'utilisation de la tâche. Cependant, dans la pratique, elle n'envoie que l'adresse MAC, ainsi que quelques autres informations :

Troisième niveau (tâches) :

À partir des tâches que nous avons pu collecter, nous n'avons observé que la mise en œuvre d'une fonction DDoS. Le code est assez explicite et consiste principalement en un appel à une fonction pour effectuer une attaque SYN DDoS contre une cible précise :

L’adresse IP de la cible du DDoS, 144.0.2.180, belongs to a Chinese ISP. We couldn’t find any obvious reason for this IP address to be a target of the DDoS attack, as no services seem to be hosted on that IP address.

L'en-tête `Last-Modified` de la réponse au fichier de tâche indique que cet objectif était le même depuis le 24 septembre 2018. Celui-ci devrait être fiable puisque le logiciel malveillant utilise l'en-tête `If-Modified-Since`, afin d’éviter de télécharger à nouveau des charges utiles.

ASDFREM est la seule autre campagne avec une tâche active. Celle-ci est très semblable, mais cible une autre adresse IP située en Chine :61.133.6.150.

Conclusion

Il parait évident que ChachaDDoS partage du code avec Xor.DDoS pour son mécanisme de persistance. Mais sont-ils la création même auteur, ou les auteurs de ChachaDDoS l'ont-ils simplement volé? ChachaDDoS a attiré notre attention parce qu'il a été vu sur des instances de VestaCP, mais l'existence de binaires pour de multiples architectures suggère que d'autres périphériques, y compris les appareils intégrés, sont visés par cette menace.

Cet incident constitue également un rappel du fait que même si un logiciel est open source, ceci ne garantit pas à 100 % qu'il soit sûr. Les logiciels malveillants peuvent encore s'infiltrer. Le code malveillant de vol de carte d'identité était là, à la vue de tous sur GitHub et ce, pendant plusieurs mois, avant d’être finalement repéré. Nous sommes d'accord que celui-ci aide à trouver les vulnérabilités - post-mortem dans ce cas - mais cela ne signifie pas que nous devrions faire aveuglément confiance à un produit, simplement sur la base qu'il est open source.

Les produits ESET détectent cette menace comme Linux/Xorddos.Q, Linux/Xorddos.R et Linux/ChachaDDoS.

Merci à Hugo Porcher pour son aide pour cette analyse et la rédaction de cet article.

Indicateurs de compromission (IoCs)

Premier niveau

Deuxième niveau

Références

1. http://blog.malwaremustdie.org/2014/09/mmd-0028-2014-fuzzy-reversing-new-china.html
2. https://www.fireeye.com/blog/threat-research/2015/02/anatomy_of_a_brutef.html
3. https://otx.alienvault.com/indicator/file/0177aa7826f5239cb53613cc90e247b710800ddf
4. https://forum.vestacp.com/viewtopic.php?f=10&t=16556
5. https://carolinafernandez.github.io/security/2015/03/16/IptabLeX-XOR-DDoS
6. https://blog.checkpoint.comhttps://web-assets.esetstatic.com/wls/2015/10/sb-report-threat-intelligence-groundhog.pdf
7. https://grehack.fr/data/2017/slides/GreHack17_Down_The_Rabbit_Hole:_How_Hackers_Exploit_Weak_SSH_Credentials_To_Build_DDoS_Botnets.pdf