2 Punkte von GN⁺ 2024-03-07 | 1 Kommentare | Auf WhatsApp teilen
  • Under New Management ist eine Erweiterung, die regelmäßig prüft, ob sich die Entwicklerinformationen installierter Browser-Erweiterungen im Chrome Web Store oder bei Firefox Add-ons geändert haben
  • Wenn sich die Entwicklerinformationen ändern, zeigt sie am Erweiterungssymbol ein rotes Badge an, damit Nutzer den Eigentümerwechsel erkennen können
  • Die Notwendigkeit ergibt sich daraus, dass Entwickler von Erweiterungen häufig Übernahmeangebote erhalten und Käufer in den meisten Fällen versuchen, bestehende Nutzer auszunutzen
  • Nutzer bemerken möglicherweise nicht, dass sich die Eigentümerschaft einer installierten Erweiterung geändert hat und sie möglicherweise kompromittiert wurde; dieses Tool gibt ihnen die Möglichkeit, eine informierte Entscheidung zu treffen
  • Da Browser Einschränkungen für Änderungen an Domains von Erweiterungs-Marktplätzen haben, wird die Prüfung der Entwicklerinformationen an den ExBoost API-Server delegiert

Erkennung von Eigentümerwechseln bei Erweiterungen

  • Under New Management prüft gelegentlich, ob sich die Entwicklerinformationen installierter Erweiterungen im Chrome Web Store oder im Firefox-Add-ons-Store geändert haben
  • Wenn es Änderungen gibt, wird am Erweiterungssymbol ein rotes Badge angezeigt, sodass Nutzer den Eigentümerwechsel erkennen können
  • Ziel ist es, Nutzern die Möglichkeit zu geben, eine informierte Entscheidung über die von ihnen verwendete Software zu treffen

Warum das nötig ist

  • Entwickler von Erweiterungen erhalten ständig Angebote, ihre Erweiterungen zu verkaufen
  • Das README macht deutlich, dass Käufer in fast allen Fällen das Ziel haben, bestehende Nutzer zu täuschen
  • Nutzer wissen möglicherweise nicht, dass sich die Eigentümerschaft einer installierten Erweiterung geändert hat und sie nun möglicherweise kompromittiert ist

Installation

Aus dem Quellcode bauen

  • Under New Management verwendet Plasmo
  • pnpm install: Abhängigkeiten installieren
  • pnpm dev: lokal ausführen
  • pnpm build --zip: Release-Build
  • pnpm build --target=firefox-mv3: Build für Firefox

Warum ein externer Server nötig ist

  • Browser haben besondere Regeln für Änderungen an Domains von Erweiterungs-Marktplätzen
  • Zum Beispiel können für chromewebstore.google.com keine declarative_net_request-Regeln gesetzt werden
  • Daher wird die Prüfung der Entwicklerinformationen an den ExBoost API-Server delegiert

1 Kommentare

 
GN⁺ 2024-03-07
Kommentare auf Hacker News
  • Die Erweiterungs-ID wird aus dem privaten Schlüssel abgeleitet, den der Entwickler beim ersten Hochladen in den App Store mit hochgeladen hat; wenn spätere Upload-ZIPs ein anderes key.pem enthalten, ändert sich die ID.
    Fehlt key.pem jedoch, bleibt die Erweiterungs-ID unverändert. Wenn sich die ID ändert, könnte also der Eigentümer gewechselt haben, aber der ursprüngliche Eigentümer könnte den privaten Schlüssel auch an den neuen Eigentümer weitergegeben haben. Da Google nicht bei jedem Upload den privaten Schlüssel verlangt, kann der neue Eigentümer Änderungen auch ohne diesen Schlüssel ausliefern.
    Das Ökosystem für Erweiterungen ist spannend, deshalb baue ich auch Tools in diesem Bereich. Ich würde gern für bestimmte Erweiterungen ein GitHub-Repository anlegen, jedes Update als Änderung im Repository protokollieren und dann einen statischen Analyzer sowie eine Runtime-Taint-Analyse laufen lassen, die verfolgt, ob Nutzereingaben in gefährliche Sinks wie eval oder postMessage fließen: https://github.com/milesrichardson/crxmon

    • Früher hatte ich einmal eine Erweiterung für Opera, die auf der ersten Seite landete und beliebt wurde, und jemand bot eine ziemlich große Summe dafür.
      Während der Verhandlungen sagte ich, ich würde die Erweiterung offline nehmen und den gesamten Quellcode übergeben, damit er sie selbst veröffentlichen könne; mein Gegenüber erwartete aber, dass ich auch die Zugangsdaten zum Opera-Erweiterungskonto übergebe. Am Ende ließ ich den Deal platzen. Solche Tools sind sicher bis zu einem gewissen Grad nützlich, aber ich stimme zu, dass ein Malware-Scanner für Erweiterungen besser wäre.
    • Das entspricht nicht der Funktionsweise einer Public-Key-Infrastruktur (PKI). Ich bezweifle, dass man bei Chrome-Erweiterungen wirklich einen privaten Schlüssel als PEM-Datei hochladen soll.
      Der Entwickler sollte die Erweiterung oder das Manifest mit dem privaten Schlüssel signieren und den öffentlichen Schlüssel teilen oder in den Upload aufnehmen. Auch Updates müssten weiterhin mit demselben privaten Schlüssel signiert werden; solange der Schlüssel sich nicht ändert, lässt sich mit dem öffentlichen Schlüssel aus dem ersten Upload prüfen, ob derselbe private Schlüssel verwendet wurde. Ob der öffentliche Schlüssel in späteren Uploads enthalten ist, ist dabei nicht wesentlich. Wenn man den privaten Schlüssel verkauft oder teilt, kann jemand anderes legitim signierte Updates erstellen; das ist aber ein Risiko, das daraus entsteht, dass der Signierende den privaten Schlüssel nicht geheim hält. Wenn Google oder irgendjemand sonst den privaten Schlüssel teilt, bricht die Herkunftsgarantie der Erweiterung zusammen.
    • Wenn sich die Erweiterungs-ID ändert, müsste man die neue Version explizit installieren; sie würde nicht automatisch aktualisiert.
      Ich frage mich aber, ob es wirklich sein kann, dass Google einem neuen Eigentümer erlaubt, Änderungen ohne den privaten Schlüssel auszuliefern. Der Chrome Web Store ist selbst bei Kleinigkeiten extrem pingelig; seltsam, dass er sich um so etwas nicht kümmern sollte.
      Ich nutze drei Erweiterungen, die nur für Tester veröffentlicht sind, um sie auf mehreren Maschinen einfach installieren zu können, ohne Entwicklermodus oder rsync/robocopy zu verwenden. Dieses Wochenende hat Chrome sie jedoch nur auf einer Maschine alle deaktiviert, mit der Begründung, sie seien „nicht im Chrome Web Store gelistet und könnten ohne Wissen des Nutzers hinzugefügt worden sein“. Ich kann sie nicht erzwungen wieder aktivieren; im Store steht „inaktiv“ und es wird „Jetzt aktivieren“ angezeigt, aber dann verschwindet nur das Banner und erscheint nach dem Neuladen wieder. Das betreffende Chrome-Profil ist mit einem Konto von der Allowlist angemeldet.
      Das Badge auf der Chrome-Web-Store-Seite zeigt, dass mein Entwicklerkonto nicht sanktioniert ist und in gutem Zustand ist. Wäre ich nicht mit der Allowlist-E-Mail angemeldet, könnte ich diese Seite gar nicht sehen. Es ist schwer nachvollziehbar, dass man sich derart „kümmert“, aber zugleich Updates ohne Schlüssel zulässt.
    • Die beschriebene Methode ist zwar möglich, aber weder die vorgeschriebene noch die übliche Art, wie eine Erweiterungs-ID erzeugt wird. Normalerweise lädt ein Entwickler bei der ersten Einreichung nur eine ZIP-Datei hoch, und der Chrome Web Store erzeugt und speichert den privaten Schlüssel, der zum Signieren für die öffentliche Verteilung verwendet wird.
      CWS darf die ID einer bestehenden Erweiterung niemals ändern. Denn die ID identifiziert die Erweiterung eindeutig. Wenn sich die ID ändert, kann der Chrome-Client keine Updates für diese Erweiterung anfordern, und CWS sowie Chrome unterstützen keine Funktion, um Nutzer von einer Erweiterung zu einer anderen zu migrieren.
      Soweit ich weiß, würde CWS nach der ersten Einreichung ein ZIP mit key.pem ablehnen. Wenn sich die Erweiterungs-ID geändert hat, ist es nicht dieselbe Erweiterung. Dass ein neuer Eigentümer Änderungen auch ohne PEM ausliefern kann, stimmt im Großen und Ganzen; wenn der Entwickler die bei CWS eingereichte Erweiterung jedoch selbst signiert hat, kann er sie ohne PEM nicht aktualisieren. Ehrlich gesagt weiß ich nicht, ob diese Funktion heute noch möglich ist; früher war es eine riesige Falle, bei der Entwickler den privaten Schlüssel für ihren Upload verloren und damit ihre Installationsbasis ruinierten.
    • Wenn jemand eine Erweiterung mit bösen Absichten kauft, wird er auch den privaten Schlüssel haben wollen.
      Fast alle werden am Ende zustimmen, wenn der Preis stimmt; die Unterschiede liegen nur darin, wie viel sie dafür verlangen.
  • Vor ein paar Monaten habe ich eine kostenlose Open-Source-Erweiterung gebaut, die YouTube-Werbung schnell vorspult, sie hier geteilt und bin damit auf die erste Seite gekommen.
    Innerhalb einer Woche kopierte jemand, der meinen Show-HN-Beitrag kommentiert hatte, die Erweiterung, bewarb seine eigene Version auf Reddit, sie ging viral und kam auf über 300.000 Nutzer: https://github.com/rkk3/ad-accelerator/blob/main/lessons_pos...
    Ich fragte mich, warum er keinen PR an die kostenlose Open-Source-Erweiterung schickte, sondern sie kopierte; ein paar Wochen später versuchte er dann, sie auf mehreren Seiten für einen fünfstelligen Betrag zu verkaufen. Vielleicht besitzt er sie noch, aber mir fiel auch auf, dass der im Chrome Store eingetragene Entwickler nicht mehr derselbe war wie bei der ersten Veröffentlichung.

    • Wenn man auch die andere Seite der Geschichte liest, ändert sich der Kontext etwas: https://news.ycombinator.com/item?id=38463233
      Ich habe den ganzen Hintergrund nicht verstanden, aber die betreffende Erweiterung ist im Grunde ein triviales JavaScript von 50 Zeilen. Zu sagen, jemand habe sie gestohlen, ist ziemlich gewagt. Die Idee an sich hat keinen Wert, und es ist auch schwer zu behaupten, sie sei besonders neu. Selbst wenn man annimmt, dass die andere Person inspiriert wurde, ist die zeitliche Reihenfolge, wer zuerst was gemacht hat, nicht ganz eindeutig.
    • Du hast gesagt: „Nächstes Mal werde ich aggressiver Werbung machen“; ich denke, das könntest du auch diesmal tun. Die Erweiterung existiert ja noch, also kann man sie auch jetzt noch bewerben.
      Allerdings ist eine andere Frage, wie lange YouTube und Chrome sie funktionieren lassen; und begeistert dürften sie davon auch nicht sein.
    • Ich hoffe, dass es gut ausgeht; falls nicht, kann vielleicht Jeff Tweedys Haltung helfen.
      „…wenn die ganze Welt dein Lied singt / und alle deine Bilder aufgehängt sind / denk daran: Was einmal deins war, gehört jetzt allen / das ist weder richtig noch falsch / aber du kannst dich daran festklammern, so sehr du willst / nur wirst du dabei der Einzige sein, der nervös wird …“ — „What Light“ von Wilco
    • Ich frage mich, warum der Handle des HN-Nutzers nie als Text geschrieben wird, sondern nur in ein Bild eingefügt ist. Ich weiß nicht, welches Threat Model hier angenommen wird, wenn man in diesem Kommentar oder im Blogpost den Namen der Person, die kopiert hat, klar nennt.
    • Das klingt nach dem, was man „zuckered“ nennen würde.
  • Wirklich nützlich, aber wie andere schon gesagt haben: Das sollte eine eingebaute Browser-Funktion sein.
    Ich habe mir den Quellcode noch nicht im Detail angesehen, frage mich aber, ob bei einem Eigentümerwechsel automatisch benachrichtigt wird. Es muss nicht in Echtzeit sein, aber wird man beim Start informiert, oder muss man manuell einen Prüf-Befehl ausführen?
    Vor ein paar Monaten war das Thema schon einmal heiß diskutiert: https://news.ycombinator.com/item?id=36233068
    Wie damals in den Top-Kommentaren gesagt wurde, sollten Firefox und Chrome in solchen Fällen ihre Policy für automatische Erweiterungs-Upgrades ändern. Wenn eine Erweiterung einen Eigentümerwechsel offenlegt, sollte für das Upgrade die Zustimmung des Nutzers erforderlich sein; wenn sie ihn nicht offenlegt, sollten Nutzer sie als bösartig melden können. Außerdem sollte im Titel vermutlich „Show HN“ stehen.

    • Ich bin der Ersteller. Die Prüfung läuft stündlich automatisch, und wenn Änderungen erkannt werden, erscheint ein Badge auf dem Erweiterungs-Icon.
      Eine stärkere Benachrichtigung hielt ich für zu aufdringlich.
    • Wenn man wegen eines Eigentümerwechsels eines Unternehmens eine Temposchwelle einbaut, bei der Nutzer Upgrades ausdrücklich genehmigen müssen, wird ein erheblicher Anteil der Nutzer abspringen.
      Das senkt bei einem Verkauf den Wert des Produkts oder Unternehmens. Es ist nutzerfreundlich, aber unfreundlich gegenüber den Machern, die ihre Rechnungen bezahlen müssen.
  • Das ist kein Witz.
    Ich habe mehrere Jahre lang eine ziemlich beliebte Open-Source-Chrome-Erweiterung besessen, und die gesamten Spenden reichten nicht einmal für den monatlichen Kaffee.
    Gleichzeitig bekam ich zahlreiche Angebote, die Erweiterung zu kaufen, mit teils völlig absurden Summen — für offensichtlich bösartige Zwecke, in manchen Fällen wurde das sogar ganz offen gesagt. Ich habe sie alle abgelehnt, aber es ist keine vernünftige Annahme, dass in so einer Situation allein die Moral des ursprünglichen Entwicklers das einzige Sicherheits- und Datenschutzsystem sein soll.

    • Die wirklich bösartigen Akteure wird das Tool aus dem Beitrag nicht erkennen. Denn sie verlangen nicht nur die Eigentumsrechte an der Erweiterung und den Code, sondern auch die Übertragung des Entwicklerkontos.
  • Das Ziel kann ich gut nachvollziehen, und auch die technischen Grenzen verstehe ich, aber dass die Liste aller Erweiterungen eines Nutzers an ein auf Browser-Erweiterungen fokussiertes Werbenetzwerk geschickt wird, wirkt etwas verdächtig.
    Als Grund dafür, dass ein externer Server nötig ist, heißt es, Browser hätten spezielle Regeln für Änderungen an Domains von Erweiterungs-Marktplätzen wie chromewebstore.google.com; deshalb werde die Prüfung der Entwicklerinfos an den ExBoost-API-Server delegiert.
    https://www.extensionboost.com/
    ExBoost beschreibt sich als Kooperationsnetzwerk für Browser-Erweiterungen, die mehr Nutzer und Reviews wollen. Dabei wird in die UI der Erweiterung ein ExBoost-Slot eingebaut, in dem für ähnliche Erweiterungen geworben oder um Reviews gebeten wird.

    • Gut gefunden. Ich habe ein bisschen nachgegraben: Derzeit werden keine mit dem Browser verknüpften Metadaten gesendet, sondern nur eine durch Kommas getrennte Liste von Erweiterungs-IDs. Die IP kann natürlich leicht genutzt werden.
      Wenn man sich das API-Ergebnis für eine installierte Erweiterung ansieht, erscheinen dort Metadaten zum Entwickler. Ich habe die Chrome-API chrome.management.get(id) ausprobiert, aber diese Information wurde nicht zurückgegeben, und es scheint auch keine Möglichkeit zu geben, den Inhalt von manifest.json programmatisch abzurufen. Wenn die aktuelle Erweiterung also tun soll, was sie vorhat, braucht sie tatsächlich eine externe Quelle.
      https://github.com/classvsoftware/under-new-management/blob/...
      https://api.extensionboost.com/v1/developer?extension_ids=gh...
    • ExBoost scheint ebenfalls ein Projekt des Autors des ursprünglichen Beitrags zu sein. Wohlwollend interpretiert hat er diesen API-Server genutzt, weil dort bereits die nötigen Daten vorhanden sind, um bei Angabe einer Erweiterungs-ID Metadaten wie den Eigentümer zusammenzukratzen.
    • Ich habe zum Spaß ein paar kleine Erweiterungen gebaut und vor einigen Wochen von ExBoost eine E-Mail mit dem Betreff „Collaboration To Grow Our Extensions“ bekommen.
      Darin wurde ich gebeten, ihren Code in meine Erweiterung einzubauen, nach dem Motto: „Wenn du meine anzeigst, zeige ich deine. Kosten 0, alle gewinnen.“ Das wirkte verdächtig, also habe ich es als Spam markiert; es sah nicht anders aus als andere Spam-Mails von Betrügern, die ich bekomme.
    • Eine unerwartete Verbindung bei dieser Art von Projekt. Überraschend.
    • Ich verstehe nicht, warum es einen externen Dienst kontaktieren muss. Ich dachte, wenn der Eigentümer wechselt, ändert sich die Erweiterungs-ID; dann müsste man doch lokal die IDs verfolgen und anzeigen, wenn eine neue ID auftaucht. Vielleicht verstehe ich da etwas falsch.
  • Für Firefox-Erweiterungen gibt es Mozillas Programm für empfohlene Erweiterungen; dort heißt es, dass sie vor der Aufnahme eine strenge technische Prüfung durch Sicherheitsfachleute aus dem Mozilla-Team durchlaufen: https://support.mozilla.org/en-US/kb/recommended-extensions-...
    Aus dem Support-Dokument allein ist allerdings nicht klar, ob alle Updates vor der Veröffentlichung geprüft werden. Wenn jedes Mal geprüft wird, würde das dieses Problem bei beliebten Erweiterungen bis zu einem gewissen Grad lösen; ich frage mich aber auch, wie groß die Verzögerung wäre, wenn ein dringendes Sicherheitsupdate nötig ist.

    • Alle Updates werden geprüft. Selbst extrem beliebte Erweiterungen wie uBlock Origin hängen manchmal fest.
      Nach meiner aktuellen persönlichen Policy erlaube ich nur solchen kuratierten Erweiterungen, auf allen Websites und Tabs zu laufen.
    • Das klingt so, als wäre ein etwas umständlicher „Marketplace“ mit Regeln und tatsächlicher Durchsetzung wünschenswert.
      Also eine Struktur, in der selbst sehr populäre oder bekannte Organisationen gesperrt werden können, wenn sie wiederholt gegen Regeln verstoßen oder versuchen, Marketplace-Funktionen zu umgehen.
  • In wirklich bösartigen Fällen werden beim Verkauf einer Erweiterung oft gleich die Zugangsdaten des Google-Entwicklerkontos verkauft; solche Fälle würde das nicht erkennen.

    • Ist es überhaupt erlaubt, das gesamte Entwicklerkonto zu verkaufen?
  • Vor langer Zeit hatte ich adblock installiert und fand es großartig.
    Dann kaufte ich einen neuen Rechner und musste es erneut installieren; dabei sah ich zum ersten Mal die Berechtigungen, und das war ziemlich irre. Logisch ergibt es Sinn, dass es sehen können muss, was ich mir ansehe, um Werbung zu blockieren, aber ich hatte nie ernsthaft darüber nachgedacht.
    Heute nutze ich Pi-hole und gar keine Erweiterungen mehr.

    • Pi-hole blockiert Werbung und Tracker nicht so effektiv wie uBlock Origin.
      Trotzdem ist es gut, dass es für diejenigen, die es wollen, eine Auswahl gibt; unterschiedliche Menschen haben unterschiedliche Risikoprofile und Sorgen.
    • Einer der Gründe für die Berechtigungsänderungen in Manifest V3 ist von Anfang an, den Umfang dessen zu verringern, worauf Erweiterungen zugreifen können.
      Manche Erweiterungen sind Open Source und vertrauenswürdig, aber viele sind es nicht, und die Leute scheinen Schwierigkeiten zu haben, sie zu überprüfen.
    • Safari hat eine spezielle Schnittstelle, mit der Content-Blocker ganz ohne Berechtigungen funktionieren können.
      Man stellt eine Blockliste bereit, und der Browser blockiert direkt. Ob das auch in Firefox möglich ist, weiß ich nicht: https://developer.apple.com/documentation/safariservices/cre...
    • Ich frage mich, welche adblock-Erweiterung hier gemeint ist. uBlock zum Beispiel verwendet lokale Blocklisten.
    • Was macht man mobil?
  • Als Käufer einer bösartigen Erweiterung könnte man das doch umgehen, indem man den Entwicklernamen einfach beibehält, oder? Oder verwaltet der Chrome Extension Store Entwicklernamen streng?

    • Es ist praktisch schwer zu verhindern, dass ein unehrlicher Erweiterungsentwickler informell das Passwort weitergibt und mit einem „Ups, ich wurde gehackt“ einem verdächtigen Käufer einen Ausweg verschafft.
      Ein böswilliger staatlicher Akteur könnte zum Beispiel dem Autor von uBlock zig Millionen Dollar anbieten, um Zugriff auf viele Browser zu bekommen. Wie die Wirtschaftlichkeit dabei aussieht, weiß ich nicht, aber deutlich nischigere Erweiterungen ließen sich viel günstiger ins Visier nehmen.
    • Vermutlich ist das ein klarer Verstoß gegen die Nutzungsbedingungen des Chrome Web Store.
  • Ich frage mich, ob dieses Problem bei Chrome gravierender ist als bei anderen Browsern.
    Die einzige Browser-Erweiterung, die ich nutze, ist HonorLock, eine Prüfungsaufsichtssoftware, und ich muss sie verwenden. Da die Erweiterung nur für Chrome verfügbar ist, nutze ich wegen HonorLock gelegentlich Chrome. Wenn man den Installationslink in Safari öffnet, wird man aufgefordert, Chrome zu installieren: https://app.honorlock.com/install/extension
    Ich frage mich, ob Chrome-Erweiterungen Eigenschaften haben, die einerseits den Use Case von HonorLock ermöglichen, andererseits aber auch das Tool aus diesem Beitrag nützlicher machen.

    • Chrome ist einfach der beliebteste Browser und deshalb der gewählte Angriffsvektor über Erweiterungen.
    • Wenn du nur HonorLock nutzt, weiß ich nicht, wie du ohne AdBlock leben kannst.