Browser-Pwning

Une documentation bien structurée pour démarrer avec le pwning de Chrome & le pwning de v8

Structure du document

Comment ce document est organisé

1. Motivation
2. Véritable matériel d’étude

Motivation

Les navigateurs sont l’une des technologies les plus utilisées aujourd’hui. Sur chaque ordinateur du commerce, si l’on branche et joue, on voit un navigateur installé. C’est pourquoi, du point de vue d’un attaquant et d’un modèle de menaces, il est très gratifiant pour l’attaquant de pouvoir compromettre le navigateur via une page malveillante. Compte tenu des arguments ci-dessus, j’ai choisi d’étudier le moteur JavaScript de Google, en particulier v8.

Étant donné la nature gigantesque du projet v8, j’ai choisi comme point de départ l’interpréteur, à savoir d8. Bien que des recherches approfondies aient déjà été menées sur d8, nous espérons trouver au moins un bug et, sinon, pouvoir avancer dans la recherche sur l’exploitation de navigateurs, car v8 constitue un terrain d’entrée pour les stratégies de base du développement d’exploits utilisées dans l’exploitation de navigateurs.

Une autre raison pour laquelle j’ai choisi v8 comme cible est qu’il est utilisé dans plusieurs navigateurs.

Si l’on regarde sous le capot, on constate que le moteur est également utilisé dans MicrosoftEdge, il y a donc une chance de recevoir plusieurs récompenses de bug bounty. Pour le système d’exploitation sous-jacent, le chercheur utilisera un mélange de Windows et Linux, car il n’y a pas de restriction en termes d’obtention d’un shell : les bugs de v8 permettent l’exécution de code via les pages wasm et ne sont liés à aucune plateforme spécifique.

Malheureusement, bien qu’un bug exploité dans v8 aboutisse à une exécution de code, nous ne pourrons exécuter aucun code à cause du sandbox. Nous obtiendrions donc une exécution de code dans le contexte du renderer, ce qui ne nous permettrait pas d’exécuter du code sur la machine. Pour cela, il nous faudrait un autre exploit pour le sandbox ; il nous faudrait donc une chaîne complète pour exploiter le système.

C’est pourquoi nous définissons les objectifs suivants afin de pouvoir démarrer le hacking de navigateurs :

• Apprendre, cartographier et maîtriser les structures internes utilisées par le moteur V8 et les points clés de l’architecture Chrome
• Apprendre et maîtriser les procédures de base nécessaires à l’exploitation de navigateurs

Apprendre, cartographier et maîtriser les structures internes utilisées par le moteur V8 et les points clés de l’architecture Chrome

Au premier stade du projet, il est nécessaire de rassembler un maximum de connaissances sur l’architecture de Chrome et sur la façon dont chaque composant interagit avec les autres. Pour mieux comprendre cela, il faut décomposer le projet Chromium en plusieurs sous-composants afin de pouvoir tout isoler et l’analyser correctement. Plus précisément, en combien de sous-composants chacun des composants suivants se divise :

• Architecture de V8
• Architecture de Chromium
• Architecture de Blink

L’étape la plus logique pour commencer est de comprendre l’architecture de Chromium. Alors, ok, nous voulons exploiter le navigateur, mais que se passe-t-il lorsque nous démarrons le navigateur ? Eh bien, après avoir cliqué sur l’exécutable Chromium, l’exécutable lance certains processus.

L’ordre et leur nom sont les suivants :

Le premier s’appelle processus de contenu. Que fait ce processus ?

• Il est connu comme le processus de démarrage.
• c’est aussi le processus principal
• il est responsable du démarrage du véritable processus principal, appelé processus navigateur.

Maintenant que nous savons brièvement ce qu’il fait, il est temps d’entrer plus en détail :

• Ainsi, la façon dont Chromium fonctionne, du moins sous Windows, consiste à compiler les fichiers dans une dll, puis à la charger en mémoire. La logique centrale du navigateur Chromium se trouve donc dans chromium.dll.
  Ceci est également confirmé par le code
  .
  Ceci est tiré de chrome_exe_main_win.cc et si vous êtes curieux de lire tout le code, il se trouve dans chromium/src/chrome/app. Ok, en poursuivant l’exécution, on voit qu’il appelle MakeMainDllLoader() pour invoquer la classe de chargement de la dll ; après cela, il lance le « loader », c’est-à-dire qu’il charge chrome.dll et, si nécessaire, le redémarre avec les lignes de commande nécessaires. Pour analyser plus en détail le Loader, il faut comprendre son code, qui se trouve dans le même répertoire, dans le fichier mail_dll_loader_win.cc. En parcourant le fichier jusqu’en bas, on voit l’appel à MakeMainDllLoader qui, selon la version que vous avez, appelle ChromeDllLoader ou ChromiumDllLoader.
  
  On voit que ChromiumDllLoader est une classe qui hérite de MainDllLoader. D’après la définition, la classe se contente de charger la dll en fonction des arguments passés à la ligne de commande et du type de processus
  .
  En analysant la méthode Launch, on comprend certaines choses qui se passent avant que chrome.dll démarre : on comprend à partir de ce commentaire que « // Launching is a matter of loading the right dll and calling the entry point. // Derived classes can add custom code in the OnBeforeLaunch callback. » lancer chrome consiste à charger un ensemble de dll qui font réellement le travail. Ensuite, il prend les arguments passés à la ligne de commande et initialise en outre les services du sandbox.
  .
  D’abord, il vérifie si c’est le navigateur qui appelle l’initialisation du sandbox, puis il vérifie si le processus qui a appelé l’initialisation du sandbox a été lancé en tant que service d’impression cloud. Il vérifie aussi si --no-sandbox a été passé au binaire, ce qui indique en gros au binaire de ne pas s’exécuter dans un sandbox. Il vérifie si l’une de ces options est définie et, si c’est le cas, il appelle le sandbox avec les options correspondantes. Puis, à la fin, nous arrivons à
  
  ce qui nous intéresse, cela représentant le wrapper d’appel à chrome_main.