[English]Unschöne Geschichte, die ein Sicherheitsforscher gerade öffentlich gemacht hat. Angreifern ist es gelungen, die Synchronisationsfunktion des Google Chrome-Browsers für eigene Zwecke zu missbrauchen, um zumindest Informationen abzufragen.
Anzeige
Ich bin über diverse Tweet wie den nachfolgenden auf diesen Sachverhalt gestoßen. Catalin Cimpanu hat es auf ZDNet in diesem Artikel aufbereitet.
Die Chrome-Synchronisierung ist eine Funktion des Chrome-Webbrowsers, die Kopien der Chrome-Lesezeichen, des Browserverlaufs, der Passwörter sowie der Browser- und Erweiterungseinstellungen eines Benutzers auf den Cloud-Servern von Google ablegt. Dies ermöglicht Benutzern, die mit dem Google Chrome-Browser an einem Google-Benutzerkonto angemeldet sind, die gespeicherten Informationen über verschiedene Geräte zu synchronisieren. Der Benutzer hat so immer Zugriff auf seine aktuellen Chrome-Daten.
Angriff über Chrome-Erweiterungen
Der Sicherheitsforscher Bojan Zdrnja hat nun herausgefunden, dass diese Infrastruktur von Google auch als Command-and-Control (C2)-Kommunikationskanal missbraucht werden kann. Angreifer können Daten abziehen und auf eigenen Servern ablegen. Der Sicherheitsforscher hat das Ganze, welches er bei einem Angriff in freier Wildbahn gefunden hat, in diesem Beitrag dokumentiert.
Anzeige
Die Grundlage für diesen Angriff waren bösartige Erweiterungen, die der Angreifer auf dem kompromittierten System abgelegt hat. Kompromittierte Browser-Erweiterungen sind an sich nichts Neues – das ist eigentlich Tagesgeschäft und Google wirft häufiger solche Extensions aus dem Chrome Web Store (siehe Chrome-Erweiterung The Great Suspender wegen Malware aus Store entfernt).
Die Neuerung bestand in diesem Fall darin, dass die Angreifer nicht den Chrome Web Store zur Installation der Erweiterung nutzten. Vielmehr legten sie die Erweiterung lokal in einem Ordner auf dem System ab und luden sie direkt aus Chrome auf eine kompromittierte Workstation. Dies ist eigentlich eine legitime Funktion in Chrome. Nutzer können über Weitere Tools -> Erweiterungen gehen und dann den Entwicklermodus aktivieren.
Danach lassen sich beliebige Erweiterungen lokal, direkt aus einem Ordner über die Schaltfläche Entpackte Erweiterung laden aufrufen. Die Angreifer erstellten ein bösartiges Addon, das vorgab, Forcepoint Endpoint Chrome Extension for Windows zu sein, wie in der Abbildung unten zu sehen ist. Natürlich hatte die Erweiterung nichts mit Forcepoint zu tun – die Angreifer verwendeten lediglich das Logo und den Namen.
Bösartige Chrome Extension
Beim Erstellen von Chrome-Erweiterungen wird deren Konfiguration in einer Datei namens manifest.json gespeichert. Dort ist auch festgelegt, welche Berechtigungen die Erweiterung hat. Die Angreifer hatten die Manifest-Datei so manipuliert, dass nach dem Laden der Erweiterung ein Script im Hintergrund startete. Das Script suchte automatisch nach oauth-Token-Schlüsseln im Chrome-Speicher, die dann automatisch mit dem Google-Cloud-Speicher des Benutzers synchronisiert wurden.
Um Zugriff auf die synchronisierten sensiblen Daten zu erhalten, müsste sich der Bedrohungsakteur nur auf einem anderen System in das gleiche Google-Konto einloggen, auf dem der Chrome-Browser läuft. Hintergrund ist, dass Drittanbieter die private Google Chrome Sync API nicht nutzen dürfen. Sobald diese Anmeldung gelingt, kann ein Angreifer "die Infrastruktur von Google missbrauchen, um mit dem Chrome-Browser im Netzwerk des Opfers zu kommunizieren", schreibt Zdrnja. Und weiter: "Es gibt zwar einige Einschränkungen bei der Größe der Daten und der Anzahl der Anfragen, aber das ist eigentlich perfekt für C&C-Befehle (die in der Regel klein sind) oder für den Diebstahl kleiner, aber sensibler Daten – wie Authentifizierungs-Tokens, geeignet."
Zdrnja vermutet ein spezielles Scenario: Die Angreifers planten Daten in einer internen Webanwendung zu manipulieren und Informationen zu sammeln, auf die das Opfer Zugriff hatte. Da heute vieles ausschließlich als Web-Anwendung läuft, fallen dort viele Informationen an. Daher beschränkten die Angreifer ihren Zugriff auf dieser Workstation zunächst auf auf alles, was mit Webanwendungen zusammenhängt. Daher wurden (noch) keine keine anderen Binärdateien abgelegt, sondern nur die bösartige Chrome-Erweiterung. Vielleicht wäre zu einem späteren Zeitpunkt eine bösartige Binärdatei zum Erweitern der Zugriffe geladen worden.
Um die bösartige Erweiterung am Exfiltrieren von Daten zu hindern, müssten auch Server blockiert werden, die von Google für verschiedene legitime Zwecke genutzt werden (z. B. clients4.google.com). Daher ist dies nicht der richtige Weg, um sich vor ähnlichen Angriffen zu schützen. Um Angreifer daran zu hindern, die Sync-API von Google Chrome zum Sammeln und Exfiltrieren von Daten aus Unternehmensumgebungen zu missbrauchen, empfiehlt Zdrnja Gruppenrichtlinien. Dort lässt sich eine Liste von zugelassenen Chrome-Erweiterungen festlegen und alle anderen Extensions werden blockiert.
Als Benutzer kann man sich meiner Meinung nach ebenfalls leicht schützen, indem man auf die Anmeldung am Sync-Konto verzichtet. Hilft natürlich nicht gegen eine böswillige Chrome-Erweiterung, die per side-loading über die oben beschriebene Möglichkeit auf den Rechner kommt und dann Daten möglicherweise direkt liest.
An der Beschreibung des Sicherheitsforschers sind mir allerdings nach dem Querlesen des Beitrag noch zwei Sachen nicht ganz klar. Wie gelang es den Angreifern, die Lade-Funktion im Chrome zu aktivieren – muss der Benutzer dort eingreifen? Und wie gelangen die Angreifer an das Zugangstoken für das Google-Konto, welches zur Synchronisierung genutzt wird?
Ob das Ganze bei anderen Chromium-Browsern so genutzt werden kann, ist mir aktuell unklar. Der unten im Kommentar angefragte Edge synchronisiert über Microsoft Cloud-Konten. Wenn aber die gleichen Mechanismen verwendet werden, gibt es die gleiche Schwachstelle.
Anzeige
nicht schön…
Bin da voll bei dir (Nachsatz) so einfach dürfte das auch hier nicht sein wie es gerne dargestellt wird.
Weiss man schon, ob es den M$ Edge Chromium da auf diesem Bein auch erwischt oder läuft da der sync Prozess entscheidend anders? (Erwarte hierzu eigentlich identisches Problem, falls es schon in Chromium schlummert.)
Der Sync ist nicht im Chromium source.
Was nix heißt
Gut, dass das Thema hier aufgegriffen wird.
Über dieseMöglichkeit zu berichten, ist der erste Schritt, aber um es besser zu verstehen sollte man es simulieren und ebenso ein Abwehr (Script zum Entdecken) entwickeln.
Ich meine, dass man Sync auch per Gruppenrichtline abschalten kann.