Dans la série précédente
Il n'y a pas si longtemps, j'ai parlé de deux vulnérabilités de Steam:
CVE-2019-14743 et
CVE-2019-15316 . Il y avait toute une histoire sur la façon dont j'ai essayé de les enregistrer, je n'y suis pas parvenu, j'ai été banni, et seulement après la divulgation publique et l'aide de la communauté, j'ai réussi à obtenir des résultats. Valve a fait semblant de s'excuser et de m'interdire sur HackerOne, j'ai donc décidé de transférer la prochaine vulnérabilité via ce service. La troisième fois (
il devrait y avoir une blague évidente sur Half-Life 3 ), tout s'est plus ou moins bien passé.
Description de la vulnérabilité
La vulnérabilité permet la création de fichiers avec un contenu partiellement contrôlé (ou l'ajout de contenu partiellement contrôlé à des fichiers existants). La version du service vulnérable est 5.31.28.21 (données du fichier SteamService.exe). Je décrirai d'abord comment exploiter la vulnérabilité, puis je décrirai les conséquences possibles.
Étape 1. Environnement
Vous devez fermer l'application Steam et arrêter le service client Steam s'ils sont en cours d'exécution. Le plus souvent, les utilisateurs sans droits d'administrateur ne peuvent démarrer et arrêter aucun service. Mais spécifiquement pour ce service, Valve a défini des droits qui permettent à tous les utilisateurs de l'arrêter et de le démarrer.
Créez un dossier dans n'importe quel endroit accessible à l'utilisateur (par exemple, «C: \ test»). Dans ce dossier, vous devez copier les fichiers Steam.exe et steamclient.dll à partir du dossier source Steam (par défaut, il s'agit de «C: \ Program Files (x86) \ Steam»). Créez un sous-dossier de journaux vide ("C: \ test \ logs").
Corrigeons maintenant le registre: dans la branche "HKLM \ Software \ wow6432node \ valve \ steam", changez la valeur du paramètre "InstallPath" en "C: \ test \ 1 \ ..". Habituellement, pour les utilisateurs non administrateurs, les branches de registre à l'intérieur de HKLM ne sont pas accessibles en écriture, mais pas dans ce cas. Lors de l'installation de Valve, ils définissent de tels droits sur leur branche dans HKLM que toutes les actions sont disponibles pour tous les utilisateurs («Contrôle total» pour le groupe «Utilisateurs»).
Étape 2. Faisons un petit test
Lancez le service client Steam. Après son arrêt (cela se produira automatiquement après quelques secondes), vérifiez le contenu du dossier «C: \ test \ logs» - nous y trouvons le fichier «service_log.txt». Le contenu du journal ressemblera à ceci:
08/27/19 13:45:01 : ERROR: SteamService: Invalid file signature C:\test\1\..\bin\SteamService.dll
Notez que le chemin d'accès "C: \ test \ 1 \ .." est équivalent au chemin d'accès "C: \ test", donc Windows a utilisé le second pour fonctionner et le premier est entré dans le message. Supprimez le fichier «service_log.txt» et continuez.
Étape 3. Ajoutez plus de texte.
Un fait intéressant: lorsque Windows fonctionne avec des chemins contenant "\ ..", il simplifie automatiquement ces chemins. Ne vérifie pas les dossiers intermédiaires.
Par exemple, le chemin «C: \ 1 \ <test> \ ..» sera converti en «C: \ 1» malgré le fait que les crochets ne peuvent pas être utilisés dans le nom du dossier.
À la première étape, nous avons enregistré le chemin dans le registre, nous allons maintenant lui ajouter des sauts de ligne. Cela peut être fait en écrivant du code simple, mais cela peut aussi être fait à partir de l'interface regedit. Il suffit d'ouvrir la branche de registre "HKLM \ Software \ wow6432node \ valve \ steam" et de sélectionner "Modifier les données binaires .." dans le menu contextuel du paramètre "InstallPath". Quelque chose comme un éditeur hexadécimal apparaîtra où vous pourrez apporter les modifications nécessaires.
Nous procéderons à un nouveau test de lancement du service et vérifierons le résultat de nos actions.
Après le test, vous devez à nouveau supprimer le fichier "service_log.txt".
Étape 4. Redirigez le fichier créé
Les utilisateurs sans droits d'administrateur ne peuvent pas créer de liens symboliques d'un fichier à un autre. Mais il y a un focus - vous pouvez combiner d'autres types de liens qui sont disponibles pour les utilisateurs sans droits d'administrateur pour obtenir un effet qui est proche d'un lien symbolique d'un fichier à l'autre.
Créez d'abord un point d'analyse NTFS (un autre nom pour le point de montage NTFS) à partir du dossier "C: \ test \ logs" vers "\ RPC Control \". "\ RPC Control \" n'est pas un dossier ordinaire au sens habituel, il ne peut pas être visualisé, par exemple, dans l'explorateur. Il s'agit d'un répertoire d'objets système, à l'intérieur duquel se trouvent, par exemple, des mutex nommés, des événements et d'autres objets similaires. Pourquoi la redirection via le point d'analyse NTFS fonctionne pour elle n'est pas claire, le plus probable, le point est d'utiliser les mêmes abstractions pour les dossiers dans le système de fichiers et les répertoires d'objets. À partir du répertoire d'objets, vous pouvez créer un lien symbolique vers un fichier sans droits d'administrateur. Créez un lien symbolique de la forme "\ RPC Control \ service_log.txt" <-> "C: \ Path \ to \ file".
Par conséquent, tous les appels à "C: \ test \ logs \ service_log.txt" seront redirigés vers le fichier "C: \ Path \ to \ file". Pour créer une telle redirection, il existe deux exigences de base: le dossier à partir duquel le point d'analyse NTFS est créé doit être vide et il doit également être accessible en écriture à l'utilisateur. Pour remplir la première condition, après chaque test, nous avons supprimé le fichier «service_logs.txt», la deuxième condition est assurée par le fait que nous avons créé le dossier source dans un endroit contrôlé par l'utilisateur.
Il existe un utilitaire spécial qui crée de telles paires de liens symboliques - CreateSymlink et est disponible en téléchargement sur
GitHub . Utilisation de l'utilitaire:
CreateSymlink.exe <> <>
Dans notre cas, ce sera:
CreateSymlink.exe "C:\test\logs\service_log.txt" "C:\\\"
En mettant tout cela ensemble, nous obtenons qu'au démarrage du service client Steam, un fichier sera créé le long du chemin spécifié lors de la création du lien symbolique, et ce fichier contiendra du contenu que nous pouvons contrôler (enfin, à l'exception de la première et de la dernière ligne). Si nous spécifions le chemin d'accès à un fichier existant, le contenu sera ajouté à la fin du fichier. Tout cela sera fait au nom du service client Steam avec les privilèges NT AUTHORITY \ SYSTEM.
Impact
Je vais maintenant énumérer les effets possibles des moins importants et ascendants.
- Dos
Si le but du lien symbolique est «C: \ Windows \ System32 \ config \ SAM» ou «C: \ Windows \ System32 \ config \ SECURITY», il est peu probable que le système d'exploitation puisse démarrer après un redémarrage. - Redirection d'utilisateurs sur Internet
Définissez l'objectif du lien symbolique "C: \ Windows \ system32 \ drivers \ etc \ hosts" et ajoutez-y une ligne comme "127.0.0.1 google.com".
Résultat:
- EoP horizontal
Une augmentation horizontale des privilèges est un changement de droits dans lequel nous avons accès non pas à des droits plus élevés, mais à des droits du même niveau, mais par rapport à d'autres objets, par exemple, aux droits d'autres utilisateurs.
Définissez l'objectif du lien symbolique «C: \ ProgramData \ Microsoft \ Windows \ Menu Démarrer \ Programmes \ StartUp \ run.bat» et ajoutez-y une ligne comme «démarrer C: \ test \ 1.exe».
Tous les fichiers du dossier C: \ ProgramData \ Microsoft \ Windows \ Start Menu \ Programs \ StartUp sont exécutés par les utilisateurs lorsqu'ils se connectent. Ainsi, un utilisateur peut forcer un autre utilisateur à exécuter du code. A partir du fichier bat, toutes les lignes seront exécutées tour à tour. Le premier et le dernier ne feront tout simplement rien, mais la commande implémentée "start C: \ test \ 1.exe" fonctionnera.
Avec l'introduction d'une telle commande, il y a une subtilité - les caractères "\" seront pris en compte lors de la normalisation du chemin, donc pour un fonctionnement correct il faudra ajouter quelques "\ .." de plus au chemin dans le registre. - EoP vertical
L'escalade de privilèges verticale est une escalade habituelle, par exemple, d'un utilisateur sans droits d'administrateur vers NT AUTHORITY \ SYSTEM.
Très souvent, vous pouvez trouver des logiciels qui exécutent des scripts de texte avec des droits élevés. Nous pouvons ajouter des commandes à ces scripts et exécuter notre code avec des autorisations élevées. Je n'ai pas trouvé de tels scripts dans un système d'exploitation propre, vous ne pouvez donc pas simplement démontrer un tel exploit. Mais à titre d'exemple, je peux spécifier des fichiers bat créés par NVIDIA et VmWare ou des scripts de connexion pour le système d'exploitation du domaine.
De plus, pour améliorer, vous pouvez vérifier la possibilité de créer des fichiers xml, des fichiers ini avec un format cassé. Malheureusement, il existe trop d'options - création de tâches pour TaskSheduler, utilisation de .manifest et d'autres téléchargements de bibliothèque, et bien d'autres. Il me semble que les résultats décrits ci-dessus sont déjà suffisants pour comprendre les résultats de la vulnérabilité.
Chronologie
Pour compléter l'image, je vais vous donner une chronologie ennuyeuse sur cette vulnérabilité.
26/08 - Trouvé une vulnérabilité.
27 août - annuler le premier semestre, a publié un rapport.
12.09 - une correction a été publiée .
Conclusions
C'est là que je termine les articles de recherche Steam - 3 vulnérabilités trouvées avec une analyse assez superficielle, ce n'est pas suffisant. Pour aller plus loin, vous avez besoin de plus de temps et de désir. Malheureusement, l’attitude de Valve et l’incompétence des employés de HackerOne sont des barrières très fortes.
Je remercie encore une fois tous les lecteurs qui ont contribué à rendre Steam plus sûr. Je remercie Valve d'avoir corrigé les vulnérabilités et réfuté mes théories du complot. Je remercie HackerOne d'avoir fourni la plateforme, malgré le fait qu'ils m'ont essentiellement empêché de communiquer les vulnérabilités à Valve.
Cet article en anglais.