Question:
Comment un logiciel malveillant crypte-t-il si rapidement les fichiers des victimes?
Ulkoma
2015-07-05 12:19:52 UTC
view on stackexchange narkive permalink

Pour moi, chiffrer un fichier revient à traiter une très longue chaîne, en l'introduisant dans la fonction de hachage ou de chiffrement pour obtenir une autre longue chaîne chiffrée (ou un hachage dans le cas du hachage).

Ce processus prend un certain temps. Je le sais parce que j'utilise HashTab pour vérifier l'intégrité des fichiers que je télécharge sur Internet.

Comment un ransomware comme CTB-Locker ou Crypt0l0cker peut-il crypter instantanément les fichiers de ses victimes?

Récemment, un de mes amis a été victime d'un de ces ransomwares et il n'a PAS pu ouvrir ses fichiers / des photos d'Ubuntu sur sa machine à double OS, même lorsque l'infection s'est produite avec MSWindows. Cela suggère que le cryptage ne se produit pas à la volée lorsque vous ouvrez un fichier.

Vous n'avez pas besoin de crypter tout un fichier, juste assez pour empêcher l'application de l'ouvrir. Étant donné que de nombreux fichiers sont déjà codés en binaire, pour l'utilisateur final, le fichier est effectivement inutilisable.
Il pourrait être intéressant de mentionner le cryptage complet du disque (mon employeur nous oblige à utiliser Symantec PGP) qui peut crypter votre disque pendant que vous l'utilisez, en utilisant (je suppose) la supercherie de pilotes. Cela dit, c'est un cryptage au niveau du lecteur, pas au niveau du fichier.
À de nombreuses fins, il pourrait même être suffisant de chiffrer les métadonnées du système de fichiers. Donc, le FAT-Table ou NTFS-Metadata dans Windows. Si je me dis qu'il serait assez difficile pour la plupart des utilisateurs de récupérer leurs fichiers, bien que le contenu des fichiers soit totalement intact.
Huit réponses:
Mike Ounsworth
2015-07-05 22:16:49 UTC
view on stackexchange narkive permalink

J'étais à une conférence OWASP où l'orateur a décompilé et analysé un exécutable de ransomware (pour Windows) devant nous. Il existe de nombreuses versions de ransomwares, donc je ne peux pas parler des ransomwares en général, mais je peux certainement parler de celui que j'ai vu. L'idée générale est que l'exécutable du ransomware contient la clé publique de chiffrement nécessaire pour chiffrer les fichiers à l'aide d'un algorithme asymétrique, par exemple RSA. La clé privée / de déchiffrement correspondante reste avec les pirates afin qu'aucune quantité de rétro-ingénierie de l'exécutable ne puisse vous donner la clé de déchiffrement.

Pour chiffrer réellement un fichier, il fait quelque chose de similaire à:

  1. Ignorez les 512 premiers octets du fichier afin que l'en-tête du fichier reste intact.

  2. Chiffrez le 1 Mo suivant à l'aide de la clé de chiffrement intégrée .

  3. Si le fichier est plus long, laissez le reste non chiffré.

Le but n'est pas de se cacher complètement ou protéger les données, il suffit de les rendre non analysables.

Quant au temps, faire 1 Mo de RSA est encore lent et prendra encore plusieurs heures pour explorer votre disque dur.

Je soupçonne que ce spécimen que j'ai vu n'était qu'une imitation paresseuse du ransomware RSA-AES complet dont Steffen Ullrich a parlé dans sa réponse - qui est celle que vous devriez être vraiment inquiet.

En raison de la lenteur de RSA, une clé aléatoire est généralement choisie, chiffrée avec RSA, puis cette clé aléatoire est utilisée pour exécuter un chiffrement de flux - souvent quelque chose comme AES / DES - qui est beaucoup plus rapide de plusieurs ordres de grandeur.
"Ignorez les 512 premiers octets du fichier pour que l'en-tête du fichier reste intact, c'est-à-dire que Windows peut toujours dire que c'est un pdf, un mp3, etc." - notez que Windows ne vérifie que l'extension, pas son contenu.
@user2064000 au sérieux? Windows est toujours aussi stupide? Je suis pur linux depuis 2006, j'aurais supposé que Windows avait résolu ce problème maintenant. Apprenez quelque chose tous les jours ...
@MikeOunsworth AFAIK, le noyau Linux ne se soucie pas non plus des en-têtes de fichiers.
@nanny De la page `man` pour la commande` file` ([lien] (http://linux.die.net/man/1/file)): "Le concept de“ magie ”a été appliqué par extension à fichiers de données. Tout fichier avec un identificateur invariant à un petit décalage fixe dans le fichier peut généralement être décrit de cette manière. " - Cela ressemble à un en-tête de fichier pour moi!
@nanny: C'est parce que le noyau Linux ne se soucie pas du tout des types de fichiers. En ce qui concerne le noyau, ce ne sont que des "fichiers". Il y a quelques exceptions (par exemple le shebang et d'autres éléments exécutables), mais sinon, les octets sont des octets. Maintenant, votre * GUI * peut afficher des types de fichiers, mais c'est à un niveau d'abstraction beaucoup plus élevé.
... et bien sûr ce n'est pas le * noyau * qui se soucie des shebangs et autres, mais le shell. Tout comme ce n'est pas Windows qui se soucie du débit de vos mp3, mais l'explorateur Windows.
C'est un peu hors sujet, mais il y a beaucoup de logiciels sous Linux qui examinent les extensions de fichiers et ne regardent pas les en-têtes de fichiers.
@jon En fait, le noyau Linux vérifie les premiers octets pour trouver l'interpréteur, voir https://coderwall.com/p/pdg77q/how-the-shebang-is-processed-by-the-linux-kernel
@Jon: En fait, [le noyau Unix * interprète * les shebangs] (https://en.wikipedia.org/wiki/Shebang_%28Unix%29#History).
Je suis corrigé - et assez confus quant à la raison pour laquelle ils pensent que faire cela dans le noyau est préférable. Merci pour la référence!
@Jon C'est une fonctionnalité qui permet aux fichiers texte d'être réellement exécutables, même en dehors du shell. Voir [execve (2)] (http://man7.org/linux/man-pages/man2/execve.2.html).
Avez-vous un lien vers la présentation de l'OWASP? Ou le nom du présentateur?
@ColBeseder Je ne pense pas que la conférence ait été enregistrée, mais voici un lien vers le résumé de la conférence et la biographie du conférencier (cliquez sur «tout voir» pour développer): http://www.meetup.com/OWASP-Ottawa/events/219842720/ ? a = uc1_vm & read = 1 & _af = événement & _af_eid = 219842720
Gerald Davis
2015-07-05 19:06:53 UTC
view on stackexchange narkive permalink

Le premier cryptage symétrique est assez rapide. AES dans certains modes est facilement de 200 Mo / s. Votre affirmation selon laquelle le hachage est lent est un hareng rouge. Le hachage est incroyablement rapide. Il est si rapide sur les processeurs modernes que cela affaiblit la sécurité efficace des hachages de mots de passe. Cela a conduit au développement de fonctions de dérivation de touches multi-tours pour "ralentir" le hachage.

La vitesse "lente" que vous voyez est principalement l'effet de votre disque dur lent. En mémoire, le hachage est de l'ordre de 500 Mo / s à 2 Go / s +.

Pourtant, le malware n'a pas besoin d'être "instantané". Le système de l'utilisateur est infecté en silence. Des copies des fichiers peuvent être cryptées sans alerter l'utilisateur, puis une fois prêts les originaux supprimés et l'utilisateur notifié "instantanément". L'ensemble du processus, de l'infection à ce stade, peut avoir pris un temps considérable, même s'il semble se produire instantanément.

Incidemment, il est également préférable que l'alerte se produise quelque temps après l'infection, de sorte que la victime ne puisse pas facilement savoir où / comment elle a été infectée.
Il y a une certaine confusion ici aussi, où l'OP confond le cryptage avec le hachage. Même s'ils partagent une théorie mathématique similaire, le hachage N'EST PAS du cryptage, et les deux ont des objectifs très différents. Pour cette raison, de nombreux algorithmes de hachage sont lents PAR DESIGN (pour ralentir les attaques par force brute), tandis que les algorithmes de chiffrement ont tendance à être rationalisés autant que possible sans compromettre la sécurité.
Il n'y avait aucune confusion. Je n'ai inclus les performances de hachage que parce que l'OP a signalé les performances de hachage et pensait que c'était lent et que le cryptage devrait donc être encore plus lent. La réalité est à la fois le cryptage symétrique et les algorithmes de hachage sont très rapides. Sur les messages longs, AES256 est d'environ 2 à 13 cycles par octet (selon le mode) et SHA-512 est de 8 cycles par octet. La plupart du «délai» lors du hachage ou du cryptage est dû au temps nécessaire pour lire les données à partir du disque. La cryptographie proprement dite est incroyablement rapide. Les KDF sont utilisés pour ralentir le hachage de mot de passe car les opérations de hachage sont très rapides.
Je ne voulais pas dire confusion de votre part - je pense que votre réponse est excellente. :-) Je voulais dire la confusion de la personne qui a posé la question. Il semble qu'ils puissent être confus s'ils utilisent les performances de hachage comme mesure des performances de chiffrement.
Les algorithmes de hachage d'@loneboat utilisés pour vérifier l'intégrité des fichiers visent à être aussi rapides que possible sans sacrifier la sécurité. It's Only les hachages de mots de passe sont délibérément lents, mais il n'y a aucune raison de les mentionner ici. Les hachages et le chiffrement symétrique ont des performances similaires et les deux sont généralement liés aux E / S. Étant donné que le hachage n'a besoin que de lire le fichier, mais que le chiffrement doit lire et écrire des données, le chiffrement devrait être environ deux fois plus cher dans ce contexte.
Un de mes amis a été touché par l'une de ces attaques. Ce n'était * pas * instantané. Il l'a remarqué assez tôt pour l'arrêter après avoir chiffré seulement environ la moitié de sa vaste bibliothèque musicale / vidéo. OP avait raison de dire que cela * prend * plusieurs heures pour faire de la magie. C'est le silence qui lui permet d'accomplir sa sale tâche.
Steffen Ullrich
2015-07-05 14:57:04 UTC
view on stackexchange narkive permalink

Le hachage (comme SHA-1, etc.) et le cryptage symétrique (comme AES) sont relativement bon marché, le cryptage asymétrique (comme RSA) est beaucoup plus cher. C'est pourquoi on n'utilise généralement pas RSA pour crypter un fichier volumineux, mais utilise plutôt une cryptographie symétrique avec une clé aléatoire et ne crypte cette clé courte qu'avec RSA.

Je le sais parce que j'utilise HashTab pour vérifier l'intégrité des fichiers que je télécharge sur Internet.

Cela me semble être une méthode très scientifique. À moins que vous n'ayez un processeur ancien et lent, la vitesse de hachage (et donc de vérification des données) est généralement plus rapide que vous ne pouvez lire les données du disque (au cas où cela ne serait pas évident: bien sûr, vous devez toujours lire les données pour les hacher. , mais cela passera plus de temps à attendre les données du disque qu'à calculer le hachage).

Comment un ransomware comme CTB-Locker ou Crypt0l0cker peut-il crypter instantanément les fichiers de leurs victimes?

Les systèmes d'exploitation modernes prennent en charge les systèmes de fichiers cryptés et avec les processeurs actuels (qui incluent souvent une accélération matérielle pour AES), vous ne remarquerez pas beaucoup de différence de vitesse si vous utilisez un système de fichiers crypté ou non, car le goulot d'étranglement est pas le cryptage mais la vitesse du disque (dans les benchmarks, vous verrez une baisse des performances mais cela ne reflète pas l'utilisation réelle pour la plupart des gens). Ainsi, il n'y a aucune raison pour laquelle les ransomwares ne pourraient pas non plus chiffrer les données rapidement. Bien sûr, ils peuvent le rendre plus rapide en se connectant au système afin que les fichiers que vous souhaitez ouvrir soient chiffrés en premier et le reste en arrière-plan.

Et la clé symétrique utilisée pour crypter les fichiers est alors supprimée? Cela signifie que vous pouvez récupérer la clé symétrique de la mémoire pendant le chiffrement, ou n'est-ce pas le cas?
@Michael: oui, vous devriez pouvoir récupérer la clé symétrique de la mémoire pendant le cryptage, bien qu'il existe probablement des moyens de rendre cela pas trop facile. Et vous pouvez bien sûr utiliser une clé différente pour chaque fichier afin de rendre plus difficile la récupération des données.
pas cher comme en rapide? cher comme lent? les fichiers sont donc cryptés symétriquement mais la clé est cryptée avec RSA. À quelle vitesse? cela ne me semble pas juste. Même sur un bon PC, j'ai besoin de 30 secondes pour calculer le MD5 d'un fichier.
Les données sont lues à partir du disque afin d'être alimentées vers la fonction, n'est-ce pas? comment le temps total peut-il être inférieur? ou vous faisiez référence au temps réel nécessaire pour traiter la chaîne / fichier en mémoire par la fonction de hachage / cryptage.
@Ulkoma: pas cher / cher comme dans les ressources, c'est-à-dire la mémoire, la puissance de traitement, etc. Et je n'ai jamais prétendu que le temps total était inférieur (que quoi?). Bien sûr, vous devez lire les données du disque pour les alimenter dans la fonction, mais l'essentiel est la lecture et non le calcul. Et concernant "J'ai besoin de 30 secondes pour calculer le MD5 pour un fichier." - quelle est la taille de votre fichier, quelle est la lenteur de votre disque, quelle est la vitesse de votre processeur ....? Si vous avez besoin de 30 secondes pour hacher un fichier de 1 octet, c'est probablement le temps dont votre système a besoin pour charger votre programme.
J'ai fait un test sur une vieille machine P4 exécutant Debian Linux. Il a fallu 0,23 seconde pour effectuer un hachage MD5 d'un fichier de 15 Mo.
@mti2935: oui, et en fonction de la "vitesse d'OpenSl", je peux faire environ 500 Mo / s SHA-1 sur un processeur mobile Intel I5 (i5-4200U). De cette façon dépasse la vitesse de mon disque.
Loren Pechtel
2015-07-06 03:19:38 UTC
view on stackexchange narkive permalink

L'erreur que vous faites est de penser que c'est instantané. Au lieu de cela, le malware se trouve là, crypter en arrière-plan et décrypter tout ce que l'utilisateur demande. Il est silencieux pendant cette phase, il ne demande la rançon qu'une fois que tout a été chiffré.

Freedo
2015-07-05 12:44:42 UTC
view on stackexchange narkive permalink

Selon wikipedia:

Lors de la première exécution, la charge utile s'installe dans le dossier du profil utilisateur et ajoute une clé au registre qui le fait s'exécuter au démarrage. Il tente ensuite de contacter l'un des nombreux serveurs de commande et de contrôle désignés; une fois connecté, le serveur génère une paire de clés RSA de 2048 bits et renvoie la clé publique à l'ordinateur infecté.

Ce n'est pas lent comme vous le pensez, si votre ordinateur est rapide et n'est pas n'utilisant pas trop le processeur au moment de l'infection, vous pourriez perdre des gigaoctets de données en moins de 15 minutes. Les PC modernes peuvent calculer le hachage et effectuer des opérations de cryptage plus rapidement que les disques durs / SSD ne peuvent fonctionner. Je dirais donc que la limite moderne de vitesse pour la vitesse de hachage / cryptage est davantage basée sur le disque lui-même. Je peux générer un hachage SHA-512 pour un fichier de 2,5 Go en 2 minutes.

Et le logiciel malveillant peut aussi attendre qu'il crypte tout ce qu'il veut avant d'afficher un message à l'utilisateur.

Si tel est le cas, pourquoi utilisons-nous des fonctions de hachage lentes pour comparer les fichiers et vérifier l'intégrité? Pourquoi ne pas simplement utiliser RSA? Je suis sûr que la sortie est unique pour chaque clé unique.
RSA n'est généralement pas utilisé pour crypter des données directement (peut-il crypter des données arbitrairement volumineuses?). Il est utilisé pour crypter la clé de cryptage symétrique.
Corey
2015-07-06 15:45:27 UTC
view on stackexchange narkive permalink

Le processus de base consiste à lire le contenu de votre fichier et à le réécrire sur le disque en utilisant une forme de cryptage asymétrique pour vous assurer que vous devez payer pour récupérer vos données. Certains ne crypteront que de petites sections des données pour améliorer la vitesse, d'autres réécriront l'intégralité de votre disque dur s'ils le peuvent. Comme certaines des autres réponses le notent, certains logiciels malveillants crypteront simplement une partie de votre fichier sur place pour accélérer le processus, car pour de nombreux formats de fichiers, même un léger changement dans le fichier rend l'ensemble du fichier inutilisable.

Comment les ransomwares comme CTB-Locker ou Crypt0l0cker peuvent-ils crypter instantanément les fichiers de leurs victimes?

Ils ne le peuvent pas. Au lieu de cela, ils dissimulent leur activité en faisant sembler que les fichiers sont OK jusqu'à ce que le processus soit terminé. En interceptant les appels du système de fichiers, vous pouvez modifier la vue de l'utilisateur de ce qui est réellement présent sur le disque, ce qui donne l'impression que tout est toujours OK jusqu'à ce que vous ayez terminé, puis lorsque vous supprimez les interceptions, l'utilisateur peut voir le véritable état du lecteur . Le danger en faisant cela est que vous devez avoir les deux parties de votre paire de clés asymétriques afin de décrypter les fichiers à la volée lorsque l'utilisateur en ouvre une, ce qui signifie en principe que quelque chose pourrait trouver la clé privée que vous souhaitez vendre l'utilisateur plus tard.

D'autres logiciels malveillants comme CryptoWall (avec lesquels j'ai eu plus d'expérience récemment que je ne veux m'en souvenir) ne prennent pas la peine de se cacher, ils s'enflamment en chiffrant tout aussi rapidement que possible ... et c'est à peu près limité par la vitesse d'E / S du disque sur lequel il crypte.

En regardant quelques benchmarks pour AES - qui est l'algorithme de cryptage que CryptoWall prétend utiliser - un processeur moderne modeste peut crypter les données à des débits bien supérieurs à 100 Mo / s, ce qui signifie que l'opération est susceptible d'être liée aux E / S sur autre chose qu'un SSD. Ajoutez plusieurs threads s'exécutant sur des cœurs de processeur distincts ciblant différents dossiers et / ou lecteurs et le processus peut se terminer assez rapidement.

J'ai récemment dû nettoyer un serveur de fichiers qui avait été traité par CryptoWall fonctionnant sur l'un des PC des utilisateurs. Au moment où les utilisateurs ont remarqué que quelque chose n'allait pas, le malware fonctionnait depuis environ 1,75 heure. Nous avons retiré la chose du réseau à un peu moins de 2 heures et pendant le nettoyage, j'ai trouvé environ 230 Go de fichiers cryptés. C'est une moyenne de chiffrement d'environ 30 Mo / s, ce qui est certainement faisable dans l'environnement. Il a fallu environ 3 fois plus de temps pour restaurer les fichiers de la sauvegarde précédente. Bien que j'aie quelques idées sur la façon d'accélérer cela la prochaine fois, la plupart des clients ont leurs sauvegardes sur des NAS de merde à bas prix ou ( frissonner ) sur des clés USB.

Malheureusement, nous sommes peu probables pour voir une fin à tout moment à ces choses. Une solution de sauvegarde compétente et correctement configurée est votre meilleur ami lorsque l'une de ces choses se produit. Cela ne fait pas de mal d'avoir un programmeur à portée de main pour programmer la restauration.

Boluc Papuccuoglu
2015-07-05 18:03:54 UTC
view on stackexchange narkive permalink

Du point de vue de l'ingénierie sociale, l'auteur du malware aurait pu écrire un programme qui remplaçait le contenu des données par des bits aléatoires. La victime n'aurait aucun moyen de vérifier si le contenu était chiffré ou simplement mis à la poubelle. S'ils décident de payer la rançon et que la «clé» ne fonctionne pas, ils ne peuvent pas faire grand-chose, les gars sont des criminels après tout.

C'est exactement ce que je soupçonne
S'ils le faisaient, ils nuiraient à leur propre modèle d'entreprise. Si suffisamment de personnes déclarent ne pas avoir récupéré leur argent, d'autres ne paieront pas. Pour tirer le meilleur parti de ces affaires louches, les victimes ont le plus confiance dans le fait qu'elles récupèrent leurs données et ces informations doivent se répandre afin que d'autres paient aussi. Et en fait, il y a suffisamment de rapports pour que l'on récupère ses données.
Le goulot d'étranglement est les E / S du disque, et l'écriture de bits aléatoires réduit de moitié le temps car elle ne nécessite pas de lecture à partir du disque. Ce n'est probablement pas très important pour un malware.
Mon sentiment est qu'il existe des auteurs de rançongiciels cryptographiques qui travaillent sur un modèle commercial durable, comme Evgeniy Bogachev. Mais il semble inévitable qu'il y en ait pour gagner rapidement de l'argent sans avoir à gérer des clés de chiffrement symétriques, des bases de données de clés, etc.
@SteffenUllrich: Il est bien connu que les pirates de l'air coupent la gorge de votre femme ou de votre enfant au moment où vous les payez (ils n'en ont plus besoin, et ils pourraient éventuellement identifier les pirates de l'air). Pourtant, presque tout le monde paiera.
@Damon: Je doute que cela soit bien connu et je doute même que ce soit vrai. Je dirais que la plupart des victimes de vols continuent de vivre.
Ángel
2015-07-06 16:33:24 UTC
view on stackexchange narkive permalink

Certaines rançons telles que TorrentLocker chiffrent uniquement le premier Mo (en plus d'ajouter un suivi). Cela suffit pour que la plupart des formats ne soient pas reconnus, mais en même temps, cela rend beaucoup plus rapide le cryptage d'un grand nombre de fichiers (rappelez-vous également que seuls certains types de fichiers sont cryptés, comme les documents, les photos…).

Cela a été rapporté par Nixu dans le blog SANS, ainsi que sur ( livre blanc ESET), bien qu'ils aient rapporté 2 Mo.

Et, comme Loren l'a mentionné , le ransomware n'affiche la grande bannière demandant la rançon qu'après que tout a été crypté (il n'est pas bon que vous vous rendiez compte que seuls quelques fichiers ont été «retenus»), bien que certains ransomwares placent pendant qu'ils vont un fichier exigeant un ransomware sur chaque dossier / pour chaque fichier qu'ils ont chiffré.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...