Un ransomware mal programmé devient incapable de déchiffrer les données des victimes
Un ransomware mal programmé devient incapable de déchiffrer les données des victimes
Après le paiement de la rançon
C’est déjà pénible de payer pour récupérer ses propres données après une « prise en otage » par des logiciels malveillants connus sous le nom de ransomware. Mais, c’est encore plus désagréable de devoir payer la rançon sans aucune possibilité d’avoir accès à nouveau à ses fichiers. C’est dans cette dernière situation que de nombreuses personnes ont probablement été, avec une nouvelle variante mal programmée du ransomware Power Worm.
Les développeurs de ransomware n’ont aucun intérêt à bloquer les fichiers de leurs victimes après avoir reçu la somme demandée. En effet, si le ransomware a la réputation de ne pas restaurer les données des victimes après le paiement de la rançon, cela garantit qu’aucun utilisateur ne va payer cette somme s’il sait qu’il ne pourra pas récupérer ses données. Pour cette raison, aussi malveillants qu’ils soient, les développeurs de ransomware prennent en général le soin de débloquer les données de leurs victimes, parce qu’ils ne percevront rien tant que ces dernières sont sures de ne pas avoir à nouveau accès à leurs fichiers. L’incapacité de ce nouveau malware à déchiffrer les données des victimes semble donc être le résultat d’une mauvaise programmation de son auteur, et c’est ce que l’analyse technique semble montrer.
BleepingComputer, qui a reçu l’échantillon du demandeur de rançons, l’a fait analyser par son équipe interne de chercheurs avant d’exposer l’erreur commise par le programmeur dans son code. L’objectif est de permettre à ce développeur de corriger la faille dans son code de sorte que ses prochaines victimes aient au moins la possibilité de récupérer leurs données.
Le ransomware est un script PowerShell de 54 lignes. Lorsqu’il est exécuté, il débute son infection en supprimant les clichés instantanés ou shadow copies des lecteurs, qui sont utilisés pour restaurer des fichiers. L’objectif est donc d’empêcher les victimes de les utiliser pour tenter une quelconque restauration. Il a ensuite recours à une commande PowerShell qu’il manipule pour obtenir la liste de lecteurs qui sont en écriture. Dans chacun de ces lecteurs, il va maintenant rechercher les fichiers de données ayant une certaine extension présente dans une longue liste prédéfinie. Les fichiers repérés sont ensuite chiffrés en utilisant une clé de chiffrement AES générée aléatoirement.
L’impossibilité de restaurer les données des victimes après le paiement de la rançon résulte d’une mauvaise programmation à cette étape. En effet, « le développeur avait prévu l’utilisation d’une clé AES statique pour l’ensemble de ses victimes », explique BleepingComputer. « Puisque tout le monde aurait la même clé de déchiffrement, cela permettrait au développeur d’avoir un déchiffreur qui pourrait fonctionner pour tout le monde plutôt que d’avoir à gérer un site de paiement complexe et un moteur de déchiffrement ». Lors de l’exécution du programme, un petit caractère ‘=’ manquant dans l'expression de la variable qui devrait contenir la clé AES décodée génère une clé aléatoire qui, malheureusement, n’est ni enregistrée ni transmise au développeur. La clé est donc perdue après que le script est exécuté.
« Le problème est que la clé AES n'a pas été correctement bourrée (padding) quand elle a été convertie en une chaîne base64. Lorsque le script PowerShell a essayé de décoder cette chaîne, il a échoué, et au lieu que la variable $RgDhcxSdghWd contienne sa chaîne AES décodée, elle contenait maintenant une valeur NULL ou vide. S’il avait ajouté un caractère ‘=’ de plus à la chaîne, cela aurait fonctionné comme prévu et tout le monde aurait eu la même clé AES », explique BleepingComputer.
Avec la valeur NULL, la tentative pour le développeur d’initialiser le moteur de chiffrement AES génère plutôt une clé aléatoire pour chaque victime, qu’il est en plus impossible de récupérer. Ce qui signifie qu’il n’y a rien qui puisse être fait pour que les victimes récupèrent leurs données, excepté une restauration à partir d’une sauvegarde, dans le meilleur des cas. Un simple test de l’infection aurait pu permettre de détecter cette faille, estime BleepingComputer.
Source : BleepingComputer
Et vous ?
Qu’en pensez-vous ?
Voir aussi
Répondre avec citation
Envoyé par DarkBakura
Partager