Dans la série précédente
Il n'y a pas si longtemps,
j'ai publié une description de la vulnérabilité de Steam. J'ai reçu beaucoup de commentaires des lecteurs. Valve n'a pas dit un mot, et HackerOne a envoyé une énorme lettre en larmes et, fondamentalement, était silencieux. En conséquence, Valve m'a interdit sur H1 - je ne peux pas participer à leur programme pour rejeter les vulnérabilités (le reste de H1 est à ma disposition).

Vous pouvez en savoir plus sur l'histoire dans une publication précédente, ici, je vais dire quelques mots sur l'état actuel.
Mais c'est simple et triste - Valve échoue toujours. La dernière mise à jour, conçue pour résoudre le problème, est
facilement contournée et la vulnérabilité est toujours d'actualité. Oui, je l'ai vérifié - cela fonctionne très bien.
Mais cet article ne porte pas sur le fait que l'ancienne vulnérabilité est toujours présente, mais sur la nouvelle. Puisque Valve a une fois de plus exprimé le désir de lire un rapport public, au lieu d'un rapport privé, nous ne les priverons pas de ce plaisir.
Brève description de la vulnérabilité
Une description générale de l'exploitation de la vulnérabilité est assez simple et comprend trois étapes:
- Nous préparons l'environnement pour le fonctionnement (jusqu'à deux façons de choisir, en utilisant différentes failles de sécurité).
- Obtenez Steam pour copier et exécuter notre DLL.
- La DLL doit répondre à de petites exigences.
Toutes ces actions peuvent être effectuées par n'importe quel utilisateur du système d'exploitation, ou plus précisément, n'importe quel programme sur l'ordinateur. Par conséquent, vous pouvez
exécuter n'importe quel code avec des privilèges maximaux , cette classe de vulnérabilités est appelée escalade de privilèges (eop) ou escalade de privilèges locale (lpe). Malgré le fait que toute demande en elle-même puisse faire du tort, l'obtention de droits maximaux entraînera des conséquences beaucoup plus importantes. Désactiver l'antivirus et le pare-feu, installer un rootkit, masquer le processus mineur, voler les données personnelles de tous les utilisateurs de PC n'est qu'une petite partie de ce à quoi vous pouvez penser.
Minimum théorique
C'était très drôle de regarder les commentaires sur l'article précédent, où les gens écrivaient «L'utilisateur ne peut pas écrire les clés de registre dans HKLM» ou «Les droits d'administrateur sont nécessaires pour créer un lien symbolique». Fait intéressant, la vérification de ces allégations ne prendra guère plus de temps que la rédaction d'un tel commentaire. Et, oui, juste au cas où: les deux affirmations sont fausses. Par conséquent, dans cet article, j'ai décidé de faire une petite section où j'ai décrit un certain nombre de moments difficiles de l'opération.
"Vous ne pouvez pas écrire dans la clé de registre HKLM"
Il n'y a pas une telle règle générale. Il existe des règles de sécurité spécifiques pour des clés de registre spécifiques. Valve a défini des droits d'accès complets pour tous les utilisateurs à la branche
HKLM \ SOFTWARE \ Wow6432Node \ Valve \ steam , et par conséquent, tout utilisateur peut faire ce qu'il veut dans cette branche.
"Vous ne pouvez pas démarrer ou arrêter un service sans droits d'administrateur"
Il n'y a pas une telle règle générale. Il existe des règles de sécurité spécifiques pour des services spécifiques. Valve a défini les droits afin que le service client Steam puisse être démarré et arrêté par n'importe quel utilisateur.
"Pour créer un lien symbolique, vous avez besoin des droits d'administrateur"
C'est une question amusante en soi, étant donné que sur les 5 principaux types de liens dans Windows, un seul et demi requiert ces droits. Alors, rencontrez: lien symbolique de fichier, lien symbolique de répertoire d'objets, lien dur, point d'analyse NTFS et reg_link. Les droits d'administrateur ne sont nécessaires que pour créer un lien symbolique de fichier et pour un lien symbolique de répertoire d'objets permanent (le lien temporaire vit exactement aussi longtemps que la session dans laquelle il est créé vit, dans le sens général, avant le redémarrage, et ne nécessite pas de droits spéciaux).
Simlink d'un dossier à l'autre
Cela s'appelle un point d'analyse NTFS ou un point de montage NTFS. Le nom n'est pas particulièrement important, le fait est que cette chose vous permet d'utiliser un dossier comme pointeur vers un autre. Il peut être créé par un utilisateur ordinaire à partir d'un dossier vide s'il dispose de droits d'écriture sur celui-ci. Pour la création, nous utiliserons l'utilitaire CreateMountPoint.exe à partir d'un
ensemble d'utilitaires pour tester le travail avec les liens .
Quitter l'écluse
Le blocage sortant (
OpLock ou Opportunistic Lock ) est un mécanisme spécial dans lequel une application peut temporairement empêcher tout le monde d'accéder à une certaine ressource de fichier. Ici, vous pouvez écrire beaucoup de détails, de fonctionnalités de travail avec des dossiers et différents accès. L'essentiel est: le programme peut "attraper" l'événement d'accéder à un certain fichier et le maintenir pendant un certain temps. Vous pouvez installer des oplocks à l'aide de l'utilitaire SetOpLock.exe de la même
suite de tests pour travailler avec des liens . L'exécution de l'utilitaire installe le déverrouillage requis; lorsque l'accès se produit, l'utilitaire écrit un message; appuyer sur enter supprime le déverrouillage.
Baitandndswitch
C'est le nom de la technique, qui combine la création de liens et l'installation d'oplos pour gagner TOCTOU (heure de vérification \ heure d'utilisation). L'essence est plus facile à expliquer avec un exemple.
Imaginez qu'il y ait un programme qui fait quelque chose comme ça d'affilée:
ReadContentFromFile(“C:\test\myfile.txt”); ReadContentFromFile(“C:\test\myfile.txt”);
Il s'agit simplement de lire le même fichier deux fois de suite. La même chose sera-t-elle toujours lue? Non, pas forcément.
Créez d'abord deux dossiers avec les fichiers C: \ test1 \ monfichier.txt et C: \ test2 \ monfichier.txt. Et en général, nous effacerons le dossier C: \ test et créerons un point d'analyse sur C: \ test1. Nous mettons le déverrouillage sur le fichier à partir du premier répertoire et exécutons le programme. Dès qu'elle ouvre le fichier, le déverrouillage fonctionnera. Nous allons changer le point d'analyse et C: \ test pointera sur C: \ test2. Maintenant, une fois le déverrouillage supprimé, le programme lira le fichier une deuxième fois à partir d'un autre fichier.
Pourquoi est-ce nécessaire? Très simple - une situation assez typique où le fichier est d'abord vérifié (première lecture) puis lancé (deuxième lecture). C'est ainsi que nous envoyons un fichier pour vérification et un autre pour exécution.
Maintenant, tout est prêt à fonctionner.
Opération 1. Préparation de l'environnement
Il faut un peu préparer l'environnement de travail. Pour commencer, vous devez prendre les fichiers exécutables CreateMountPoint.exe et SetOpLock.exe.
Maintenant, nous devons apporter de petites modifications à la structure des fichiers de Steam. Notre tâche consiste à obtenir un dossier avec deux fichiers Steam.exe et steamclient.dll et l'absence obligatoire du dossier bin. Il y a deux façons de procéder.
Méthode 1
Renommer \ supprimer le dossier bin du dossier Steam principal. C'est tout, vous êtes génial (Steam lors de l'installation donne à tout utilisateur les droits sur tout dans son dossier).
Méthode 2
Dans la clé de registre HKLM \ SOFTWARE \ Wow6432Node \ Valve \ steam, modifiez le paramètre InstallPath dans une partie de notre dossier. Dans ce dossier, déposez Steam.exe et steamclient.dll du dossier principal de Steam.
Supposons que par l'une des méthodes, nous avons préparé le dossier C: \ Steam (le chemin peut être n'importe lequel, mais dans les exemples, je vais l'utiliser). Créez maintenant un autre dossier b1, b2, b3 et b4. Dans les trois premiers, nous téléchargerons le fichier steamservice.dll (à partir du kit Steam, dans l'original, il se trouvait dans le dossier bin), et dans le dossier b4, nous déposerons la bibliothèque spécialement formée du même nom - steamservice.dll. Les détails sur la préparation de la bibliothèque seront au paragraphe 3.
Nous ouvrons deux fenêtres de la console. Ceci termine la préparation de l'environnement.
Opération 2. Remplacement du fichier
Je pense que d'après les préparatifs, il est déjà devenu clair qu'il y aura quelque chose comme le BaitAndSwitch décrit ci-dessus.
Capture d'écran de ProcMon:

Cela fait partie du lancement typique du service client Steam. Notez la partie où la DLL est d'abord copiée dans C: \ Program Files (x86) \ Common Files \ Steam, puis chargée. Nous nous assurerons que notre bibliothèque est copiée depuis C: \ Steam \ b4. Malheureusement, des vérifications sont d'abord effectuées, y compris la signature de la bibliothèque, afin qu'elle ne puisse pas être remplacée (oh, ironie).
Je vais donc me connecter par étapes. Les étapes sont combinées en groupes des mêmes actions. Pour chaque étape, il sera indiqué où lancer et ce qui se passe (j'ai appelé les différentes fenêtres de console cmd1 et cmd2).
- Créez le dossier C: \ Steam \ bin et exécutez dans cmd1:
CreateMountPoint.exe C: \ Steam \ bin C: \ Steam \ b1 - Dans cmd1, nous mettons l'oplock:
SetOpLock.exe C: \ Steam \ b1 \ steamservice.dll - Nous démarrons le service client Steam, nous voyons dans cmd1 que nous avons attrapé l'accès au fichier.
*** - Supprimez C: \ Steam \ bin, créez le dossier C: \ Steam \ bin à sa place et exécutez dans cmd2:
CreateMountPoint.exe C: \ Steam \ bin C: \ Steam \ b2 - En cmd2, nous mettons l'oplock:
SetOpLock.exe C: \ Steam \ b2 \ steamservice.dll - Dans cmd1, nous libérons le déverrouillage, nous voyons que cmd2 a attrapé l'accès au fichier.
*** - Supprimez C: \ Steam \ bin, créez le dossier C: \ Steam \ bin à sa place et exécutez cmd1:
CreateMountPoint.exe C: \ Steam \ bin C: \ Steam \ b3 - Dans cmd1, nous mettons l'oplock:
SetOpLock.exe C: \ Steam \ b3 \ steamservice.dll - Dans cmd2, nous libérons le déverrouillage, nous voyons que cmd1 a pris accès au fichier.
*** - Supprimez C: \ Steam \ bin, créez le dossier C: \ Steam \ bin à sa place et exécutez cmd2:
CreateMountPoint.exe C: \ Steam \ bin C: \ Steam \ b2 - En cmd2, nous mettons l'oplock:
SetOpLock.exe C: \ Steam \ b2 \ steamservice.dll - Dans cmd1, nous libérons le déverrouillage, nous voyons que cmd2 a attrapé l'accès au fichier.
*** - Supprimez C: \ Steam \ bin, créez le dossier C: \ Steam \ bin à sa place et exécutez cmd1:
CreateMountPoint.exe C: \ Steam \ bin C: \ Steam \ b3 - Dans cmd1, nous mettons l'oplock:
SetOpLock.exe C: \ Steam \ b3 \ steamservice.dll - Dans cmd2, nous libérons le déverrouillage, nous voyons que cmd1 a pris accès au fichier.
*** - Supprimez C: \ Steam \ bin, créez le dossier C: \ Steam \ bin à sa place et exécutez cmd2:
CreateMountPoint.exe C: \ Steam \ bin C: \ Steam \ b4 - Dans cmd1, nous libérons le déverrouillage
Bien que cela semble compliqué, en fait, l'idée est simple: de 6 accès au fichier C: \ Steam \ bin \ steamservice.dll, les 5 premières fois, les fichiers originaux de différents dossiers ont été donnés (dans l'ordre d'accès: b1, b2, b3, b2, b3), et pour la sixième fois, un fichier contenant une charge utile a été remis pour copie.
Schématiquement, je l'ai représenté comme ceci:

À gauche, le comportement normal, à droite, le comportement d'exploitation.
Opération 3. Bibliothèque implémentée
Pour la charge utile, j'ai d'abord utilisé ma DLL la plus typique, qui dans DllEntry crée une console interactive. Étant donné que le code de la DLL sera exécuté dans le contexte du service client Steam, il sera exécuté avec les mêmes droits que le service lui-même - NT AUTHORITY \ SYSTEM. Mais à la suite de l'opération, la console n'est pas apparue.
Après le téléchargement, le service Steam comprend toujours qu'il a glissé un tilleul et a fini de travailler, donc la charge utile de ma DLL n'a pas réussi à être exécutée.
J'ai dû me retourner un peu, et il s'est avéré que le service après le chargement de la dll vérifie l'existence des fonctions
int WINAPI SteamService_RunMainLoop() void WINAPI SteamService_Stop()
dans la bibliothèque. De plus, le service appelle la première fonction, où j'ai décidé de mettre la charge utile (lancement d'une console interactive avec les droits du service - NT AUTHORITY \ SYSTEM). Maintenant, c'est tout - nous répétons toutes les étapes et obtenons une console avec des autorisations maximales.
Conclusion
Vous pouvez envelopper tout cela dans un fichier exe, mais, franchement, je ne veux pas vraiment déranger. Je pense qu'une vidéo avec une démonstration sera suffisante (
option avec le registre ,
option avec le système de fichiers ).
Je ne copierai pas ici la section "Spéculation" d'un article précédent. Juste les faits: l'ancienne vulnérabilité est actuelle, vous venez de lire la nouvelle, Valve ne veut toujours pas entendre parler des problèmes.
Mise à jour (22/08/2019)
Pour le moment, il y a deux nouvelles:
- Le client bêta a reçu un correctif . Je regarderai quand la mise à jour atteindra le client principal.
- Valve a changé la politique LPE . Et c'est une excellente nouvelle!
Mise à jour (27/08/2019)
Bonne nouvelle.
- Le client principal a reçu la mise à jour du correctif .
- J'ai été banni de H1 et payé une récompense
Cet article en anglais.