La sécurité des clés USB

Magazine
Marque
MISC
Numéro
45
Mois de parution
septembre 2009
Spécialité(s)


Résumé

Dans les précédents articles à propos des clés USB, il a été montré que, grâce à quelques règles udev et quelques scripts savamment écrits, il était possible de recopier le contenu d'une clé (même effacé) et même le contenu du disque dur de la victime, en jouant avec les fichiers autorun. Tout ceci sans aucune manipulation suspecte de l'attaquant, simplement grâce à l'automatisation des scripts et la crédulité de la victime.Dans cet article, nous allons présenter une catégorie plus récente d'attaques concernant des clés USB, qui porte cette fois-ci sur un certain type de clés, disponibles à prix modique au grand public.Mots-clés : USB / U3 / autorun / CDFS / proof-of-concept


Body

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 :

 

pop1

 

Figure 1 : Disques de la clé, tels qu'ils apparaissent par défaut

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é :

 

pop2

 

Figure 2 : Contenu du lecteur CD 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).

[Autorun]      

icon=Memup.ico

label=Pop key

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 :

# ls /dev/ub*

/dev/uba /dev/ubb /dev/ubb1

Ne vous trompez pas lorsque vous vous servez des périphériques situés dans le répertoire /dev : une fausse manipulation et vous risquez de détruire des données de façon irrémédiable !

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 :

# mount /dev/uba /mnt/tmp

# ls /mnt/tmp

Autorun.inf                   IT_Memory\ bar\ manual.pdf

DE_Memory\ bar\ manual.pdf    Memorybar.exe

EN\ Memory\ bar\ manual.pdf   Memup.ico

ES_Memory\ bar\ manual.pdf    PT_Memory\ bar\ manual.pdf

FR\ Memory\ bar\ manual.pdf

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

# dd if=/dev/uba of=/root/popkey.iso

11264+0 records in

11264+0 records out

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 :

# mount /root/popkey.iso /mnt/tmp -o loop

# ls /mnt/tmp

Autorun.inf                   IT_Memory\ bar\ manual.pdf

DE_Memory\ bar\ manual.pdf    Memorybar.exe

EN\ Memory\ bar\ manual.pdf   Memup.ico

ES_Memory\ bar\ manual.pdf    PT_Memory\ bar\ manual.pdf

FR\ Memory\ bar\ manual.pdf

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

# dd if=/root/popkey.iso of=/dev/uba

11264+0 records in

11264+0 records out

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é :

# mkdir macle

# echo "Bonjour" > macle/test.txt

# mkisofs -o /tmp/testcle.iso macle

# dd if=/tmp/testcle.iso of=/dev/uba

700+0 records in

700+0 records out

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

 

 

pop3

 

 

pop4

 

Figures 3 et 4 : Disques de la clé et contenu du lecteur CD, après modification.

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 :

[autorun]

open=calc.exe

icon=ico_key.ico

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é :

 

pop5

 

Figure 5 : Disques de la clé, avec notre fichier autorun.inf personnalisé

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é :

# dd if=/dev/zero of=/dev/uba

dd: writing /dev/uba: No space left on device

11265+0 records in

11264+0 records out

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.

 

Rappelons tout de même que, si les virus n'ont pas l'habitude de se loger dans le lecteur CD virtuel, ils peuvent (et ne s'en privent pas) très facilement infecter la partie stockage de la clé, et ceci concerne toutes les clés. Autrefois, on pouvait encore protéger physiquement les disquettes contre l'écriture, mais la plupart des clés USB ne disposent plus de cette fonction. Une parade consisterait à utiliser une clé lecteur de cartes flash (SD, MMC, xD...), et protéger la carte flash en écriture.

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 !

 

pop6

 

Figure 6 : Clé du registre à modifier afin de désactiver l'autorun

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].

 

Conficker_worm_AutoPlay_Vista

 

Figure 7 : Présentation de l'autorun sous Vista, avec un fichier autorun.inf malicieux

[autorun]

open=RECYCLER\\S-1-6-20-3802918391-3809376219-530039213-2313\\jwgkvsq.vmx,ahaezedrn

icon=%SystemRoot%\\system32\\SHELL32.dll,4

action=Open folder to view files

shell\\open=Open

shell\\open\\command=RECYCLER\\S-1-6-20-3802918391-3809376219-530039213-2313\\jwgkvsq.vmx,ahaezedrn

shell\\open\\default=1

Figure 8 : Exemple de fichier autorun.inf qui produit le résultat de la figure 7. Remarquez que l'exécutable est dissimulé dans la corbeille de la clé.

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

 



Article rédigé par

Les derniers articles Premiums

Les derniers articles Premium

De la scytale au bit quantique : l’avenir de la cryptographie

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Imaginez un monde où nos données seraient aussi insaisissables que le célèbre chat de Schrödinger : à la fois sécurisées et non sécurisées jusqu'à ce qu'un cryptographe quantique décide d’y jeter un œil. Cet article nous emmène dans les méandres de la cryptographie quantique, où la physique quantique n'est pas seulement une affaire de laboratoires, mais la clé d'un futur numérique très sécurisé. Entre principes quantiques mystérieux, défis techniques, et applications pratiques, nous allons découvrir comment cette technologie s'apprête à encoder nos données dans une dimension où même les meilleurs cryptographes n’y pourraient rien faire.

Les nouvelles menaces liées à l’intelligence artificielle

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Sommes-nous proches de la singularité technologique ? Peu probable. Même si l’intelligence artificielle a fait un bond ces dernières années (elle est étudiée depuis des dizaines d’années), nous sommes loin d’en perdre le contrôle. Et pourtant, une partie de l’utilisation de l’intelligence artificielle échappe aux analystes. Eh oui ! Comme tout système, elle est utilisée par des acteurs malveillants essayant d’en tirer profit pécuniairement. Cet article met en exergue quelques-unes des applications de l’intelligence artificielle par des acteurs malveillants et décrit succinctement comment parer à leurs attaques.

Migration d’une collection Ansible à l’aide de fqcn_migration

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Distribuer du contenu Ansible réutilisable (rôle, playbooks) par l’intermédiaire d’une collection est devenu le standard dans l’écosystème de l’outil d’automatisation. Pour éviter tout conflit de noms, ces collections sont caractérisées par un nom unique, formé d’une espace de nom, qui peut-être employé par plusieurs collections (tel qu'ansible ou community) et d’un nom plus spécifique à la fonction de la collection en elle-même. Cependant, il arrive parfois qu’il faille migrer une collection d’un espace de noms à un autre, par exemple une collection personnelle ou communautaire qui passe à un espace de noms plus connus ou certifiés. De même, le nom même de la collection peut être amené à changer, si elle dépasse son périmètre d’origine ou que le produit qu’elle concerne est lui-même renommé.

Les listes de lecture

11 article(s) - ajoutée le 01/07/2020
Clé de voûte d'une infrastructure Windows, Active Directory est l'une des cibles les plus appréciées des attaquants. Les articles regroupés dans cette liste vous permettront de découvrir l'état de la menace, les attaques et, bien sûr, les contre-mesures.
8 article(s) - ajoutée le 13/10/2020
Découvrez les méthodologies d'analyse de la sécurité des terminaux mobiles au travers d'exemples concrets sur Android et iOS.
10 article(s) - ajoutée le 13/10/2020
Vous retrouverez ici un ensemble d'articles sur les usages contemporains de la cryptographie (whitebox, courbes elliptiques, embarqué, post-quantique), qu'il s'agisse de rechercher des vulnérabilités ou simplement comprendre les fondamentaux du domaine.
Voir les 66 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous