« Le générateur de mots de passe inclus dans Kaspersky Password Manager a rencontré plusieurs problèmes », a expliqué mardi l'équipe de recherche de Donjon sur son blog. « Le plus critique est qu'il utilisait un générateur de nombres pseudo-aléatoires (PRNG) non adapté à des fins cryptographiques. Sa seule source d'entropie était l'heure actuelle. Tous les mots de passe qu'il créait pouvaient être brutalement forcés en quelques secondes ».
Il générait en effet des mots de passe identiques à tout moment et partout dans le monde : « Par exemple, il y a 315 619 200 secondes entre 2010 et 2021, donc KPM pourrait générer au plus 315 619 200 mots de passe pour un jeu de caractères donné. Les forcer brutalement prend quelques minutes ».
« Kaspersky a corrigé un problème de sécurité dans Kaspersky Password Manager, qui permettait potentiellement à un attaquant de découvrir les mots de passe générés par l'outil », a déclaré un porte-parole de l'entreprise dans un e-mail à The Register. Il « n'était possible que dans le cas improbable où l'attaquant connaissait les informations du compte de l'utilisateur et l'heure exacte à laquelle un mot de passe avait été généré. Cela obligerait également la cible à réduire ses paramètres de complexité de mot de passe ».
Commentaires (28)
#1
Curieux, car Kaspersky n’est pas une startup novice, ils ont forcément des spécialistes de haut niveau sur le sujet. L’heure peut être un des éléments pour le générateur d’aléas, mais ne peut pas être le seul ! Cette technique suffisait pour faire un jeu pour Commodore 64 ou Vic 20 (je suis de cette génération), mais on ne peut supposer que ce produit a été développé sans le concours de ces spécialistes, et c’est surtout ça qui pose question.
CloudFlare utilise des lampes à lave et d’autres sources multiples et variées pour générer de l’entropie (de l’aléa)… La génération de nombres aléatoires de qualité est un problème primordial en sécurité du SI, c’est inquiétant qu’une société comme Kaspersky ait pu laisser passer cela.
#1.1
Je crois que c’est pas un produit Kaspersky mais un produit rebrandé (ils mettent leur nom mais c’est pas eux qui le font)…
#2
Backdoor ?
ça marche vraiment ce genre de truc ? Mieux qu’un bon vieux Fortuna ou qu’une seed initialisé depuis l’heure, le RDSEED, un /dev/random et mixé avec des hashs et du chacha ?
#3
Backdoor : je ne pense pas, c’est trop gros et pas assez discret. Je pense plutôt à un problème d’organisation ou de priorité produit chez Kaspersky.
Côté lampes à lave, oui, ça marche, mais une des bases en crypto est d’avoir des sources variées d’aléas. Plus il y en a, mieux c’est, surtout pour pallier à l’insuffisance d’une des sources, justement.
Le problème du /dev/random est qu’il est insuffisant, notamment sur des petites machines type Raspberry : si tu la laisses tourner sans qu’il y ait de frappes clavier ou d’échanges divers et variés, tu te retrouves avec une entropie très faible (en clair : y a pas grand chose qui se passe sur la machine). Surtout que dans un Raspberry, il n’y a pas de pile pour conserver l’heure, et donc s’il n’est pas connecté au réseau l’horloge fournira encore moins d’entropie puisqu’on repart à zéro à chaque redémarrage…
#4
Kaspersky est un antivirus que je peux conseiller si on me demande.
Même si la génération de password n’est pas son cœur de métier, c’est vrai que ça pose question pour un problème aussi connu :(
#5
Même avec la nouvelle façon dont le noyau gère ce genre de chose depuis la version 4.8 ? Mixage des sources + Chacha20 ? (Sur raspberry j’entends).
#6
C’est clair que c’est gros… mais est-ce de l’incompétence ou un dev qui a été obligé de le mettre en place et qui a implémenté la chose de la manière la plus visible possible? Rappelons-nous que de nombreux états ont des lois permettant de contraindre un éditeur ou un développeur à implémenter des backdoors, le tout assorti de “gag orders” et de peines de prison si il dévoile l’existence de l’implémentation.
#6.1
Oui il peut exister des lois contraignantes mais il y a beaucoup plus simple et moins voyant pour avoir une backdoor : le produit Kaspersky Password Manager utilise un fichier stocké en ligne (“dans le cloud”) ! Donc je reste d’avis qu’il s’agit d’un problème interne à Kaspersky.
Chacha est un algorithme de chiffrement, ça n’apporte aucun aléa (heureusement). Pour ce qui est de /udev/random, sa principale source d’entropie provient des pilotes des périphériques. Donc si tu as un Raspberry connecté à un clavier, une souris, un réseau, avec des pilotes de périphériques fortement sollicités, tu auras une source d’aléa. Sinon, tu n’auras pas grand chose : un ordinateur connecté à rien ne produit aucun aléa ! C’est le principe même d’un ordinateur. Pour l’aléa, il te faut impérativement une source externe.
Dans mon boulot, j’ai des collègues qui ont utilisé des Raspberry pour des applications crypto, on a ajouté de l’aléa en demandant aux utilisateurs de taper “n’importe quoi” sur un clavier, car sinon on avait un niveau d’entropie très pauvre.
#7
On a déjà vu des trucs louches aussi avec des histoires de clés “oublié” chez Cisco. C’est quand même gros pour un éditeur de pare-feu/switch/VPN de ne pas avoir des procédures de qualité pour ce genre de chose. Donc soit, il y a des bugs dans leur QA soit il y a une autre anguille sous roche.
#8
Soit. Pourtant, Intel utilise du chiffrement AES-CTR sur la sortie de son HWRNG. Si j’en crois ce commit du noyau linux Linux Kernel, Chacha20 joue un rôle de CSPRNG (qui a été développé par D. J. Bernstein.
Si je regarde la distribution statistique d’AES (ou de Chacha) pour moi, ça ressemble à une jolie loi uniforme.
La conclusion serait-elle que dériver une source d’aléa à partir d’une source physique (clavier, réseau…) en utilisant une fonction de chiffrement n’est pas suffisant pour garantir un bon aléa cryptographie ?
PS : Désolé de poser ces questions. La crypto est un de mes hobby mais j’ai rarement l’occasion d’échanger sur ce genre de sujet.
#8.1
Chacha évite certaines attaques en effet, améliore l’utilisation de l’entropie disponible, mais n’en créé pas. Néanmoins, si tu n’as pas d’entropie en entrée, tu es mort de toute façon quoi qu’il se passe derrière.
Par ailleurs, je connais des usages pour des ordinateurs connectés à rien mais qui chiffrent des données, par exemple pour faire un stockage sécurisé (coffre-fort de données). On entre une clé de chiffrement d’une façon ou d’une autre, on lit les données sur l’ordi, mais comme il n’est relié à rien, on réalise une protection appelée “air gap”, ce qui signifie justement que le dispositif n’est relié à rien et que toute attaque passe par un contact physique avec la machine (il existe quand même des scenarios d’attaque, mais très difficile à mettre en place en pratique).
La source d’aléa est un élément critique dans la conception de systèmes cryptos.
Le seul moyen d’avoir un bon aléa (= un bon générateur de nombre aléatoire) est d’avoir plusieurs sources physiques distinctes. Néanmoins, quand tu décortiques une frappe clavier (ou un déplacement de souris dans certaines conditions), tu peux quand même y trouver beaucoup d’aléas (temps de frappe, touches/texte saisi) si on force l’observation suffisamment longtemps.
Pour le déplacement de souris, PuTTYGen utilise ce mécanisme pour créer de l’aléa “indépendamment” du système informatique sur lequel il tourne.
#9
Certes non, mais il n’en est pas moins une partie essentielle de la solution. Le chiffrement (utilisé souvent en mode génération de hash) permet de répartir l’entropie disponible dans l’intégralité du pool. C’est utile justement si l’entropie disponible est faible, inférieure à la taille du pool ; cela évite notamment qu’un attaquant puisse reconstruire une image du pool d’entropie à partir des bits random qu’il a pu intercepter.
On va dire que je chicane, mais un ordinateur connecté à rien n’a pas franchement besoin de chiffrer les données
#10
Non, une seule source physique ce n’est pas suffisant. C’est tiré par les cheveux, mais un attaquant pourrait manipuler le timing (par exemple, sur une machine virtuelle…) pour affaiblir ta source d’entropie. Multiplier les sources impose à l’attaquant de contrôler de nombreux paramètres de l’environnement, en l’obligeant à corrompre simultanément toutes les sources.
#11
Donc si on te vole le pc, tes données sont toujours protégées ?
#12
Nos portables de boulot sont tous chiffrés. Même ceux qui ne sont jamais connectés.
La raison : empêcher d’accéder aux données aux personnes non autorisées. Exactement comme pour une machine connectée, donc.
#12.1
Ils sont donc connectés à un disque dur, un clavier, une souris… Toutes choses qui peuvent servir de source d’entropie.
Janiko et moi parlions d’un ordinateur synchrone composé d’un CPU et de ram sans aucun périphérique, par exemple un microcontrôleur Arduino nu. Dès qu’on connecte un périphérique asynchrone comme un disque dur, un réseau, etc… ces composants permettent d’extraire de l’entropie par analyse des temps de traitement.
#13
Pourquoi cela sonne-t-il familièrement ?
Ah oui ! 15 ans, un tour de manège et ça revient : Debian 2006 weak SSL keys
De la criticité d’avoir une bonne génération pseudo-aléatoire (aka grande entropie, aka mixer plusieurs sources non-prédictibles, dont le mélange ne l’est pas non plus)… même si ça ne sera jamais parfait.
#13.1
Pas tout à fait, quand même : la faille Debian/openSSL était un peu plus sioux : l’erreur était due à la longueur utilisée pour stocker l’aléa produit par le système, trop petite, et donc qui réduit l’entropie à peau de chagrin. Et franchement ça fait partie des erreurs que l’on peut commettre même en étant un programmeur expérimenté qui connait bien la crypto. Et surtout qu’à tester, c’est pas simple non plus.
Ou alors c’est un sacré gros malin qui est super bon en programmation et en crypto qui a introduit cette fonctionnalité non documentée dans le code…
#14
J’ai vu que depuis quelques temps, les processeur Intel et AMD embarque les instructions RDRAND et RDSEED. D’après ce que je lis, ces instructions implique la présence d’une source d’entropie matérielle. Qu’en est-il vraiment de cette source d’aléatoire ? Qu’est ce qu’elle vaut ?
#14.1
Du point de vue physique, ça utilise le bruit thermique sur un composant électronique (diode ?). Pour le dire rapidement, c’est le penchant du mouvement brownien pour les fluides. Donc oui, ça a un comportement considéré comme aléatoire d’un point de vue statistique.
#14.3
Thx.
Pour RDSEED, ça semble dire ce que ça veux dire : générer une seed pour un générateur pseudo-aléatoire.
#14.2
Intel dit : “RDSEED is intended for seeding a software PRNG of arbitrary width. RDRAND is intended for applications that merely require high-quality random numbers.”
En gros, RDSEED doit être utilisé pour de l’aléa “simple” (ex : dans des jeux), RDRAND doit être utilisé quand on a besoin de nombres aléatoires de haute qualité (genre crypto).
Intel dit ensuite qu’ils se conforment aux standards NIST SP800-90x, mais ce ne sont que des recommandations, donc ça ne veut pas dire grand chose.
Néanmoins, ces recommandations insistent bien sur la source d’entropie (cf. NIST SP800-90B), et là on voit que ça n’est pas simple d’avoir une source fiable… Donc difficile d’évaluer simplement ces fonctions, sauf si un jour elles sont certifiées sur des bases très strictes, genre critères communs.
#15
Quoi ? Copier “srand(time(NULL))” depuis stackoverflow c’était pas bon ? Mince…
#15.1
Si si c’était bon, mais pas pour le copieur
#16
Kaspersky, l’antivirus qui faisait du man-in-the-middle sur mon PC pro.
Il interceptait et resignait tout le trafic HTTPS qui passait … (j’imagine que d’autres le font aussi).
“n’était possible que dans le cas improbable où l’attaquant connaissait les informations du compte de l’utilisateur et l’heure exacte à laquelle un mot de passe avait été généré.”
Ca reste quand même vraiment à la marge pour le coup non ? Dans tous les cas, si le pirate a ces infos, c’est qu’il y a un autre problème plus gros à côté j’imagine.
#16.1
C’est pas plutôt le proxy de l’entreprise qui était en cause ?
#17
Du coup, la protection était aléatoire
#18
Mauvaise pioche alors, parce que la honte, c’est eux qui vont se la taper.