Browser-Pwning

Una documentación adecuada y bien estructurada para comenzar con chrome pwning & v8 pwning

Estructura del documento

Cómo está organizado este documento

1. Motivación
2. Material de estudio real

Motivación

Los navegadores son una de las tecnologías más utilizadas hoy en día. En cualquier computadora estándar, si simplemente conectamos y usamos, veremos un navegador instalado. Es por eso que, desde la perspectiva de un atacante y desde una perspectiva de modelo de amenazas, es muy gratificante si el atacante puede comprometer el navegador a través de una página maliciosa. Dados los argumentos anteriores, elegí estudiar el motor de JavaScript de Google, particularmente v8.

Dada la gigantesca naturaleza del proyecto de v8, elegí como punto de partida el intérprete, es decir, d8. Aunque ya se han realizado investigaciones extensas sobre d8, esperamos encontrar al menos un bug y, si no, poder avanzar con la investigación sobre la explotación de navegadores, ya que v8 proporciona el terreno de entrada para las estrategias básicas de desarrollo de exploits utilizadas en la explotación de navegadores.

Otra razón por la que elegí v8 como objetivo es que se utiliza en múltiples navegadores.

Si miramos bajo el capó, podemos ver que el motor también se utiliza en MicrosoftEdge, por lo que hay una oportunidad de múltiples recompensas por bugs. Para el sistema operativo subyacente, el investigador utilizará una combinación de Windows y Linux, ya que no hay restricción en cuanto a obtener una shell, porque los bugs de v8 permiten la ejecución de código a través de páginas wasm y no están ligados a ninguna plataforma específica.

Desafortunadamente, aunque un bug explotado en v8 resultaría en ejecución de código, no podremos ejecutar ningún código debido al sandbox, y como tal obtendríamos ejecución de código en el contexto del renderer, lo que no nos permitiría ejecutar código en la máquina. Para eso necesitaríamos otro exploit para el sandbox, por lo que necesitaríamos una cadena completa para explotar el sistema.

Y así definimos los siguientes objetivos para poder comenzar con el hacking de navegadores

• Aprender, mapear y dominar las estructuras internas utilizadas por el motor V8 y los puntos clave de la arquitectura de Chrome
• Aprender y dominar los procedimientos básicos necesarios para la explotación de navegadores

Aprender, mapear y dominar las estructuras internas utilizadas por el motor V8 y los puntos clave de la arquitectura de Chrome

En la primera etapa del proyecto es necesario recopilar tanto conocimiento como sea posible sobre la arquitectura de Chrome y cómo interactúa cada componente entre sí. Para entender mejor esto, debemos dividir el Proyecto Chromium en múltiples subcomponentes para poder aislar todo y analizarlo adecuadamente. Más precisamente, en cuántos subcomponentes se divide cada uno de los siguientes componentes:

• Arquitectura de V8
• Arquitectura de Chromium
• Arquitectura de Blink

Ahora, el paso más lógico para un primer paso es entender la arquitectura de Chromium. Así que, vale, queremos explotar el navegador, pero ¿qué sucede cuando iniciamos el navegador por primera vez? Bueno, después de hacer clic en el ejecutable de Chromium, el ejecutable inicia algunos procesos.

El orden y sus nombres son los siguientes:

El primero se llama content process. ¿Qué hace este proceso?

• Se conoce como el proceso de inicio.
• también es el proceso principal
• es responsable de iniciar el proceso principal real, que se llama browser process

Ahora que sabemos brevemente qué hace, es hora de profundizar en ello:

• La forma en que funciona Chromium, al menos en Windows, es que compila los archivos en una dll y después la carga en memoria. Así que la lógica central del navegador Chromium está en chromium.dll. Esto también se confirma con el código . Esto está tomado de chrome_exe_main_win.cc y si tienes curiosidad por leer el código completo, se encuentra en chromium/src/chrome/app. Vale, bajando con la ejecución podemos ver que llama a MakeMainDllLoader() para llamar a la clase del cargador de dll; después de eso, lanza el "loader", es decir, carga el chrome.dll y, si es necesario, lo reinicia con las líneas de comando necesarias. Para analizar más a fondo el Loader, necesitamos entender su código, que está en el mismo directorio, en el archivo mail_dll_loader_win.cc. Desplazándonos hasta el final del archivo podemos ver la llamada a MakeMainDllLoader, que a su vez llama, según la versión que tengas, a ChromeDllLoader o ChromiumDllLoader. Podemos ver que ChromiumDllLoader es una clase que hereda de MainDllLoader. Podemos ver en la definición que la clase simplemente carga la dll basándose en los argumentos pasados a la línea de comandos y al tipo de proceso. . Analizando el método Launch podemos entender algunas cosas que suceden antes de que chrome.dll se inicie: Podemos entender de este comentario 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." lanzar chrome es cuestión de cargar un montón de dll que realmente hacen el trabajo. En segundo lugar, toma los argumentos pasados a la línea de comandos y además inicializa los servicios del sandbox. . Primero comprueba si es el navegador quien llama a la inicialización del sandbox; luego comprueba si el proceso que llamó a la inicialización del sandbox fue llamado como un servicio de impresión en la nube. También comprueba si se pasó --no-sandbox al binario, lo que básicamente le indica al binario que no se ejecute en un sandbox. Comprueba si alguna de estas opciones se estableció y, si alguna es verdadera, llama al sandbox con las opciones respectivas. Luego, al final llegamos a que es lo que nos interesa, esto representa el envoltorio para llamar a chrome_main.