Browser-Pwning

Una documentazione adeguata e ben strutturata per iniziare con il chrome pwning & il v8 pwning

Struttura del documento

Come è organizzato questo documento

1. Motivazione
2. Materiale di Studio Reale

Motivazione

I browser sono una delle tecnologie più utilizzate oggi. Su ogni computer standard, se facciamo plug and play vedremo un browser installato. Ecco perché, dalla prospettiva di un attaccante e di un modello di minaccia, è molto gratificante se l'attaccante riesce a compromettere il browser tramite una pagina dannosa. Dati gli argomenti precedenti, ho scelto di studiare il motore JavaScript di Google, in particolare v8.

Data la natura gigantesca del progetto v8, ho scelto come punto di partenza l'interprete, cioè d8. Sebbene su d8 sia già stata fatta una ricerca approfondita, speriamo di trovare almeno un bug e, in caso contrario, di poter andare avanti con la ricerca sullo sfruttamento dei browser, poiché v8 fornisce il terreno di ingresso per le strategie di base dello sviluppo di exploit utilizzate nell'esploitazione dei browser.

Un altro motivo per cui ho scelto v8 come bersaglio è che è usato su più browser.

Se guardiamo sotto il cofano, possiamo vedere che il motore è usato anche in MicrosoftEdge, quindi c'è la possibilità di multipli premi bug bounty. Per quanto riguarda il sistema operativo sottostante, il ricercatore userà un mix di Windows e Linux, poiché non ci sono restrizioni in termini di ottenimento di una shell, dato che i bug di v8 consentono l'esecuzione di codice tramite pagine wasm e non sono legati a una piattaforma specifica.

Purtroppo, anche se un bug sfruttato in v8 comporterebbe l'esecuzione di codice, non saremo in grado di eseguire alcun codice a causa della sandbox, e pertanto otterremmo l'esecuzione di codice nel contesto del renderer, il che non ci permetterebbe di eseguire codice sulla macchina. Per quello avremmo bisogno di un altro exploit per la sandbox, quindi avremmo bisogno di una full chain per compromettere il sistema.

E quindi definiamo i seguenti obiettivi per poter iniziare con il browser hacking

• Imparare, mappare, padroneggiare le strutture interne usate dal motore V8 e i punti chiave dell'architettura di Chrome
• Imparare e padroneggiare le procedure di base necessarie per lo sfruttamento dei browser

Imparare, mappare, padroneggiare le strutture interne usate dal motore V8 e i punti chiave dell'architettura di Chrome

Nella prima fase del progetto è necessario raccogliere quante più conoscenze possibili riguardo all'architettura di Chrome e a come ogni componente interagisce con gli altri. Per capire meglio questo, dobbiamo suddividere il Progetto Chromium in più sottocomponenti in modo da poter isolare tutto e analizzarlo correttamente. Più precisamente, in quanti sottocomponenti si suddivide ciascuno dei seguenti componenti

• Architettura V8
• Architettura Chromium
• Architettura Blink

Ora, il passo più logico per un primo passo è capire l'architettura di Chromium. Ok, quindi vogliamo sfruttare il browser, ma cosa succede quando avviamo il browser? Beh, dopo aver fatto clic sull'eseguibile di Chromium, l'eseguibile avvia alcuni processi.

L'ordine e i loro nomi sono i seguenti:

Il primo si chiama content process. Cosa fa questo processo?

• È conosciuto come il processo di avvio.
• è anche il processo principale
• è responsabile dell'avvio del vero processo principale chiamato browser process

Ora che sappiamo brevemente cosa fa, è il momento di approfondire:

• Quindi, il modo in cui Chromium funziona, almeno su Windows, è che compila i file in una dll e poi la carica in memoria. Quindi la logica principale del browser Chromium è in chromium.dll.
  Questo è confermato anche dal codice
  .
  Questo è tratto da chrome_exe_main_win.cc e se sei curioso di leggere tutto il codice si trova in chromium/src/chrome/app . Ok, proseguendo con l'esecuzione possiamo vedere che chiama MakeMainDllLoader() per chiamare la classe che carica la dll; dopo di che lancia il "loader", cioè carica la chrome.dll e, se necessario, la riavvia con le necessarie righe di comando. Per analizzare ulteriormente il Loader dobbiamo capire il suo codice, che si trova nella stessa directory, nel file mail_dll_loader_win.cc. Scorrendo fino in fondo al file possiamo vedere la chiamata a MakeMainDllLoader che a sua volta chiama, in base alla versione che hai, ChromeDllLoader o ChromiumDllLoader.
  
  Possiamo vedere che ChromiumDllLoader è una classe che eredita da MainDllLoader. Dalla definizione possiamo vedere che la classe semplicemente carica la dll in base agli argomenti passati alla riga di comando e al tipo di processo
  .
  Analizzando il metodo Launch possiamo capire alcune cose che accadono prima che chrome.dll parta: possiamo capire da questo commento che "// Launching is a matter of loading the right dll and calling the entry point. // Derived classes can add custom code in the OnBeforeLaunch callback." lanciare chrome è una questione di caricare un mucchio di dll che fanno effettivamente il lavoro. In secondo luogo, prende gli argomenti passati alla riga di comando e inizializza i servizi sandbox.
  .
  Prima controlla se è il browser a chiamare l'inizializzazione della sandbox, poi controlla se il processo che ha chiamato l'inizializzazione della sandbox è stato avviato come servizio di cloud print. Controlla anche se --no-sandbox è stato passato al binario, il che dice fondamentalmente al binario di non girare in una sandbox. Controlla se uno qualsiasi di questi era impostato e, se uno dei due è vero, chiama la sandbox con le rispettive opzioni. Poi alla fine arriviamo a
  
  che è ciò che ci interessa, questo rappresenta il wrapper per chiamare chrome_main.