Browser-Pwning

Eine ordentlich strukturierte Dokumentation für den Einstieg in Chrome-Pwning & v8-Pwning

Struktur des Dokuments

Wie dieses Dokument organisiert ist

1. Motivation
2. Eigentliches Studienmaterial

Motivation

Browser gehören heute zu den am häufigsten genutzten Technologien. Auf jedem handelsüblichen Computer, den wir einfach anschließen und einschalten, ist ein Browser installiert. Aus der Perspektive eines Angreifers und aus einer Bedrohungsmodell-Perspektive ist es daher sehr lohnenswert, wenn der Angreifer den Browser durch eine bösartige Seite kompromittieren kann. Aufgrund dieser Argumente habe ich mich entschieden, Googles JavaScript-Engine, insbesondere v8, zu studieren.

Angesichts der gigantischen Größe des v8-Projekts wähle ich als Startpunkt den Interpreter, nämlich d8. Obwohl bereits umfangreiche Forschung an d8 betrieben wurde, hoffen wir, mindestens einen Bug zu finden, und wenn nicht, in der Lage zu sein, mit der Forschung zur Browser-Ausnutzung fortzufahren, da v8 die Grundlage für die grundlegenden Exploit-Entwicklungsstrategien bietet, die bei der Browser-Ausnutzung verwendet werden.

Ein weiterer Grund, warum ich v8 als Ziel gewählt habe, ist, dass es in mehreren Browsern verwendet wird.

Wenn wir unter die Haube schauen, sehen wir, dass die Engine auch in MicrosoftEdge verwendet wird, sodass es eine Chance auf mehrere Bug-Bounty-Prämien gibt. Für das zugrunde liegende Betriebssystem wird der Forscher eine Mischung aus Windows und Linux verwenden, da es keine Einschränkungen hinsichtlich des Erhaltens einer Shell gibt, da v8-Bugs die Codeausführung über wasm-Seiten ermöglichen und nicht an eine bestimmte Plattform gebunden sind.

Leider werden wir, obwohl ein ausgenutzter Bug in v8 zu Codeausführung führen würde, aufgrund der Sandbox keinen Code ausführen können, und daher würden wir eine Codeausführung im Kontext des Renderers erhalten, was uns nicht erlauben würde, Code auf dem Rechner auszuführen. Dafür bräuchten wir einen weiteren Exploit für die Sandbox, also eine vollständige Kette, um das System auszunutzen.

Und so definieren wir die folgenden Ziele, um mit dem Browser-Hacking beginnen zu können:

• Die internen Strukturen der V8-Engine und die wichtigsten Punkte der Chrome-Architektur lernen, abbilden und beherrschen
• Die grundlegenden Verfahren lernen und beherrschen, die für die Browser-Ausnutzung notwendig sind

Lernen, Abbilden, Beherrschen der internen Strukturen der V8-Engine und der wichtigsten Punkte der Chrome-Architektur

In der ersten Phase des Projekts ist es notwendig, so viel Wissen wie möglich über die Chrome-Architektur zu sammeln und wie jede Komponente miteinander interagiert. Um dies besser zu verstehen, müssen wir das Chromium-Projekt in mehrere Unterkomponenten aufteilen, sodass wir alles isolieren und richtig analysieren können. Genauer gesagt, in wie viele Unterkomponenten die folgenden Komponenten zerfallen:

• V8-Architektur
• Chromium-Architektur
• Blink-Architektur

Der logischste erste Schritt ist nun, die Chromium-Architektur zu verstehen. Also gut, wir wollen den Browser ausnutzen, aber was passiert, wenn wir den Browser zum ersten Mal starten? Nun, nach dem Klicken auf die Chromium-Ausführbare startet diese einige Prozesse.

Die Reihenfolge und ihre Namen sind wie folgt:

Der erste heißt Content-Prozess. Was macht dieser Prozess?

• Er ist als Startprozess bekannt.
• Er ist auch der Hauptprozess.
• Er ist verantwortlich für das Starten des eigentlichen Hauptprozesses, der Browser-Prozess genannt wird.

Nachdem wir nun kurz wissen, was er tut, ist es Zeit, tiefer einzusteigen:

• Die Art und Weise, wie Chromium zumindest unter Windows funktioniert, ist, dass es die Dateien in eine DLL kompiliert und sie dann in den Speicher lädt. Die Kernlogik des Chromium-Browsers befindet sich also in chromium.dll. Dies wird auch durch den Code bestätigt . Dies stammt aus chrome_exe_main_win.cc und wenn du neugierig bist, den gesamten Code zu lesen, befindet er sich unter chromium/src/chrome/app. Ok, wenn wir die Ausführung weiterverfolgen, sehen wir, dass es MakeMainDllLoader() aufruft, um die DLL-Ladeklasse aufzurufen, danach startet es den "Loader", d.h. es lädt chrome.dll und startet es bei Bedarf mit den notwendigen Befehlszeilen neu. Um den Loader weiter zu analysieren, müssen wir seinen Code verstehen, der im selben Verzeichnis in der Datei mail_dll_loader_win.cc liegt. Wenn wir ganz nach unten scrollen, sehen wir den Aufruf von MakeMainDllLoader, der wiederum basierend auf der Version, die du hast, ChromeDllLoader oder ChromiumDllLoader aufruft. Wir sehen, dass ChromiumDllLoader eine Klasse ist, die von MainDllLoader erbt. Aus der Definition können wir ersehen, dass die Klasse einfach die DLL basierend auf den an cmdline und Prozesstyp übergebenen Argumenten lädt . Wenn wir die Launch-Methode analysieren, können wir einige Dinge verstehen, die passieren, bevor chrome.dll startet: Aus diesem Kommentar können wir entnehmen, dass "// Launching is a matter of loading the right dll and calling the entry point. // Derived classes can add custom code in the OnBeforeLaunch callback." Das Starten von Chrome ist eine Frage des Ladens einer Reihe von DLLs, die tatsächlich die Arbeit erledigen. Zweitens nimmt es die an die Befehlszeile übergebenen Argumente und initialisiert weiter die Sandbox-Dienste. . Zuerst prüft es, ob es der Browser ist, der die Sandbox-Initialisierung aufruft, dann prüft es, ob der Prozess, der die Initialisierung der Sandbox aufgerufen hat, als Cloud Print-Dienst aufgerufen wurde. Es prüft auch, ob --no-sandbox an die Binärdatei übergeben wurde, was der Binärdatei im Grunde sagt, dass sie nicht in einer Sandbox ausgeführt werden soll. Es prüft, ob eine dieser Optionen gesetzt wurde, und wenn eine davon wahr ist, ruft es die Sandbox mit den entsprechenden Optionen auf. Am Ende gelangen wir zu was uns interessiert, das den Wrapper zum Aufrufen von chrome_main darstellt.