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.