macOS, contournement enfantin du mot de passe root / CVE-2017-13872

Dans le même esprit que la vulnérabilité ridicule concernant Fortinet où il est possible de se connecter en administrateur juste en se trompant de mot de passe, Apple a décidé d’aller plus loin !

Parmi les innovations de macOS High Sierra 10.13.1 et 10.13.2, on trouve le fait de pouvoir élever ses privilèges localement en devenant root grâce au fait de « ne pas saisir de mot de passe » lorsque c’est demandé, c’est beau !
Lorsque vous avez besoin de modifier le système, il peut vous être demandé de saisir le mot de passe « root », il suffit alors de… ne rien saisir 😉

alt

D’ailleurs, il y a deux semaines, cette problématique (ou fonctionnalité, c’est selon le point de vue 😂) a même été proposée comme une astuce sur le forum officiel d’aide d’Apple.

alt
alt

Le problème semble venir du fait que si le compte « root » n’a pas été initialisé et qu'aucun mot de passe ne lui a été mis, alors, lors de la première demande d’élévation de privilèges pour modifier une configuration, le système va activer le compte « root » avec comme mot de passe une chaîne de caractère vide (celle venant de la zone de saisie laissée vide).

Apple a confirmé le problème mais sans détailler l’origine, en dehors d’un problème de logique.

Impact

La vulnérabilité est locale mais si un utilisateur a déjà modifié les paramètres de son mac alors son utilisateur « root » est activé et dispose d’un mot de passe vide.

Localement, le risque est avéré. Sur un mac verrouillé, il est possible d’ouvrir une session en tant que « root », sans mot de passe.

Sur le réseau, il y a plusieurs services à risques :

  • SSH : le risque est limité et ne peut pas être exploité à distance par défaut. En effet, par défaut, le service d’accès à distance (SSH) est désactivé. Si l’utilisateur a quand même activé SSH, l’utilisateur « root » n’a pas le droit de se connecter directement, sauf si l’utilisateur a lui-même modifié le fichier de configuration du service SSHD 😉 ;
  • Partage d’écran (le VNC d’Apple) : tout comme pour SSH, le risque est limité car le service n’est pas activé par défaut. Par contre, pour les gens ayant activé ce service et ayant récemment connecté leur mac sur Internet, il y a un risque car de nombreuses personnes se sont mises à scanner internet à la recherche de macOS vulnérables, sont tombées sur des systèmes vulnérables et ont activé le mot de passe vide pour le compte root 😃 ;
    alt
  • ARD : le risque est limité avec le service de partage d’écran Apple Remote Desktop qui n’est pas activé par défaut et est vendu $89. A titre d’information, il est possible de s’y connecter avec n’importe quel compte, dont le « root », pour prendre le contrôle de l’écran, de la souris et du clavier, mais également de faire des exécutions de processus, sans que l’utilisateur soit notifié ;
  • _uucp : le service de transfert de fichiers Unix-to-Unix Copy semble activé par défaut et accessible pour n’importe quel compte, dont le « root ».

Solution

A présent que le correctif est disponible, il faut mettre à jour son système.
Sinon, le seul contournement est de changer le mot de passe du compte root soit même.

Conclusion

La question se pose de savoir comment une chose pareille à pu passer les tests fonctionnels d’Apple… mais n’y connaissant personne, je n’ai pas la réponse.
Je vais simplement conclure en disant que c’est bientôt noël et que pour nous faire patienter, papa noël a surement décidé d’offrir pleins de cadeaux à ses hackeurs préférés 😃 .