Les détails d’une inquiétante faille de l’USB sont désormais accessibles à tous. Démontrée lors de la dernière conférence Black Hat, elle permet de corrompre n’importe quel périphérique USB pour lui faire embarquer des malwares pratiquement indétectables. Devant le manque de réaction de l’industrie, certains chercheurs en ont eu assez d’attendre.
Cacher des malwares dans le firmware d'une clé USB
Le chercheur Karsten Nohl, de chez SR Labs, avait fait la démonstration de cette faille dans une petite pièce il y a deux mois. Nommée BadUSB, ses implications étaient particulièrement conséquentes : la possibilité d’infecter une clé USB par exemple pour lui faire intégrer un code capable ensuite de s’exécuter de manière automatique par la machine sur laquelle elle est reliée. Une version beaucoup plus grave en quelque sorte des anciens problèmes liés au fichier autorun.inf sous Windows.
Les travaux de Nohl étaient restés secrets car la faille a le potentiel de faire de grands dégâts. Et pour cause : par sa nature même, elle bloque la possibilité de détecter les malwares ainsi embarqués par les solutions de sécurité. La seule parade est que les constructeurs prennent au sérieux la faille et agissent pour que les nouveaux périphériques USB ne puissent plus être infectés. Et pour les existants ? C’est bien là tout le problème.
Les constructeurs sous pression
Deux chercheurs, Adam Caudill et Brandon Wilson, se sont lancés sur la piste de BadUSB et sa rétroingénierie. Ils sont parvenus à retrouver plusieurs méthodes d’exploitation de la faille et ont publié leurs résultats sur GitHub, donc en accès libre. Durant la conférence Derbycon, qui s’est tenue il y a une semaine à Louisville (Kentucky), ils ont expliqué leur geste : « Nous pensons que tout ceci devrait être public. Ce ne devrait pas être gardé caché. Nous publions donc tout ce que nous avons ». Et d’expliquer que puisque SR Labs n’a pas souhaité montrer les détails de la faille, les entreprises impliquées n’ont pas pu la considérer sérieusement.
Interrogé par Wired, Adam Caudill précise : « Si cela doit être corrigé, nous avons besoin de plus qu’une présentation à la Black Hat. Si les seules personnes qui peuvent le faire sont celles ayant de gros budgets, les constructeurs ne feront jamais rien. Vous devez prouver au monde que c’est utilisable, que n’importe qui peut le faire… Ce qui impose une pression aux constructeurs pour qu’ils corrigent le vrai problème ».
Mettre à jour les périphériques existants ? Difficile
Nohl avait initialement refusé de partager les détails de sa faille car il estimait qu’en l’état, la corriger était impossible : comment flasher les firmwares des centaines de millions de clés USB existant sur le marché ? Les constructeurs devraient se pencher sur le problème, créer de nouveaux firmwares pour des modèles qui ne sont plus vendus depuis bien longtemps, avertir les utilisateurs, leur faire prendre conscience du danger et les amener à changer le firmware : rien de bien simple en somme.
Et c’est d’ailleurs ce grand danger qui a empêché Adam Caudill et Brandon Wilson de publier l’intégralité des méthodes d’exploitation découvertes. Actuellement, ils travaillent sur un processus masqué dans le firmware capable d’infecter à la volée tous les fichiers entrant et sortant de la clé avec des malwares. Il suffirait donc de brancher la clé pour déclencher une infection généralisée d’une machine.
Commentaires (122)
#1
Donc si je comprends bien, ça concerne potentiellement tous les OS, ordinateur comme mobile ? Dans la pratique, il faut que l’OS puisse exécuter le code du virus, donc ça touchera certainement principalement Windows, mais c’est sérieux comme faille.
#2
Périphérique USB c’est vague quand même. La souris programmable que j’ai dans la main possède aussi de la mémoire de stockage!
Ca serait, selon moi, plus simple de changer le parc de machines plutôt que le parc de périphériques.
N’importe comment cela parait être une mission impossible.
#3
Je lance l’idée sur kickstarter => le hub usb pare feu
#4
L’OS ne pourrait-il tout simplement pas vérifier le contenu du firmware avant de l’exécuter ? Ce serait le rôle de l’antivirus, et il me semble que Windows contient un antivirus par défaut depuis Windows 8 au moins.
#5
#6
#7
PCI, vous avez vu la news sur le spyware de la police installé dans un programme de logiciel de filtrage parental ?
https://www.eff.org/deeplinks/2014/09/computercop-dangerous-internet-safety-soft…
#8
Nohl avait initialement refusé de partager les détails de sa faille car il estimait qu’en l’état, la corriger était impossible : comment flasher les firmwares des centaines de millions de clés USB existant sur le marché ? Les constructeurs devraient se pencher sur le problème, créer de nouveaux firmwares pour des modèles qui ne sont plus vendus depuis bien longtemps, avertir les utilisateurs, leur faire prendre conscience du danger et les amener à changer le firmware : rien de bien simple en somme.
Je ne comprends pas, c’était au contraire une aubaine pour tous les fabricants : une belle annonce catastrophiste entre le réchauffement climatique et une décapitation au moyen-orient pour inciter tout le monde à racheter des clés USB.
#9
Serait-il possible d’avoir des informations techniques pour détecter si une clé USB contient cette faille ?
Quel logiciel utiliser ? A quelle adresse mémoire chercher ?
#10
#11
#12
#13
#14
#15
J’ai du mal à saisir en quoi cette « faille » est grave. En gros un périphérique de stockage dispose d’un firmware qui est éventuellement reprogrammable si une interface ISP (In System Programing) est disponible via le bus de contrôle. En l’absence d’ISP dans tous les cas le fabricant peut mettre le firmware qu’il souhaite en partenariat avec la NSA.
Maintenant, sans connaître la cible, modifier à la volée une archive compactée disposant d’une somme de contrôle pour infecter la machine hôte en utilisant un firmware d’une taille ridicule et avec un micro-contrôleur qui dispose de quelques kilo-octets de RAM, bon courage !
#16
#17
#18
#19
Korben en a parlé il y a déjà 2 mois : Faut-il boucher ses ports USB au ciment ?
#20
Erratum : le 8051 est en fait le MCU de la clé, donc c’est juste de la cross-compilation pour créer le firmware. Ma conclusion reste inchangée.
#21
#22
Le gros souci, ça reste les postes en libre service dont on n’a pas d’autre choix que de laisser les ports USB accessibles.
#23
Une question que je me pose (mais peut être avec répionse positive) : qu’en est-il des stockages “HDD” sur port USB ? Le disque dur 2 TO USB3 que j’ai peut en être victime ?
#24
#25
Excellente affaire pour les constructeurs, ils vont pouvoir nous revendre plein de nouvelles clés USB fiabilisées pendant qu’on mettra les anciennes à la poubelle.
#26
#27
Question peut-être bête mais je me demande pourquoi ça ne pourrait pas être le cas de toute entrées sur un ordinateur ? (hdmi, jack, série, etc..)
#28
#29
#30
Mais le malware une fois executé, se loge obligatoirement en memoire vive et donc l’antivirus pourra l’intercepter.
#31
#32
#33
#34
#35
Beaucoup de bruit pour rien, a moins que le firmware puisse accédé a une faille de l’os…
#36
#37
Une bonne raison d’employer les clés qu’avec Linux
" />
" />
" />
" />
Une alternative de choix, non ?
#38
#39
sur l article de wired, il y a plusieurs commentaires intéressants de gars bossant ds la programmation des firmware USB, notamment de “zieroh”.
En résumé, le pb n est pas du standard USB mais de l’implémentation libre des constructeurs concernant la procédure de flashage, plus exactement le fait que certains ne prennent pas la peine de vérifier la source (avec par ex une signature) du nouveau firmware avant d accepter son flashage.
Par ailleurs, le pb n affecte que certaines puces de certains constructeurs, on est loin du “toutes les clefs USB” ! Reste à savoir lesquelles!
#40
Marrant ce buzz autour de BADUSB tout d’un coup, alors que ça fait plusieurs années que n’importe qui peut faire la même chose avec une teensy et 30 lignes de code (pour émuler le clavier par exemple).
#41
#42
C’est vieux comme tout cette faille :
… Branchement d’un périphérique type USB ou Firewire (faille DMA pour le protocole raw1394)
exploitant une faille de ces protocoles pour attaquer le système via ces bus (ByPass authentification
Windows),
Note : ici on ne parle pas « d’Autorun » mais bien de couche basse, niveau pilote bas niveau.
je l’enseignai déjà en 2011 à mes stagiaires dans ce cours que j’ai écrit : “Firewall - Architecture et déploiement (Linux).pdf”
#43
Il suffirait donc de brancher la clé pour déclencher une infection généralisée d’une machine.
Donc un malware a la capacité de traverser TOUT les systèmes de fichiers existant ?
#44
#45
#46
#47
#48
#49
bah avec çà ?https://hakshop.myshopify.com/collections/usb-rubber-ducky/products/usb-rubber-d…
#50
#51
#52
#53
#54
#55
#56
#57
#58
#59
#60
De ce que j’en ai compris, le problème principal vient du fait que l’on puisse mettre à jour le firmware (FW) d’un périphérique USB sans que celui-ci ne vérifie l’auteur du FW.
Pour mettre à jour un FW, il faut généralement passer par un bootloader qui est inclus dans le périphérique qui permet de charger ce FW. C’est au bootloader du vérifier la signature du FW et de décider ou non de le sauvegarder. Une fois sauvegardé, ce FW va être exécuté sur le périphérique USB.
A partir de là, il est possible de faire “ce qu’on veut” avec le périphérique USB. On peut faire en sorte qu’il s’énumère comme un clavier, une clé USB, une carte réseau, une webcam ou ne ne sais quoi.
L’exploitation est, à mon avis, plus compliquée puisque un périphérique USB n’exécute pas de code sur la machine à laquelle il est branché.
On peut donc imaginer plusieurs vecteurs d’attaque:
1. émuler une clé USB pour que le système boot dessus et ainsi installer un virus ==> pas besoin de bidouiller le FW du périphérique, on peut le faire avec une simple clé USB. L’avantage de le faire en trafiquant le FW c’est d’être “clean” au branchement et lorsque le PC redémarre, monter la partition avec le virus . La parade est super simple: désactiver le boot sur USB, ce qui, au passage est fortement recommandé.
2. émuler un périphérique USB dont on connait les failles de sécurité du driver installé sur la machine. On pourra essayer de faire des débordement de mémoire et exécuter du code aléatoire sur la machine. Une mise à jour du driver pourra corriger le problème s’il est connu. Cette attaque est donc liée à un système d’exploitation, Windows, Linux et MacOS n’ayant pas les mêmes driver…
3. émuler des périphériques et essayer de glaner des informations.
Cela peut se faire en se déclarant comme une carte réseau et essayer de re-router le trafic réseau vers nous. Je ne m’y connais pas trop en réseau, donc je ne sais pas ce qu’il est possible de faire, mais je pense que si le trafic est redirigé vers cette carte factice, il y a de forte chance que le réseau ne marche plus (à moins de pouvoir forcer les paquets à passer par la carte réseau factice puis de les renvoyer vers la carte réseau légitime… j’ai du mal à voir comment faire… mais pourquoi pas…)
On peut aussi se faire passer pour un clavier et entrer des commandes, comme par exemple lancer une console DOS, aller télécharger un virus sur internet toujours en commande dos puis l’exécuter. Cette attaque est plutôt visible car la fenêtre dos est visible et si jamais le périphérique USB infecté effectue cette manipulation alors que vous être en train de rédiger votre rapport sur votre éditeur de texte favoris, alors tout tombe à l’eau.
Cette attaque par clavier factice tombe aussi à l’eau si vous branchez le périphérique USB alors que la session est verrouillée… puisqu’il faut entrer le mot de passe de la session pour pouvoir faire quelque chose.
En plus l’execution d’un virus sera surement détecté par votre anti-virus.
On peut aussi se déclarer en périphérique composite (plusieurs “périphériques” dans 1), comme un clavier + une carte réseau + une clé USB + … Pareil, l’attaque est assez compliqué car il faudra faire en sorte que tout soit bien synchro pour attaquer le PC et espérer faire quelque chose.
Il faut aussi prendre conscience que généralement les mémoires embarquées dans les périphériques sont réduites au minimum. Donc une souris avec ses quelques ko de flash aura du mal à sauvegarder 3 jours de trafic réseau. C’est pour cela que les clés USB (stockage de masse) sont les plus sujet aux attaques car il est possible de sauvegarder beaucoup plus de données.
Une parade à tout cela serait que le système affiche lors du branchement d’un périphérique USB ce à quoi il sert et demande à l’utilisateur de valider. Ainsi, si vous branchez une clé USB (stockage de masse) et que celle-ci se déclare comme un stockage de masse et un clavier ==> vous refusez. Idem si la clé USB se déclare comme une carte réseau…
Reste le problème du démarrage… il faudra bien autoriser au moins un clavier et une souris pour permettre à l’utiliser de valider les autres périphériques…
L’autre parade est de bien regarder ce que votre système vous dit lorsque vous branchez votre périphérique…
#61
#62
#63
#64
#65
#66
#67
#68
#69
#70
Encore des wannabes.
Les supports USB existent depuis tellement d’années, même si les géants ne corrigent pas ce problème avant 1-2 années, ce n’est pas comme si ça allait avoir un réel impact.
#71
Eh, mais c’est pas une faille de l’USB, c’est juste qu’il faut savoir d’où viennent les périphériques qu’on branche…
Evidemment que si je branche un périphérique qui fait souris et clavier il peur prendre le contrôle de l’ordinateur, et il existe bien d’autres périphériques qui ont le droit de faire plein de trucs dans l’ordinateur !
Du coup, ne laissez pas un inconnu brancher un périphérique USB sur votre PC, mais cela va de soi… De même que je ne laisse pas un inconnu installer un logiciel sur mon PC…
La protection contre ça, il n’y en a pas, à part l’intelligence, mais tous n’en sont pas dotés.
#72
#73
Les gars, au lieu de chercher une super solution de la mort qui tue avec des softs et blabla, balancez votre PC dans les chiottes et faites vous un PC vous même, de la fabrication des composants à la programmation. Pareil pour les périphériques. J’en conclue que j’ai trouvé la meilleurs solution !
" />
#74
#75
#76
double post
#77
#78
#79
Si cela doit être corrigé, nous avons besoin de plus qu’une présentation à la Black Hat. Si les seules personnes qui peuvent le faire sont celles ayant de gros budgets, les constructeurs ne feront jamais rien. Vous devez prouver au monde que c’est utilisable, que n’importe qui peut le faire… Ce qui impose une pression aux constructeurs pour qu’ils corrigent le vrai problème
J’imagine que c’est valable pour les fabricants de serrure…
#80
Plus je pense a cette histoire, plus je me dis que la faille c’est finalement windows.
" />
Je veux bien servir de cobaye.
OS: Funtoo.
FS: XFS
KERNEL LINUX compilé aux petits oignons avec le stricte nécessaire en pilotes pour prendre en charge mes périphériques.
AUTOMOUNT: disabled
Envoyez moi vos clef USB vérolées
#81
moi j’ai ca http://www.lactualite.com/wp-content/uploads/2013/11/machine-a-ecrire.jpg
" />
Envoyez moi aussi vos clé USB vérolées
#82
#83
#84
#85
#86
Une des faiblesses du protocoles USB est que tous les périphériques peuvent écouter les paquets envoyés à destination d’un autre périphérique.
Je crois comprendre que l’unicast introduit avec l’usb3 vise à régler ce problème.
#87
ah…il NE manquait PLUS que ça !
" />
" />
“ - ne trouvez-vous pas qu’on ait assez d’em…comme ça ?
hop…on en rajoute “une couche” !
ce monde va à sa perte !!!
il fournit, LUI MÊME, le bâton pour se faire battre…maso., vas …pff !
#88
#89
#90
#91
#92
#93
#94
#95
#96
#97
#98
#99
#100
#101
#102
#103
#104
#105
#106
#107
#108
#109
On enfonce un peu des portes ouvertes, puisque le fait d’intégrer des malware via un firmware n’est pas nouveau. C’est même quasiment une évidence pour qui voudrait rester discret. Ça existe déjà via des clés USB promotionnelles dont une partie du contenu est figé dans le firmware et /ou dans une partie de la NAND en lecture seule et s’auto exécute dès l’insertion de la clef.
C’était déjà le cas d’un virus nommé GenP (ouB) qui se calait sur la piste 0 d’une disquette pour infecter ensuite le système. Étant donné que matériellement le lecteur lisait forcément cette piste, le virus était lu et injecté ensuite dans n’importe quel secteur de démarrage.
Sans parlé de certains autres virus qui infectent les BIOS.
#110
#111
#112
Dans la video BADUSB, on voit l’activité visuel de la clé usb => En gros ça laisse des traces. De plus “dans la video”, le code doit être adapté en fonction de l’OS. Sous linux la clé a beaucoup mal à exécuter l’ensemble des codes spoil “ elle n’arrive pas à modifier le dns”, cette clé n’a pas le droit root “c’est marqué dans les slides de la video”. Sous windows , on voit clairement la deuxième carte réseau.
Est ce que la clé fonction toujours en veille ou devant l’écran de login?
Sources:https://www.youtube.com/watch?v=nuruzFqMgIw
#113
#114
#115
OK avec tout c’est du bon sens. Mais :
Je sais pas expérience que beaucoup de personnes appuient sur le bouton
power, et vont faire autre chose le temps que le système se charge. La
clé peu avoir détecté qu’elle était énumérée par le bios et proposer une
partition bootable, s’énumérer comme clavier et appuyer sur F12, faire
deux fois flèche bas puis “enter”… et si ça ne marche pas cette fois,
on mémorise et on recommence une autre séquence le prochain boot.
Oui, c’est en théorie possible, mais avec du matos plus spécifique (électroniquement) qu’une clef basique quand même. non ?
#116
#117
#118
#119
#120
#121
Oui il y a pas besoin pour installer un matériel usb. Par contre sous ubuntu, il faut des droits pour modifier le DNS même pour reset le DNS. c’est pourquoi ça ne marche pas.
http://doc.ubuntu-fr.org/dns
Dans tous les cas de figures, l’USB utilise la session de la personne donc l’attaque doit être personnalisé en fonction de l’OS et de la configuration session. Rien empêche à la clé de faire appel à un tiers ( ici c’est la cas dans la video BADUSB) pour exploiter une faille système.
#122