Browser-Pwning

Uma documentação adequada e bem estruturada para começar com chrome pwning & v8 pwning

Estrutura do documento

Como este documento está organizado

1. Motivação
2. Material de Estudo Real

Motivação

Navegadores são uma das tecnologias mais usadas hoje em dia. Em todo computador de prateleira, se simplesmente conectarmos e usarmos, veremos um navegador instalado. É por isso que, do ponto de vista de um atacante e de uma perspectiva de modelo de ameaças, é muito recompensador se o atacante conseguir comprometer o navegador através de uma página maliciosa. Dados os argumentos acima, escolhi estudar o Motor JavaScript do Google, particularmente o v8.

Dada a natureza gigantesca do projeto do v8, escolhi como ponto de partida o interpretador, nomeadamente o d8. Embora uma pesquisa extensa já tenha sido feita sobre o d8, esperamos encontrar pelo menos um bug e, se não, conseguir avançar com a pesquisa sobre exploração de navegadores, já que o v8 fornece o terreno de entrada para as estratégias básicas de desenvolvimento de exploits usadas na exploração de navegadores.

Outra razão pela qual escolhi o v8 como alvo é que ele é usado em vários navegadores.

Se olharmos por baixo do capô, podemos ver que o motor também é usado no MicrosoftEdge, então há uma chance de múltiplos prêmios de bug bounty. Para o sistema operacional subjacente, o pesquisador usará uma mistura de Windows e Linux, já que não há restrição em termos de obter um shell, pois bugs do v8 permitem execução de código através de páginas wasm e isso não está vinculado a nenhuma plataforma específica.

Infelizmente, embora um bug explorado no v8 resulte em execução de código, não conseguiremos executar nenhum código devido à sandbox e, assim, obteríamos execução de código no contexto do renderer, o que não nos permitiria executar código na máquina. Para isso, precisaríamos de outro exploit para a sandbox; portanto, precisaríamos de uma cadeia completa para explorar o sistema.

E assim definimos os seguintes objetivos para conseguir começar com hacking de navegadores

• Aprender, mapear, dominar as estruturas internas usadas pelo motor V8 e os pontos-chave da arquitetura do Chrome
• Aprender e dominar os procedimentos básicos necessários para a exploração de navegadores

Aprender, mapear, dominar as estruturas internas usadas pelo motor V8 e os pontos-chave da arquitetura do Chrome

Na primeira fase do projeto, é necessário reunir o máximo de conhecimento sobre a Arquitetura do Chrome e como cada componente interage com os outros. Para entender melhor isso, precisamos dividir o Projeto Chromium em vários subcomponentes, de modo que possamos isolar tudo e analisá-lo adequadamente. Mais precisamente, em quantos subcomponentes cada um dos seguintes componentes se divide

• Arquitetura do V8
• Arquitetura do Chromium
• Arquitetura Blink

Agora, o passo mais lógico para um primeiro passo é entender a arquitetura do Chromium. Então, ok, queremos explorar o navegador, mas o que acontece quando iniciamos o navegador pela primeira vez? Bem, depois de clicar no executável do Chromium, o executável inicia alguns processos.

A ordem e seus nomes são os seguintes:

O primeiro é chamado de content process. O que esse processo faz ?

• Ele é conhecido como o processo de inicialização.
• Ele também é o processo principal
• É responsável por iniciar o processo principal real, chamado browser process

Agora que sabemos brevemente o que ele faz, é hora de nos aprofundarmos nele:

• Então, a forma como o Chromium funciona, pelo menos no Windows, é que ele compila os arquivos em uma dll e, depois disso, carrega-a na memória. Portanto, a lógica central do navegador Chromium está em chromium.dll.
  Isso também é confirmado pelo código
  .
  Isso é retirado de chrome_exe_main_win.cc e, se você estiver curioso para ler o código inteiro, ele está localizado em chromium/src/chrome/app . Ok, descendo na execução, podemos ver que ele chama MakeMainDllLoader() para chamar a classe de dll carregada; depois disso, ele inicia o "loader", ou seja, carrega o chrome.dll e, se necessário, o reinicia com as linhas de comando necessárias. Para analisar melhor o Loader, precisamos entender seu código, que está no mesmo diretório, no arquivo mail_dll_loader_win.cc.Descendo até o final do arquivo, podemos ver a chamada a MakeMainDllLoader, que, por sua vez, chama, com base na versão que você tem, ChromeDllLoader ou ChromiumDllLoader.
  
  Podemos ver que ChromiumDllLoader é uma classe que herda de MainDllLoader. Podemos ver pela definição que a classe simplesmente carrega a dll com base nos argumentos passados para cmdline e no tipo de processo
  .
  Analisando o método Launch, podemos entender algumas coisas que acontecem antes de o chrome.dll iniciar: Podemos entender deste comentário 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." lançar o chrome é uma questão de carregar um monte de dlls que realmente fazem o trabalho. Em segundo lugar, ele pega os argumentos passados para a linha de comando e, além disso, inicializa os serviços de sandbox.
  .
  Primeiro, ele verifica se é o navegador que está chamando a inicialização da sandbox; depois, verifica se o processo que chamou a inicialização da sandbox foi chamado como um serviço de impressão na nuvem. Ele também verifica se --no-sandbox foi passado para o binário, o que basicamente diz ao binário para não executar em uma sandbox. Ele verifica se alguma dessas opções foi definida e, se alguma for verdadeira, chama a sandbox com as respectivas opções. Então, no final, chegamos a
  
  que é o que nos interessa, representando o wrapper para chamar chrome_main.