PClock s’empare de votre blog WordPress pour en faire un centre de commande malveillant

Voilà cinq mois que nos chercheurs suivent de près l’évolution de la famille de rançongiciels PClock. Simple copie de CryptoLocker à ses débuts, nous avons constaté au fil des mois que la famille se sophistiquait. Dans ce billet, nous souhaitons nous pencher plus précisément sur les aspects techniques du cryptage utilisé pour les dernières variantes. Nous enquêterons également sur la façon dont l’auteur de ce malware arrive à s’emparer des blogs sous WordPress pour en faire des serveurs C2 (c’est-à-dire des serveurs de contrôle et commandes) via un plug-in malveillant pour WordPress.

Format de cryptage

Peu après que nous avons craqué la toute première version de PClock et publié un outil de décryptage dédié, l’auteur de ce malware opta pour un nouveau format de cryptage. Ce dernier est désormais utilisé sur toutes les variantes de PClock. Sa clé est générée par infection lors de la première exécution en concaténant les valeurs de retour des différentes fonctions de Windows.

Part of the per-infection key generation function

Extrait de génération de la clé par infection

La chaîne résultante s’apparentera à ceci :

12:15:19 PM 2416  3464  1376256  0  262292  65556  590762  65672

Dans l’ordre, voici les différents éléments qui la composent :

La dernière clé générée par infection est obtenue par hachage de la chaîne au moyen de l’algorithme SHA-256. La dernière clé générée par infection de notre exemple serait dbbff5ce8b1d8e58e28346b0ebbb9a70c7d04e05f10a803bff9539d4e6e044ed. Le malware enverra ensuite cette clé de cryptage générée par infection à son serveur C2. Si le serveur confirme avoir enregistré ladite clé, le malware continuera à crypter les fichiers de la victime.

Les fichiers sont cryptés par bloc de 16 384 octets au moyen de l’algorithme RC4. Chaque bloc utilise une clé générée par bloc obtenue également par hachage d’une chaîne au moyen de l’algorithme SHA-256. La chaîne renferme désormais la clé générée par infection, le chemin complet vers le fichier ainsi que l’index de blocage. Supposons que le malware ait l’intention de crypter le premier bloc de 16 384 octets d’un fichier intitulé “C:\MesDocuments.doc”, la clé générée par bloc serait alors le résultat du cryptage par SHA-256 de la chaîne “dbbff5ce8b1d8e58e28346b0ebbb9a70c7d04e05f10a803bff9539d4e6e044edC:\MesDocuments.doc1”. Pour le second bloc de ce même fichier, la chaîne utilisée pour le calcul de la clé serait alors “dbbff5ce8b1d8e58e28346b0ebbb9a70c7d04e05f10a803bff9539d4e6e044edC:\MesDocuments.doc2” et ainsi de suite. Le malware crypte de cette manière le premier mégaoctet de chaque bloc du fichier. Ensuite, un bloc sur dix-sept uniquement est crypté. S’il reste moins de dix-sept blocs dans le fichier, chacun des blocs restants sera alors crypté. Tout octet restant ne faisant pas partie d’un bloc sera également crypté par une clé dérivée de la clé générée par infection et du nom du fichier, généralement ne comprenant simplement pas le numéro du bloc.

Broken Unicode conversion code used by the SHA-256 implementation of the malware

Code craqué de conversion Unicode utilisé par l’implémentation SHA-256 du malware

Ce qui semble intéressant dans l’implémentation SHA-256 utilisée par le malware est que tant que son fonctionnement en interne repose sur des chaînes ANSI. Un grand nombre de fichiers sur les systèmes des utilisateurs non-anglophones contiennent des caractères ne faisant pas partie du jeu de caractères ANSI standard. PClock utilise lui-même des chaînes Unicode en interne partout. Plutôt que d’effectuer une conversion adéquate des chaînes Unicode en ANSI, le malware effectuera simplement une conversion de type de tous les caractères Unicode en caractère ANSI, laissant par là même de côté l’octet de plus haut niveau du caractère Unicode.

 

Une fois le cryptage de tous les fichiers effectués, le malware supprimera du système de la victime la clé générée par infection en toute sécurité. Le serveur C2 du malware sera le seul donc à conserver une copie de la clé générée par infection utilisée pour crypter les fichiers de la victime.

Le serveur C2 de PClock

Compte tenu de la complexité du nouveau système de cryptage utilisé par PClock, il est raisonnable de se demander comment nous avons réussi à décrypter certains fichiers. La réponse est simple : l’auteur de ce malware a utilisé des serveurs Web piratés pour accueillir toute l’infrastructure de son C2. Nous convenons que cette méthode est certainement un moyen rentable de lancer sa campagne malveillante, toutefois elle comporte quelques inconvénients. Tout d’abord, cette méthode ne vous garantit pas un accès complet au serveur ; il se pourrait donc que vous ne soyez pas en mesure de corriger la configuration non sécurisée qui vous a permis de pirater le serveur Web en premier lieu. Cependant, votre logiciel de serveur C2 pourrait lui alors se retrouver entre les mains d’une équipe de détection de logiciels malveillants telle que la nôtre, désireuse de venir observer plus en détail en quoi il consiste.

Les toutes premières variantes utilisant le nouveau format de cryptage utilisaient un script PHP C2 simpliste qui ne vérifiait pas si vous aviez réellement payé lorsque vous demandiez la clé de décryptage. Notre ami Nathan de BleepingComputer a utilisé cette faille pour fournir un petit correctif qui indique erronément au malware que l’utilisateur a payé ; le malware demande alors au serveur C2 la clé pour décrypter les fichiers de la victime. L’auteur du malware dut rapidement actualiser les scripts côté serveur en ajoutant une étape de vérification de paiement par l’utilisateur :

Payment check added by the malware author

Vérification de paiement ajoutée par l’auteur du malware aux versions ultérieures de ses scripts côté serveur de contrôle et de commande

Cette faille fut la première d’une série de failles découvertes ultérieurement. En examinant le code de plus près, vous verrez que la clé lue se situe dans le sous-répertoire “keys”. Sachant cela, il nous a été facile de deviner les noms de fichier des clés et de les télécharger directement. Nous n’avions plus besoin que de la liste des adresses Bitcoin générées par les logiciels malveillants, laissée par mégarde, mais une vraie aubaine pour nous, par l’auteur du malware sur le serveur sous la forme d’un fichier journal accessible au public nommé “filescount.log” :

Some example entries from the public log kept by the malware's C2 server, containing the victim's IP, their Bitcoin address and the number of files that were encrypted.

Exemples de certaines entrées trouvées du journal accessible au public stocké sur le serveur C2 du malware. Il contient les adresses IP des victimes (version expurgée), leurs adresses Bitcoin associées et le nombre de fichiers cryptés par adresse.

Il ne nous a fallu que quelques minutes pour développer un petit script permettant de télécharger le journal, extraire toutes les adresses générées par Bitcoin et télécharger les clés respectives sans utiliser le script C2 de l’auteur du malware. Ce dernier s’est cependant rendu compte que nous étions toujours en mesure de prêter assistance aux victimes en leur fournissant un moyen de décryptage. Il a donc décidé de rendre encore plus aléatoire les noms de fichier de clés. En regardant de plus près l’extrait du script ci-dessus, vous remarquerez que le nom du fichier dans le dossier “keys” se compose de deux parties : la variable “$wallet” correspond à l’adresse Bitcoin à laquelle l’auteur demande à la victime de payer la rançon et la variable “$SALT”. En informatique, “salt” correspond généralement à des données aléatoires censées compliquer la tâche des attaquants. Dans ce cas particulier, nous pourrions le considérer comme un type primitif de mot de passe. Heureusement pour nous, les auteurs de malware sont des utilisateurs comme vous et moi qui utilisent parfois des mots de passe évidents. Ici, l’entièreté de la sécurité du C2 de l’auteur du malware reposait sur quatre petits chiffres, “0000”:

"0000" is not a secure password

“0000” n’est pas un mot de passe sécurisé

Inutile de le dire, il n’a pas fallu plus de quelques secondes pour le deviner et mettre à mal une autre variante de ce malware. Son auteur tenta alors d’utiliser des salts plus complexes comme “80b5c1cc” pour contrecarrer nos efforts de décryptage, mais heureusement l’un des propriétaires du serveur piraté répondit à nos notifications l’informant que son serveur avait été confirmé comme faisant partie d’une campagne malveillante. Il décida de nous aider en partageant avec nous une copie des scripts côté serveur de toutes les clés que l’auteur du malware stockait sur son serveur. Nous avons bien entendu réussi à déjouer toutes les variantes de ce malware sans grande difficulté.

Le calme avant la tempête

Au cours des semaines suivantes, le calme est quelque peu revenu. Nous avons craqué toutes les variantes à l’exception d’une puisque nous n’avions pas été en mesure d’obtenir à temps du serveur C2 toutes les clés de chiffrement stockées. Comme nous connaissions toutefois toutes les adresses Bitcoin associées au malware, nous avons été en mesure de déterminer à partir des premières variantes ayant infecté quelque 4 000 utilisateurs que moins de 5 utilisateurs avaient payé la rançon. Optimistes de nature, nous nous sommes pris à penser que l’auteur du malware avait tout simplement abandonné la partie. Nous avions tort.

Le 3 mars, près d’un mois et demi après la dernière attaque de PClock, l’un de nos systèmes d’alerte précoce que nous mettons en place régulièrement afin de détecter de nouvelles familles de malware, décela une nouvelle variante de PClock. Nous avons rapidement relevé les nouvelles adresses du serveur C2 et avons essayé nos scripts existants pour extraire les clés, sans succès. Une analyse plus poussée a montré que les serveurs exécutaient tous des versions obsolètes de WordPress. En examinant le protocole de communication utilisé par le malware, nous avons également remarqué qu’il ne parlait plus à un script de serveur dédié C2 mais à l’instance WordPress. C’est là que nous sommes arrivés à la conclusion que l’auteur de malware venait de changer de tactique.

Une des premières mesures que nous mettons en place quand nous observons un site piraté est d’essayer des noms de fichier aléatoires afin de voir si nous sommes redirigés vers des informations utiles, et nous avons eu de la chance. Nous ne le savions pas à l’époque mais, l’auteur du malware avait basé la sécurité de l’ensemble de son opération autour d’un seul mot de passe et avait cette fois encore choisi l’un des mots de passe les plus faibles imaginables :

QWERTY is a bad idea for a password as well

QWERTY est également une très mauvaise idée de mot de passe

Après avoir découvert le répertoire ouvert “QWERTY” accessible à tous pour listage et téléchargement, nous avions une fois de plus un moyen d’extraire toutes les clés du serveur C2. Nous savions que l’auteur de malware finirait par changer de serveur et que le nouveau ne nous permettrait peut-être pas de lister les répertoires facilement. Pour garantir notre efficacité dans le futur, il nous fallait trouver une autre façon d’extraire les clés. Comme toujours, nous avons informé tous les propriétaires de sites Web que leur site était utilisé comme centre de commande d’une campagne malveillante. Une fois de plus, un des propriétaires de site Web monta au créneau et accepta de coopérer avec nous.

WPUnitE transforme votre blog en un serveur C2 malveillant

Nous savions que le nouveau script C2 utilisé par l’auteur de malware agissait dans le cadre de l’installation WordPress. Nous avons donc  immédiatement pensé à vérifier les plug-ins de WordPress. WordPress permet aux propriétaires de sites Web d’ajouter sur leur blog des fonctions et des fonctionnalités supplémentaires au-delà de la portée originale du logiciel WordPress en recourant à des plug-ins tiers. Ces plug-ins sont chargés par WordPress chaque fois que l’on accède au blog et ne comportent que très peu de restrictions. Lorsque nous avons examiné les plug-ins installés, l’un d’entre eux a éveillé notre attention en particulier : WPUnitE 1.0, prétendument publié par “WordPress”.

Malicious WPUnitE plugin installed in hacked WordPress blog

Plug-in WPUnitE malveillant installé dans un blog WordPress piraté

Le code source du plug-in est masqué par diverses couches d’éval., de compression Gzip et d’encodage BASE64. Une fois les couches d’obfuscation retirées, vous vous retrouvez avec un petit script qui gère toutes les commandes envoyées par le malware :

Malware C2 plugin code deobfuscated

Code du plug-in malveillant sur le C2 plugin code éclairci

Ce plug-in distingue deux types de commandes : les commandes restreintes uniquement accessibles sur saisie de mot de passe et les commandes non restreintes accessibles par tous. Dans cette version du script, le mot de passe est le fameux “QWERTY”. Ce mot de passe est également utilisé par le plug-in C2 comme chemin de stockage pour toutes les clés de cryptage enregistrées. Cela explique pourquoi nous avons été en mesure de trouver le répertoire/QWERTY / plus tôt.

Les commandes restreintes sont :

  • CHECK
    Cette commande effectue une vérification automatique simple pour s’assurer que le plug-in est fonctionnel et en mesure de stocker correctement les fichiers de clés de cryptage reçus.
  • GET_STATE
    Cette commande prend toutes les clés enregistrées et les renvoie au client dans un format sérialisé et codé en BASE64.
  • SET_STATE
    Cette commande prend essentiellement une liste sérialisée et codée en BASE64 de clés de cryptage et la stocke sur le serveur.

Nous pensons que l’auteur du malware a utilisé GET_STATE et SET_STATE afin de synchroniser les clés de cryptage entre tous les serveurs C2. Par le passé, certaines clés avaient été égarées, résultant en une impossibilité de décrypter les fichiers une fois le serveur C2 neutralisé. Cette nouvelle approche permet à l’auteur de malware de conserver une sauvegarde de toutes les clés générées et de l’implémenter dans de nouveaux serveurs C2 en cas de fermeture des anciens serveurs.

Les commandes disponibles sans mot de passe et exclusivement utilisées par le malware sont :

  • PING
    PING est utilisé par le malware pour envoyer l’adresse Bitcoin et la clé cryptée générées ainsi que le nombre de fichiers cryptés sur le serveur C2.
  • GET_KEY
    Cette commande est utilisée par le malware une fois que la victime a payé la rançon pour obtenir la clé de cryptage nécessaire au décryptage des fichiers de la victime. Elle procède à une vérification analogue à celle de la version précédente afin de s’assurer que les clés divulguées ont été effectivement payées.

Puisque nous connaissions désormais le fonctionnement du plug-in C2, nous avons pu écrire notre propre script client capable d’utiliser la commande GET_STATE afin d’obtenir toutes les clés de cryptage stockées sur tous les serveurs C2.

À ce stade, l’auteur publia presque chaque semaine de nouvelles variantes du malware sur de nouveaux serveurs C2, ne sachant pas comment nous avions pu obtenir les clés de cryptage sur ses serveurs C2. Il a dû penser que nous pirations les serveurs de la même façon que lui le faisait parce qu’il commença à actualiser les blogs WordPress qu’il avait infiltrés afin de parer à toutes les failles ouvertes qui nous auraient permis d’accéder au site Web et aux clés stockées. En réalité, nous connaissions son mot de passe et son interface C2 ; c’est ainsi que nous avons utilisé les mêmes méthodes de création de sauvegardes des clés que lui mais en notre faveur.

Modification des mots de passe

Les lecteurs de notre blog savent que, contrairement à certains de nos concurrents, nous ne communiquons jamais publiquement d’informations susceptibles d’être utilisées par les auteurs de malware pour améliorer leurs créations. Nous avons plutôt tendance généralement à taire les failles trouvées et à ne les partager qu’avec d’autres experts en détection de malware, à titre privé, afin que nous puissions exploiter ces failles dans le but d’aider les nombreuses victimes de rançongiciels, pendant plus longtemps. Vous aurez compris en lisant ce billet que, sans surprise, l’auteur des malware finit par trouver un moyen de nous éjecter du système. Le 21 avril, de nouvelles variantes de PClock firent leur apparition sur des serveurs C2 avec lesquels notre client personnalisé fut incapable de communiquer. Il est fort probable que l’auteur de malware se soit enfin rendu compte que nous avions découvert et utilisions son mot de passe “sécurisé” et qu’en fait nous utilisions les mêmes commandes qu’il utilisait pour créer ses propres sauvegardes de clés. Il changea enfin de mot de passe. Malheureusement pour lui, nous sommes vertueux et n’avons aucunement besoin de nous cacher. Nous pouvons gentiment demander à l’un des propriétaires de sites infectés de nous envoyer une copie du plug-in de C2 malveillant et, comme par le passé, l’un d’entre eux l’a fait. Nous avons réussi à déchiffrer le nouveau mot de passe (“9eba6538”) et sommes remontés au front. Malencontreusement, le 28 avril, l’auteur de malware publia une nouvelle variante de son malware ainsi qu’une version mise à jour de son plug-in C2.

Nous vous présentons la version 2.0 de WPUnitE

Comme avec les versions précédentes, la version 2.0 du plug-in C2 utilise une technique de dissimulation similaire. La majorité des commandes restreintes ont toutefois été modifiées :

Command parsing function of WPUnitE 2.0 C2 plugin

Fonction d’analyse de commande de la version 2.0 du plug-in WPUnitE

Tout d’abord, le mot de passe n’est plus enregistré en texte clair. Au lieu de cela, il est stocké sous forme de hachage MD5 (“7afd6de416cfd1427262d380ef1d4c33”). Les commandes GET-STATE et SET_STATE ont disparu. Désormais, les commandes s’intitulent GET_CLIENTS, GET_ORDERS et SET_KEY, toutes exigeant une authentification par mot de passe. GET_CLIENTS remplace GET_STATE. Elle renvoie essentiellement une liste sérialisée et codée en BASE64 de toutes les clés stockées sur le serveur. Contrairement à GET_STATE cependant, GET_CLIENTS supprime toutes les clés une fois celles-ci exportée. Il n’est plus possible d’obtenir une copie de sauvegarde de toutes les clés. Vous n’obtiendrez que les clés générées depuis l’exportation de la dernière sauvegarde. Sur base des journaux que nous avons trouvés, l’auteur de malware exporte automatiquement les clés toutes les 5 minutes environ grâce à une connexion Tor.

Développement impossible dès lors d’un correctif pour les dernières variantes de PClock

Si le serveur C2 ne renferme plus les clés, comment les victimes ayant décidé de payer une rançon peuvent-elles dès lors obtenir une clé de décryptage ? C’est là qu’entrent en jeu GET_ORDERS et SET_KEY. Dès qu’une rançon est payée, le malware contacte le serveur C2 en utilisant la commande GET_KEY, comme dans les versions précédentes. GET_KEY vérifiera si la clé se trouve sur le serveur et si la réponse est négative, il passera une “commande” de clé et demandera au malware de réessayer ultérieurement. Ces “commandes” peuvent être exportées comme les clés en utilisant la fonction GET_ORDERS. Une fois que l’auteur de malware a vérifié qu’une rançon a été payée, il utilise alors la fonction SET_KEY pour placer à nouveau la bonne clé sur le serveur. À la prochaine visite du malware pour connaître la disponibilité de la clé de décryptage via la commande GET_KEY, il l’obtiendra et effectuera le décryptage.

Puisque les clés cryptographiques ne sont plus stockées sur le serveur, nous ne pouvons malheureusement plus les vider. Après près de quatre mois, l’auteur des malware a finalement réussi à nous exclure.

Comment dès lors se protéger ?

Nous ne le dirons jamais assez mais la prévention est la meilleure défense. Si vous êtes un utilisateur d’Emsisoft, soyez assuré que toutes les variantes de PClock ont été bloquées par le module Analyse de comportements que vous retrouvez dans les produits Emsisoft Anti-Malware et Emsisoft Internet Security. Les clients d’Emsisoft ne courent donc jamais aucun risque d’infection par PClock.

New PClock variant being blocked by Emsisoft's behavior blocking technology

Nouvelle variante de PClock bloquée par la technologie d’Analyse de comportements d’Emsisoft

Si vous détenez un blog WordPress et ne voulez pas que votre site soit malmené par des auteurs de malware, nous vous recommandons fortement de maintenir à jour scrupuleusement aussi bien WordPress que vos plug-ins  En outre, il est crucial de faire en sorte que tous vos comptes rédacteurs et administrateurs utilisent des mots de passe sécurisés. Dans au moins un cas porté à notre connaissance, l’auteur de malware  a pu pirater le site en raison d’un mot de passe faible du compte administrateur.

En dernier lieu, nous tenons à remercier nos amis de chez BleepingComputer et les propriétaires des sites Web piratés qui ont gracieusement répondu à nos notifications et ont pris la bonne décision en nous aidant.

Comme toujours, nous vous souhaitons une excellente journée (sans rançongiciels) !