La sécurité des clés USB

1. Les faits

Aujourd'hui, quand vous achetez une clé USB, vous n'achetez plus seulement un bout de silicium capable de transporter des données. Les clés sont de plus en plus complètes, et afin de rivaliser avec les concurrents, les fabricants ne cessent de trouver de nouvelles idées afin de faire vendre leurs produits : par exemple, les clés qui savent lire les MP3/WMA, celles avec une diode blanche qui sert de lampe-torche ou encore celles que l'on peut protéger par mot de passe. Certaines d'entre elles proposent également des logiciels gratuits permettant de gérer les images ou la musique. Tous ces outils suivent bien la tendance actuelle dans le monde de l'informatique grand public qui veut que tout fonctionne seul, et ce, le plus simplement possible (et parfois au détriment de la sécurité, comme nous l'avons déjà vu et que nous allons encore le voir).

Afin de combler le confort que l'utilisateur réclame, il est de plus en plus courant de voir disparaître les CD de pilotes fournis avec les clés USB. En effet, la plupart du temps, les pilotes sont intégrés à Windows, ce qui justifie réellement l'utilité du fameux Plug & Play (sauf pour les systèmes les plus anciens comme Windows 98). Mais les logiciels nécessaires au fonctionnement des différents services proposés ne sont pas forcément intégrés au système d'exploitation. Il faut donc arriver à les stocker quelque part.

Une solution plausible : Internet. Mais, l'utilisateur moyen ne se verra pas aller sur Internet afin de trouver puis télécharger les logiciels de sa clé USB. Non, il fallait autre chose qui permette à l'utilisateur d'avoir le CD de pilotes, mais sans avoir à le transporter...

Et c'est là que nos constructeurs ont eu une idée de génie : intégrer le CD à la clé ! La solution adoptée est donc de faire installer un lecteur CD virtuel en même temps que la clé de stockage, qui propose à l'utilisateur les outils dont il a besoin. Évidemment, le principe du lecteur CD virtuel a trois avantages :

- Pas besoin de s'encombrer d'un CD : tout est déjà dans la clé ;

- L'utilisateur ne risque pas d'effacer le CD, et donc de perdre accidentellement les pilotes ;

- En branchant la clé dans son ordinateur, et grâce au fichier autorun.inf, le pilote peut démarrer son installation automatiquement, évitant ainsi à l'utilisateur d'avoir à le faire à la main.

L'idée semblait être bonne, mais les fabricants ont, sans le vouloir, mis à disposition des pirates un excellent moyen de propager des virus ou des moyens de vols de données.

2. Les explications

2.1 Petit tour d'horizon sous Windows

Prenons par exemple une clé de marque Memup Pop Key [1], les clés avec le bouchon rétractable. Ces clés, que l'on trouve en hypermarché à partir de 5 €, proposent à l'utilisateur de créer une partie de la clé publique (accessible dès l'insertion de la clé) et une autre partie de la clé « privée » (accessible uniquement après avoir entré un mot de passe). Le logiciel capable de configurer la clé et gérer l'accès à la partie privée se trouve dans un lecteur CD virtuel :

La lettre G contient ici le lecteur CD virtuel de la clé, et la partie stockage de la clé est accessible à la lettre H. Si nous regardons le contenu du lecteur CD, nous y trouvons le manuel en PDF et en plusieurs langues, et le petit programme capable de donner accès à la partie privée de la clé :

Enfin, les propriétés du lecteur CD en question ne nous apprennent rien de très intéressant, seulement que c'est un système de fichiers CDFS, et qu'il utilise 2,01 Mo de place. Le fichier Autorun.inf est configuré de sorte à donner au CD l'icône Memup et le nom « Pop key » (et ça fonctionne bien).

Rien d'intéressant à première vue sous Windows. Passons à Linux.

2.2 Analyse sous Linux

Le système avec lequel ces tests ont été réalisés est une distribution à base de noyau Linux 2.6.18. Il faut préciser que la seule nécessité est d'utiliser le module du noyau « Low Performance USB Block driver » (/dev/ub*) et non le « USB Mass Storage support » (/dev/sd*), car ce dernier ne fonctionne pas avec les manipulations décrites ci-après.

Branchons la clé. Notre cher ami udev nous a créé quelques fichiers pour l'occasion :

Le périphérique ubb semble contenir les informations de la clé (à cause de la partition ubb1), tandis que uba semble contenir le lecteur CD. Vérifions-le en le montant dans un répertoire temporaire :

Après avoir démonté le répertoire, nous allons faire quelques tests sur la clé, avec l'outil dd :

Cette commande nous a permis de récupérer le contenu complet et exact, octet par octet, du périphérique /dev/uba. Nous nous retrouvons donc avec un fichier popkey.iso faisant environ 5,5 Mo (11264*512 octets), contenant l'ISO de la clé. Nous le vérifions simplement en montant le fichier en loopback :

Nous avons donc copié le contenu du CD sur le disque dur. Essayons maintenant de faire l'inverse :

Tiens donc ! Il semblerait que ça n'a dérangé personne... En effet, si on rebranche la clé sous Windows, le contenu de la clé est toujours accessible. Testons à présent autre chose : nous allons créer une nouvelle ISO contenant un simple fichier texte, et l'écrire dans la clé :

Sans surprise, l'écriture semble avoir réussi ici aussi. Maintenant, retournons sous Windows, et observons ce qu'il en est :

Eh oui, sous vos yeux ébahis, nous venons bel et bien de modifier la structure du lecteur CD virtuel de notre clé USB.

3. Les possibilités

Le fait de pouvoir modifier l'image du lecteur CD de notre clé pourrait sembler assez peu utile, voire passer pour un de ces « trucs de geek » aux yeux du grand public. Et pourtant, un gros problème se pose en réalité : le fichier autorun.inf, contenu dans ce CD, est modifiable, donc la possibilité de faire exécuter un fichier de notre choix à chaque insertion de la clé est possible.

3.1 La preuve en images

Afin de prouver que ces modifications sont réalisables, nous allons ajouter quelques éléments à notre fichier ISO : un fichier icône, un exécutable (par exemple la calculatrice Windows) et un fichier autorun.inf que voici :

Après un petit coup de mkisofs et de dd, nous repartons sur notre Windows où, après insertion de la clé, nous nous retrouvons face à... la calculatrice Windows. L'icône du lecteur CD dans le poste de travail a également changé :

Il a également été possible de mettre le nom MEMUP comme titre du CD, afin de faire croire qu'il s'agissait bel et bien de la clé Memup. Bien sûr, il est plus judicieux de reprendre l'icône et le nom d'origine, mais il ne s'agit là que de tests, pour bien montrer les changements sur la clé.

3.2 Les risques réels

Évidemment, pour un attaquant, il n'y a pas grand intérêt à forcer un utilisateur à faire des maths. Mais pour lui, le fait d'y glisser un virus ou un programme de sa création est bien plus important. De cette manière, il peut s'assurer que, sur toutes les machines Windows (non protégées, voir la suite) où la clé ira, son programme entrera en action et pourra dérober des fichiers en les copiant sur la clé, ou bien en se les envoyant par mail, comme cela a été décrit dans l'article précédent [2]. Il pourra également surveiller les frappes du clavier, dérober les informations des autres clés USB qui pourraient se connecter à la machine, désactiver certaines sécurités afin de faciliter l'accès ou la modification des données... Enfin tout un programme de pirate, en somme. Les différents moyens de programmer des scripts malveillants ont déjà été discutés dans de précédents articles [2], et il est même possible de trouver des kits spécialisés (« clés en main », si j'ose dire...) sur Internet, créés dans le but de faciliter la mise en œuvre et le déploiement de ce type d'attaque.

Pour information, le contenu maximal de la clé peut être facilement vérifiable, en remplissant la clé :

La quantité maximum de place disponible est donc de 5,5 Mo, qui n'est finalement rien d'autre que la taille du fichier popkey.iso que nous avons récupéré au début de l'article. C'est largement suffisant pour y mettre toute une panoplie d'outils dangereux pour la santé d'une entreprise. Et les méthodes pour dissimuler des fichiers exécutables sont nombreuses : noms de fichiers barbares ou connus (UsrMgr32.exe, ToolBar.exe, AdobeReader70fr.exe...), fichiers cachés ou système, utilisation de l'extension pif (UserManual.pdf.pif) ou de noms de fichiers très longs pour cacher l'extension... L'attaquant n'a que l'embarras du choix.

Un autre avantage, de taille, est que l'utilisateur, même s'il s'aperçoit de l'arnaque, ne pourra pas changer lui-même la clé afin de supprimer le virus, sauf s'il connaît cette technique. Cela dit, même si son antivirus lui avertit qu'un virus a été trouvé dans le lecteur CD de sa clé USB, pensez-vous qu'il y croirait ? Et vous ?

3.3 Encore plus loin

On peut être encore plus vicieux que cela, en automatisant le processus : notre ami Bob (des articles précédents) peut, dans son prochain fichier usbdumper-4.sh, patcher automatiquement la clé de son « amie » Alice afin d'insérer un virus dans le lecteur CD virtuel. Il n'aura qu'à découvrir le type de chacune des parties de sa clé, extraire le contenu de l'image du CD, ajouter son virus, modifier le fichier autorun.inf, recréer l'image avec mkisofs puis réécrire la clé (vous me suivez ?). Tout ceci très rapidement, et très silencieusement. Ainsi, la clé d'échange d'Alice pourra infecter tous ses amis à la fois, et ce, sans le moindre soupçon de leur part. Et malgré un formatage complet de la clé comme cela avait été préconisé comme moyen de protection, le lecteur CD, lui, ne changera pas, et le virus restera donc dans la clé.

Si la clé d'Alice ne contient pas de lecteur CD virtuel ou si celui-ci n'est pas modifiable, il est tout à fait possible qu'un jour ce soit Bob qui aille chez Alice, avec sa propre clé piratée. Méfiez-vous donc des clés que l'on branche sur vos PC, même si ça paraît évident, on n'y pense pas toujours ! Il peut même arriver que l'on branche une clé sur votre machine sans que vous ne soyez au courant, en particulier sur un ordinateur portable dans un lieu public, dans le train par exemple. Un moment d'inattention, et le mal est déjà fait.

On peut également se poser la question de la faisabilité de la chose sous Windows, c'est-à-dire qu'un virus puisse infecter les lecteurs CD virtuels des clés USB, par exemple. Il serait alors envisageable d'installer un pilote trafiqué afin de pouvoir affecter la clé directement, mais ce n'est possible qu'en tant qu'administrateur (et c'est tout sauf silencieux). Il est également possible de profiter des bugs du pilote ou des fonctionnalités de mise à jour pour écrire sa propre image ISO dans la clé [3]. Le lecteur intéressé saura trouver la documentation nécessaire sur les sites spécialisés.

4. Les recours

4.1 Comment se protéger

Les explications du précédent article [2] à propos de la désactivation de l'autoexécution s'appliquent dans notre cas aussi (car le lecteur CD ne pourra alors plus démarrer automatiquement, même si le virus reste dans la clé). La modification de la clé de registre appropriée est donc une bonne parade (voir Figure 6), mais le lancement manuel de la clé est toujours possible, et l'attaque au fichier autorun.inf dans la zone de stockage de la clé peut tout à fait être utilisée en combinaison avec la modification de l'image du CD. Plus il y a de moyens, plus il y a de chances de succès !

Comme nous l'avons déjà fait remarquer, les antivirus ne seront ici d'aucune utilité, car ils ne pourront pas supprimer le virus de la clé. Tout au plus, ils avertiront l'utilisateur du problème, mais celui-ci risque fort de ne pas y croire ou tout simplement ne pas savoir quoi faire.

Une parade également évidente est d'utiliser Linux pour faire ses manipulations avec la clé USB. À ma connaissance, aucune distribution Linux ne propose de fonctionnalité similaire à l'autorun sous Windows, mais le jour où ce sera le cas, il faudra s'en méfier. Un projet existe à ce sujet [4], mais n'est pas proposé par défaut sur la plupart des distributions, bien qu'il existe sous forme de package, en particulier pour Gentoo.

4.2 Quelques défauts

Cette technique, mis à part les défaillances relatives à la désactivation de l'autorun et de l'utilisation de Linux, souffre de quelques défauts, mais ils ne sont pas insurmontables :

D'abord, à l'insertion de la clé, les lettres de lecteur choisies dépendent de la configuration de l'ordinateur de l'utilisateur, donc peuvent être considérées comme aléatoires (par exemple, sur mon PC principal, il n'y a même plus de lettre disponible...). L'astuce, dans le cas d'un virus, serait de détecter la lettre de la clé grâce à un nom de fichier connu ou au numéro de série du système de fichiers. Cela ralentit le processus de copie de fichiers, mais ne l'empêche pas.

Ensuite, avec les clés testées dans cet article, le lecteur CD ne démarre pas automatiquement dans un cas bien précis : celui où la clé est insérée pour la première fois. Le lecteur étant fraîchement installé, Windows ne lance pas l'autorun. Ceci est toutefois provisoire, car à la deuxième insertion, cette fois-ci tout fonctionne normalement. Si vous n'avez la possibilité d'insérer qu'une seule fois votre clé, vous pouvez toujours faire croire que celle-ci a quelques problèmes et qu'il faut la réinsérer pour qu'elle fonctionne correctement, et le tour est joué.

Enfin, toutes les clés ne peuvent pas modifier l'image du lecteur CD virtuel, comme décrit ici. Par exemple, des tests menés avec une clé de marque SanDisk U3 révèlent qu'elle ne semble pas vulnérable (l'image ISO reste la même après la manipulation, même si dd n'indique aucun message d'erreur). Cependant, une attaque similaire sur ces clés a été publiée en 2006 [3], mettant en œuvre le logiciel de mise à jour fourni par le constructeur. Bien sûr, cela ne veut pas dire qu'elle n'est pas vulnérable aux virus, mais elle n'est pas vulnérable à l'attaque décrite dans cet article. Enfin, si c'est votre propre clé, il existe sur Internet des moyens physiques de modifier la mémoire Flash de la clé, mais cela nécessite beaucoup plus de compétences et de matériel.

Il faut également parler de Windows Vista et Windows Server 2008 : la fonction Autorun ne se comporte plus de la même manière sur ces systèmes. Alors que sur les versions précédentes, le fichier autorun.inf était immédiatement exécuté sans aucune action de l'utilisateur, désormais une fenêtre propose le choix de l'action à mener. Donc, a priori, l'attaque n'est plus possible avec Vista. Et pourtant, c'est faux, car il suffit de créer un fichier autorun.inf qui trompe le choix de l'utilisateur (voir Figures 7 et 8). Cette technique a notamment été utilisée par le ver Conflicker [5].

Conclusion

On a pu voir que l'automatisation des tâches de l'utilisateur lui facilite la vie autant qu'aux attaquants. Les points forts des clés USB deviennent très vite des points faibles, à partir du moment où des actions malhonnêtes sont possibles. Cette technique peut toutefois être utilisée à bon escient par un informaticien qui voudrait par exemple pratiquer une installation automatique d'un logiciel sur une série de PC en insérant une simple clé, utiliser ses propres outils ou encore se débarrasser de ces logiciels encombrants que les constructeurs nous forcent à utiliser.

Afin de se protéger un maximum contre ce type d'attaques, il faut donc être certain que la clé n'est pas modifiable (un simple test sous Linux comme celui décrit plus haut permet de le vérifier ou bien d’acheter une clé qui ne propose pas de lecteur CD virtuel), ne jamais cliquer sur les autoexécutions (et les désactiver dès que possible) et utiliser une machine et une clé USB dédiées à ce type d'échanges, sur un système d'exploitation non propriétaire, afin d'éviter un vol de données trop important. Et évidemment, éviter les clés proposant des fonctions d'autorun intégrées (par exemple [6]).

Encore une fois, et comme dans bien des cas, une sensibilisation des utilisateurs sur les risques liés aux clés USB et aux échanges de fichiers et d'informations en général [7] est primordiale, car ce sont aussi les plus vulnérables et les plus crédules en la matière.

Remerciements

Je souhaiterais remercier chaleureusement toutes les personnes m'ayant aidé à la rédaction, aux tests et à la relecture de cet article, en particulier à M. Nidal Ben Aloui, M. Pierre Bétouin et, bien sûr, M. Frédéric Raynal, pour la publication de mon premier article.

Références

[1] http://www.memup.fr/POP-KEY-La-petite-cle-coloree-et-retractable-!_a333.html

[2] MISC n°42, pages 60 à 67.

[3] http://web.archive.org/web/20080214021248/www.mcgrewsecurity.com/research/hackingU3/

[4] http://sourceforge.net/projects/autorun/

[5] http://en.wikipedia.org/wiki/AutoRun#Attack_vectors

[6] http://www.flashbay.com/usb_flash_drive_autorun_setup.html

[7] http://en.wikipedia.org/wiki/USB_flash_drive#Security