Mots de passe aléatoires : Synology se fait avoir par des dés pipés, un problème pourtant connu

Mots de passe aléatoires : Synology se fait avoir par des dés pipés, un problème pourtant connu

Moins pire que admin/admin

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

24/10/2023 9 minutes
22

Mots de passe aléatoires : Synology se fait avoir par des dés pipés, un problème pourtant connu

La semaine dernière, une faille de moyenne sévérité du DiskStation Manager (DSM) de Synology a été détaillée. Dans certaines circonstances, il était possible de prendre en défaut la génération de nombres pseudo-aléatoires et d’exploiter cette faiblesse pour obtenir l’accès au compte administrateur. Bien que corrigée, la faille permet certains rappels importants.

La vulnérabilité a été révélée par l’équipe Team82 de Claroty Research, plus particulièrement quatre chercheurs, Vera Mens, Uri Katz, Noam Moshe et Sharon Brizinov. Dans un billet publié le 17 octobre, cette équipe explique avoir découvert un problème en lien avec un générateur de nombres pseudo-aléatoires « faible » ainsi qu’une méthode considérée comme pas assez sécurisée.

Les chercheurs indiquaient alors : « Dans certaines conditions rares, un attaquant pourrait laisser filtrer suffisamment d'informations pour restaurer la graine du générateur de nombres pseudo-aléatoires (PRNG), reconstruire le mot de passe administrateur et prendre le contrôle à distance du compte administrateur ».

Cette faille pouvait être exploitée dans le DiskStation Manager (DSM) de Synology, qui a déjà corrigé le problème. En fait, la faille a été bouchée en juin pour le DSM, via la version 7.2-64561. En revanche, elle est présente aussi dans le Synology Router Manager (SRM) 1.3, sur lequel le travail est toujours en cours.

Un générateur de nombres pseudo-aléatoires ?

Ce type de générateur est communément désigné sous l’appellation de PRNG, pour « pseudorandom number generator ». Ils occupent une place essentielle dans le monde de la sécurité informatique, car ils sont chargés de fournir des nombres aussi aléatoires que possible aux fonctions cryptographiques qui en ont besoin.

Mais pourquoi dire « aussi aléatoires que possibles » ? Un nombre ne serait-il pas soit aléatoire, soit déterminée ? C’est toute la question. On parle de nombres pseudo-aléatoires car l’objectif des fonctions responsables de cette génération ont pour mission de s’approcher autant que possible d’un hasard absolu. Mais il est très difficile d’atteindre ce dernier, car les PRNG sont des méthodes déterministes, donc des suites d’opérations clairement établies, du simple fait que les ordinateurs soient des machines déterministes.

Ces nombres peuvent tout à fait apparaître comme aléatoires à un être humain. Mais en creusant un peu, particulièrement quand l’informatique s’en mêle, on peut trouver des « patterns », jusqu’à pouvoir retrouver la méthode utilisée et son fonctionnement, plus particulièrement sa périodicité. Cette dernière est un élément-clé dans l’étude de la robustesse d’un PRNG, via des méthodes statistiques.

L’un des points importants à retenir pour la suite est qu’un générateur de nombres pseudo-aléatoires a besoin d’un état de départ pour démarrer ses opérations. Cet état est nommé « graine », que l’on rencontre souvent sous le nom anglais « seed ». Si l’un ou l’autre de ces mots vous semble familier, c’est qu’on les retrouve fréquemment dans des jeux vidéo, dès lors que ces derniers incluent la génération aléatoire de niveaux ou de cartes. Minecraft est un exemple classique, mais on peut l’étendre à tous les jeux disposant d’un système de « loot » ou de plages de dégâts (on parle plus communément de RNG).

Dans ce domaine, la sécurité est considérée comme brisée dès que l’on connait la graine et l’algorithme utilisé, car il devient dès lors possible de deviner le prochain nombre pseudo-aléatoire. Pour contourner ce problème, on introduit des variables considérées comme aléatoires selon les cas : les mouvements de la souris avant une opération, le bruit d’un ventilateur, le nombre de microsecondes écoulées depuis la dernière seconde, ou même les mouvements de matière dans une lampe à lave. C’est ce que l’on appelle l’entropie : un degré plus ou moins élevé de désorganisation dans une structure pour repousser l’ordre, donc le déterminisme. En clair, elle représente le degré de hasard.

Où est cette faille ?

Maintenant que l’on a rappelé quelques éléments cruciaux sur les PRNG, voyons où réside la vulnérabilité. Principalement dans l’utilisation de la méthode JavaScript Math.Random(), dont la documentation informe d’ailleurs qu’elle n’est pas considérée comme « sûre » pour les usages cryptographiques, et qu’il ne faut donc pas s’en servir pour tout ce qui touche à la sécurité.

Or, cette méthode est utilisée pour créer automatiquement un mot de passe « aléatoire » sur le compte administrateur, lors de la phase d’initialisation de la première utilisation (ou après réinitialisation complète de l’appareil). S’il n’est pas modifié manuellement par l’utilisateur, il reste donc en place.

Problème, puisque Math.Random() n’est pas considéré comme robuste, il est prévisible. Tout ce qu’il y aurait à faire serait alors de récupérer les valeurs émises par la méthode. Ce qui est possible durant l’assistant de configuration, car DSM demande la création d’un nouveau compte disposant de privilèges administrateurs.

Un mot de passe est proposé automatiquement, lui aussi généré par Math.Random() côté client. Le modèle est simple, basé sur un nombre de caractères égal à un nombre aléatoire auquel on ajoute 16. Le premier caractère sera toujours un chiffre aléatoire, le deuxième une lettre minuscule aléatoire, le troisième une majuscule aléatoire, le quatrière un caractère spécial, puis le reste est rempli « au hasard », avant qu’un nombre aléatoire de caractères soient remplacés de manière aléatoire.

C’est en étudiant les valeurs générées que les chercheurs se sont rendu compte de la périodicité et de la faille.

Une exploitation complexe limitant la dangerosité

La faille CVE-2023-2729 est classée 5,9, témoignant d’une sévérité moyenne. Son exploitation, bien que complexe, n’est pas non plus impossible.

Pour que l’attaque fonctionne, il faut qu’un acteur malveillant réussisse d’abord à extraire plusieurs GUID générés à l’aide de la méthode Math.Random() durant le processus d’installation. La possession de ces informations peut conduire à la reconstruction de la graine du générateur de nombres pseudo-aléatoires.

À partir de là, il serait possible de retrouver le mot de passe généré aléatoirement pour le compte administrateur.

Mais alors, les portes des NAS équipés de DSM seraient-elles toutes grandes ouvertes ?

Non, car si les produits de Synology ont bien un compte administrateur, il est désactivé par défaut. Pour exploiter la faille, il faut donc trouver des équipements sur lesquels ce compte est actif, et que le mot de passe n’ait pas été modifié par son utilisateur.

Si la faille est réelle, son exploitation est bien plus théorique. L’équipe Teams82 de Claroty Research l’indique d’ailleurs clairement à la fin de son billet : « Nous avons découvert cette vulnérabilité lors de la préparation de Pwn2Own, ce qui nous a permis de nous rendre compte rapidement qu'il serait pratiquement impossible de l'exploiter dans une situation réelle. Quoi qu'il en soit, nous avons pensé qu'il serait approprié d'écrire à ce sujet afin de souligner l'importance de l'utilisation de nombres aléatoires cryptographiquement sécurisés lors de la génération de mots de passe ».

Générateurs de nombres pseudo-aléatoires : quel est le problème ?

Le cœur du sujet n’est finalement pas la faille elle-même, en dépit de son existence très concrète. Synology a corrigé le tir rapidement sur ses NAS (reste les routeurs) et l’équipe de recherche n’a publié ses résultats qu’après un certain temps, pour s’assurer que la plupart des produits concernés seraient mis à jour au moment des explications publiques.

Comme les chercheurs l’indiquent, le thème important est celui des générateurs proprement dits et de leur utilisation. Certains sont plus robustes que d’autres : « Encore une fois, il est important de se rappeler que Math.random() ne fournit pas de nombres aléatoires cryptographiquement sûrs. Ne l'utilisez pas pour tout ce qui touche à la sécurité. Utilisez plutôt l'API Web Crypto, et plus précisément la méthode window.crypto.getRandomValues() », explique ainsi la Team82.

Ceux qui nous suivent depuis longtemps savent que ce sujet revient régulièrement sur le tapis dans le monde de la sécurité. On pourrait citer des mises à jour en 2016 pour GnuPG et Libgcrypt car le PRNG utilisé n’était pas assez fiable, avec d'importantes conséquences potentielles. Les nombres pseudo-aléatoires sont en effet utilisés pour la création des empreintes (hash) et autres fonctions cryptographiques. On peut alors aboutir à une collision, terme employé pour signifier le pire des scénarios : deux entrées différentes, un résultat identique, avec tous les problèmes que l’on imagine en matière d’authentification.

En 2019, on se souvient que Cloudflare avait créé la League of Entropy pour réunir des acteurs autour de ce sujet. Objectif alors, mettre en commun des efforts et mélanger les sources d’entropie pour obtenir des nombres encore plus aléatoires.

Autre exemple, la correction en 2021 d’un grave souci de sécurité chez Kaspersky, dont le gestionnaire de mots de passe utilisait alors un générateur de nombres pseudo-aléatoires très en deçà des standards. Les chercheurs expliquaient alors que la seule source d’entropie était… l’heure au moment de la génération.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Un générateur de nombres pseudo-aléatoires ?

Où est cette faille ?

Une exploitation complexe limitant la dangerosité

Générateurs de nombres pseudo-aléatoires : quel est le problème ?

Fermer

Commentaires (22)


Et ce sous réserve d’avoir utilisé le générateur de mdp de synology… Ça fait encore un peu de marge.


Très chouette article ! :yes:


effectivement ca fait des années que synology persuade de laisser le compte admin désactivé :inpactitude:


Un autre générateur d’entropie pourrait tout aussi bien être utilisé : le bruit blanc (ou rose, ou…).



Tous ceux qui touchent de près ou de loin à l’audio, au mixage et à la synthèse musicale analogique savent ce qu’est le bruit blanc : un son, généré par un… générateur (un circuit électronique), qui peut contenir toutes les fréquences audibles (de 20 à 20Khz) en même temps… mais cet état est plutôt rare. Ce qui arrive (avec un générateur de son analogique, pas numérique), c’est qu’il est impossible de prédire quel ensemble de fréquences va être généré à un instant T.



C’est pour cela qu’il est très utilisé en musique électro, pour imiter le vent ou les vagues, mais notamment comme source pour un module de synthétiseur que l’on appelle “sample and hold”: un circuit électronique très simple qui va se baser sur le bruit blanc pour générer des sons / notes de hauteur totalement aléatoires et imprévisibles, un “effet” qui est très utilisé en musique électro “traditionnelle” (écouter Kraftwerk, Klaus Schulze, les vieux albums de Tangerine Dream…)



Ce module “sample and hold” fonctionne de la façon suivante : il échantillonne du bruit blanc à un instant T, et délivre en sortie une tension, tension qui va commander la hauteur d’un oscillateur (ou l’ouverture d’un filtre, ou…), ce qui génère donc des hauteurs de notes imprévisibles.



Pour en revenir à notre sujet de fond (la sécurité) j’avais lu il y a un bail une thèse proposant d’utiliser de tels générateurs - analogiques - de bruit blanc pour générer des mots de passe ou des clés de chiffrement réellement aléatoires.



Pourquoi est-ce important que ces générateurs de bruit soient analogiques et pas numériques ? parce que tous les vrais amateurs de synthèse ou encore les “sound designers” (c’est un vrai métier, excessivement bien payé) vous expliqueront que par essence, l’électronique numérique est… prévisible, je veux dire par là qu’un générateur de bruit blanc numérique a tendance à générer en fait des patterns de bruits qui se répètent, plutôt que du “vrai” bruit aléatoire.



Mais vu la simplicité du concept, un tel générateur analo pourrait très bien être miniaturisé à l’extrême, et sa sortie numérisée pour générer… du vrai bruit numérique ! Bruit numérique qui pourrait très bien servir de base à la génération de nombres garantis aléatoires.



(reply:2161495:DantonQ-Robespierre)




:yes:



Les CPU modernes ont un générateur de nombre aléatoire “matériel” basé sur l’observation du bruit thermique dans le cpu.



https://www.intel.com/content/www/us/en/developer/articles/guide/intel-digital-random-number-generator-drng-software-implementation-guide.html:




[The entropy source] uses thermal noise within the silicon to output a random stream of bits at the rate of 3 GHz




(reply:2161472:Fab’z)




Et de ne pas forcé le changement de mot de passe à la première connexion en prime :oops:



Intéressant tiens, merci :smack:



En truc Random pas Rarndom y’avait eu les modules crypto dans Debian avant tous ceux sités dans l’article.
Le changement de clés SSH en prod avait du être sympa chez certains …
Ca m’avait valu de grands moment de mon côté.


Sous les *nix / dev/random est assez fiable, sa seed est basée sur des relevés de tout ce qui est externe au PC (mouvement de la souris, temps depuis la dernière erreur de lecture ou la dernière frappe de clavier, la dernière interruption CPU…) ces sources sont mixées puis hachées afin de proposer un nombre aléatoire.
En hardware, on a aussi les TPM dont c’est la raison d’être !
Côté logiciel, plusieurs algos arrivent à une bonne entropie, le problème étant que la charge CPU augmente avec l’entropie.



Bref Math.random() est parfait (rapide) pour un truc qui semble aléatoire sans lien avec la sécurité, pour le reste c’est Crypto.getRandomValues() qui est beaucoup plus lourd niveau CPU mais nettement mieux sécurisé.



Ce qui est dingue c’est que ce point est quand même clairement documenté :




Note: Math.random() does not provide cryptographically secure random numbers. Do not use them for anything related to security. Use the Web Crypto API instead, and more precisely the window.crypto.getRandomValues() method.



C’est fou hein !
Et pourtant ce sujet va continuer à revenir pour les décennies à venir…



Il est pourtant loin le temps où générer des valeurs pseudo-aléatoires sécurisées était dur et où il fallait manuellement initialiser le moteur avec suffisamment d’entropie pour que la sortie en ait elle aussi suffisamment.



Et puis, quand des petits malins “optimisent” le code manipulant des PRNG, ça donne des situations caustiques.
Vous souvenez-vous des clés Debian vulnérables en 2006, détectées en 2008 ? Une “optimisation” OpenSSL.



(reply:2161495:DantonQ-Robespierre)




Tout est une question de coût (et d’encombrement) tu ne vas pas inclure un générateur de bruit blanc analogique dans un SoC de téléphone ;)



(quote:2161495:DantonQ-Robespierre)

(écouter Kraftwerk, Klaus Schulze, les vieux albums de Tangerine Dream…)




Oh ! Il y a encore des gens qui connaissent…
Il ne manque que Popol Vuh…
:phibee:
:copain:



fofo9012 a dit:


Sous les *nix / dev/random est assez fiable, sa seed est basée sur des relevés de tout ce qui est externe au PC (mouvement de la souris, temps depuis la dernière erreur de lecture ou la dernière frappe de clavier, la dernière interruption CPU…) ces sources sont mixées puis hachées afin de proposer un nombre aléatoire.




Oui, mais attention, comme le disait janiko :




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…



je pense qu’il y’a confusion entre /dev/random et /dev/urandom ;-)


Les Raspberry Pi ont un générateur aléatoire matériel, mais côté Linux il y a souvent eu une méfiance envers ces générateurs dont l’implémentation n’est pas publique.



Il est possible d’avoir soit un démon userspace comme rngd, qui lit /dev/hwrng pour alimenter le kernel en entropie.



Il est aussi possible de donner le paramètre rng_core.default_quality=1024 au kernel (>= 3.16), pour qu’il se serve du générateur pour alimenter le pool d’entropie quand il y en a besoin.
A partir du kernel 6.2, c’est d’ailleurs le comportement par défaut : https://github.com/torvalds/linux/commit/16bdbae394280f1d97933d919023eccbf0b564bd.


il y a pas mal de temps, j’étais tombé sur un article évoquant ce problème et un mec qui prenait des images d’une “Lava Lamp” pour son générateur de nombre aléatoire. J’avais trouvé cette approche un peu “too much” jusqu’à mieux comprendre le sujet évoqué ici.
Il n’y a rien de mieux que l’analogique pour générer simplement de l’aléatoire.


Cloudflare utilisé la méthode des lampes à lave dans son siège pour générer de l’aléa. L’article décrit d’ailleurs assez bien pourquoi et comment.


Il y a https://www.random.org/randomness/ qui traite le sujet des “True Random Number Generator”.



(reply:2161502:wagaf) Heeey, merci beaucoup, passionnant ! Comme quoi ils sont parfaitement conscient des limites du numérique, qui est, par essence, par conception, prévisible.



(reply:2161507:fofo9012) Eh bien détrompe-toi, comme je dis plus haut, vu la simplicité du circuit en question, il est parfaitement possible de le miniaturiser sous la forme d’un microscopique composant CMS, tout à fait intégrable dans un téléphone.




Le principe théorique serait le suivant : générateur -> convertisseur A/N -> bus CPU.



Il faudrait en fait que le processeur aie une broche “RND” spécialement prévue pour cet usage, qu’il échantillonnerait régulièrement afin de générer une entropie scientifiquement démontrable.


J’aime bien cet article qui se base sur une actu pour éélargir le sujet :yes:



(quote)
Synology a corrigé le tir rapidement sur ses NAS (reste les routeurs)




Euh non, reste tous les NAS en version 7.1 et inférieurs et il en reste un paquet…
Et ils marquent bien qu’ils ne feront pas de corrections pour ceux là


N’empêche c’est fou le nombre d’alertes relatives type “weak cryptography” basées sur du nombre pseudo aléatoire que je vois passer dans les analyses SAST de développements. Sur les projets que j’ai fait analyser j’en ai jamais eu un seul qui n’en remontait pas (par contre certains étaient des faux positifs, mais plus liés à une mauvaise idée).


La news passe et le Nas de mes parents prends des tentatives de connexion :transpi:



Pas de bol, les règles en place font que les mecs se sont fait bouler comme des mal propres :mdr2:


Des circuits électroniques légers pour générer de l’aléatoire, ça existe :
https://fr.m.wikipedia.org/wiki/G%C3%A9n%C3%A9rateur_de_nombres_al%C3%A9atoires_mat%C3%A9riel
Leur débit est limité, mais pour générer une clé et un mot de passe de temps en temps, c’est très pratique.
Y’avait ça de base sur mon DAI (c’est du matos de l’âge de Kraftwerk, Konrad Schnitzler et autres 😉). Autrement dit : messieurs les constructeurs, allez-y, régalez-nous. 🙂