Sie würden niemals eine Anwendung installieren, die sich in Ihre Google Docs einloggen, Ihre Tastenanschläge in Ihrem Browser lesen, Anfragen im Transit abfangen, kontinuierlich läuft, stillschweigend Updates durchführt UND mächtig genug sein könnte, um Ihre Passwörter zu stehlen, oder? Nun, genau das können Browser-Erweiterungen mehr oder weniger tun, und sie schaffen Schwachstellen, die über einen einzelnen Computer oder sogar ein einzelnes Unternehmen hinausgehen.
Vor einigen Monaten installierte ein Vercel-Mitarbeitender die relativ neue und beliebte Browser-Erweiterung Context.ai, die eine „AI Office Suite“ bereitstellte. Sie benötigte eine OAuth-Berechtigung, um sich mit den Anwendungen zu verbinden. Als der Berechtigungsbildschirm sie aufforderte, dem Tool Zugriff auf ihr Google-Konto zu gewähren, klickten sie auf „Zulassen“. Es war keine Erweiterung, die Vercel intern genehmigt hatte, aber auch keine blockierte.
Ende Februar installierte ein Mitarbeiter von Context.ai später einen Roblox-Cheat-Download, der einen Infostealer enthielt. Diese Malware fand das Vercel OAuth-Token, das zum Einfallstor für einen groß angelegten Angriff auf Vercel wurde. Der Angreifer musste Vercel nicht hacken. Sie mussten das KI-Startup hacken, dessen Software ein Vercel-Mitarbeiter bereits die Zugangsdaten anvertraut hatte.
Eine Malware stahl Daten, die von einer Shadow-Browser-Erweiterung gesammelt wurden. Klingt das Muster bekannt? Es sieht nach einem Supply-Chain-Angriff aus, und das ist es auch.
Wie die Vercel-Datenpanne ein Lieferkettenangriff war
Browser-Erweiterungen haben sich zu einem der am meisten unterschätzten Angriffsvektoren in der Unternehmenssicherheit entwickelt, und die Vercel-Datenpanne ist nur das jüngste Beispiel dafür. Der Angriff folgte einem Muster, das der Sicherheitsbranche von Open-Source-Abhängigkeiten gut bekannt ist: Drittanbieter-Code wird implizit vertraut und dann vorgelagert kompromittiert. Wir haben einen Namen für dieses Muster und eine ganze Kategorie von Tools, die darauf aufbauen, aber die Branche als Ganzes hat sie noch nicht auf Browser-Erweiterungen angewendet.
Ein Lieferkettenangriff hat einige Hauptbestandteile. Man benötigt Drittanbieter-Code, der mit echten Privilegien läuft, implizites Vertrauen und Opfer ohne direkte Beziehung zur Quelle der ursprünglichen Kompromittierung. Die Vercel-Datenpanne erfüllt alle drei Kriterien. Context.ai war ein echtes Produkt, das eine echte Aufgabe erfüllte, und der OAuth-Zugriff, der ihm auf Google Workspace gewährt wurde, war für seine Zwecke eine vernünftige Anforderung (wenn auch wohl etwas zu viel Vertrauen und Macht). Das bedeutete, dass ein hochprivilegiertes OAuth-Token im AWS-Backend von Context.ai lag, nur ein kompromittiertes Mitarbeitergerät davon entfernt, Eigentum eines Angreifers zu werden.
Als dieser Context.ai-Mitarbeiter einen Infostealer auf seinem eigenen Rechner installierte, wurde das Vertrauen, das nur ein Mitarbeiter einer zuvor legitimen Erweiterung entgegengebracht hatte, zum Einfallstor in deren interne Umgebungen. Die ursprüngliche Datenpanne geschah woanders, aber Vercel war betroffen. Und das nennen wir einen Lieferkettenangriff.
Der Fall von Vercel ist nicht der erste Malware-Angriff, der Browser-Erweiterungen als Teil eines Lieferkettenangriffs nutzt. Zum Beispiel war die Cyberhaven-Datenpanne Ende 2024 eine gezielte Version eines ähnlichen Szenarios, bei der entwicklerorientierte Erweiterungen speziell im Visier der Angreifer standen. Die eigene Chrome-Erweiterung von Cyberhaven wurde über einen Phishing-Angriff auf ein Entwicklerkonto kompromittiert, und ein bösartiges Update wurde an die Nutzer verteilt, bevor es jemand bemerkte. Die bösartige Version war etwa 24 Stunden lang aktiv.
Das Modell der stillen Updates birgt mehr Gefahren
Das Update-Modell für Erweiterungen ist aus Sicherheitsperspektive betrachtet etwas heikel. Im Gegensatz zu Betriebssystem-Software aktualisieren sich Browser-Erweiterungen still und automatisch. Der Code, der heute in Ihrem Browser läuft, ist möglicherweise nicht die App, der Sie bei der Installation zugestimmt haben. Anders als bei anderen Software-Updates, die Sie zur Aktualisierung auffordern (monatelang, während Sie immer wieder auf „Später aktualisieren“ klicken), gibt es keine Aufforderung, die Zustimmung des Nutzers für ein Update einzuholen. Eine Benachrichtigung erhalten Sie nur, wenn die Erweiterung zusätzliche Berechtigungen anfordert. Eine Erweiterung, die letzten Monat sauber war, könnte heute Nacht ein bösartiges Update erhalten, und jeder Nutzer, der sie installiert hat, würde es automatisch bekommen. Wenn sie bereits viele Berechtigungen hatte, sind Sie in Schwierigkeiten. Stellen Sie sich vor, Software-Abhängigkeiten würden sich auf Ihrem Entwicklerrechner stillschweigend automatisch aktualisieren.
Was bisher nicht funktioniert hat
Unternehmen haben oft versucht, entweder Listen erlaubter Erweiterungen zu erstellen (alles andere blockierend) oder das Gegenteil, also Listen blockierter Erweiterungen. In beiden Fällen gibt es jedoch offensichtliche Hindernisse, die Liste kuratiert und aktuell zu halten. Etwa die Hälfte der Erweiterungsautoren ist unbekannt, und die meisten Herausgeber haben nur eine Erweiterung veröffentlicht, sodass die Verwaltung von Erweiterungen basierend auf Reputation nur für einen kleinen Teil der Erweiterungen funktioniert. Selbst große Unternehmen veröffentlichen Erweiterungen, die ohnehin nicht lupenrein sind. Eine genaue und aktuelle interne Liste manuell zu pflegen ist unmöglich.
SCA-Scanning wurde erfunden, um dies für Pakete zu lösen. Die Mechanismen, die für Open-Source-Abhängigkeiten funktionieren, basieren darauf, was das Paket tut (nicht auf Name oder beanspruchter Funktionalität). npm-Pakete allein nach Paketnamen zu genehmigen, ohne Code-Scanning und ohne Bedrohungsaufklärung, würde nicht als Lieferketten-Sicherheit für Abhängigkeiten zählen. Tauscht man jedoch „npm-Paket“ gegen „Chrome-Erweiterung“ aus, so ist dies mehr oder weniger der Ansatz für Browsersicherheit in den letzten Jahren.
Behandeln wir Browser-Erweiterungen wie andere Lieferkettenvektoren
Auch wenn die Marktplätze es nicht widerspiegeln, reicht Vertrauen zum Installationszeitpunkt nicht aus. Wir müssen hier dieselbe Philosophie anwenden wie bei der Paketsicherheit. Organisationen müssen wissen, was auf allen Maschinen installiert ist, und sie benötigen eine kontinuierliche Überwachung, damit eine scheinbar saubere Erweiterung, die bösartig wird, nicht unbemerkt bleibt.
Die meisten Sicherheitsteams können ein Bedrohungsmodell für Lieferketten bei Abhängigkeiten formulieren. Sie wissen, dass Maintainer-Konten kompromittiert werden und ein Paket, das letztes Quartal sauber war, heute ein Vektor sein kann (und wir haben in letzter Zeit viele hochkarätige Lieferkettenangriffe gesehen). Als Branche haben wir dieses Wissen jedoch nicht im gleichen Maße auf Browser-Erweiterungen angewendet.
Was für Abhängigkeiten funktioniert, kann auch für Browser-Erweiterungen funktionieren. Der Scan von Softwareabhängigkeiten funktioniert, weil die zugrunde liegende Bedrohungsaufklärung aktuell bleibt und mit Datenbanken abgeglichen wird, die sich bei Entdeckung neuer Bedrohungen aktualisieren, anstatt mit einer Liste, die jemand letztes Quartal erstellt hat. Die Vorinstallationsblockierung für Browser-Erweiterungen muss auf die gleiche Weise funktionieren. Lieferkettenangriffe entwickeln sich schnell, und eine Positivliste, die letzten Monat korrekt war, weiß nicht, dass eine Erweiterung den Besitzer wechselte oder letzte Woche ein bösartiges Update erhielt.
Organisationen benötigen außerdem Transparenz darüber, was auf jedem Entwicklergerät installiert ist. Paketmanager hinterlassen eine digitale Spur wie Lock-Dateien und Abhängigkeitslisten, die in Repositories gespeichert sind, aber Browser-Erweiterungen haben das nicht. Die einzige Möglichkeit, dies zu wissen, besteht darin, alle Geräte in der Organisation aktiv zu prüfen. Man kann nicht auf Bedrohungen reagieren, von denen man nichts weiß, und viele Unternehmen verfügen nicht über die entsprechenden Tools dafür.
Schließlich muss sich jeder in einer Organisation, von Ingenieuren bis zur Personalabteilung, der Risiken von Browser-Erweiterungen bewusst sein. Abhängigkeits-Schwachstellen haben viel Aufmerksamkeit in den Medien erhalten, die Browsersicherheit jedoch weniger. Während die Menschen im Allgemeinen wissen, dass sie nicht ideal sind, sind sie sich oft nicht so sehr dieser großen Schwachstellen wie dem Diebstahl von Zugangsdaten bewusst. Wir müssen unsere Teams und Organisationen über Risiken und Best Practices aufklären (senden Sie ihnen zum Beispiel diesen Artikel).
Den nächsten Lieferkettenangriff im Vercel-Stil verhindern
Die Vercel-Datenpanne wird nicht der letzte Vorfall sein, bei dem eine Browser-Erweiterung Teil der Kill Chain ist. Die Angriffsfläche ist zu wertvoll, und die Kontrollen, auf die sich die meisten Organisationen verlassen, sind zu begrenzt, als dass sich dies von selbst ändern würde. Behandeln Sie die Browsersicherheit für Erweiterungen als das Lieferkettenproblem, das sie bereits ist, hoffentlich vor dem nächsten Angriff (nicht danach).
Aikido Endpoint wendet ein Lieferketten-Sicherheitsmodell an, um Entwicklergeräte zu schützen. Bösartige Erweiterungen werden blockiert, bevor sie installiert werden, als bösartig erkannt und gegen Aikido Intel geprüft, bevor sie das Gerät erreichen. Der Aikido Intel Feed, der dies ermöglicht, identifiziert täglich bis zu 100.000 bösartige Pakete und ist öffentlich sowie kostenlos unter intel.aikido.dev einsehbar.
Erfahren Sie mehr über Aikido Endpoint oder erkunden Sie den Aikido Intel Feed, um zu sehen, was in Echtzeit in den Open-Source-Ökosystemen entdeckt wurde.
