Un guet-apens pour les logiciels malveillants

Je n’ai pas vu le sixième volet de la saga Mission Impossible et je ne pense pas le voir un jour. J’ai enduré le cinquième jusqu’au bout, dans un état absolument zombifié, de retour chez moi après un vol long-courrier et une semaine difficile, uniquement parce qu’une scène a été tournée dans notre tout nouveau bureau moderne à Londres. Et c’était un Mission Impossible de trop, vraiment. Non, ce n’est pas pour moi. Slap, bang, smash, crash, pow, wow. Non, je préfère quelque chose d’un peu plus stimulant, qui fasse réfléchir et qui soit tout simplement intéressant. Après tout, j’ai déjà très peu de temps à perdre !

Je suis vraiment en train de manquer de respect à Tom Cruise et compagnie, n’est-ce pas ? Mais attendez un peu. Je dois leur donner ce qu’ils méritent pour au moins une scène assez bien faite (c’est-à-dire, qui fasse réfléchir et qui soit tout simplement intéressante !). Celle où les gentils ont besoin d’un méchant pour dénoncer leurs collègues méchants, ou quelque chose comme ça. Ils ont donc mis en place un faux environnement dans un « hôpital » avec « CNN » sur la « télévision » diffusant un reportage sur l’Armageddon atomique. Tout à fait satisfait que son manifeste apocalyptique ait été diffusé dans le monde entier, le méchant abandonne ses copains (ou était-ce un code d’accès ?) après avoir passé un accord avec ses interrogateurs. Oups. Voilà la vidéo.

Pourquoi est-ce que j’aime tant cette scène ? Parce qu’en fait, elle explique très bien l’une des méthodes de détection… de cybermenaces jamais vues auparavant ! Il existe en fait de nombreuses méthodes de ce type, elles varient selon le domaine d’application, l’efficacité, l’utilisation des ressources et d’autres paramètres (j’en parle régulièrement ici). Mais il y en a toujours une qui semble se démarquer : l’émulation (sur laquelle j’ai également beaucoup écrit ici avant).

Comme dans le film Mission Impossible, un émulateur lance l’objet étudié dans un environnement artificiel isolé, ce qui le pousse à révéler sa malveillance.

 

Mais cette approche présente un inconvénient sérieux : l’environnement est artificiel. L’émulateur fait de son mieux pour que cet environnement artificiel ressemble autant que faire se peut à un environnement de système d’exploitation réel, mais de plus en plus de logiciels malveillants intelligents parviennent toujours à le distinguer de la réalité. L’émulateur voit alors comment le logiciel malveillant l’a reconnu, le regroupe et améliore son émulation, et ainsi de suite dans un cycle sans fin qui ouvre régulièrement une fenêtre de vulnérabilité sur un ordinateur protégé. Le problème fondamental est qu’aucun émulateur n’a encore été le portrait craché d’un vrai système d’exploitation.

D’autre part, il existe une autre technique d’approche de l’analyse comportementale des objets suspects : l’analyse sur une machine virtuelle, sur un système d’exploitation réel. Et pourquoi pas ? Si l’émulateur n’y met jamais un terme, laissez une machine réelle, quoique virtuelle, essayer ! Ce serait l' »interrogatoire » idéal, mené dans un environnement réel et non pas artificiel, mais sans conséquences négatives réelles.

En entendant parler de ce concept, certains pourraient se précipiter et demander pourquoi personne n’y avait pensé avant. Après tout, la virtualisation fait partie des tendances dominantes en matière de technologies depuis 1992. Eh bien, il s’avère que ce n’est pas si simple.

Tout d’abord, l’analyse d’objets suspects dans une machine virtuelle est un processus qui exige beaucoup de ressources, seulement compatibles avec les solutions de sécurité de très grandes entreprises, où l’analyse doit être faite de façon intensive afin qu’absolument aucune malveillance ne passe à travers les défenses. Hélas, pour les ordinateurs personnels, sans parler des smartphones, cette technologie n’est pas encore adaptée.

Deuxièmement, de telles choses existent en réalité. En fait, nous utilisons déjà cette technologie, en interne, ici à la Kompany, pour des enquêtes internes. Mais en matière de produits prêts à être commercialisés, il n’y en a encore que très peu qui soient disponibles. Nos concurrents ont lancé des produits similaires, mais leur efficacité laisse à désirer. En règle générale, ces produits sont limités à la collecte de registres et aux analyses de base.

Troisièmement, le lancement d’un fichier sur une machine virtuelle n’est que le début d’un processus très long et délicat. Après tout, le but de l’exercice est de faire apparaître la malice d’un objet, et pour cela vous avez besoin d’un hyperviseur intelligent, d’une journalisation et d’une analyse du comportement, d’un ajustement constant des modèles d’actions dangereuses, d’une protection contre les astuces anti-émulation, d’une optimisation d’exécution et bien plus.

Je peux dire sans fausse modestie que nous sommes vraiment en avance sur la planète entière !

Nous avons récemment obtenu un brevet américain (US1033339301) pour la création d’un environnement approprié pour une machine virtuelle permettant une analyse rapide et approfondie des objets suspects. Voici comment cela fonctionne :

  • Des machines virtuelles sont créées (pour différents types d’objets) avec des paramètres qui assurent à la fois leur exécution optimale et un taux de détection maximal.
  • L’hyperviseur d’une machine virtuelle fonctionne en tandem avec l’enregistrement du système du comportement d’un objet et son analyse système, aidé par des bases de données actualisables de modèles de comportements suspects, l’heuristique, la logique des réactions aux actions et plus.
  • Si des actions suspectes sont détectées, le système d’analyse introduit rapidement des modifications dans le processus d’exécution de l’objet sur une machine virtuelle pour l’encourager à montrer ses intentions malveillantes. Par exemple, le système peut créer des fichiers, modifier le registre, accélérer le temps, etc.

Ce dernier point est la caractéristique la plus unique et la plus remarquable de notre technologie. Permettez-moi de vous donner un exemple pour vous montrer comment cela fonctionne.

Le système détecte qu’un fichier s’est « endormi » à son lancement et ne manifeste plus aucun signe d’activité. C’est parce que l’objet peut être programmé pour ne rien faire tranquillement pendant plusieurs (dizaines) minutes (heures) jusqu’au début de l’activité malveillante. Lorsqu’il commence à ne plus rien faire, nous accélérons le temps à l’intérieur de la machine virtuelle pour qu’elle passe une, trois, cinq et jusqu’à plus d’un million de minutes par seconde. La fonctionnalité du fichier analysé ne change pas, tandis que le temps d’attente est réduit de centaines (ou de milliers) de fois. Et si, après son « somme », le logiciel malveillant décide de vérifier l’horloge du système (a-t-elle fait tic-tac ?), il se laissera berner en pensant qu’elle l’a fait et poursuivra sa mission malveillante, s’exposant ainsi en passant à l’action.

Un autre exemple :

L’objet utilise une vulnérabilité dans une bibliothèque en particulier ou tente de modifier le contenu d’un fichier ou d’un registre. Au début, à l’aide de la fonction fopen(), il essaie d’ouvrir la bibliothèque (ou le fichier ou le registre), et s’il n’y arrive pas (il n’y a pas de bibliothèque, ou aucun droit d’accès au fichier), alors il abandonne. Dans un tel scénario, nous changeons (rapidement) la valeur de retour de la fonction fopen() de « fichier absent » à « fichier existant » (ou, si nécessaire, nous créons le fichier lui-même et le remplissons de contenu approprié), puis nous observons simplement comment l’objet se comporte.

Une telle approche fonctionne également très bien dans des conditions d’arbres logiques du comportement d’un objet. Par exemple : s’il existe un fichier A et un fichier B, alors le fichier C est modifié et le travail terminé. Cependant, nous ne savons pas ce que fera le programme analysé s’il n’existe qu’un seul fichier A ou un seul fichier B. Par conséquent, nous lançons une itération en parallèle et disons au programme suspect que le fichier A existe mais pas le B, puis nous analysons plus profondément l’activité de l’arbre logique.

Il est important de noter que les règles de réaction à l’exécution du fichier sont configurées par des bases de données externes qu’il est facile de mettre à jour. Vous n’avez pas besoin de redévelopper le moteur entier pour ajouter une nouvelle logique ; il suffit de décrire correctement la multitude de scénarios possibles de comportements malveillants et d’effectuer une mise à jour en un clic.

Et c’est ainsi, en un mot, que fonctionne cette technologie. Elle sera bientôt ajoutée à KATA, et également distribuée sur le marché comme solution autonome pour les entreprises, Kaspersky Sandbox.

LIRE LES COMMENTAIRES 0
Laisser un commentaire