Steam Windows Client Local Privilege Escalation 0day

Je recherche des vulnérabilités depuis de nombreuses années, et il semblerait que j'en ai vu beaucoup, mais il y a une telle partie du travail à laquelle je ne peux pas m'habituer et que je ne peux pas comprendre. Il s'agit d'une réticence absolue des fournisseurs à accepter des informations sur les vulnérabilités et les problèmes. Je comprends que c'est très désagréable quand ils vous montrent directement que vous avez fait une erreur et, probablement, pas une. Il est désagréable de confirmer publiquement dans des sources ouvertes qu’il y avait des problèmes, que les employés ne travaillaient pas. Mais je ne comprends pas pourquoi les informations de vulnérabilité doivent être rejetées.


Ainsi, le héros de notre histoire est Steam from Valve. Et la vulnérabilité d'élévation de privilèges, qui permet à tout utilisateur d'exécuter des commandes au nom de NT AUTHORITY \ SYSTEM.

Vulnérabilité

La vulnérabilité elle-même est assez simple. Steam installe le service «Steam Client Service» pour son travail. Jetez un œil au descripteur de service SDDL :

O:SYG:SYD:(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;RPWP;;;BU)

Ici, nous nous intéressons à la partie (A ;; RPWP ;;; BU). Dans ce cas, cette entrée signifie que tout utilisateur du groupe Utilisateurs peut démarrer et arrêter le service.
Voyons ce que fait le service au démarrage. Pas très intéressant, mais certaines opérations semblent inhabituelles - le service répertorie le contenu de la section HKLM \ SOFTWARE \ Wow6432Node \ Valve \ Steam \ Apps et définit certains droits pour toutes les sous-sections.



Je me demande quel genre de droits sont exposés? Nous créons une clé de test, démarrons le service (journal de procmon ci-dessus) et voyons ce qui est bien. Ici, il est également découvert que la section HKLM \ SOFTWARE \ Wow6432Node \ Valve \ Steam a des droits d'accès complets pour tous les utilisateurs hérités de toutes les sous-clés. Une hypothèse est née que les mêmes droits seront définis pour toutes les sous-sections de HKLM \ SOFTWARE \ Wow6432Node \ Valve \ Steam \ Apps via un appel à RegSetKeySecurity . Mais que faire s'il y a un lien symbolique dans le registre et que la branche HKLM \ SOFTWARE \ Wow6432Node \ Valve \ Steam \ Apps \ test pointera, par exemple, vers HKLM \ SOFTWARE \ test2 ?

Nous vérifions et voyons que les droits dans le cas d'un lien symbolique sont enregistrés pour la branche de registre cible.



Nous vérifions les droits de la branche cible et voyons dans le formulaire SDDL (sauter sans intérêt):

(A;ID;KA;;;BU)(A;OICIIOID;GA;;;BU)

Sous forme verbale, cela signifie que l'accès complet (lecture et écriture) pour tous les utilisateurs. Ce sont les droits que le service Steam a prescrits à la succursale.

Maintenant que la primitive est prête à prendre le contrôle de presque toutes les branches de registre, il est facile de lancer PoC. J'ai choisi la branche HKLM \ SYSTEM \ ControlSet001 \ Services \ msiserver - elle correspond au service "Windows Installer", qui peut également être démarré par l'utilisateur, mais le service fonctionnera avec les privilèges NT AUTHORITY \ SYSTEM. Après avoir pris le contrôle de la branche HKLM \ SYSTEM \ ControlSet001 \ Services \ msiserver, nous modifions le chemin d'accès à l'exécutable dans la clé ImagePath et démarrons le service msiserver. Notre fichier exécutable est lancé avec les autorisations les plus élevées possibles - NT AUTHORITY \ SYSTEM.

Nous collectons tout ce qui est écrit ci-dessus dans le code et obtenons une simple élévation de privilèges sur tout ordinateur Windows où Steam est installé.

Rapport de vulnérabilité

J'ai envoyé un rapport de vulnérabilité à Valve via Hackerone.

Ici, la première surprise m'attendait - avant de transférer la vulnérabilité directement à Valve, je devais d'abord convaincre le personnel hackerone que j'avais vraiment un rapport de vulnérabilité, car Valve utilisait la fonction "Managed by HackerOne" . Cela ne me dérange pas - j'ai PoC, qui appelle la console au nom de NT AUTHORITY \ SYSTEM - des preuves sur le visage. Et je reçois un déni dans le rapport. La raison indique que mon rapport est en dehors de la portée de la recherche, car "Les attaques qui nécessitent la possibilité de déposer des fichiers à des emplacements arbitraires sur le système de fichiers de l'utilisateur." (une attaque nécessite la possibilité de localiser des fichiers dans des chemins de système de fichiers arbitraires). Ma réaction: "Je n'ai même pas une seule opération de système de fichiers, mais un échec pour cette raison, vraiment?"

J'écris un commentaire à ce sujet et un autre employé arrive, qui s'engage néanmoins à vérifier la vulnérabilité. Le confirme et passe Valve. Hourra, l'objectif est atteint. Ou pas ...?

Le temps passe et le rapport est à nouveau marqué comme non applicable. Motifs: «Attaques qui nécessitent la possibilité de déposer des fichiers à des emplacements arbitraires sur le système de fichiers de l'utilisateur» et «Attaques qui nécessitent un accès physique à l'appareil de l'utilisateur» (l'attaque nécessite un accès physique à l'appareil de l'utilisateur). Ensuite, j'ai réalisé que les attaques par escalade de privilèges n'étaient tout simplement pas intéressantes pour Valve.


Étant donné que 45 jours se sont écoulés depuis le rapport, j'ai décidé de divulguer publiquement les détails de la vulnérabilité, même si je ne suis pas sûr que cela encouragera les développeurs Steam à apporter des modifications.

Petites statistiques: la vulnérabilité a été testée sur Windows 8 x64, Windows 8.1 x64 et Windows 10 x64. Je ne connais pas les fonctionnalités de numérotation des versions du logiciel Steam, je vais donc corriger la version des composants de service:

• SteamService.dll (5.16.86.11, signé par Valve le 14/06/2019)
• SteamService.exe (5.16.86.11, signé par Valve le 14/06/2019)

Chronologie:

15 juin - rapport de vulnérabilité envoyé.
16 juin - Rejeté, "Attaques qui nécessitent la possibilité de déposer des fichiers à des emplacements arbitraires sur le système de fichiers de l'utilisateur."
16 juin - redécouvert avec commentaire.
2 juillet - confirmé par un employé de HackerOne, transféré à Valve.
20 juillet - Rejeté, "Attaques qui nécessitent la possibilité de déposer des fichiers à des emplacements arbitraires sur le système de fichiers de l'utilisateur.", "Attaques qui nécessitent un accès physique à l'appareil de l'utilisateur."
7 août - Cet article a été publié.

Un peu de spéculation

Je suis très déçu. Une entreprise sérieuse qui écrit des mots pompeux que la sécurité est importante ouvre votre ordinateur pour un accès maximal à tous les programmes que vous exécutez.

Il est plutôt ironique de constater qu’un lanceur, qui est en fait conçu pour exécuter des programmes tiers sur votre ordinateur, leur permet d’obtenir discrètement le maximum de privilèges. Êtes-vous sûr qu'un jeu gratuit créé à genoux par un développeur inconnu se comportera honnêtement? Croyez-vous que pour une remise de 90%, vous n'obtiendrez pas de mineur caché? Bien sûr, certaines menaces subsisteront tout en travaillant sans droits d'administrateur, mais les droits élevés des programmes malveillants peuvent gâcher considérablement les nerfs - désactiver l'antivirus, le fixer aux démarrages du système, modifier presque tous les fichiers, tous les utilisateurs.

En raison de la popularité de Steam, le nombre de victimes potentielles est très élevé. En 2015, le nombre de comptes Steam actifs était estimé à 125 millions. Oui, tous les utilisateurs de Steam n'ont pas de système d'exploitation Windows, mais la plupart en ont certains, et certains utilisateurs ont plusieurs comptes "en direct" sur la même machine. Mais l'ampleur du problème est toujours impressionnante.
Ou peut-être que tout cela est exprès? Peut-être que Steam est une sorte de porte dérobée légale? Il est impossible d'établir cela exactement, mais comparons les faits:

1. Il existe une vulnérabilité facile à exploiter (et, à en juger par les messages sur Twitter , pas une).
2. Il est assez facile à repérer - je ne suis pas sûr d'avoir été le premier à le trouver, mais au moins le premier je l'ai décrit publiquement.
3. Réticence à accepter un rapport sur de telles vulnérabilités et similaires (la portée est spécialement choisie pour que l'escalade de privilèges en tombe).

Je n'aime vraiment pas tout ça. Je ne vous inciterai pas à supprimer Steam, mais je propose d'être très prudent avec ce qu'il fait. Votre sécurité est en jeu.

Bonus

Le fait est que dans le processus de préparation de cet article, un événement assez intéressant s'est produit, à propos duquel j'ai décidé de compléter la chronologie.

20 juillet - après avoir rejeté le rapport, j'ai prévenu h1 que je divulguerais publiquement les détails de la vulnérabilité après le 30 juillet.
2 août - un autre employé du premier semestre est signalé dans un rapport fermé et dit qu'il ne me permet pas de divulguer.

Cet article a été préparé pour publication le 30 juillet (cette date a été choisie au rythme de 45 jours après l'envoi du rapport), mais a été retardé. Et donc, deux semaines plus tard à partir de mon message du 20 juillet, une personne apparaît qui me dit: «nous ne donnons pas la permission de révéler la vulnérabilité». En fait, il s'avère que nous avons marqué votre rapport comme inapproprié, nous avons clos la discussion, nous n'avons pas jugé nécessaire de vous expliquer quoi que ce soit et nous ne voulons tout simplement pas que vous le publiiez. Il n'y a pas un seul mot de Valve. Pas de gars, ça ne marchera pas. Vous n'avez pas respecté mon travail, je ne respecterai pas le vôtre - je ne vois aucune raison de ne pas publier ce rapport pour tout le monde. Très probablement, je serai banni sur h1 à cause de cela, mais je ne serai pas contrarié.

UPD Il s'avère hier (6 août) que la mise à jour Steam a été publiée. Non, cela n'a rien arrangé.
Version du fichier: signature du 5.27.59.20 du 08/08/2019.

Après la divulgation

Nous continuons à mettre à jour la chronologie:

7 août (après publication) - le rapport sur le premier semestre a été redécouvert. J'ai reçu une lettre dont il est difficile de résumer l'essentiel, mais le plus important est que certains arguments convaincants doivent être tirés pour conclure que les conséquences de la vulnérabilité sont importantes. Il y avait "Valve ne va pas réparer quelque chose qu'ils ont déterminé être N / A." Ces mots ont une fois de plus confirmé ma conviction que j'ai raison en ce que j'ai procédé à une divulgation publique des détails.

7 août - Matt Nelson écrit que la vulnérabilité qu'il a signalée est exactement la même que la mienne. Ce qui confirme ma thèse sur la facilité de la trouver. Il ouvre son PoC .


9 août - Steam Beta reçoit une mise à jour où l'une des lignes est «Exploitation d'une escalade de privilèges fixe à l'aide de liens symboliques dans le registre Windows». On soupçonne que le correctif peut être contourné, mais pour l'instant faire le plein de pop-corn.

13 août - Steam reçoit une mise à jour où l'une des lignes est «Exploitation d'une escalade de privilèges fixe à l'aide de liens symboliques dans le registre Windows». Il semble que le service n'expose pas de droits sur le registre, nous pouvons donc supposer qu'il est fixe.

15 août - le chercheur a montré que le patch peut être contourné , la vulnérabilité est toujours d'actualité. Raccourci - vous pouvez renvoyer la version précédente (avant le correctif) du service.

20 août - Valve m'a interdit dans leur programme sur H1. Le reste du H1 est à ma disposition.

Cet article en anglais.