Versteckter Verlaufssammler in ModHeader: Risiken für Entwickler

Google und Microsoft haben aus ihren Erweiterungs-Stores das beliebte Tool zur Bearbeitung von HTTP-Headern ModHeader (etwa 1,6 Mio. Installationen unter Chrome und Edge) entfernt, nachdem Forschende in seinem Code einen versteckten Mechanismus zur Sammlung des Browserverlaufs entdeckt hatten. Nach Angaben der Forschenden war der Mechanismus inaktiv – die interne Allowlist wurde leer ausgeliefert, und es wurden keine Belege für eine tatsächliche Datenübertragung gefunden. Allerdings war die gesamte Infrastruktur für Exfiltration – Verschlüsselung, Endpoint, Scheduler – bereits in der signierten und verifizierten Erweiterung vorhanden und konnte über ein normales Update ohne Anforderung zusätzlicher Berechtigungen beim Nutzer aktiviert werden. Nutzern wird empfohlen, die Erweiterung umgehend zu entfernen und sämtliche Secrets (API-Keys, Token, Cookies), die darüber eingegeben wurden, zu rotieren.

Was im Code entdeckt wurde

Die Analyse wurde vom britischen Unternehmen Stripe OLT durchgeführt, das den Erweiterungscode anhand der Signatur aus dem Chrome Web Store überprüfte und bestätigte, dass der versteckte Collector in der authentischen Version der Erweiterung und nicht in einer Fälschung vorhanden war. Unabhängige Analysen von HackIndex (Version 7.0.18) und des Forschers Yunus Aydin (Version 7.0.17) beschreiben denselben Mechanismus.

Die Version 7.0.18 (Erweiterungs-ID idgpnmonknjnojddfkpgkljpfnnfcklj) erfüllte die angegebene Funktion zum Bearbeiten von Headern. Im selben minimierten Hintergrundcode befand sich jedoch ein zweites System mit folgender Logik:

• Beim ersten Start wurde ein digitaler Fingerabdruck des Geräts erzeugt und ein fest im Code hinterlegter Verschlüsselungsschlüssel geladen.
• Beim Aufruf von Seiten wurde die Domain jeder geöffneten Seite extrahiert, verschlüsselt und lokal gespeichert – bis zu 1000 eindeutige Domains.
• Ein täglicher Scheduler sollte die verschlüsselte Liste zusammen mit dem Geräte-Fingerabdruck einsammeln, einen POST-Request an api.stanfordstudies[.]com senden und die lokale Kopie danach löschen.
• Die Sendezeit wurde für jede Installation verschoben, damit die Erweiterungen auf verschiedenen Maschinen nicht gleichzeitig den Server kontaktieren.

Der entscheidende Punkt: Der Collector wurde nur aktiviert, wenn der Browser mit einem Eintrag in der internen Allowlist übereinstimmte, die leer ausgeliefert wurde. Die Prüfung schlug daher stets fehl, und die Pipeline stoppte, bevor überhaupt die erste Domain erfasst wurde. Das Befüllen dieser Liste wäre jedoch eine minimale Änderung, die sich über ein Routine-Update ausliefern ließe – ohne neue Berechtigungen und ohne Zutun des Nutzers.

Aktive Komponenten

Nicht alles war inaktiv. Nach Angaben der Forschenden sendete die Erweiterung bei Installation, Update und Entfernung einen Request an die Domain extensions-hub[.]com mit Informationen zu Produkt, Version und Browser. Außerdem zeichnete ein auf jeder Seite ausgeführtes Skript Metadaten tatsächlicher Requests im Klartext im lokalen Speicher auf – diese Komponente war aktiv.

Warum automatische Scanner die Bedrohung nicht erkannten

Berichten zufolge stuften automatische Prüfungen ModHeader als Erweiterung mit geringem Risiko ein, einige bewerteten sie mit bis zu 95 von 100 Punkten. Jedes Element der Architektur war darauf ausgelegt, einen bestimmten Prüftyp auszutricksen: Die Daten sind verschlüsselt – der Scanner sieht nur Ciphertext; das Senden ist blockiert – die Sandbox registriert keinen ausgehenden Traffic; schädlicher Code ist in eine legitime Codebasis minimiert; Endpoints haben keine bösartige Reputation; eine signierte, populäre Erweiterung wird als vertrauenswürdig wahrgenommen. Die Signatur des Stores bestätigt die Herkunft der Datei, aber nicht ihr Verhalten.

Infrastruktur und Kontext

Stripe OLT ordnete die Domains einer tatsächlich betriebenen Infrastruktur zu. Die Domain stanfordstudies[.]com steht in keinem Zusammenhang mit der Stanford University – es handelt sich um eine umgewidmete Alt-Domain, hinter der ein OpenSearch-Backend steht. Die Domain extensions-hub[.]com ist für Werbezwecke konfiguriert. Zum Zeitpunkt der Analyse zeigten beide API-Endpoints auf denselben Server bei Amazon.

ModHeader sorgte bereits 2023 für Nutzerbeschwerden aufgrund der Einblendung von Werbung in Suchergebnissen und soll ungefähr im selben Zeitraum auf ein werbefinanziertes Modell umgestellt haben. Wer genau die Kontrolle über die Erweiterung übernommen hat, ist nicht bestätigt. Gleichzeitig behauptet die eigene ModHeader-Seite weiterhin, die Erweiterung sammle keine Nutzerdaten – was sich nur schwer mit einem eingebauten, wenn auch inaktiven Browserverlauf-Collector vereinbaren lässt.

Dieser Fall fügt sich in das Muster ein, das Brian Krebs bereits 2021 beschrieben hat: Populäre Erweiterungen werden still und leise aufgekauft und in Kanäle zur Datensammlung verwandelt. Der Unterschied besteht darin, dass der Mechanismus nun um Verschlüsselung und ein Gateway ergänzt wurde, das die Datenübertragung vor Scannern verbirgt.

Einschätzung der Auswirkungen

Am stärksten gefährdet sind Entwickler und Testfachleute – die Hauptzielgruppe von Tools zur Bearbeitung von HTTP-Headern. Diese Nutzergruppe arbeitet regelmäßig mit API-Keys, Authentifizierungs-Token und Session-Cookies, die direkt in die Erweiterung eingegeben werden. Die Forschenden stellten fest, dass die Header-History-Funktion von ModHeader vollständige HTTP-Header auf dem Datenträger speicherte, was ein Risiko für die Kompromittierung von Secrets darstellt – selbst ohne Aktivierung des eigentlichen Domain-Collectors.

Erweiterungen zur Bearbeitung von Headern und zur Verwaltung von Cookies benötigen ihrer Natur nach weitreichende Berechtigungen. Wenn dieses Vertrauen missbraucht wird, ist der potenzielle Schadensradius erheblich.

Praxisempfehlungen

Für Nutzer

• Entfernen Sie ModHeader aus Chrome und Edge – der Browser könnte die Erweiterung bereits automatisch deaktiviert haben.
• Stellen Sie sicher, dass Profil-Synchronisation oder verwaltete Erweiterungsrichtlinien sie nicht wiederherstellen.
• Wenn Sie über ModHeader API-Keys, Bearer-Token oder Session-Cookies eingegeben haben, rotieren Sie diese umgehend.

Für Sicherheitsteams

• Blockieren und protokollieren Sie Zugriffe auf die Domains stanfordstudies[.]com und extensions-hub[.]com auf DNS- und Proxy-Ebene.
• Suchen Sie in Logdaten nach der Erweiterungs-ID idgpnmonknjnojddfkpgkljpfnnfcklj und nach beliebigen POST-Requests an api.stanfordstudies[.]com/app/log.
• Stripe OLT hat fertige KQL-Abfragen für Microsoft Defender und Sentinel zur Erkennung dieser Aktivität veröffentlicht.

Das Entfernen der Erweiterung aus den Stores löst das Problem dieses konkreten Tools, beseitigt aber nicht das systemische Risiko. Dieser Fall zeigt eine konkrete architektonische Bedrohung: ein vollständig einsatzbereiter Datensammler, der die Store-Verifikation passiert, in ein vertrauenswürdiges, populäres Tool eingebettet ist und so ausgelegt wurde, dass er über ein gewöhnliches Update aktiviert werden kann. Organisationen sollten ihre Verfahren zur Kontrolle von Erweiterungen überdenken: auf schlafende Codepfade achten, auf neue Endpunkte für Verbindungen zu externen Servern und auf Funktionen, die ein Routine-Update nach einem Eigentümerwechsel der Erweiterung hinzufügen kann.