Escalade de privilèges dans le client EA Origin Windows (CVE-2019-19247 et CVE-2019-19248)

Salutations à tous ceux qui ont décidé de lire mon nouvel article sur l'analyse de vulnérabilité. La dernière fois, dans une courte série de trois articles, j'ai parlé des vulnérabilités de Steam ( 1 , 2 et 3 ). Dans cet article, je parlerai des vulnérabilités d'un produit similaire - Origin, qui est également un lanceur de jeux. Les vulnérabilités découvertes étaient numérotées CVE-2019-19247 et CVE-2019-19248.



Cette fois, il n'y aura pas de jeu avec la banane anban. L'histoire de la communication avec la division de la sécurité d'Electronic Arts Inc est d'abord passée au niveau professionnel. Lorsque j'ai été contacté, ils m'ont donné un numéro d'enregistrement, les rapports ont été soigneusement examinés et confirmés. Aucun de mes e-mails n'a été ignoré, et pour une petite discussion, une conférence a été organisée. La maintenance de ces rapports a été très simple pour moi, pour laquelle je remercie beaucoup Adrian Stone, Elise Murphy et d'autres employés d'EA qui ont travaillé avec mes rapports. Article de blog et avis sur la sécurité .

Passons maintenant aux vulnérabilités. J'ai trouvé deux vulnérabilités telles que «escalade de privilèges» (lpe - escalade de privilèges locale ou eop - escalade de privilèges) dans le client Windows Origin. Ce type de vulnérabilité permet à tout utilisateur Windows d'obtenir plus de droits que ceux initialement accordés par l'administrateur. Dans ce cas, nous parlons de deux améliorations "typiques" - de n'importe quel utilisateur à NT AUTHORITY \ SYSTEM (un compte avec des autorisations maximales dans le système d'exploitation). La première vulnérabilité est plutôt ennuyeuse, donc dans la section suivante je vais la décrire brièvement. Mais la seconde était assez intéressante, dans sa section je vais vous dire exactement comment je la cherchais.

CVE-2019-19248

Cette vulnérabilité se compose de deux parties:

1. Création d'un dossier sur un chemin arbitraire (avec des droits d'accès complet);
2. Utilisez la clause 1 pour obtenir les privilèges NT AUTHORITY \ SYSTEM.

Maintenant sur le premier point plus en détail:

Préparation de l'environnement

Il est nécessaire de fermer le client Origin et d'arrêter le service client Origin (en théorie, le service lui-même s'arrêtera si vous fermez le client, mais juste au cas où).

Pour le dossier "C: \ ProgramData \ Origin" les droits sont "All-Full Access", ce qui nous permet de supprimer complètement son contenu.

Création de liens

Créez maintenant quelques liens. Le premier lien sera de type NTFS Reparse Point (NTFS Mount Point) - le type de liens pointant d'un dossier à un autre: «C: \ ProgramData \ Origin» <-> «\ RPC Control». Pour créer des points d'analyse, vous n'avez pas besoin de droits d'administrateur. Il est seulement nécessaire que le dossier source soit vide et que l'utilisateur y ait des droits d'écriture (ils ont été effacés à la dernière étape, les droits y ont été vérifiés). "\ RPC Control" n'est pas un dossier dans le système de fichiers, mais un type spécial de dossier - un répertoire d'objets. Vous ne pouvez pas le voir avec un explorateur ordinaire, mais vous pouvez y faire un point d'analyse, apparemment en raison des abstractions courantes utilisées dans les entrailles de Windows.

Nous allons maintenant créer le lien symbolique habituel "\ RPC Control \ CatalogCache" <-> "C: \ Path \ To \ Target \ Folder". Dans le système de fichiers, la création de liens symboliques sans droits d'administrateur est interdite, mais cette règle ne s'applique pas aux répertoires d'objets. Par conséquent, notre lien sera créé avec succès. En raison d'une combinaison de ces deux liens, les appels à "C: \ ProgramData \ Origin \ CatalogCache" seront redirigés vers "C: \ Path \ To \ Target \ Folder".

En savoir plus sur ces liens ici . Dans le même référentiel, vous pouvez télécharger des utilitaires pour travailler avec des liens.

Lancement

Dans la dernière étape, exécutez le client. Au début de son travail, il lancera «Origin Client Service» et, constatant qu'il n'y a pas de dossier «C: \ ProgramData \ Origin \ CatalogCache», il tentera de le créer. À la suite de la navigation dans les liens symboliques, il créera «C: \ Path \ To \ Target \ Folder» et donnera à ce dossier les droits «All-Full Access».

Ce qui devait être obtenu au premier point de fonctionnement. Passons à la seconde.

L'opération de création d'un dossier sur un chemin arbitraire

Ici, vous pouvez travailler de différentes manières.

La création du dossier «C: \ Windows \ system32 \ LogonUI.exe.local» est simple et assez fiable. "LogonUI.exe" (une application qui s'exécute à partir de NT AUTHORITY \ SYSTEM, est responsable du fonctionnement de l'écran de sélection des utilisateurs et de l'écran de verrouillage) grâce au mécanisme .local-redirection ("dotlocal redirection"), il chargera la bibliothèque depuis le chemin "C: \ Windows \ system32 \ LogonUI.exe.local \ amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.17134.648_none_fb45a0e93062a6d2 \ comctl32.dll. " En général, le mécanisme lui-même est assez courant, il peut donc avoir de nombreux objectifs.

Un moyen long mais intéressant consiste à soustraire le hachage du mot de passe administrateur par des fraudes spéciales. Plus de détails ici .

Total

La vulnérabilité est exploitée assez facilement, il suffit de travailler un peu sur le deuxième point - trouver la cible et écrire une dll appropriée. De plus, Matt Nelson a également signalé cette vulnérabilité, et son écriture peut être trouvée ici .

CVE-2019-19247

C'est l'une de mes vulnérabilités préférées. Il montre avec quelle prudence vous devez vous relier à la cryptographie utilisée.

Tout a commencé avec le fait que j'ai installé le jeu via Origin. Tout s'est en quelque sorte trop bien déroulé - quelques clics et après quelques minutes de téléchargement, le jeu peut être lancé. Pas immédiatement, mais j'ai compris ce qui se passait: le jeu a été installé le long du chemin "C: \ Program Files \ GameName", mais n'a pas posé une seule question via UAC. J'ai rapidement vérifié les droits, tout était standard - un utilisateur ordinaire ne pouvait pas écrire dans "C: \ Program Files". Un peu plus de recherche et j'ai découvert que le jeu n'est pas «prescrit» par le client Origin lui-même, mais par son service client Origin.

J'ai commencé à faire des hypothèses sur la façon dont le client transmet les informations au service afin de vérifier si quelque chose peut être exploité.

La méthode de transmission des informations s'est avérée simple - un canal nommé. J'ai appris cela à partir des journaux d'installation - en texte clair, il a été indiqué que le canal OriginClientService acceptait les commandes pour travailler avec les fichiers et les dossiers.

Ouverture de l'IDA, téléchargement du client là-bas.

* travaux effectués en IDA: 1 *

Assez rapidement, j'ai trouvé que les commandes étaient envoyées au pipe en général sous forme de texte. À proximité, j'ai trouvé une liste de commandes et, sans plus tarder, j'ai envoyé une commande du type «copier« C: \ test \ payload.dll »« C: \ Windows \ pwn.dll »au tuyau. En prévision d'un résultat rapide, je vérifie le dossier «C: \ Windows» et n'y trouve rien de nouveau. Mais il y a quelque chose de nouveau dans les journaux - quelques mots sur le fait que le client du canal n'a pas réussi la vérification de la signature numérique.

A ouvert IDA, y a téléchargé le service.

* travaux effectués à l'IDA: 2 *

J'ai découvert que les équipes ne sont pas attendues de toute façon. Lors de la connexion à un tuyau, le service vérifie qui y est connecté. Le pid de processus est extrait de la connexion, le chemin d'accès au fichier exécutable est extrait du pid, la signature est vérifiée pour son exactitude et émise par EA.
Sonne bien, mais pas assez. Vous pouvez prendre le "Origin.exe" légal (fichier exécutable client), le copier quelque part dans votre dossier. Placez une DLL de la liste d'importation «Origin.exe» dans ce dossier. Par exemple, version.dll est apparu. J'ai appelé cette approche «injection inversée de DLL»: dans une injection régulière de DLL, nous copions la DLL dans le fichier exe, mais maintenant nous avons fait le contraire. J'écris rapidement la DLL du proxy pour version.dll, j'ajoute du code en envoyant la commande au tube. La charge utile n'est toujours pas copiée. Nous lisons les journaux - "qu'est-ce que cela signifie, la commande n'a pas pu être déchiffrée!?". J'ai sauté le cryptage.

Ouverture de l'IDA, téléchargement du client là-bas.

* travaux réalisés en IDA: 3, contournement de signature: 1 *

Étant donné que le client envoie des commandes cryptées dans son travail habituel, je le peux. Là j'ai regardé, puis j'ai regardé, le résultat est le suivant: chiffrement AES, initialisation d'un vecteur constant, la clé est lue dans le fichier. Nous copions pratiquement cette pièce et IDA dans le code, compilons, vérifions. Encore rien. Mais les journaux fournissent à nouveau des informations utiles - vous ne pouvez pas spécifier Program Files comme chemin cible.

A ouvert IDA, y a téléchargé le service.

* travail effectué en IDA: 4, contournement de signature: 1, contournement de cryptage: 1 *

Donc, il est vrai qu'il y a des vérifications pour obtenir une commande qui s'avère que les fichiers ne peuvent pas être copiés partout. Et les chemins avec "\ .. \" ne peuvent pas être écrits. Nous regardons ce que sont les autres équipes.
Travailler avec le registre - il y a encore beaucoup de restrictions. Mais le lancement de fichiers semble intéressant. Au moins, les chèques ne sont pas particulièrement visibles. Modifiez le code, envoyez la commande «ExecuteProcess« C: \ test \ payload.exe »». Eh bien, tu comprends ... Rien.

Les journaux parlent à nouveau de la signature. Oh, nous l'avons déjà gagné. Nous indiquons dans le code que nous avons appelé notre Origin.exe copié pour charger à nouveau notre DLL de proxy, mais avec les droits système. Ajoutez des chèques et lancez la console. Nous commençons et la console avec les droits NT AUTHORITY \ SYSTEM apparaît - enfin tout a fonctionné.

* travail effectué en IDA: 4, contournement de signature: 2, contournement de cryptage: 1 *

Donc, vous devez redémarrer, effectuer une dernière course et toujours admirer la console avec des droits maximaux. Redémarrez, vérifiez et ... rien. Comment ça? Ça a juste fonctionné.

Les diagnostics montrent que le service client d'origine n'a pas été démarré, je le lance donc. Mais ça ne démarre pas. Plus précisément, il démarre, mais se ferme immédiatement. Je démarre le client Origin et le service démarre normalement. Après cela, l'exploit fonctionne à nouveau correctement. Il serait possible de s'arrêter là, mais ce n'est pas mon chemin - je veux que l'exploit fonctionne pleinement.

A ouvert IDA, y a téléchargé le service.

* travail effectué en IDA: 5, signature de contournement: 2, cryptage de contournement: 1 *

Il s'avère qu'au démarrage, il vérifie les paramètres avec lesquels le service a commencé. Il n'y a rien de directement intéressant là-bas. Base64 à partir du pid chiffré du processus dont le fichier est vérifié par la signature. Cela semble compliqué, mais nous avons déjà contourné le cryptage et la signature également. Nous écrivons du code et un exploit complet est prêt.

Total

L'exploit fonctionne. Le travail a été effectué en IDA: 5 fois, contournement de la signature: 3 fois, contournement du cryptage: 2 fois.

Conclusion

Vulnérabilités corrigées: les développeurs d'EA ont introduit un mode de fonctionnement restreint spécial pour le client, qui définit de sérieuses restrictions sur l'utilisation des dossiers et des canaux Origin.

Vulnérabilités chronologiques:

1er avril 2019 : rapport de vulnérabilité avec pipe;

7 avril 2019 : envoi d'un rapport de vulnérabilité avec un dossier arbitraire;

... TRÈS BEAUCOUP DE LETTRES (j'en ai compté 40) ...

10 décembre 2019 : divulgation convenue.

Merci à tous pour votre attention, je vous souhaite les mêmes agents de sécurité.

Cet article en anglais.