Auparavant, nous à propos d'une vulnérabilité zero-day découverte dans Internet Explorer, qui permet d'utiliser un fichier MHT spécialement préparé pour télécharger des informations de l'ordinateur de l'utilisateur vers un serveur distant. Récemment, cette vulnérabilité, découverte par le spécialiste de la sécurité John Page, a décidé de vérifier et d'étudier un autre spécialiste bien connu dans ce domaine - Mitya Kolsek, directeur d'ACROS Security, une société d'audit de sécurité et co-fondateur du service de micropatch 0patch. Il chronique complète de son enquête, indiquant que Microsoft a considérablement sous-estimé la gravité du problème.
Curieusement, Kolsek n'a pas pu initialement reproduire l'attaque décrite et démontrée par John, où il a utilisé Internet Explorer fonctionnant sous Windows 7 pour télécharger puis ouvrir un fichier MHT malveillant. Bien que son gestionnaire de processus ait montré que system.ini, qui devait lui être volé, avait été lu par un script caché dans le fichier MHT, mais n'avait pas été envoyé au serveur distant.
"Cela ressemblait à une situation classique de marquage du Web", écrit Kolsek. "Lorsqu'un fichier est reçu d'Internet, des applications Windows exécutées correctement telles que des navigateurs Web et des clients de messagerie ajoutent une étiquette à ce fichier sous la forme avec le nom Zone.Identifier contenant la chaîne ZoneId = 3. Cela permet aux autres applications de savoir que le fichier provient d'une source non fiable et doit donc être ouvert dans un bac à sable ou un autre environnement restreint.
Le chercheur a vérifié qu'IE avait effectivement défini une telle étiquette pour le fichier MHT téléchargé. Kolsek a ensuite essayé de télécharger le même fichier à l'aide d'Edge et de l'ouvrir dans IE, qui reste l'application par défaut pour les fichiers MHT. De manière inattendue, l’exploit a fonctionné.
Tout d'abord, le chercheur a vérifié «mark-of-the-Web», il s'est avéré qu'Edge stocke également la source de l'origine du fichier dans un flux de données alternatif en plus de l'identifiant de sécurité, ce qui peut soulever des questions quant à la confidentialité de ce méthode. Kolsek a émis l'hypothèse que les lignes supplémentaires auraient pu confondre IE et l'empêcher de lire le SID, mais il s'est avéré que le problème était ailleurs. Après une longue analyse, le spécialiste de la sécurité a trouvé la cause dans deux entrées de la liste de contrôle d'accès qui ajoutaient le droit de lire le fichier MHT à un certain service système, qu'Edge y avait ajouté après l'avoir chargé.
James Foreshaw de l'équipe dédiée aux vulnérabilités Zero Day - Google Project Zero - a tweeté que les entrées ajoutées par Edge font référence aux identifiants de sécurité de groupe pour le package Microsoft.MicrosoftEdge_8wekyb3d8bbwe. Après avoir supprimé la deuxième ligne du SID S-1-15-2 - * de la liste de contrôle d'accès du fichier malveillant, l'exploit n'a plus fonctionné. En conséquence, d'une manière ou d'une autre, l'autorisation ajoutée par Edge a permis au fichier de contourner le bac à sable dans IE. Comme Kolsek et ses collègues l'ont suggéré, Edge utilise ces autorisations pour protéger les fichiers téléchargés contre l'accès par des processus peu fiables en exécutant le fichier dans un environnement partiellement isolé.
Ensuite, le chercheur a voulu mieux comprendre les causes de l'échec du système de sécurité d'IE. Une analyse approfondie à l'aide de l'utilitaire Process Monitor et du désassembleur IDA a finalement révélé que la résolution définie par Edge empêchait la fonction Win Api GetZoneFromAlternateDataStreamEx de lire le flux du fichier Zone.Identifier et renvoyait une erreur. Pour Internet Explorer, une telle erreur lors de la demande de l'étiquette de sécurité d'un fichier était complètement inattendue et, apparemment, le navigateur considérait que l'erreur était équivalente au fait que le fichier n'avait pas de marque « marque du Web », ce qui le rend automatiquement fiable, après quoi IE a autorisé le script caché dans le fichier MHT à s'exécuter et à envoyer le fichier local cible au serveur distant.
"Voyez-vous l'ironie ici?" demande Kolsek. "Une fonctionnalité de sécurité non documentée utilisée par Edge a neutralisé une fonctionnalité existante, sans aucun doute beaucoup plus importante (marque du Web) dans Internet Explorer."
Malgré l'importance accrue de la vulnérabilité, qui permet à un script malveillant d'être exécuté en tant que script de confiance, rien n'indique que Microsoft ait l'intention de corriger le bogue dans un avenir proche, si jamais il est corrigé. Par conséquent, nous vous recommandons toujours, comme dans l'article précédent, de modifier le programme par défaut d'ouverture des fichiers MHT vers n'importe quel navigateur moderne.
Bien entendu, les recherches de Kolsek ne se sont pas déroulées sans un peu d’auto-RP. À la fin de l'article, il a présenté un petit patch écrit en langage assembleur pouvant utiliser le service 0patch développé par son entreprise. 0patch détecte automatiquement les logiciels vulnérables sur l'ordinateur de l'utilisateur et y applique de petits correctifs littéralement à la volée. Par exemple, dans le cas que nous avons décrit, 0patch remplacera le message d'erreur dans la fonction GetZoneFromAlternateDataStreamEx par une valeur correspondant à un fichier non fiable reçu du réseau, afin qu'IE n'autorise l'exécution d'aucun script caché conformément aux spécifications intégrées. dans la politique de sécurité.
Source: 3dnews.ru