edubr2020/rp_dcp_code_execExploit de preuve de concept pour l'exécution de code arbitraire via le schéma d'URI DCP de Real Player, utilisant la plantation de fichiers et le contournement du contrôle ActiveX.
Real Player 'DCP://' URI Remote Arbitrary Code Execution Vulnerability
video demo: https://youtu.be/AMODp3iTnqY
Le schéma d'URI « DCP:// » est un protocole interne utilisé par Real Player pour récupérer des URL à afficher dans l'onglet navigateur du lecteur. Il signifie « Data Cache Protocol ». Il récupère les fichiers depuis « %appdata%\real\realplayer ». Ces fichiers sont de simples fichiers « .ini » avec le code suivant :
L'attribut « offlineurl » semble être ignoré, mais il est possible de passer des URL arbitraires, y compris des URL vers des fichiers locaux et des URI « Javascript: » non sécurisées.
Exemple : dcp://custom.ini
Cela crée potentiellement une condition universelle de cross-site scripting (uXSS).
Real Player utilise les fonctionnalités de Microsoft Internet Explorer et expose des propriétés et méthodes via un moyen spécial propre à l'application :
L'objet « external » expose plusieurs méthodes et propriétés personnalisées.
Il n'est pas possible de récupérer des fichiers distants, mais il est possible d'utiliser les répertoires parents (..) pour récupérer les fichiers. Pour cela, nous pouvons utiliser la méthode « external::OpenURLInPlayerBrowser() ».
En combinant ce problème avec un problème de dépôt de fichier utilisant la méthode « external::RecordClip() », nous sommes en mesure de déposer des fichiers « .ini » valides (bien qu'ils soient sans extension) à un emplacement prévisible :
« Videos\RealPlayer Downloads ».
En déposant 2 fichiers, puis en les référençant via une URI « DCP:// », il est possible de référencer une URL appartenant à un domaine ou une « zone de sécurité » arbitraire (zones de sécurité Windows), puis d'injecter du code javascript personnalisé.
La preuve de concept (PoC) utilise du code qui provoque le contournement de l'invite concernant les contrôles ActiveX non sécurisés et exécute MSHTA pointant vers le second fichier qui contient le code permettant d'exécuter « cmd.exe ». Il pourrait contenir par exemple un EXE intégré.
Pour reproduire ce problème, il vous suffit de modifier les fichiers et de remplacer « %server% » par le nom d'hôte ou l'IP réels du serveur. Remplacez également « %username% » par le nom d'utilisateur Windows réel de la cible dans les fichiers « dcp1.txt » et « rp_dcp.htm ».
Remarque : Le nom d'utilisateur Windows peut être obtenu via des requêtes vers un serveur SMB ou un serveur WebDAV.
Versions concernées : 16.0.3.51, Cloud 17.0.9.17, v.20.0.7.309 sur toute version de Windows (de XP à 11).
