Les navigateurs web sont installés sur des milliards d'appareils dans le monde, ce qui en fait des cibles de choix pour les cybercriminels. Les principaux navigateurs web ayant des bases d'utilisateurs considérables, une seule vulnérabilité peut avoir des conséquences considérables. Il est essentiel de maintenir les navigateurs à jour pour rester protégé contre l'évolution des menaces.
Pour illustrer la gravité des vulnérabilités dans les navigateurs web, nos chercheurs ont mené une analyse approfondie de la CVE-2024-6778, une vulnérabilité dans les navigateurs basés sur Chromium, affectant particulièrement Chrome DevTools. Ce blog présente un examen détaillé des aspects techniques de la vulnérabilité, de son impact potentiel et des stratégies d'atténuation.
Historique de CVE-2024-6778
CVE-2024-6778 est une vulnérabilité de type "race condition" découverte dans Chrome DevTools. Elle permet aux attaquants d'injecter du HTML ou du JavaScript malveillant dans des pages de navigateur privilégiées via des extensions de navigateur malveillantes. Selon la NVD (National Vulnerability Database), cette vulnérabilité a été classée avec une sévérité élevée, avec un score CVSS de 8.8.
La gravité élevée de cette vulnérabilité est due au fait qu'elle peut permettre l'exécution de codes à distance, ce qui peut compromettre les systèmes, porter atteinte à la confidentialité et réduire la disponibilité.
Aperçu de la sécurité de Chromium
Pour mieux comprendre les implications de CVE-2024-6778, il est important de connaître les principaux aspects du modèle de sécurité de Chromium. Chromium est la base open-source de navigateurs tels que Google Chrome, Microsoft Edge, Opera et Brave. Il utilise un modèle multiprocessus dans lequel chaque onglet, également appelé moteur de rendu, et divers composants du navigateur s'exécutent dans des processus isolés afin d'améliorer la stabilité et la sécurité en limitant la portée des compromissions potentielles.
Un élément fondamental de la sécurité de Chromium est son mécanisme de bac à sable, qui empêche les processus de rendu d'accéder directement aux ressources du système. Au lieu de cela, toutes les interactions sont gérées par des canaux IPC (Inter-Process Communication) afin de garantir que seules les opérations autorisées sont effectuées.
Tous les composants de Chromium ne sont pas soumis à un sandboxing complet. Les pages de l'interface Web, telles que chrome://settings et chrome://downloads, sont rendues dans les processus de rendu mais fonctionnent avec des restrictions de bac à sable partielles. Ce processus leur permet d'accéder aux API du navigateur qui ne sont généralement pas accessibles via le web.
Par exemple, la page chrome://policy joue un rôle essentiel dans les environnements d'entreprise, car elle permet aux administrateurs et aux utilisateurs de configurer et d'appliquer les règles de sécurité du navigateur. Ces politiques sont également gérées par le biais de la stratégie de groupe sur les systèmes Windows.
Comme chrome://policy peut interagir directement avec le système d'exploitation, il s'agit d'une cible précieuse pour les attaquants. Avec la vulnérabilité CVE-2024-6778 qui exploite une condition de course dans Chrome DevTools, les attaquants peuvent injecter du code malveillant dans ces pages, ce qui pose de sérieux risques de sécurité.
Analyse technique de CVE-2024-6778
Découverte
Cette vulnérabilité a été découverte dans une fonctionnalité de test introduite dans la version 117 de Chrome Enterprise. Cette fonctionnalité permet de tester les politiques via la page chrome://policy/test. En raison d'une documentation officielle limitée sur cette fonctionnalité, nos collègues ont procédé à un examen approfondi du code source de Chromium, complété par des informations fournies par l'auteur du CVE, afin de bien comprendre sa mise en œuvre et d'identifier les vulnérabilités de sécurité qui y sont associées.
Composants de la gestion des politiques
L'analyse du code source effectuée par les membres d'OPSWAT a révélé qu'à l'intérieur des chrome://policy/testLes politiques sont gérées à l'aide de l'outil InfoPolitique et communiquée entre l'interface WebUI et les processus du navigateur par l'intermédiaire de l'interface PolicyTestBrowserProxy classe. Les InfoPolitique est définie comme suit :
Un examen plus approfondi de la classe responsable du traitement de ces politiques a permis d'identifier une méthode appelée applyTestPolicies. Cette méthode s'appuie sur une API privée, setLocalTestPoliciespour appliquer dynamiquement une liste de politiques.
Pour mieux comprendre comment les demandes de politiques sont traitées via cette API, les chercheurs analysent le fichier Gestion des politiques de test locales (HandleSetLocalTestPolicies) au sein de la méthode PolicyUIHandler classe :
Le Gestion des politiques de test locales (HandleSetLocalTestPolicies) récupère les données de la politique à partir des arguments fournis et obtient un pointeur sur le fichier LocalTestPolicyProvider via le connecteur de politique globale du navigateur. Il vérifie ensuite l'existence de ce fournisseur avant de demander au profil de l'utilisateur actuel de l'utiliser.
Cette vérification s'est avérée insuffisante, car elle ne permet que de s'assurer que fournisseur_de_test_local est non nul avant d'appliquer les politiques. La création et l'initialisation des fournisseur_de_test_local sont contrôlées par le CreateIfAllowed méthode :
Dans le cadre de la CreateIfAllowed la valeur de retour dépend entièrement du résultat de la méthode IsPolicyTestingEnabled fonction. Cette fonction détermine si un LocalTestPolicyProvider est créée en fonction des préférences de l'utilisateur et du canal de diffusion du navigateur :
Depuis préf_service est systématiquement mis à zéro à chaque fois que IsPolicyTestingEnabled() est appelée, la première condition est contournée, la décision d'activation reposant alors uniquement sur le canal de validation du navigateur.
Dans les versions sans marque de Chromium, le canal de publication est par défaut le suivant Canal::UNKNOWN. Selon la logique de la fonction, Canal::UNKNOWN est traité de la même manière que Canal::DEFAULTqui active par défaut la fonction de test des politiques. L'analyse du flux de code a révélé que l'API privée setLocalTestPolicies peut être invoqué via l'interface WebUI pour appliquer des politiques sans restrictions d'accès significatives.
Exploitation
En identifiant et en exploitant cette API privée, un attaquant peut appliquer arbitrairement des politiques par le biais de l'interface WebUI, ce qui permet de manipuler des paramètres tels que BrowserSwitcherEnabled, BrowserSwitcherUrlList, Chemin d'accès alternatifet AlternativeBrowserParameters pour exécuter des commandes. Par exemple, en définissant Chemin d'accès alternatif à powershell et AlternativeBrowserParameters à ["calc"]Les commandes arbitraires du shell peuvent être exécutées lorsqu'une URL spécifique est visitée.
Application d'une politique arbitraire pour les utilisateurs malveillants via une API privée
Pour démontrer comment les politiques peuvent être appliquées à l'aide de l'interface privée setLocalTestPolicies identifiée dans l'analyse précédente, le code JavaScript suivant est un script qui définit l'API Autoriser l'œuf de Pâques au dinosaure et l'applique efficacement par le biais de la WebUI en invoquant setLocalTestPolicies:
La politique peut être appliquée avec succès pour désactiver la Autoriser l'œuf de Pâques au dinosaure de la mise en place.
Pour plus d'impact, un attaquant peut cibler le BrowserSwitcher politique :
Cette politique permet au navigateur d'invoquer un autre chemin d'accès si l'URL répond à certaines conditions. Elle peut être exploitée en configurant ce chemin pour qu'il pointe vers un exécutable système afin d'exécuter des commandes du système d'exploitation. Le code JavaScript suivant illustre cette approche :
Ce script effectue les tâches suivantes :
- Active la fonction
BrowserSwitcherfonctionnalité pour exemple.com - Définit le chemin d'accès du navigateur alternatif à powerShell
- Exécute
calcà chaque fois que l'on accède à l'URL spécifié.
Simulation d'une extension Chrome malveillante
L'identification de l'API privée qui permet d'appliquer les politiques introduit un vecteur d'attaque important pour les adversaires. Pour exploiter efficacement cette vulnérabilité, un attaquant devrait développer une extension Chrome malveillante qui utilise l'API Chrome DevTools pour exécuter un code JavaScript malveillant.
Pour démontrer l'impact potentiel sur le monde réel, nos collègues ont simulé un scénario dans lequel une extension Chrome malveillante est installée sur un navigateur vulnérable et utilisée pour exécuter l'attaque.Les API chrome.devtools dans Chrome Extensions permettent aux développeurs d'étendre et d'interagir avec l'interface DevTools de Chrome.
Toutefois, l'exécution de l'API DevTools par le biais d'une extension présente certaines difficultés qu'il convient de contourner. Tout d'abord, l'API DevTools n'est opérationnelle que lorsque DevTools est ouvert et inspecte activement un site web. Deuxièmement, l'API DevTools ne permet pas l'exécution de code sur l'interface utilisateur Web (WebUI). Cette limitation permet de préserver la sécurité et l'intégrité de l'interface WebUI pendant les processus de développement et d'inspection.
Signes indiquant l'exécution de Javascript via l'API rechargement
Une analyse plus approfondie a révélé que la fonction chrome.devtools.inspectedWindow.reload ne dispose pas de la vérification nécessaire pour confirmer qu'une extension est autorisée à exécuter des scripts sur la page inspectée. Son seul niveau de défense est le serveur d'extension devtools, qui bloque l'accès dès que l'URL de la page inspectée change.
Les pages about:blank héritent des permissions et de l'origine de la page qui les a ouvertes. Cela signifie que la possibilité d'exécuter du code sur about:blank lorsqu'elles sont redirigées depuis les signaux de l'interface WebUI constitue une vulnérabilité potentielle.
Exécution de code sur l'interface webUI via l'API rechargement
La condition de course dans chrome.devtools.inspectedWindow.reload() permet l'exécution de code sur les pages WebUI de Chrome (par exemple, chrome://policy), qui sont généralement protégées. L'exploit tire parti de la capacité de l'API rechargement à injecter du JavaScript pendant les transitions de page. Voici comment cela fonctionne :
- Cibler l'interface WebUI : Ouvrez une page WebUI (par exemple, chrome://policy) dans un onglet et attachez DevTools.
- Injecter un script : Utiliser l'API reload() avec un
injectedScriptpour exécuter un code JavaScript arbitraire pendant le rechargement. - Exploitation de la condition de course : La condition de course se produit lorsque le rechargement se déclenche avant que les mécanismes de sécurité de l'interface WebUI ne s'initialisent complètement, ce qui permet au script injecté de s'exécuter.
Dans le contexte de la navigation de la page about:blank vers chrome://policy :
Comme seule l'URL est vérifiée au lieu de l'origine de la page, il existe une brève période après la navigation pendant laquelle l'origine reflète la nouvelle page alors que l'URL reste inchangée.
Si chrome.devtools.inspectedWindow.reload est invoqué dans cette fenêtre, il risque d'exécuter involontairement du JavaScript sur la page de destination.
Améliorer la fiabilité des conditions de course
L'exploitation de la condition de course est intrinsèquement peu fiable en raison de sa dépendance à l'égard du temps. En outre, les rechargements rapides ou les scripts malformés peuvent provoquer des plantages de page. Une nouvelle approche pour améliorer la fiabilité consiste à provoquer intentionnellement un plantage de page, car les commandes émises via DevTools sont généralement annulées lors d'un plantage, mais Page.reload mappé à chrome.devtools.inspectedWindow.reload() est inscrit sur la liste blanche et exécuté après le rechargement de la page.
Voici un modèle de flux de travail permettant de planter une page en poussant les commandes suivantes :
Une déclaration de débogage dans un script de contenu peut déclencher un crash
L'utilisation du débogueur deux fois de suite perturbe le processus de navigation dans un script de contenu. Elle peut entraîner un plantage en plaçant navigation_commit_state dans un état imprévu. Ce problème se pose lorsque RenderFrameImpl::SynchronouslyCommitAboutBlankForBug778318 est exécuté, modification de _navigation_commit_state à une valeur inattendue.
La première invocation met l'exécution en pause, laissant navigation_commit_state dans un état incohérent, et la seconde s'interrompt pendant la durée de la CHECK_EQ ce qui fait échouer la validation de l'état et provoque un plantage.
Remédiation
Négliger de mettre régulièrement à jour la version de votre navigateur peut laisser votre appareil exposé à de graves menaces de sécurité, en particulier celles liées aux CVE (Common Vulnerabilities and Exposures). Pour aider à atténuer ce risque, MetaDefender Endpoint™ offre une protection robuste en détectant la version de votre navigateur et en vérifiant les vulnérabilités, y compris les CVE connues comme CVE-2024-6778.
MetaDefender Endpoint s'assure que votre application est à jour et signale toute version obsolète ou infectée. Il répertorie également les applications installées présentant des vulnérabilités connues, classées par gravité CVE, et recommande des correctifs pour atténuer efficacement les menaces potentielles. Pour voir une démonstration en direct de la façon dont MetaDefender Endpoint peut vous aider à réduire ces risques, contactez l'un de nos experts dès aujourd'hui.
