Webbrowser sind auf Milliarden von Geräten weltweit installiert und damit ein bevorzugtes Ziel für Cyberkriminelle. Da die großen Webbrowser eine riesige Nutzerbasis haben, kann eine einzige Sicherheitslücke weitreichende Folgen haben. Es ist wichtig, die Browser auf dem neuesten Stand zu halten, um vor den sich entwickelnden Bedrohungen geschützt zu sein.
Um den Schweregrad von Sicherheitslücken in Webbrowsern zu veranschaulichen, haben unsere Mitarbeiter eine umfassende Analyse von CVE-2024-6778 durchgeführt, einer Sicherheitslücke in Chromium-basierten Browsern, die insbesondere Chrome DevTools betrifft. In diesem Blog werden die technischen Aspekte der Schwachstelle, die potenziellen Auswirkungen und die Strategien zur Schadensbegrenzung ausführlich erläutert.
Hintergrund von CVE-2024-6778
CVE-2024-6778 ist eine in Chrome DevTools entdeckte Sicherheitslücke. Sie ermöglicht es Angreifern, über böswillige Browsererweiterungen bösartigen HTML- oder JavaScript-Code in privilegierte Browserseiten einzuschleusen. Laut NVD (National Vulnerability Database) wurde diese Sicherheitsanfälligkeit mit einem CVSS-Score von 8,8 als sehr schwerwiegend eingestuft.
Der hohe Schweregrad dieser Sicherheitsanfälligkeit ist darauf zurückzuführen, dass sie die Ausführung von Remotecode ermöglichen kann, was zu einer Beeinträchtigung von Systemen, einer Beeinträchtigung der Vertraulichkeit und einer Verringerung der Verfügbarkeit führen kann.
Chromium-Sicherheitsübersicht
Um die Auswirkungen von CVE-2024-6778 besser verstehen zu können, ist es wichtig, die wichtigsten Aspekte des Chromium-Sicherheitsmodells zu kennen. Chromium ist die Open-Source-Grundlage für Browser wie Google Chrome, Microsoft Edge, Opera und Brave. Es verwendet ein Multiprozessmodell, bei dem jede Registerkarte, auch als Renderer bezeichnet, und verschiedene Browserkomponenten in isolierten Prozessen ausgeführt werden, um die Stabilität und Sicherheit zu verbessern, indem der Umfang potenzieller Kompromisse begrenzt wird.
Ein grundlegendes Element der Sicherheit von Chromium ist sein Sandboxing-Mechanismus, der den direkten Zugriff von Renderer-Prozessen auf Systemressourcen einschränkt. Stattdessen werden alle Interaktionen über IPC-Kanäle (Inter-Process Communication) verwaltet, um sicherzustellen, dass nur autorisierte Operationen durchgeführt werden.
Nicht alle Komponenten innerhalb von Chromium unterliegen der vollständigen Sandboxing-Funktion. WebUI-Seiten, wie chrome://settings und chrome://downloads, werden innerhalb der Renderer-Prozesse gerendert, arbeiten aber mit teilweisen Sandbox-Einschränkungen. Dieser Prozess gewährt ihnen Zugriff auf Browser-APIs, die normalerweise nicht über das Web zugänglich sind.
So spielt beispielsweise die Seite chrome://policy in Unternehmensumgebungen eine wichtige Rolle, da sie es Administratoren und Benutzern ermöglicht, Browser-Sicherheitsrichtlinien zu konfigurieren und durchzusetzen. Diese Richtlinien werden auf Windows-Systemen auch über Gruppenrichtlinien verwaltet.
Da chrome://policy direkt mit dem Betriebssystem interagieren kann, ist es ein wertvolles Ziel für Angreifer. Mit der Sicherheitslücke CVE-2024-6778, die eine Race Condition in Chrome DevTools ausnutzt, können Angreifer bösartigen Code in diese Seiten einschleusen, was ein ernstes Sicherheitsrisiko darstellt.
Technische Analyse von CVE-2024-6778
Entdeckung
Diese Sicherheitslücke wurde in einer Testfunktion entdeckt, die in Chrome Enterprise Version 117 eingeführt wurde. Diese Funktion ermöglicht das Testen von Richtlinien über die Seite chrome://policy/test. Da die offizielle Dokumentation zu dieser Funktion begrenzt ist, führten unsere Mitarbeiter eine gründliche Untersuchung des Chromium-Quellcodes durch, die durch Erkenntnisse des CVE-Autors ergänzt wurde, um die Implementierung vollständig zu verstehen und damit verbundene Sicherheitslücken zu identifizieren.
Komponenten der Richtlinienverwaltung
Die Analyse des Quellcodes durch die OPSWAT ergab, dass innerhalb chrome://policy/testwerden die Richtlinien mit Hilfe der PolicyInfo Schnittstelle und kommuniziert zwischen der WebUI und den Browserprozessen über die PolicyTestBrowserProxy Klasse. Die Website PolicyInfo Struktur ist wie folgt definiert:
Bei einer weiteren Untersuchung der für die Bearbeitung dieser Politiken zuständigen Klasse wurde eine Methode namens applyTestPolicies. Bei dieser Methode wird eine private API verwendet, setLocalTestPolicies, um eine Liste von Richtlinien dynamisch anzuwenden.
Um einen Einblick in die Verarbeitung von Richtlinienanfragen über diese API zu erhalten, analysieren die Stipendiaten die HandleSetLocalTestPolicies Methode innerhalb der PolicyUIHandler Klasse:
Die HandleSetLocalTestPolicies Methode ruft die Richtliniendaten aus den angegebenen Argumenten ab und erhält einen Zeiger auf den LocalTestPolicyProvider Instanz über den globalen Policy Connector des Browsers. Anschließend wird die Existenz dieses Anbieters überprüft, bevor das aktuelle Benutzerprofil angewiesen wird, ihn zu nutzen.
Diese Überprüfung wurde als unzureichend erachtet, da sie nur sicherstellt, dass local_test_provider nicht null ist, bevor die Richtlinien angewendet werden. Die Erstellung und Initialisierung von local_test_provider werden von der CreateIfAllowed Methode:
Innerhalb der CreateIfAllowed Methode ist der Rückgabewert vollständig abhängig vom Ergebnis der IsPolicyTestingEnabled Funktion. Diese Funktion ermittelt, ob ein LocalTestPolicyProvider Instanz erstellt, die auf einer Kombination aus Benutzereinstellungen und dem Freigabekanal des Browsers basiert:
Seit pref_service wird jedes Mal konsequent auf Null gesetzt, wenn IsPolicyTestingEnabled() aufgerufen wird, wird die erste Bedingung umgangen, so dass sich die Freigabeentscheidung allein auf den Freigabekanal des Browsers stützt.
In ungebrandeten Chromium-Builds ist der Release-Channel standardmäßig auf Kanal::UNKNOWN. Nach der Logik der Funktion, Kanal::UNKNOWN wird genauso behandelt wie Kanal::DEFAULT, wodurch die Funktion zum Testen von Richtlinien standardmäßig aktiviert wird. Die Code-Flow-Analyse ergab, dass die private API setLocalTestPolicies kann über die WebUI aufgerufen werden, um Richtlinien ohne sinnvolle Zugriffsbeschränkungen anzuwenden.
Ausbeutung
Indem er diese private API identifiziert und ausnutzt, kann ein Angreifer über die WebUI willkürlich Richtlinien anwenden und Einstellungen manipulieren, z. B. BrowserSwitcherEnabled, BrowserSwitcherUrlList, AlternativerBrowserPfadund AlternativeBrowserParameter um Befehle auszuführen. Zum Beispiel durch die Einstellung AlternativerBrowserPfad zur Powershell und AlternativeBrowserParameter zu ["calc"]können beliebige Shell-Befehle ausgeführt werden, wenn eine bestimmte URL besucht wird.
Anwenden einer willkürlichen Richtlinie für böswillige Benutzer über eine private API
Um zu demonstrieren, wie Richtlinien mit Hilfe der privaten setLocalTestPolicies API , die in der vorherigen Analyse identifiziert wurde, ist der folgende JavaScript-Code ein Skript, das die AllowDinosaurEasterEgg Politik und wendet sie effektiv über die WebUI unter Berufung auf setLocalTestPolicies:
Die Richtlinie kann erfolgreich angewendet werden, um die AllowDinosaurEasterEgg Umgebung.
Um eine größere Wirkung zu erzielen, kann ein Angreifer auf die BrowserSwitcher Politik:
Diese Richtlinie ermöglicht es dem Browser, einen alternativen Browserpfad aufzurufen, wenn die URL bestimmten Bedingungen entspricht. Sie kann ausgenutzt werden, indem dieser Pfad so konfiguriert wird, dass er auf eine ausführbare Datei des Systems verweist, um Betriebssystembefehle auszuführen. Der folgende JavaScript-Code veranschaulicht diesen Ansatz:
Dieses Skript erledigt die folgenden Aufgaben:
- Aktiviert die
BrowserSwitcherFunktion für example.com - Legt den alternativen Browserpfad zur powerShell fest
- Führt aus.
calcwenn auf die angegebene URL zugegriffen wird.
Simulation einer bösartigen Chrome-Erweiterung
Die Identifizierung der privaten API , die die Anwendung von Richtlinien ermöglicht, stellt für Angreifer einen wichtigen Angriffsvektor dar. Um diese Schwachstelle effektiv auszunutzen, müsste ein Angreifer eine bösartige Chrome-Erweiterung entwickeln, die die Chrome API nutzt, um bösartigen JavaScript-Code auszuführen.
Um die potenziellen Auswirkungen in der Praxis zu veranschaulichen, simulierten unsere Stipendiaten ein Szenario, in dem eine bösartige Chrome-Erweiterung auf einem anfälligen Browser installiert und zur Durchführung des Angriffs genutzt wurde. Die chrome.devtools-APIs in Chrome-Erweiterungen ermöglichen es Entwicklern, die DevTools-Oberfläche von Chrome zu erweitern und mit ihr zu interagieren.
Die Ausführung der API über eine Erweiterung birgt jedoch einige Herausforderungen, die umgangen werden müssen. Erstens ist die API nur funktionsfähig, wenn DevTools geöffnet ist und aktiv eine Website inspiziert. Zweitens erlaubt die API nicht die Ausführung von Code auf der Web-Benutzeroberfläche (WebUI). Diese Einschränkung trägt dazu bei, die Sicherheit und Integrität der WebUI während der Entwicklungs- und Inspektionsprozesse zu wahren.
Zeichen, die auf die Ausführung von Javascript über die API hinweisen
Eine weitere Analyse ergab, dass bei der Einstellung „chrome.devtools.inspectedWindow.reloadfunction“ keine Überprüfung stattfindet, ob eine Erweiterung Skripte auf der untersuchten Seite ausführen darf. Die einzige Schutzmaßnahme ist der DevTools-Erweiterungsserver, der den Zugriff sperrt, sobald sich die URL der untersuchten Seite ändert.
About:blank-Seiten erben die Berechtigungen und den Ursprung der Seite, die sie geöffnet hat. Dies bedeutet, dass die Möglichkeit, Code auf about:blank auszuführen, wenn sie von den WebUI-Signalen umgeleitet werden, eine potenzielle Schwachstelle darstellt.
Ausführen von Code auf der webUI über reload API
Die Wettlaufbedingung in chrome.devtools.inspectedWindow.reload() ermöglicht die Codeausführung auf den WebUI-Seiten von Chrome (z. B. chrome://policy), die normalerweise geschützt sind. Der Exploit nutzt die Fähigkeit der API, JavaScript bei Seitenübergängen einzuschleusen. Und so funktioniert es:
- Ziel-WebUI: Öffnen Sie eine WebUI-Seite (z. B. chrome://policy) in einer Registerkarte und hängen Sie DevTools an.
- Skript einschleusen: Verwenden Sie die reload() API mit einer
injiziertesScriptParameter, um beliebiges JavaScript während des Neuladens auszuführen. - Race Condition ausnutzen: Die Race Condition tritt auf, wenn der Reload ausgelöst wird, bevor die Sicherheitsmechanismen der WebUI vollständig initialisiert sind, so dass das eingeschleuste Skript ausgeführt werden kann.
Im Zusammenhang mit der Navigation von der Seite about:blank zu chrome://policy:
Da nur die URL und nicht der Ursprung der Seite überprüft wird, gibt es nach der Navigation einen kurzen Zeitraum, in dem der Ursprung die neue Seite widerspiegelt, während die URL unverändert bleibt.
Wenn chrome.devtools.inspectedWindow.reload während dieses Fensters aufgerufen wird, wird möglicherweise unbeabsichtigt JavaScript auf der Zielseite ausgeführt.
Verbesserung der Zuverlässigkeit unter Rennbedingungen
Die Ausnutzung der Race Condition ist aufgrund ihrer Abhängigkeit vom Timing von Natur aus unzuverlässig. Außerdem können schnelle Neuladungen oder fehlerhafte Skripte zu Seitenabstürzen führen. Ein neuer Ansatz zur Verbesserung der Zuverlässigkeit besteht darin, absichtlich einen Seitenabsturz herbeizuführen, da Befehle, die über DevTools ausgegeben werden, während eines Absturzes in der Regel abgebrochen werden, aber Seite.neu laden abgebildet auf chrome.devtools.inspectedWindow.reload() wird in die Whitelist aufgenommen und nach dem Neuladen der Seite ausgeführt.
Im Folgenden wird ein Workflow-Modell zum Absturz einer Seite durch das Schieben nachfolgender Befehle dargestellt:
Debugger-Anweisung im Inhaltsskript kann einen Absturz auslösen
Wenn Sie den Debugger zweimal kurz hintereinander verwenden, wird der Navigationsprozess in einem Inhaltsskript unterbrochen. Es kann zu einem Absturz führen, indem es navigation_commit_state_ in einen unvorhergesehenen Zustand versetzt. Dieses Problem tritt auf, wenn RenderFrameImpl::SynchronouslyCommitAboutBlankForBug778318 ausgeführt wird, Ändern von _navigation_commit_state auf einen unerwarteten Wert.
Der erste Aufruf unterbricht die Ausführung und lässt navigation_commit_state_ in einem inkonsistenten Zustand, und der zweite pausiert während der CHECK_EQ überprüfen, was die Zustandsüberprüfung fehlschlagen lässt und einen Absturz verursacht.
Sanierung
Wenn Sie es versäumen, Ihre Browserversion regelmäßig zu aktualisieren, kann Ihr Gerät ernsthaften Sicherheitsbedrohungen ausgesetzt sein, insbesondere solchen, die mit CVEs (Common Vulnerabilities and Exposures) zusammenhängen. Um dieses Risiko zu mindern, bietet MetaDefender Endpoint™ zuverlässigen Schutz, indem es Ihre Browserversion erkennt und auf Schwachstellen prüft, einschließlich bekannter CVEs wie CVE-2024-6778.
MetaDefender Endpoint stellt sicher, dass Ihre Anwendung auf dem neuesten Stand ist und zeigt veraltete oder infizierte Versionen an. Es listet auch installierte Anwendungen mit bekannten Schwachstellen auf, kategorisiert nach CVE-Schweregrad, und empfiehlt Korrekturen, um potenzielle Bedrohungen effektiv zu entschärfen. Um eine Live-Demo zu sehen, wie MetaDefender Endpoint Ihnen dabei helfen kann, diese Risiken zu minimieren, nehmen Sie noch heute Kontakt mit einem unserer Experten auf.
