Retrouvez cet article dans : Misc 20

Le virus Whale qui a été présenté dans le numéro précédent était le premier virus connu à mettre en œuvre des techniques de blindage, c'est-à-dire des techniques destinées à retarder ou empêcher l'analyse du code binaire. Mais Whale, de manière peu efficace, n'était parvenu qu'à retarder cette analyse. Dans cet article, nous présentons une technique de blindage qui permet d'interdire non seulement la mise à jour des antivirus mais également de déterminer les actions qu'un code malveillant a pu commettre dans un système. Par l'utilisation de chiffrement d'un haut niveau de sécurité et une technique de gestion de clef appropriée, il est possible de réaliser un blindage total et efficace.

Introduction

La lutte antivirale repose entièrement sur la capacité de disposer d'une copie de chaque code malicieux et celle de pouvoir l'étudier. En général, il s'agit de désassembler/débugger le binaire correspondant. Ce travail permet alors de mettre à jour les différents moteurs de chaque antivirus, grâce aux connaissances que l'analyse du code a permis d'acquérir. Comme cela a été présenté dans le numéro précédent avec le virus Whale [2], certains auteurs de virus ont vite compris l'utilité de mettre en œuvre des techniques permettant de contrarier voire d’interdire une telle analyse. Si le virus Whale eut un effet très limité, il atteignit cet objectif dans la mesure où son analyse nécessita plus d'une semaine. De nos jours, le moindre ver informatique se propage, au niveau mondial, en une quinzaine de minutes, pour les vers simples de type Slammer ou en une poignée d'heure pour un simple ver de courrier électronique de type MyDoom. Avec ces ordres de grandeur, il serait inimaginable de devoir attendre ne serait-ce que quelques jours pour disposer d'antivirus mis à jour. C'est la raison pour laquelle les techniques de blindage sont à prendre très au sérieux, même si par chance aucune attaque réelle utilisant du blindage efficace n'est connue à ce jour 1. Les techniques de blindage rencontrées jusqu'à présent (voir l'analyse du virus Whale) utilisent, en général, des techniques qui s'apparentent directement ou indirectement aux techniques de la cryptologie :

• l'obfuscation de code (cf. [4] dans ce même dossier).

Le but est de transformer le code d'un programme en un autre code fonctionnellement identique mais rendu plus difficile à décompiler et à analyser (en réduisant la lisibilité par exemple). Trois classes de techniques sont connues : les transformations lexicales (changement de noms de variables par exemple), les transformations de contrôle de flux (utilisation de code placebo, d'enchevêtrement de code...) et les transformations des flux de données (modification des structures de données, codage, agrégation...) Ces techniques ont une efficacité limitée en virologie (voir bibliographie de [3]) ;

• le polymorphisme par réécriture de code (voir [4]).

Le but est de faire varier le code le plus souvent possible mais sans changer ses caractéristiques statistiques ou son entropie ; notons que dans ce cas comme dans le cas précédent, il est possible de considérer que l'on " chiffre du clair par du clair " ;

• le polymorphisme par chiffrement (cf. [1] dans ce dossier).

Il s'agit là d'assurer le polymorphisme en chiffrant le code (la forme change avec chaque clef) et de compliquer l'analyse. Mais les techniques rencontrées à ce jour souffre d'un grave défaut dans la mesure où la gestion des clefs est (heureusement) très mauvaise. Ces dernières sont toujours contenues dans la partie non chiffrée du code malicieux et sont donc relativement facilement disponibles pour l'analyste qui opérera alors un simple déchiffrement. Toutes les techniques de blindage connues actuellement ont eu une efficacité limitée sur les virus. En effet :

• Tout d'abord parce que les analystes de virus parviennent toujours à disposer d'une copie d'un code binaire (fichier infecté) à analyser. Cela tient à la virulence très élevée des codes malicieux actuels, lesquels circulent en de multiples copies. Dans le cadre d'attaques ciblées (voir note 1), cette facilité est plus discutable voire totalement illusoire.
• Les techniques de blindage proprement dites relèvent toutes de classes de problèmes (ceux qu'il faut résoudre pour contourner ces techniques) de complexité polynomiale. Par exemple, soit les systèmes de chiffrement sont faibles soit l'espace clef est trop restreint et permet une approche exhaustive. Le plus souvent, la gestion des clefs est si catastrophique que le problème initial de cryptanalyse du code devient un simple problème de décodage.

Dans cet article (voir [3] pour la référence originale et détaillée), nous montrons comment le risque de blindage viral total et efficace peut se concrétiser au travers d'une attaque virale ciblée. En utilisant un système de chiffrement de haut niveau de sécurité et une gestion environnementale des clefs de chiffrement, il est possible d'interdire effectivement toute analyse du code malicieux  2.

La gestion environnementale des clefs

En 1998, B. Schneier et J. Riordan [5] ont introduit la notion de " gestion environnementale " des clefs cryptographiques. Tout agent logiciel ou matériel mobile évoluant dans un milieu hostile ne peut contenir des clefs statiques sous peine de les voir compromises par analyse de cet agent, en cas de capture. En d'autres termes, ils ont imaginé des protocoles permettant de construire, par l'agent, la clef à partir de données issues de son environnement, uniquement quand ces clefs sont nécessaires à son action et dont la validité est limitée à la durée de l'action elle-même. L'agent évolue de plus en aveugle car il ignore en permanence quand les clefs sont disponibles (autrement dit quand l'environnement est propice à leur génération). Le modèle décrivant ce type de gestion de clefs suppose également que tout attaquant (dans notre cas, l'analyste qui étudie le code malveillant) peut avoir un contrôle total sur l'environnement immédiat dans lequel évolue l'agent. L'attaquant peut leurrer ce dernier et lui fournir toutes les données qu'il souhaite (attaque par dictionnaire par exemple) afin de deviner lesquelles interviennent dans l'élaboration des clefs utilisées par l'agent. Les auteurs ont proposé plusieurs constructions pour ce type de protocole. Présentons-en, quelques-unes des plus basiques. Soient N un entier représentant une observation de l'environnement, H une fonction de hachage, une valeur M = H(N), R une valeur aléatoire, et K une clef cryptologique. La valeur M est transportée par l'agent (et donc accessible à tout attaquant). Alors, entre autres constructions possibles (voir [3] ou [5] pour plus de détails), nous avons : si H(N) = M$ alors K = N, si H(H(N)) = M$ alors K = H(N). Le lecteur remarquera que le premier mécanisme est celui utilisé pour la protection des mots de passe. Nous allons voir maintenant comment ce type de mécanisme peut être utilisé dans le cadre du blindage viral.

Les codes Bradley

Les codes Bradley modélisent des attaques ciblées (virulence limitée et contrôlée des codes), et mettent en œuvre un blindage total.

Description générale

La version que nous détaillons comporte deux variantes principales :

• Un code viral générique ayant pour cible un groupe limité de quelques centaines de cibles (utilisateurs/machines) (variante A).
• Un code viral attaquant de manière très ciblée quelques utilisateurs seulement (variante B).

Figure 1 : Structure générale des codes Bradley.

La structure générale des codes Bradley est indiquée sur la figure 1 et se résume comme suit : 1 Rappelons toutefois qu'en matière d'attaque virale, et plus généralement informatique, on ne peut parler que de ce qui a été détecté et identifié. Qui sait si certaines ne sont pas restées " invisibles ".

• Une procédure de déchiffrement D a pour fonction de collecter les données environnementales d'activation, de les tester et le cas échéant de procéder au déchiffrement des différentes parties du code.
• Une première partie de code EVP1 chiffrée avec une clef K1. Une fois déchiffrée, cette partie du code installe toutes les fonctionnalités, actives et passives, de lutte anti-antivirale.
• Une deuxième partie de code EVP2 chiffrée avec une clef K2. Cette partie contient les procédures d'infection proprement dites et de polymorphisme/métamorphisme 3. Le code se propage sous une forme à chaque fois différente (procédure D incluse).
• Une troisième partie EVP3 (optionnelle) contenant la ou les charges finales. Cette partie est chiffrée avec une clef K3.

La gestion de clef dans Bradley

La procédure D doit récupérer, dans l'environnement du code, des données d'activation pour construire la clef qui lui permettra de déchiffrer, dans un premier temps, la partie EVP1. Ces données, dans le cas de la variante A, sont : 2 Les aspects techniques spécifiquement viraux (polymorphisme, métamorphisme, furtivité) ne seront pas présentés ici, ces aspects-là n'étant pas utiles pour la compréhension du blindage lui-même. 3 Rappelons que le polymorphisme consiste à faire varier constamment le code d'un programme alors que le métamorphisme fait varier non seulement le code mais également les méthodes de variation du code.

• L'adresse DNS locale de la machine cible (par exemple ma-compagny.com ; nous la noterons α ;
• l'heure (hh seulement) et la date (mmdd) système ; cette donnée est notée δ ;
• Une donnée particulière, notée ι, supposée être présente dans toute machine éligible pour l'attaque (dans notre cas, la présence d'un fichier particulier) ;
• une donnée spécifique, π sous le contrôle exclusif de l'auteur du code viral (celui qui lance l'attaque), disponible à l'extérieur du système (canal public) mais accessible au virus (dans notre cas, une page web contenant une donnée particulière dont la présence dans la page est limitée dans le temps et en relation avec la valeur δ). La valeur π est obtenue par hachage de l'information d'activation (le hash de la page web, en l'occurrence) 4.

Pour la variante B, la donnée ι est une certaine clef publique présente dans un fichier pubring.gpg (par exemple). Ainsi, cette version ciblera un utilisateur particulier, utilisant cette clef, ainsi que tous les utilisateurs communiquant avec lui. Décrivons le protocole de génération de clef :

• La procédure D collecte les données d'activation (valeurs α, δ, ι et π). Elle calcule ensuite une valeur V de 160 bits (dans le reste du texte, le signe + désigne l'addition modulo 2, bit à bit) :

V = H(α + δ + ι + π) + ν) La valeur ν désigne les 512 premiers bits de la partie chiffrée EVP1.

• Si V = M (M est la valeur d'activation détenue par l'agent) alors

K1 = H(α + δ + ι + π) sinon la procédure D s'arrête et désinfecte totalement et de manière sécurisée le système du code viral (processus d'auto-désinfection destiné à minimiser le temps de présence du virus dans la machine).

• D déchiffre ensuite EVP1, produisant

VP1 = DK1(EVP1) et ensuite l'exécute. Ensuite, D calcule la clef K2 comme suit : K2 = H(K1 + ν2) où ν2 désigne les 512 derniers bits de VP1.

• D déchiffre ensuite EVP2, produisant

VP2 = DK2(EVP2) et l'exécute. La clef K3 est ensuite calculée : K3 = H(K1 + K3 + ν3) où ν3 désigne les 512 derniers bits de VP2. D déchiffre EVP3 produisant VP3 = DK3(EVP3) et l'exécute.

• Une fois, l'action du code viral terminée, le virus s'auto-désinfecte de la machine.

Quelques remarques peuvent être faites au sujet de ce protocole et de ces deux variantes présentées :

• De copie en copie (mécanisme de duplication assuré par une partie du code contenue dans VP2), la totalité du code a complètement été changée (mais reste fonctionnellement identique). Cela concerne également la procédure D et la valeur M. Le polymorphisme/métamorphisme est conditionné par le protocole de gestion de clef (en pratique, par l'intermédiaire des valeurs δ et π).
• Le rôle des valeurs ν et νi est de s'assurer que les valeurs d'entrée de la fonction de hachage décrivent le plus possible l'espace de définition de la fonction. Le but est d'éviter que l'attaquant puisse réduire le champ des possibilités dans le cadre d'une cryptanalyse de cette fonction (essais exhaustifs par exemple).
• les clefs Ki peuvent être rendues indépendantes les unes des autres en considérant des données environnementales supplémentaires.

Analyse théorique

Pour évaluer la complexité de l'analyse d'un code de type Bradley, deux situations doivent d'abord être considérées :

• L'analyste n'a pas de copie du code. Le problème de l'analyse ne se pose même pas. Le code a agi sans qu'aucun système de détection ne le repère (la détection interviendra éventuellement pour un virus ou un ver programmé de manière trop classique ou malhabile).
• L'analyste dispose d'une copie du code binaire. Cette hypothèse est très improbable dans le cas de codes de type Bradley. En effet, le code viral limite au maximum sa présence dans la machine, sa virulence est très fortement limitée. Enfin, les IDS et autres antivirus restent muets.

4 Le lecteur pourrait objecter que la présence dans la procédure D d'une URL de page web est susceptible de fournir une information utile à l'analyste. Mais ce n'est pas le cas. La page web étant sous le contrôle de l'attaquant et la gestion limitée dans le temps de la donnée d'activation dans la page, la connaissance de l'URL par l'analyste ne remet pas en cause le modèle proposé. En revanche, la présence de cette URL pose un problème d'anonymisation non pris en compte ici. Bien que ce dernier cas soit fortement improbable, supposons malgré tout que l'analyste dispose d'une copie du code viral. Il a été démontré dans [3] que l'analyse de ce code est en fait un problème de complexité exponentielle. La démonstration ne sera pas donnée ici mais indiquons quelques chiffres qui aideront le lecteur à se faire une idée de la difficulté du problème. Dans le cas des deux variantes présentées dans cet article, l'effort de cryptanalyse requiert min(2n, 2((n2 - m)/2)) = 2n opérations, pour des fonctions de hachage de type (n, m) (n bits en entrée, m bits en sortie). Dans notre cas, cela équivaut à 2512 opérations au minimum.

Conclusion

Les codes Bradley démontrent que le blindage total est une chose opérationnellement réalisable, en particulier dans le cadre d'attaques virales ciblées, dans lesquelles la virulence des codes utilisés est maîtrisée. À l'heure actuelle, il semble ne pas y avoir de solutions techniques au problème que posent des codes de ce type. À moins de disposer d'un réseau mondial de pots de miel pour tenter d'anticiper et de gérer en direct de telles attaques, il n'y a pas d'autres moyens de contrer de tels codes, l'approche cryptanalytique étant hors de portée. L'existence de tels codes et la possibilité d'attaques ciblées (contre des entreprises sensibles, des administrations, des personnes...) montrent encore une fois que la solution n'est pas technique. Ces codes illustrent le fait qu'un antivirus peut toujours être contourné : en amont par l'absence de détection face à un code innovant et en aval avec un blindage viral efficace qui non seulement interdit toute mise à jour mais également de déterminer éventuellement l'origine de l'attaque et la nature des actions offensives. Cela illustre encore une fois les risques du " tout connecté ". À ce titre, l'attaque par le ver Slammer des réseaux d'une centrale nucléaire américaine, connectés sur Internet (janvier 2003) est particulièrement parlante. Les réseaux les plus sensibles doivent rester hermétiquement isolés. Cela suppose en outre une politique de sécurité drastique pour interdire l'import incontrôlé de données extérieures et les connexions avec de l'informatique mobile. Cette politique de sécurité doit faire l'objet de contrôles fréquents et impliquer des sanctions pour les personnels qui ne l'auraient pas respectée. C'est le prix à payer pour avoir une sécurité adaptée face à des codes de type Bradley. Références

•  [1] BRULEZ, N. et RAYNAL, F., " Le polymorphisme viral : quand les opcodes se mettent à la chirurgie esthétique ", Journal de la sécurité informatique MISC 20, juillet 2005.
• [2] FILIOL, E, " Whale : le virus se rebiffe ", Journal de la sécurité informatique MISC 19, mai 2005.
• [3] FILIOL, E. " Strong Cryptography Armoured Computer Viruses Forbidding Code Analysis: the “ Bradley” virus ", in Proceedings of the 14th EICAR Conference, Malte, Mai 2005. Disponible sur : http://papers.weburb.dk/archive/00000136/
• [4] JOSSE, S. " Techniques d'obfuscation de codes : chiffrer du clair avec du clair ", Journal de la sécurité informatique MISC 20, juillet 2005.
• [5] RIORDAN J. et SCHNEIER B, " Environmental key generation towards clueless agents ", Mobile Agents and Security Conference'98, Lecture Notes in Computer Science, pp. 15-24, Springer-Verlag, 1998.

  Retrouvez cet article dans : Misc 20