Zusammenfassung

  • Eine Website, diecdn.polyfill.iolud, tat mehr, als ein Open-Source-Projekt zu zitieren. Sie erlaubte einem Live-Remote-Dienst, JavaScript auszuwählen und zur Ausführung im Browser-Kontext der Website zurückzugeben. Das Vertrauensobjekt umfasste daher die Domain, den Betreiber, den Routing- und Antwortpfad, nicht nur Quellcode, der anderswo eingesehen werden konnte. [15][16][17]
  • Die Kontrolle über die Polyfill.io-Domain und die dazugehörige Projektpräsenz wechselte im Februar 2024. Fastly, Cloudflare und ein FormatJS-Projekt-Problem reagierten damals und zeigten, dass eine nachgelagerte Neubewertung möglich war, bevor die bösartige Auslieferung im Juni öffentlich gemeldet wurde. Die Übertragung selbst sollte nicht als Beweis für böswillige Absicht beschrieben werden. [2][3][4]
  • Sansec berichtete am 25. Juni, dass der Dienst selektiv modifiziertes JavaScript zurückgab, das qualifizierte Besucher umleitete. Cloudflare erklärte, dass Page Shield-Indikatoren Übereinstimmungen bereits ab dem 8. Juni enthielten, während Akamai serverseitiges Sampling gefolgt von clientseitigen Prüfungen beschrieb. Diese Beobachtungen belegen eine Weiterleitungskampagne, nicht jede Aktion, die ein Remote-JavaScript theoretisch ausführen könnte. [1][5][9]
  • Sansecs Schätzung von mehr als 100.000 Websites bezog sich auf Websites, die den Dienst einbetteten oder nutzten. Cloudflare nannte eine Nutzungsschätzung von nahezu vier Prozent der Websites. Keine der Zahlen ist eine verifizierte Anzahl von Websites, die den bösartigen Zweig ausgeliefert, Besucher umgeleitet oder einen Schaden erlitten haben. [1][5]
  • Cloudflares automatische Umschreibung und Namecheaps Sperrung der Domain schränkten den Auslieferungspfad ein. Sie entfernten jedoch keine veralteten Referenzen aus nachgelagertem Code, stellten nicht fest, was jeder frühere Besucher erhalten hatte, und schlossen die Untersuchung jedes Website-Betreibers nicht ab. [5][6][10]
  • Fides, Jellyfish und Wordfence veranschaulichen drei verschiedene Evidenzaufgaben: Feststellen, ob ein bedingter Pfad erreichbar war, Rückverfolgung eines transitiven Anbieters, Überprüfung der Entfernung und Vermeidung, eine Referenz auf den Endpunkt als Beweis für eine Ausnutzung zu behandeln. [11][12][13][14][22]
  • Verantwortlichkeit ist hier kein rechtliches Urteil oder eine Behauptung gleicher Schuld. Es bedeutet, dass jede Partei für die Kontrollen rechenschaftspflichtig sein sollte, die sie tatsächlich ausüben konnte. Website-Betreiber behielten die Kontrolle über Notwendigkeit, Inventar, Anbieterwahl, Self-Hosting, Eigentumsüberwachung, browserseitige Beobachtung, Untersuchung, Reparatur und Kommunikation.

Ein Skript-Tag delegierte Autorität, nicht nur Bequemlichkeit

Die zentrale technische Entscheidung sah gewöhnlich aus. Eine Website platzierte einscript-Element auf einer Seite und verwies es aufcdn.polyfill.io. Wenn ein Besucher diese Seite lud, forderte der Browser JavaScript vom Remote-Dienst an. Der Dienst konnte Merkmale der Anfrage untersuchen und Polyfills liefern, die für den Browser geeignet waren, sodass ältere Browser Webfunktionen nutzen konnten, die sie nativ nicht implementiert hatten.

Diese Anordnung löste ein praktisches Kompatibilitätsproblem. Anstatt jede Kompatibilitätsfunktion an jeden Besucher auszuliefern, konnte eine Website einen spezialisierten Dienst bitten, das zurückzugeben, was ein bestimmter Browser zu benötigen schien. Das Ergebnis konnte kleiner und einfacher zu warten sein als ein universelles lokales Bundle. Aber die Effizienz beruhte darauf, die Antwort dynamisch zu halten. Die Website lud nicht einfach ein festes Paket während der Entwicklung herunter und setzte überprüfte Bytes aus ihrer eigenen Infrastruktur ein.

Sie lud einen anderen Betreiber ein, zum Zeitpunkt des Seitenaufbaus zu entscheiden, welche Bytes ein Besucher ausführen würde.

Die Unterscheidung bestimmt den Verantwortlichkeitsrahmen. Ein Open-Source-Repository ist überprüfbarer Code und Verlauf. Ein gehosteter Dienst ist eine Betriebsbeziehung. Der Live-Dienst hängt von einer Domain, DNS, Routing, Hosting, Zertifikaten, Bereitstellungszugriff und den Personen oder Organisationen ab, die die Antwort ändern können. Eine Website kann dem öffentlichen Code vertrauen, während sie dennoch versäumt zu prüfen, ob der Endpunkt, der ihre Besucher bedient, noch unter derselben Kontrolle steht, denselben Prozess befolgt oder dieselbe Art von Ausgabe zurückgibt.

HTTPS kollabiert diese Fragen nicht. Es kann einem Browser helfen, zu authentifizieren, dass er den Inhaber einer gültigen Autorität für die angeforderte Domain erreicht hat, und die Antwort während der Übertragung schützen. Es verspricht nicht, dass der Domaininhaber unverändert ist, dass das zurückgegebene Programm wohlwollend ist oder dass der Inhalt über Anfragen hinweg invariant ist. Wenn die Domainkontrolle legitim wechselt, kann HTTPS weiterhin genau wie vorgesehen funktionieren, während es eine neue operative Realität authentifiziert.

Der Browser gibt remote geladenem JavaScript umfangreichen praktischen Einfluss auf die einbettende Seite. Die genaue Reichweite hängt von der Seite und den Browserkontrollen ab, aber die grundlegende Schwäche ist gut dokumentiert: Drittanbieter-Funktionalität wird im Webkontext der ersten Partei ausgeführt. MITREs CWE-830 beschreibt diese Art der Einbindung als Übertragung von Vertrauen auf Code von einer anderen Domain, und OWASP behandelt Drittanbieter-JavaScript als Governance-Problem, da es Daten und Seitenverhalten beeinflussen kann.

GitHub CodeQLs Leitfaden wendet dieselbe Logik auf Funktionalität an, die von einer nicht vertrauenswürdigen Domain geladen wird. [15][16][17]

Deshalb sollte der Vorfall nicht auf „Open Source wurde unsicher" reduziert werden. Der ursprüngliche Open-Source-Code, eine überprüfte selbst gehostete Kopie und ein Live-Domain-gesteuerter Dienst waren unterschiedliche Vertrauensobjekte. Eine Website, die eine feste lokale Kopie verwendete, traf nicht dieselbe Laufzeitdelegation wie eine Website, die eine sich ändernde Antwort voncdn.polyfill.ioanforderte. Ein alternativer Host schuf ebenfalls eine andere Betriebsbeziehung, selbst wenn er Code aus demselben Projekt auslieferte.

Die erste Verantwortlichkeitsfrage ist daher nicht, ob Entwickler jeder externen Bibliothek misstrauen sollten. Es ist, ob die Website wusste, welche Partei zum Zeitpunkt der Nutzung ausführbare Bytes für ihre Besucher auswählen konnte. Ein nützliches Inventar würde mindestens fünf Fragen beantworten: welche Seiten das Skript anforderten, ob die Einbindung direkt oder transitiv war, welche Benutzer und Browserpfade es erreichen konnten, welche Geschäftsfunktion es erforderte und wer aktuell den Endpunkt kontrollierte.

Diese Fragen gehören dem Website-Betreiber, da die Website die Einbindung wirksam machte. Ein Besucher verhandelte nicht mit Polyfill.io oder wählte dessen Betreiber. Der Besucher forderte eine Seite von der Website an und erlebte die zurückgegebenen Skripte vernünftigerweise als Teil dieser Seite. Selbst wenn ein Theme, Plugin, Tag-Manager oder Anbieter die Referenz einfügte, blieb die nachgelagerte Organisation die Partei, die die kombinierte Erfahrung ihren Nutzern präsentierte.

Dies macht den Website-Betreiber nicht zum Autor von bösartigem Code und löscht nicht die Kontrolle des Dienstanbieters aus. Es bedeutet, dass delegierte Macht die Verantwortlichkeit der ersten Partei nicht aufhebt. Der Dienstanbieter konnte die Antwort wählen. Der Website-Betreiber konnte wählen, ob dieser Anbieter weiterhin einen Platz auf der Seite hatte. Das sind unterschiedliche Kontrollen, und der Vorfall testete beide.

Der Februar-Transfer war ein Software-Governance-Ereignis

Die öffentliche Chronologie bietet ein ungewöhnlich wichtiges Warnintervall. Im Februar 2024 wechselte die Kontrolle über die Polyfill.io-Domain und die dazugehörige GitHub-Präsenz zu Funnull, wie in den zeitgenössischen Quellen beschrieben. Die Quellen belegen einen Wechsel der Kontrolle und Vertrauensbasis. Sie begründen allein dadurch nicht das Motiv des neuen Betreibers, einen kriminellen Plan, einen Rechtsverstoß oder die endgültige Identität jeder Person, die später die Auslieferung beeinflusste.

Für eine konventionelle Informationswebsite mag ein Domain-Transfer hauptsächlich die Veröffentlichungsautorität ändern. Für eine Domain, die ausführbares JavaScript an andere Websites zurückgibt, ändert der Transfer, wer die Software beeinflussen kann, die auf diesen nachgelagerten Seiten läuft. Das macht Eigentumsinformationen zu einem Teil des Abhängigkeitszustands. Ein neuer Eigentümer des Endpunkts ist betrieblich vergleichbar mit einem neuen Maintainer, einer neuen Signierungsautorität oder einem neuen Release-Kanal, selbst wenn das Quellrepository vertraut erscheint.

Fastlys Mitteilung vom 28. Februar macht die Governance-Bedeutung sichtbar. Es kündigte Ersatzdomänen an und gab Nutzern Optionen, die Migration, Self-Hosting oder Entfernung des Dienstes umfassten. Diese Optionen waren nicht nur Alternativen zur Marke. Jede änderte, wer die Bytes kontrollieren würde, die an Besucher ausgeliefert wurden. Migration wählte eine andere Dienstbeziehung. Self-Hosting stellte die Auslieferung unter die eigenen Bereitstellungskontrollen der Website. Entfernung beseitigte die Kompatibilitätsabhängigkeit, falls sie nicht mehr benötigt wurde. [3]

Cloudflare folgte am 29. Februar mit einer cdnjs-gehosteten Alternative. Seine Erklärung verband den Anbieterwechsel mit dem Lieferkettenrisiko: Websites hatten sich auf eine andere Partei verlassen, um einen Dienst zu warten und zu sichern, der Code in ihren Seiten ausführen konnte. Cloudflares Alternative machte das Drittanbieter-Hosting nicht risikofrei, aber es zeigte, dass Infrastrukturanbieter den Eigentumswechsel als Grund für eine neue Vertrauensentscheidung verstanden. [2]

Ein am 28. Februar eröffnetes FormatJS-Problem bietet einen nachgelagerten Projektvermerk aus demselben Zeitraum. Es äußerte Bedenken bezüglich des Eigentums und der CNAME-Beziehung und bat das Projekt, die Empfehlung des Endpunkts einzustellen. Dieser Vermerk ist wichtig, weil er zeigt, dass ein Maintainer aufgrund einer Dokumentationsabhängigkeit handelte, bevor eine öffentlich gemeldete bösartige Kampagne bekannt wurde. Das Entfernen einer Empfehlung repariert nicht jede Website, die ihr zuvor gefolgt ist, aber es begrenzt die zukünftige Verbreitung und schafft eine nachvollziehbare Warnung. [4]

Zusammen verhindern diese Aufzeichnungen eine allzu bequeme Erzählung, wonach nachgelagerte Eigentümer bis zum 25. Juni kein Signal hatten. Nicht jeder Website-Betreiber hätte die Fastly-Mitteilung, den Cloudflare-Beitrag oder das FormatJS-Problem gesehen. Die Quellen belegen keine universelle Kenntnisnahme, und es wäre unfair, öffentliche Verfügbarkeit in den Beweis zu verwandeln, dass jede Organisation tatsächlich Bescheid wusste. Sie belegen jedoch, dass der Eigentumswechsel beobachtbar war, dass Alternativen verfügbar waren und dass einige verantwortliche Parteien den Endpunkt Monate vor dem Vorfallsbericht neu bewerteten.

Diese Unterscheidung ist für die Verantwortlichkeit wesentlich. Eine Pflicht zur Überwachung bedeutet nicht Allwissenheit. Es bedeutet, einen Prozess zu entwerfen, der relevante Änderungen für Abhängigkeiten mit hoher Autorität empfangen kann. Eine Site kann Paketwarnungen verfolgen, während sie Domain-Eigentum, DNS- oder Hosting-Änderungen ignoriert. Für ein versioniertes Paket können Release- und Sicherheitslücken-Feeds die wichtigen Signale sein. Für einen Remote-Skript-Endpunkt gehören Registrierung, DNS, Betreiber und Antwortverhalten ebenfalls in das Überwachungsmodell.

Das Februar-Ereignis offenbart auch die Grenzen einer einmaligen Anbieterüberprüfung. Ein Team könnte Polyfill.io Jahre zuvor basierend auf dem Betreiber, der Infrastruktur, dem Projektruf und den damaligen Browseranforderungen genehmigt haben. Wenn der Genehmigungsdatensatz nur die Zeichenfolgecdn.polyfill.ioenthielt, könnte das Team die Abhängigkeit fälschlicherweise als unverändert betrachten, solange die URL unverändert blieb. In Wirklichkeit hatte sich die Partei hinter dem stabilen Namen geändert.

Eine verantwortungsvolle Genehmigung sollte die Vertrauensbasis dokumentieren, nicht nur die Adresse. Diese Basis könnte den Betreiber, den Dienstzweck, die erwarteten Antwortmerkmale, die vertragliche oder gemeinschaftliche Beziehung, verfügbare Prüfnachweise, einen Notfallplan und Überprüfungsauslöser umfassen. Ein Eigentumswechsel würde dann die Genehmigung ungültig machen oder zumindest wieder öffnen. Ohne einen solchen Datensatz kann eine Organisation nicht einfach erklären, warum die fortgesetzte Delegation gerechtfertigt blieb, nachdem die Prämisse geändert wurde.

Die Frage der Notwendigkeit hätte ebenfalls wieder eröffnet werden sollen. Polyfills sind an die Browserfähigkeit gebunden. Browserpopulationen entwickeln sich weiter, Produktunterstützungsrichtlinien ändern sich, und Kompatibilitätscode, der einst wesentlich war, kann zu Residuen werden. Eine Remote-Abhängigkeit mit Seitenebenen-Autorität sollte nicht nur bestehen bleiben, weil niemand ihre Entfernung besitzt. Die Februar-Mitteilungen boten einen Moment, um zu fragen, ob die Unterstützung älterer Browser den Endpunkt noch erforderte und ob ein kleineres lokales Bundle den verbleibenden Bedarf decken konnte.

Nichts davon beweist, dass jede Site, die die Referenz beibehielt, fahrlässig handelte, und es macht den Domain-Transfer selbst nicht zu einem Angriff. Es stellt einen engeren Punkt fest: Der Transfer veränderte eine materielle Softwarekontrolle, noch bevor schädliche Ausgabe beobachtet wurde. Die Verantwortlichkeit der Website beginnt damit, ob diese materielle Änderung erkennbar und überprüfbar war.

Selektive Auslieferung machte beiläufige Inspektion unzuverlässig

Am 25. Juni berichtete Sansec, dasscdn.polyfill.iomodifiziertes JavaScript über Websites auslieferte, die es einbetteten. Das beobachtete Verhalten leitete ausgewählte Besucher über Domains, die Google Analytics ähneln sollten, zu Betrugs- oder Glücksspielzielen um. Sansec beschrieb Bedingungen, die mobiles Targeting, serverseitige und clientseitige Prüfungen, zeitbasiertes Verhalten und die Vermeidung einiger Administrator- oder Analysekontexte umfassten. [1]

Die beobachtete Handlung benötigt ein präzises Nomen. Es war eine Weiterleitungskampagne, die durch modifiziertes JavaScript ausgeliefert wurde. Der Datensatz unterstützt nicht die Hochstufung dieser Beobachtung auf Diebstahl von Anmeldeinformationen, Diebstahl von Seitendaten, Host-Kompromittierung, Codeausführung außerhalb des Browsers oder einen quantifizierten finanziellen Verlust. Ein ferngesteuerter Skript-Endpunkt könnte prinzipiell JavaScript zurückgeben, das eine viel breitere Palette von Browseraktionen ausführen kann.

CNCF TAG Security, CWE-830 und das allgemeine Browser-Ausführungsmodell unterstützen diese Fähigkeitsschlussfolgerung. Fähigkeit ist kein Beweis dafür, dass jede mögliche Aktion aufgetreten ist. [8][16]

Cloudflare sagte, seine Page Shield-Daten würden die Indikatoren bestätigen und Übereinstimmungen bereits ab dem 8. Juni enthalten. Dies ist die früheste Übereinstimmung in Cloudflares Datensatz, die im Quellvermerk beschrieben wird. Es ist kein Beweis dafür, dass alle bösartigen Aktivitäten an diesem Datum begannen, dass derselbe Zweig jede Site kontinuierlich von da an erreichte oder dass keine frühere Auslieferung außerhalb von Cloudflares Sichtbarkeit stattfand. [5]

Akamai beschrieb separat ein zweistufiges Muster, bei dem eine serverseitige Auswahl basierend auf Anfrage-Headern bestimmen konnte, was gesendet wurde, gefolgt von clientseitigen Prüfungen vor der Weiterleitung. Diese Architektur erklärt, warum eine gewöhnliche Inspektion das Problem übersehen konnte. Ein Entwickler, der das Skript von einem Desktop-Browser anforderte, könnte ein erwartetes Polyfill erhalten. Ein mobiler Besucher mit anderen Headern, Standort, Timing oder Seitenstatus könnte einen anderen Zweig erhalten oder aktivieren. [9]

Selektive Auslieferung ändert die Beweislast. Ein einzelner sauberer Download beweist keine historische Sicherheit. Ein Quellcode-Vergleich von einem Browser zu einem Zeitpunkt zeigt möglicherweise nur die für diese Anfrage ausgewählte Antwort. Ein Suchmaschinen-Crawler, Uptime-Monitor oder Sicherheitsscanner kann Merkmale aufweisen, die von der Auslieferungslogik absichtlich ausgeschlossen wurden. Ein Administrator, der während der Anmeldung testet, sieht möglicherweise ein anderes Verhalten als ein Erstbesucher.

Dies bedeutet nicht, dass eine Erkennung unmöglich war. Es bedeutet, dass die Überwachung der Variabilität der Abhängigkeit entsprechen musste. Eine nützliche Beobachtung würde Browser, Geräte, Standorte und Anfragebedingungen abtasten; Antwortkörper und Hashes im Laufe der Zeit aufbewahren; neue Domains und Weiterleitungsketten erkennen; und das von echten Clients beobachtete Verhalten mit dem erklärten Zweck des Dienstes vergleichen. Clientseitige Überwachung spielte eine wichtige Rolle, da das folgenreiche Programm im Browser zusammengestellt und ausgeführt wurde.

Der Vorfall zeigt auch, wie Optimierung zu Tarnung werden kann. Dynamisches Browser-Targeting war Teil des legitimen Dienstmodells von Polyfill.io: Der Dienst wählte Kompatibilitätscode entsprechend den Browserfähigkeiten aus. Ein bösartiger Zweig konnte die Erwartung ausnutzen, dass Antworten natürlich unterschiedlich sind. Variabilität selbst war kein Missbrauchsbeweis. Sie machte ein einfaches Modell „bekannter Hash gleich sicherer Dienst" schwerer anwendbar und gab der selektiven Auslieferung Raum, sich innerhalb eines akzeptierten Betriebsmusters zu verstecken.

Verantwortlichkeit hängt daher davon ab, die erwartete Variabilität zu definieren. Eine Website sollte angeben können, welche Anfrageattribute der Anbieter legitimerweise verwendet, welche Familien von Code zurückgegeben werden dürfen, welche Ziele das Skript kontaktieren darf und welche Seitenaktionen außerhalb des Zwecks liegen. Ohne diese Basislinie kann die Überwachung Veränderungen beobachten, ohne zu wissen, ob die Veränderung autorisiert ist.

Serverseitiges Sampling verkompliziert auch retrospektive Untersuchungen. Das statische Repository einer Site enthält möglicherweise nur die Skript-URL, nicht die bösartigen Bytes, die ein Besucher erhalten hat. Die Bytes kamen zum Zeitpunkt der Anfrage von einem anderen System und sind nach der Eindämmung möglicherweise nicht mehr verfügbar. Browser-Telemetrie, CDN-Protokolle, gespeicherte Antworten, Content-Security-Berichte und Endpunktaufzeichnungen können die einzigen Beweise für die Rekonstruktion der Reichweite sein.

Wenn diese Aufzeichnungen nie gesammelt oder zu kurz aufbewahrt wurden, kann eine Site möglicherweise nicht beantworten, welche Besucher auf den Zweig gestoßen sind.

Diese Unsicherheit sollte nicht mit einer pauschalen Behauptung verdeckt werden, dass alle sicher oder alle kompromittiert waren. Eine verantwortungsvolle Vorfallsmitteilung kann stattdessen definieren, was gefunden wurde: Auf den Endpunkt wurde verwiesen; ein bestimmter bedingter Pfad war erreichbar oder nicht erreichbar; die Telemetrie deckte bestimmte Daten und Populationen ab; beobachtete Weiterleitungen stimmten mit bekannten Indikatoren überein oder nicht; und es bleiben Lücken für Anfragen außerhalb der aufbewahrten Beweise.

Selektive Auslieferung ist daher zentral für den Verantwortlichkeitstest. Sie erklärt, wie schädliche Ausgabe mit harmloser Inspektion koexistieren konnte, warum Endpunktverweise keine Opferzahlen sind und warum eine verifizierte Behebung mehr erfordert, als die Seite einmal zu laden, nachdem die Domain gesperrt wurde.

Skalenschätzungen waren keine Opferzahlen

Sansec beschrieb mehr als 100.000 Sites als Einbettung oder Nutzung des Dienstes. Cloudflare nannte Schätzungen, dass Polyfill.io auf fast vier Prozent der Websites erschien. Diese Zahlen vermitteln die potenzielle Breite eines weit verbreiteten Dienstes. Sie haben nicht denselben Nenner, und keine stellt eine vollständige Menge bestätigter Kompromittierungen dar. [1][5]

Mehrere Populationen müssen getrennt bleiben. Eine ist die Menge der Websites, deren aktueller oder historischer Code auf einen Polyfill.io-Endpunkt verwies. Eine andere ist die Menge, für die der relevante Einbindungspfad in der Produktion erreichbar war. Eine dritte ist die Menge, die während der Kampagne eine bösartige Antwort angefordert hat. Eine vierte ist die Menge, deren Besucher die serverseitigen und clientseitigen Bedingungen erfüllten. Eine fünfte sind die Besucher, die tatsächlich umgeleitet wurden. Eine sechste ist jede Population, die später einen messbaren Verlust erlitt.

Der verfügbare öffentliche Datensatz liefert keine verifizierte Anzahl für die meisten dieser Gruppen. Es wäre daher ungenau, jede Referenz als Opfer, jede einbettende Site als kompromittiert oder jeden Besucher als exponiert zu bezeichnen. Es wäre ebenso ungenau, Referenzen als harmlos abzutun, nur weil selektive Auslieferung eine universelle Beobachtung verhinderte. Eine Referenz stellt einen Vertrauenspfad dar. Zusätzliche Beweise sind erforderlich, um Erreichbarkeit, Auslieferung und Auswirkung festzustellen.

Diese Terminologie ist wichtig für nachgelagerte Mitteilungen. „Unser Code enthielt eine Referenz" ist anders als „unsere Telemetrie zeigt, dass das Skript angefordert wurde". Beides unterscheidet sich von „wir haben den bösartigen Zweig beobachtet" und von „ein Besucher meldete eine Weiterleitung". Ihre Kombination kann unnötigen Alarm oder falsche Beruhigung erzeugen. Die Trennung ermöglicht es den Nutzern zu verstehen, was die Organisation weiß.

Wordfences Behandlung betroffener WordPress-Plugin-Muster verstärkt diese Grenze. Sein Katalog identifizierte Verwendungen von Polyfill.io, warnte aber davor, anzunehmen, dass jede Plugin-Instanz bösartige Inhalte ausgeliefert habe. Plugins konnten den Endpunkt in viele Sites einführen, was die Inventarisierung dringend machte, während das Vorhandensein des Codes dennoch hinter dem Nachweis einer bösartigen Ausführung in jeder Installation zurückblieb. [14]

Regierungsberichte wiederholten die ernsthafte Skalenbesorgnis, während sie die Betreiber auf Entfernung und Untersuchung konzentrierten. CERT-AGID beschrieb die Übernahme und die header-abhängige Auslieferung und bezog sich auf die Zahl von mehr als 100.000. Diese unabhängige Warnung unterstützt breite defensive Aufmerksamkeit, ändert aber nicht den Nenner zu bestätigten betroffenen Besuchern. [21]

Die stärkste Skalenaussage ist daher auch die begrenzteste: Der Endpunkt hatte einen großen nachgelagerten Fußabdruck, und die beobachtete selektive Kampagne schuf Risiko über diesen Fußabdruck hinweg. Die genaue Auswirkung musste Site für Site und Besucherpopulation für Besucherpopulation festgestellt werden.

Eindämmung änderte den Pfad; sie schloss die Behebung nicht ab

Die Reaktion umfasste Parteien mit unterschiedlichen Arten von Kontrolle. Cloudflare schrieb automatisch Polyfill.io-Referenzen auf proxysierten Kundenseiten auf einen Cloudflare-gehosteten Mirror um. Das Unternehmen erklärte, dass das einfache Blockieren der ursprünglichen Domain Sites brechen könnte, die noch auf den Dienst angewiesen waren. Die Umschreibung versuchte, die erwartete Kompatibilität zu bewahren, während die sofortige Abhängigkeit vom geänderten Endpunkt entfernt wurde. [5]

Dieser Eingriff veranschaulicht einen echten betrieblichen Zielkonflikt. Sicherheitsteams bevorzugen oft die sofortige Entfernung einer verdächtigen Ressource. Produktteams wissen, dass das abrupte Entfernen einer Kompatibilitätsschicht eine Site für einige Besucher unbrauchbar machen kann. Cloudflares Position in der Auslieferungskette ermöglichte es, eine andere Quelle zu ersetzen, ohne darauf zu warten, dass jeder Website-Betreiber eine Änderung bereitstellt.

Substitution war Eindämmung, kein Nachweis vollständiger Reparatur. Sie änderte den vertrauenswürdigen Betreiber und Antwortpfad für den durch den Mechanismus abgedeckten Datenverkehr. Sie stellte nicht fest, dass der Ersatz für jeden Browser identisches Verhalten aufwies, dass alle Seiten und Auslieferungspfade abgedeckt waren oder dass nachgelagerte Repositorien nicht mehr die alte Referenz enthielten. Sie beantwortete auch nicht, was Besucher vor der Umschreibung erhalten hatten.

Namecheap setzte dann die Polyfill.io-Domain auf Hold, und Regierungsadvisorys beschrieben den Endpunkt ab dem 27. Juni als gesperrt. Die Domain-Maßnahme entfernte den sofortigen Dienstpfad, konnte aber auch Sites brechen, die noch eine Antwort erwarteten. Der Hold war ein wichtiger Eindämmungshebel, der vom Registrar gehalten wurde. Er bereinigte keine nachgelagerten Vorlagen, Plugin-Einstellungen, zwischengespeicherten Seiten, Tag-Manager-Konfigurationen oder Anbieterprodukte. [6][10]

Der Unterschied wird deutlicher, wenn die Domain nicht verfügbar ist. Eine Site mag geschützt erscheinen, weil der Browser das verdächtige Skript nicht mehr abrufen kann. Doch die veraltete Referenz bleibt eine ungelöste Abhängigkeit. Wenn sich der Kontrollstatus wieder ändert, ein alternativer Hostname bestehen bleibt oder eine interne Kopie nicht untersucht wurde, bleibt das zugrunde liegende Governance-Problem bestehen. Selbst ein dauerhaft toter Endpunkt kann Leistungs-, Fehlerbehandlungs- und Kompatibilitätskosten verursachen.

CERT-FR und die Western Australia Cyber Security Unit rieten den Betreibern, Referenzen zu identifizieren und zu entfernen, bei Bedarf auf eine kontrollierte Alternative umzusteigen und Browserkontrollen wie Subresource Integrity und Content Security Policy zu erwägen. Semgrep konzentrierte sich ebenfalls auf die repositorienweite Erkennung, anstatt die Domain-Sperrung als ausreichend zu betrachten. [6][7][20]

Diese Abfolge legt vier unterschiedliche Abschlussbehauptungen nahe. „Eingedämmt" bedeutet, dass der bekannte schädliche Auslieferungspfad unterbrochen wurde. „Entfernt" bedeutet, dass die nachgelagerte Referenz und die transitiven Einfügepfade beseitigt sind. „Untersucht" bedeutet, dass verfügbare Beweise verwendet wurden, um die historische Reichweite und Auswirkung zu bewerten. „Verifiziert" bedeutet, dass Tests und Überwachung zeigen, dass die aktuelle Site nicht mehr vom alten Pfad abhängt und dass der Ersatz sich innerhalb seines beabsichtigten Rahmens verhält.

Ein Website-Betreiber konnte sich für die erste Behauptung auf einen Infrastrukturanbieter verlassen, während er die anderen drei selbst besaß. Cloudflare konnte den von ihm gesehenen Datenverkehr umschreiben. Namecheap konnte eine von ihm registrierte Domain sperren. Keiner konnte jeden Ort kennen, an dem ein Kunde die URL eingebettet hatte, jeden bedingten Browserpfad innerhalb eines Plugins oder jede Besucherpopulation, die die Website untersuchen musste.

Diese Trennung schützt auch vor einer Überbetonung des Eingreifens Dritter. Eine Registrar-Sperrung ist kein Zuordnungsergebnis. Automatische Umschreibung beweist nicht, dass jeder geschützte Kunde den bösartigen Zweig ausgeliefert hatte. Ein Indikator-Treffer eines Erkennungsanbieters ist kein vollständiger forensischer Bericht für jede Site. Jede Aktion sollte gemäß der Kontrolle, die sie ausübte, und den Beweisen, die sie produzierte, beschrieben werden.

Operativ sollte die nachgelagerte Behebung mit einer vollständigen Suche beginnen. Der wörtliche Hostname kann in Quelldateien, generierten Bundles, Content-Management-Feldern, Plugin-Code, Tag-Managern, Vorlagen, archivierten Konfigurationen oder Anbieterantworten erscheinen. Suchwerkzeuge können bekannte Zeichenfolgen finden, aber ein Abhängigkeitsinventar muss auch erklären, wer die Referenz eingeführt hat und welcher Build- oder Laufzeitpfad sie aktiv machte.

Die Entfernung benötigt dann eine funktionale Entscheidung. Wenn das Polyfill nicht mehr notwendig ist, ist die Beseitigung die sauberste Reduzierung der Autorität. Wenn Legacy-Browser-Unterstützung weiterhin erforderlich ist, kann ein überprüftes lokales Bundle oder ein explizit genehmigter Anbieter angemessen sein. Der Ersatz sollte nicht nur wegen seiner bequemen URL gewählt werden. Sein Betreiber, Aktualisierungsprozess, Antwortvariabilität und Überwachungsmodell werden Teil der neuen Vertrauensbasis.

Schließlich erfordert die historische Bewertung Beweise, die proportional zum Risiko der Site sind. Browserseitige Beobachtungen, Netzwerkprotokolle, Sicherheitsberichte, Kundenbeschwerden und gespeicherte Skriptantworten können helfen festzustellen, ob bekannte Weiterleitungsindikatoren aufgetreten sind. Fehlende Beweise sollten mit der Abdeckung verknüpft werden. Eine Site ohne gespeicherte Client-Telemetrie kann sagen, dass sie in den verfügbaren Aufzeichnungen keine Berichte oder Indikatoren gefunden hat; sie kann fehlende Aufzeichnungen nicht in den Beweis verwandeln, dass kein Besucher den Zweig erhalten hat.

Fides zeigte, warum ein bedingter Zweig dennoch wichtig ist

CVE-2024-38537 dokumentiert ein nachgelagertes Problem in Fides. Der relevantefides.js-Pfad konnte Polyfill.io für Legacy-Browser laden. Der Datensatz identifiziert betroffene Versionen und sagt, dass Version 2.39.1 die Gefährdung beseitigt hat. Er bewahrt auch eine wichtige Grenze: Es wurde keine Ausnutzung über Fides identifiziert. [11][12]

Dieser Fall ist nützlich, weil er zwei entgegengesetzten Fehlern widersteht. Der erste würde das Problem abtun, weil nur ein Pfad für ältere Browser den Endpunkt lud. Bedingte Erreichbarkeit ist immer noch Erreichbarkeit. Wenn eine Produktionsseite für eine unterstützte Besucherpopulation Remote-JavaScript anfordern konnte, gehörte die Abhängigkeit in das Sicherheitsinventar des Produkts, selbst wenn die meisten Entwickler sie nie auslösten.

Der zweite Fehler würde die CVE als Beweis dafür behandeln, dass Fides-Benutzer ausgenutzt wurden. Ein Schwachstellendatensatz kann einen unsicheren Einbindungspfad und betroffene Versionen feststellen, ohne zu belegen, dass der bösartige Zweig eine bestimmte Bereitstellung erreicht hat. „Konnte laden" und „wurde beim Ausnutzen beobachtet" beantworten unterschiedliche Fragen. Der Fides-Datensatz hielt diese Unterscheidung explizit aufrecht.

Die Behebung zeigt auch, warum versionierte Reparatur wichtig ist. Das Entfernen der Remote-Abhängigkeit in einer benannten Version gibt nachgelagerten Betreibern eine konkrete Aktion und eine nachvollziehbare Grenze. Sie können bereitgestellte Versionen identifizieren, aktualisieren, nach verbleibenden Referenzen suchen und den Legacy-Pfad testen. Eine allgemeine Warnung, „vorsichtig mit Polyfill.io zu sein", würde nicht denselben Abschlussbeweis liefern.

Die Legacy-Bedingung sollte die Überprüfung bestimmen. Das Testen nur eines modernen Desktop-Browsers könnte den betroffenen Zweig niemals ausführen. Die Überprüfung sollte die Bedingung, die ihn ursprünglich ausgewählt hat, reproduzieren oder inspizieren. Dies kann die Überprüfung von gebündeltem Code, die Simulation eines älteren User-Agents, die Überprüfung von Netzwerkanfragen und die Bestätigung umfassen, dass die reparierte Version den Endpunkt nicht mehr konstruiert oder anfordert.

SingCERTs Bulletin diskutierte ebenfalls den nachgelagerten Fides-Fall und behielt die Grenze „keine Ausnutzung beobachtet" bei. Die Wiederholung durch ein nationales CERT erhöht die Sichtbarkeit des Problems; sie verwandelt die Möglichkeit nicht in beobachtete Ausnutzung. [22]

Die Lektion von Fides ist daher nicht, dass jede bedingte Drittanbieteranfrage dieselbe Schwere verdient. Es ist, dass ein Maintainer die Bedingung, die betroffenen Versionen, die erreichbare Population, die Reparaturversion und die Evidenzgrenze kennen sollte. Verantwortlichkeit ist am stärksten, wenn ein formaler Schwachstellendatensatz sowohl sagt, was passieren könnte, als auch, was nicht beobachtet wurde.

Jellyfish zeigte, wie man eine transitive Abhängigkeit zurückverfolgt

Jellyfishs Advisory dokumentierte einen anderen Pfad. Sein Dienst hing von einem Anbieter ab, der Polyfill.io unter besonderen Bedingungen laden konnte. Jellyfish identifizierte die transitive Beziehung, kontaktierte den Anbieter, verifizierte die Entfernung und grenzte die Browserpopulation ein, die den Pfad erreicht haben könnte. [13]

Diese Sequenz ist ein praktisches Modell, weil sie mit der Architektur beginnt, nicht mit einer Beschuldigung. Eine kundenorientierte Organisation hat das Skript-Tag möglicherweise nicht direkt im eigenen Repository platziert. Die Referenz könnte von einer Analysekomponente, einem Consent-Tool, einem Plugin, einem Support-Widget oder einem anderen Anbietercode stammen. Der direkte Besitz der Zeile ist nicht dasselbe wie die Kontrolle über das Benutzererlebnis.

Transitive Abhängigkeiten schaffen ein Beweisproblem. Eine Software-Stückliste, die auf zur Build-Zeit installierte Pakete ausgerichtet ist, enthält möglicherweise keine Domain, die ein Anbieter dynamisch im Browser anfordert. Vertragsinventare mögen den Anbieter nennen, nicht aber die eigenen Skriptlieferanten des Anbieters. Netzwerküberwachung kann den Hostnamen sehen, ohne den Geschäftsinhaber zu identifizieren, der ihn eingeführt hat. Alle drei Ansichten sind erforderlich, um eine Anfrage mit einer rechenschaftspflichtigen Beziehung zu verbinden.

Jellyfishs Reaktionssequenz adressiert diese Lücken. Erstens identifizieren, dass die Abhängigkeit existiert und unter welchen Bedingungen sie aufgerufen werden kann. Zweitens, sie der Anbieterbeziehung zuordnen. Drittens, die Partei mit Codekontrolle bitten, sie zu entfernen. Viertens, die Änderung verifizieren, anstatt die Zusicherung des Anbieters als Ende der Angelegenheit zu betrachten. Fünftens, die Population mit den besten verfügbaren Browser- und Produktbeweisen eingrenzen.

Die Verifizierung ist besonders wichtig, wenn die Bedingung ungewöhnlich ist. Ein Anbieter könnte eine sichtbare Referenz entfernen, während ein Fallback, ein älteres Bundle oder ein zwischengespeichertes Asset sie noch enthält. Der Kunde sollte sowohl von außen testen als auch die interne Bestätigung akzeptieren. Netzwerkerfassung über relevante Browser, Repository- oder Bundle-Scans und clientseitige Überwachung können zeigen, ob die Anfrage tatsächlich verschwunden ist.

Die eingegrenzte Population sollte ihren Nenner behalten. Wenn nur bestimmte Browserversionen oder Seitenflüsse den Anbieterpfad auslösen konnten, kann die Untersuchung die potenzielle Reichweite eingrenzen. Es sollte nicht implizieren, dass jedes Mitglied dieser Browser-Gruppe bösartige Inhalte erhalten hat. Umgekehrt entschuldigt die Tatsache, dass ein Pfad selten war, nicht das Versäumnis, ihn zu entfernen. Seltene Pfade erhalten oft weniger routinemäßige Tests, was sie zu attraktiven Orten machen kann, an denen Abhängigkeiten unbemerkt bestehen bleiben.

Jellyfish demonstriert auch geteilte, aber nicht austauschbare Verantwortung. Der Anbieter kontrollierte seinen Code und konnte die Einbindung entfernen. Jellyfish kontrollierte die Eskalation zum Anbieter, die kundenorientierte Untersuchung und die Annahme der Reparatur. Infrastruktur- und Sicherheitsanbieter konnten Telemetrie beisteuern. Keine dieser Parteien konnte eine andere vollständig ersetzen.

Dieses Modell skaliert über diesen Vorfall hinaus. Eine nachgelagerte Organisation benötigt eine Eskalationsroute für jeden Anbieter, der ausführbaren Code einführen kann. Der Vertrag oder der technische Onboarding-Prozess sollte identifizieren, wer dringende Abhängigkeitsfragen beantworten kann, wie schnell ein Drittanbieter-Skript deaktiviert werden kann, welche Protokolle verfügbar sind und wie der Kunde eine Änderung verifizieren kann.

WordPress-Plugins zeigten, warum Referenzen und Ausnutzung getrennt bleiben müssen

Wordfence katalogisierte die Nutzung von Polyfill.io in verschiedenen WordPress-Plugin-Mustern. Diese Art von Inventar ist wertvoll, weil Plugins eine externe Abhängigkeit über viele unabhängig betriebene Websites verteilen können. Eine kleine Maintainer-Entscheidung kann eine breite nachgelagerte Vertrauensbeziehung werden, ohne dass jeder Site-Betreiber den Endpunkt bewusst hinzufügt. [14]

Der Katalog trug auch eine entscheidende Warnung: Die Nutzung des Endpunkts bewies nicht, dass jedes Plugin oder jede Site bösartige Inhalte ausgeliefert hatte. Die Referenz identifizierte einen potenziellen Ausführungspfad. Ob dieser Pfad aktiv war, hing von der Plugin-Version, Konfiguration, Seitenrendering, Caching, Browserbedingungen und der Remote-Antwort zum Zeitpunkt ab.

Für einen WordPress-Site-Betreiber besteht die richtige Reaktion nicht in einer Debatte darüber, ob der Plugin-Autor oder Dienstanbieter „der wirklich" Verantwortliche ist. Die unmittelbaren Aufgaben sind lokal: installierte und aktive Versionen identifizieren, bestimmen, welche Seiten die Referenz rendern, betroffene Komponenten aktualisieren oder entfernen, generierte Assets bei Bedarf löschen und das Netzwerkverhalten der öffentlichen Site überprüfen.

Der Plugin-Maintainer hat eine andere Reihe von Aufgaben. Er kann die Abhängigkeit entfernen, eine behobene Version veröffentlichen, betroffene Bedingungen erklären, die Dokumentation aktualisieren und Benutzer benachrichtigen. Ein Plugin-Repository oder Sicherheitsdienst kann Warnungen verteilen. Der Website-Betreiber muss die Änderung dennoch bereitstellen. Eine behobene Version, die nicht installiert ist, ändert nichts am Browserpfad.

Dies ist ein weiterer Grund, warum Skalenzahlen nicht als Anzahl geschädigter Organisationen gelesen werden sollten. Ein Plugin kann Tausende von Referenzen erzeugen; eine Site kann mehrere Plugins mit demselben Hostnamen enthalten; ein ruhendes oder deaktiviertes Plugin kann ohne Rendern des Skripts auf der Festplatte verbleiben; und eine zwischengespeicherte öffentliche Seite kann nach Quellcodeänderungen weiterhin eine alte Referenz ausliefern. Das Zählen von Zeichenfolgen, Installationen, aktiven Anfragen und bösartigen Auslieferungen ergibt unterschiedliche Zahlen.

Ein rechenschaftspflichtiges Ökosystem hält diese Maße gekennzeichnet. Sicherheitsintelligenz kann eine breite Expositionsliste veröffentlichen, um Maßnahmen zu beschleunigen. Maintainer können betroffene Versionen angeben. Site-Betreiber können die bereitgestellte Erreichbarkeit melden. Vorfallsermittler können beobachtete Indikatoren melden. Keiner sollte sich der Gewissheit der anderen bedienen.

SRI und CSP waren Kontrollen, keine Zauberantworten

Subresource Integrity (SRI) ermöglicht es einem Seitenautor, einen kryptografischen Digest für eine externe Ressource bereitzustellen. Ein unterstützender Browser kann die Ressource abrufen und sich weigern, sie auszuführen, wenn die zurückgegebenen Bytes nicht dem erwarteten Digest entsprechen. Die W3C-Spezifikation und MDNs Implementierungsleitfaden präsentieren SRI als eine Möglichkeit, zu verhindern, dass ein kompromittierter Drittanbieter-Host eine Ressource stillschweigend ändert, von der die einbettende Site erwartet, dass sie fest bleibt. [18][19]

Das ist eine starke Kontrolle für ein stabiles Skript. Es verwandelt eine offene Delegation in die Genehmigung spezifischer Bytes. Wenn der Host etwas anderes zurückgibt, blockiert der Browser die Ausführung. Die Website kann dann den Digest durch ihren eigenen Bereitstellungsprozess aktualisieren, nachdem sie eine neue Version überprüft hat.

Polyfill.ios legitimes Design verkompliziert dieses Modell, da der Dienst absichtlich verschiedene Bundles entsprechend den Browserfähigkeiten und Anforderungsparametern generierte. Ein stabiler Digest kann viele gültige Bytesequenzen nicht genehmigen, es sei denn, die Site ändert, wie sie den Dienst konsumiert. Ein Team könnte in manchen Architekturen eine begrenzte Menge fester Ressourcen vorberechnen und genehmigen, aber das Anhängen eines Hashs an einen Endpunkt, dessen Zweck die dynamische Antwortauswahl ist, würde wahrscheinlich das erwartete Verhalten brechen oder wichtige Variationen ungebunden lassen.

Die richtige Schlussfolgerung ist nicht, dass SRI nutzlos ist. Es ist, dass die Kontrollwahl dem Ressourcenmodell entsprechen muss. Wenn eine Site Integrity-Pinning wünscht, muss sie möglicherweise aufhören, einen Remote-Dienst zu bitten, beliebige anforderungsspezifische Bytes zu generieren. Self-Hosting eines überprüften Bundles, das Ausliefern fester versionierter Varianten oder das Einschränken unterstützter Browser kann die Byte-Ebene-Genehmigung praktikabel machen.

Content Security Policy (CSP) adressiert eine andere Ebene. Eine Richtlinie kann einschränken, welche Ursprünge Skripte bereitstellen dürfen, und kann Nonces, Hashes oder verwandte Direktiven verwenden, um die Ausführung einzuschränken. Sie kann unerwartete Domains blockieren und die Freiheit von injiziertem Markup reduzieren, neue Ressourcen zu laden. Aber wenncdn.polyfill.ioexplizit als vertrauenswürdiger Skript-Ursprung erlaubt ist, wird eine vom Ursprung genehmigte bösartige Antwort nicht vertrauenswürdig, indem sie auf der Whitelist erscheint.

CSP kann dennoch helfen, sekundäres Verhalten einzudämmen. Eine sorgfältig entworfene Richtlinie kann Verbindungen, Frames oder Navigationen einschränken, die an einer Angriffskette beteiligt sind, und Verstoßmeldungen können Erkennungsbeweise hinzufügen. Der genaue Effekt hängt von der Richtlinie und dem Browserverhalten ab. Die Kernbeschränkung bleibt: Die Ursprungsgenehmigung beantwortet, woher Code kommen darf, nicht, ob der genehmigte Betreiber immer akzeptablen Code zurückgibt.

Mirroring verschiebt die Vertrauensgrenze erneut. Eine Website oder ein Infrastrukturanbieter ruft eine Kopie ab oder pflegt sie und stellt sie von einem kontrollierten Ort aus bereit. Dies kann verhindern, dass die ursprüngliche Domain Bytes zum Zeitpunkt der Anfrage ändert. Es schafft auch Verpflichtungen dafür, wie der Mirror bezogen, überprüft, aktualisiert und gesichert wird. Automatische Umschreibung auf Cloudflares Mirror war eine nützliche Eindämmung, aber sie wählte Cloudflare als neue Betriebsautorität; sie beseitigte nicht das Konzept des Vertrauens.

Self-Hosting gibt dem Website-Betreiber eine direktere Kontrolle über die Auslieferung. Er kann eine Version überprüfen, sie mit der Anwendung bereitstellen und Änderungen durch seinen normalen Release-Prozess überwachen. Self-Hosting garantiert keinen sicheren Code. Es schränkt ein, wer die Produktionsantwort ändern kann, und macht es einfacher, die bereitgestellten Bytes an einen Release zu binden.

Entfernung ist stärker, wenn die Funktion unnötig ist. Wenn der aktuelle Browser-Support keinen Polyfill-Dienst mehr erfordert, ist das risikoärmste Remote-Skript das, das die Seite nicht anfordert. Deshalb gehört die Lebenszyklusüberprüfung neben die Sicherheitskontrollen. Kompatibilitätsentscheidungen, die Jahre zuvor getroffen wurden, sollten nicht zu dauerhaften Autoritätsgewährungen werden.

Sandboxing kann den Einfluss Dritter verringern, wenn die Funktionalität in einem eingeschränkten Frame oder isolierten Kontext ausgeführt werden kann. Nicht jedes Skript kann dorthin verschoben werden, ohne das Produkt zu ändern. Ein Polyfill, das die JavaScript-Umgebung der Seite modifizieren soll, ist besonders an den Hauptausführungskontext gebunden, was die Nützlichkeit der Isolation einschränkt. Diese Einschränkung sollte beeinflussen, ob die Bequemlichkeit die Autorität wert ist.

Code-Scanning-Tools helfen, bekannte Referenzen zu finden. CodeQLs Polyfill-spezifische Anleitung betont Sorgfalt bei der Inhaberschaft, Protokollprüfung, Self-Hosting und die Grenzen von Integritätskontrollen für dynamische Inhalte. Semgrep schlug Repository-Suchen und Regeln vor, um die Nutzung von Polyfill.io nach dem Vorfall zu identifizieren. [15][20]

Statisches Scannen allein ist unvollständig, da Runtime-Injection von Content-Systemen, Tag-Managern oder Anbietern kommen kann. Laufzeitbeobachtung allein ist unvollständig, da seltene Bedingungen während der Stichprobe möglicherweise nicht auftreten. Ein ausgereifter Kontrollstapel kombiniert Quell- und Bundle-Scanning, ein Drittanbieter-Skript-Inventar, DNS- und Eigentumsüberwachung, browserseitige Telemetrie, Änderungsüberprüfung und einen Notfall-Deaktivierungsmechanismus.

Der Stapel sollte auch das Fehlerverhalten spezifizieren. Wenn ein Polyfill nicht geladen wird, verliert die Seite eine geringfügige Verbesserung, wird sie unbrauchbar oder verhindert eine kritische Transaktion? Teams, die die Auswirkungen von Fehlern verstehen, können eine verdächtige Ressource schnell entfernen oder blockieren, ohne während eines Vorfalls improvisieren zu müssen. Wenn die Kontinuität von der Ressource abhängt, ist ein getesteter lokaler Fallback sicherer, als die Abhängigkeit zu entdecken, wenn ein Registrar die Domain sperrt.

Kontrollen sind daher kein Menü, aus dem ein modisches Akronym ausgewählt werden kann. Sie sind eine Folge von Entscheidungen: unnötige Autorität entfernen, notwendigen Code wo möglich fixieren, einschränken, woher er kommen kann, beobachten, was er tut, Beweise aufbewahren und einen getesteten Pfad zur Deaktivierung oder zum Ersatz unterhalten.

Verantwortlichkeit sollte den Kontrollen folgen, die jede Partei innehatte

Der Vorfall umfasste einen Dienstanbieter, Website-Betreiber, Infrastrukturanbieter, einen Registrar, Sicherheitsforscher, Plugin- und Produkt-Maintainer sowie Anbieter, deren Code den Endpunkt einführte. Ihre Verantwortlichkeiten überlappten sich, waren aber nicht austauschbar.

Der Betreiber, der den gehosteten Polyfill.io-Dienst kontrollierte, hatte die direkteste Autorität über die von diesem Dienst zurückgegebene Antwort. Das unterscheidet sich von der Wartung des ursprünglichen Open-Source-Codes. Verantwortlichkeit auf dieser Ebene betrifft die Verwahrung der Domain und des Bereitstellungspfads, die Änderungskontrolle, die Antwortintegrität, die Transparenz der Auslieferung und die genaue Kommunikation über den Betrieb. Der verfügbare Datensatz sollte nicht zu einem Ergebnis über jeden einzelnen Akteur, jede Unternehmensbeziehung oder rechtliche Pflicht gedehnt werden.

Fastly und Cloudflare verfügten über Infrastruktur- und Substitutionsfähigkeiten. Ihre Februar-Mitteilungen konnten warnen und Alternativen anbieten. Cloudflares spätere Position ermöglichte automatische Umschreibung und clientseitige Telemetrie für abgedeckten Datenverkehr. Diese Kontrollen waren bedeutend, gaben aber keinem der Anbieter vollständige Kenntnis über jede nachgelagerte Site-Quelle, Konfiguration oder Besucherauswirkung. [2][3][5]

Namecheap hielt einen Eindämmungshebel auf Registrar-Ebene. Das Sperren der Domain unterbrach die Auflösung oder Nutzung des Endpunkts. Diese Aktion verringerte die unmittelbare Exposition, während sie möglicherweise abhängige Sites beeinträchtigte. Die Registrar-Kontrolle konnte einen Pfad stoppen; sie konnte keine Anwendungen patchen oder die historische Auslieferung für jede Website feststellen. [10]

Sicherheitsforscher und staatliche Responder verfügten über Erkennungs-, Analyse- und Warnfähigkeiten. Sansec veröffentlichte Indikatoren und beobachtetes Verhalten. Akamai und Cloudflare fügten Telemetrieperspektiven hinzu. CERT-FR, Western Australia, CERT-AGID und SingCERT übersetzten den Vorfall in operative Anleitungen für ihr Publikum. Diese Parteien konnten die Sichtbarkeit erhöhen und Kontrollen empfehlen; sie konnten keine Fixes auf jeder Site bereitstellen. [1][5][6][7][9][21][22]

Plugin-, Bibliotheks- und Anbieter-Maintainer kontrollierten Code, der die Abhängigkeit transitiv einführen konnte. Zu ihren rechenschaftspflichtigen Handlungen gehörten die Identifizierung betroffener Versionen und Bedingungen, das Entfernen des Endpunkts, die Veröffentlichung eines Fixes, die Kommunikation des Umfangs und die Wahrung der Unterscheidung zwischen potenzieller Exposition und beobachteter Ausnutzung. Die Datensätze von Fides und der WordPress-Plugins zeigen, warum Versionen und Erreichbarkeitsnachweise wichtig sind. [11][12][14]

Website-Betreiber kontrollierten die endgültige Einbindungsentscheidung, selbst wenn deren Ausführung erforderte, dass ein Anbieter oder Maintainer Code änderte. Sie konnten unterstützte Browser definieren, Drittanbieter-Skript-Anbieter genehmigen, Inventare führen, Eigentum überwachen, Ressourcen blockieren oder umschreiben, überprüften Code selbst hosten, Browser-Beweise aufbewahren, Beschwerden untersuchen und mit Besuchern kommunizieren.

Dies impliziert keine gleiche Schuld. Ein kleiner Site-Betreiber kann weitaus weniger Sichtbarkeit und Fachwissen haben als ein globales Infrastrukturunternehmen. Ein Anbieter kann die einzige Partei sein, die einen gebündelten Fallback ändern kann. Ein Registrar kann die einzige Partei sein, die eine Domain schnell sperren kann. Verantwortlichkeit folgt der praktischen Kontrolle und den Beweisen, die zu ihrer Ausübung verfügbar sind, nicht einer Annahme, dass jeder Teilnehmer dieselbe Fähigkeit hatte.

Eine nützliche Pflichtenkarte kann um sechs Fragen organisiert werden.

Erstens, wer konnte unnötige Exposition verhindern? Website- und Produktbesitzer konnten den Browser-Support überprüfen und die Abhängigkeit entfernen. Maintainer konnten die Empfehlung oder Bündelung einstellen. Anbieter konnten sicherere Migrationspfade anbieten.

Zweitens, wer konnte geändertes Vertrauen erkennen? Domain- und Infrastrukturmonitore konnten Eigentums-, DNS- und Routing-Änderungen beobachten. Projekt-Maintainer konnten die Kontrolle über Konten und Dokumentation verfolgen. Website-Betreiber konnten relevante Mitteilungen abonnieren und Abhängigkeiten mit hoher Autorität überprüfen, wenn sich ihr Betreiber änderte.

Drittens, wer konnte schädliche Auslieferung beobachten? Der Dienstanbieter und Infrastrukturanbieter konnten serverseitige Antworten sehen. Website-Betreiber und clientseitige Sicherheitsdienste konnten das Browserverhalten sehen. Forscher konnten Stichproben über Bedingungen hinweg vergleichen. Keine einzelne Sicht erfasste notwendigerweise die gesamte Kampagne.

Viertens, wer konnte den Pfad eindämmen? Der Betreiber konnte die Auslieferung stoppen, der Registrar konnte die Domain sperren, Infrastrukturanbieter konnten Datenverkehr umschreiben oder blockieren, Maintainer konnten Fixes veröffentlichen, und Website-Betreiber konnten Referenzen deaktivieren oder entfernen.

Fünftens, wer konnte die Auswirkung untersuchen? Jeder Website-Betreiber besaß seine eigene Seitenarchitektur, Besucheraufzeichnungen, Beschwerden und Bereitstellungshistorie. Anbieter besaßen Informationen über transitive Bedingungen. Infrastrukturanbieter besaßen ausgewählte Datenverkehrs- und Antworttelemetrie. Die Untersuchung erforderte Zusammenarbeit, ohne vorzutäuschen, dass der Datensatz einer Partei alle Besucher repräsentierte.

Sechstens, wer konnte die Reparatur verifizieren und kommunizieren? Maintainer konnten Fixes an Versionen binden. Anbieter konnten die Entfernung zeigen. Website-Betreiber konnten den öffentlichen Pfad testen und angeben, was ihre Beweise abdeckten. Regierungs- und Sicherheitsstellen konnten Anleitungen aktualisieren. Die Verifizierung musste auf die Sichtbarkeit der Partei beschränkt bleiben.

Diese Karte macht Verantwortlichkeit testbar. Anstatt nur zu fragen, wer den Vorfall verursacht hat, fragt sie, welche Partei jede Präventions-, Erkennungs-, Eindämmungs-, Untersuchungs- und Reparaturfrage beantworten konnte. Sie deckt auch Kontrolllücken auf. Wenn niemand das Domain-Eigentum für ein Skript mit Seitenebenen-Autorität überwachte, bestand die Lücke, bevor der bösartige Zweig auftauchte.

Was eine nachgelagerte Website beweisen können sollte

Eine glaubwürdige nachgelagerte Antwort kann als Beweiskette ausgedrückt werden, nicht als allgemeine Zusicherung.

Die Kette beginnt mit dem Inventar. Die Organisation sollte jede direkte und transitive Polyfill.io-Referenz identifizieren, die Komponente oder den Anbieter, der sie eingeführt hat, die Seiten, die sie renderten, und die Browserbedingungen, die sie erreichbar machten. Suchergebnisse sollten mit dem bereitgestellten Verhalten verbunden sein, nicht als Liste übereinstimmender Dateien belassen werden.

Als nächstes kommt die Notwendigkeit. Der Eigentümer sollte dokumentieren, ob die Kompatibilitätsfunktion für die Browser, die er absichtlich unterstützt, weiterhin erforderlich ist. Wenn nicht, sollte die Entfernung bevorzugt werden. Wenn sie erforderlich ist, sollte die Organisation erklären, warum der gewählte Ersatz oder die selbst gehostete Version dem Bedarf angemessen ist.

Der dritte Schritt ist die Neubewertung des Vertrauens. Der Datensatz sollte zeigen, wann die Organisation von der Eigentumsübertragung oder dem Juni-Vorfall erfuhr, wer die Entscheidung traf, den Dienst fortzusetzen, zu blockieren, zu ersetzen oder zu entfernen, und welche Beweise diese Entscheidung stützten. Eine Februar-Überprüfung und eine Juni-Notfallreaktion sind unterschiedliche Ereignisse und sollten nicht zusammengefasst werden.

Der vierte Schritt ist der historische Umfang. Die Organisation sollte angeben, welche Daten, Besucherpopulationen und Telemetriequellen sie untersucht hat. Sie sollte Endpunktverweise, Anfragen, bekannte Indikatorübereinstimmungen, Weiterleitungen und gemeldeten Schaden trennen. Wenn Protokolle fehlen, sollte die Lücke explizit bleiben.

Der fünfte Schritt ist die Reparatur. Der Eigentümer sollte die Änderung an ein Release, eine Konfiguration oder eine Anbieterbestätigung binden. Er sollte generierte Assets, Caches, Plugins, Tag-Manager und bedingte Zweige berücksichtigen. Die bloße Beobachtung, dass die gesperrte Domain nicht mehr antwortet, ist kein Entfernungsnachweis.

Der sechste Schritt ist die Verifizierung. Tests sollten relevante Browserbedingungen abdecken und bestätigen, dass die öffentliche Seite keine Anfrage an den alten Endpunkt stellt. Die Überwachung sollte auf Wiedereinführung, unerwartete Skript-Ursprünge und Weiterleitungsverhalten achten. Wenn der Anbieter den Fix bereitgestellt hat, sollte der Kunde das externe Ergebnis überprüfen.

Der siebte Schritt ist die Kommunikation. Eine Mitteilung sollte stabile Definitionen verwenden und vermeiden, Nutzung in Opferschaft umzuwandeln. Sie sollte erklären, welche Abhängigkeit bestand, ob sie erreichbar war, welche Beweise für bösartige Auslieferung gefunden wurden oder nicht, was sich geändert hat und welche Unsicherheiten bestehen bleiben. Benutzer benötigen praktische Fakten, keine pauschale Erklärung, dass das Problem „gelöst" sei.

Schließlich sollte der Eigentümer seine Lebenszykluskontrollen aktualisieren. Remote-Skripte mit hoher Autorität benötigen benannte Eigentümer, Überprüfungsdaten, Vertrauensbasisaufzeichnungen, Domain- und Betreiberüberwachung, Notfall-Deaktivierungspfade und die Aufbewahrung nützlicher Browserbeweise. Andernfalls kann derselbe Governance-Fehler unter einem anderen Hostnamen erneut auftreten.

Ein Domain-Transfer kann eine Softwareänderung sein

Polyfill.io machte ein einfaches Prinzip schwer zu ignorieren: Wenn eine Domain ausführbaren Code zurückgibt, ist das Eigentum an der Domain Teil des Sicherheitszustands der Software. Die URL kann stabil bleiben, während der effektive Lieferant wechselt. Ein Repository kann öffentlich bleiben, während die gehostete Antwort unter andere Kontrolle gerät. HTTPS kann gültig bleiben, während die Vertrauensbasis, die die Aufnahme rechtfertigte, nicht mehr existiert.

Die Februar-Mitteilungen zeigten, dass diese Änderung sichtbar und handhabbar war. Die Juni-Berichte zeigten, warum sie wichtig war. Selektive Weiterleitungsauslieferung nutzte ein Modell aus, bei dem verschiedene Besucher legitimerweise unterschiedlichen Code erhalten konnten, was beiläufige Inspektion zu einer schwachen Sicherheitsmaßnahme machte. Spätere Umschreibung und Domain-Sperrung schränkten den Pfad ein, aber nur nachgelagertes Inventar, Entfernung, Untersuchung und Verifizierung konnten den Teil jedes Website-Problems schließen.

Der Vorfall rechtfertigt es nicht, mehr als 100.000 Sites als bestätigte Opfer zu bezeichnen. Er beweist nicht, dass jede Referenz bösartige Inhalte ausgeliefert hat, dass jeder Besucher exponiert war oder dass jedes nachgelagerte Produkt ausgenutzt wurde. Er rechtfertigt auch nicht, den ursprünglichen Open-Source-Code als allgemein bösartig zu beschreiben oder eine selbst gehostete Kopie als identisch mit der kompromittierten gehosteten Beziehung zu behandeln.

Noch unterstützt das Ereignis ein rechtliches Urteil oder eine vollständige Zuordnungsgeschichte aus dem verfügbaren Datensatz. Verantwortlichkeit ist hier enger und operativer. Es ist die Verpflichtung zu erklären, warum ausführbare Autorität delegiert wurde, wie geänderte Kontrolle erkannt wurde, welche Beweise die Reichweite feststellten, welche Maßnahme die Exposition reduzierte und wie die Reparatur verifiziert wurde.

Der Dienstanbieter, die Infrastrukturunternehmen, der Registrar, die Maintainer, Anbieter und Website-Betreiber hatten jeweils verschiedene Teile dieser Antwort. Die Verantwortung wurde geteilt, weil das System geteilt war, aber sie war nicht austauschbar. Ein Registrar konnte eine Domain sperren und dennoch veralteten Code hinterlassen. Ein Anbieter konnte eine Referenz entfernen und dennoch die Besuchertelemetrie des Kunden vermissen. Eine Website konnte ihre Nutzer untersuchen und dennoch von einer vorgelagerten Partei abhängen, um eine gebündelte Komponente zu ändern.

Für nachgelagerte Eigentümer ist der dauerhafte Standard direkt: Kennen Sie jede externe Partei, die Code für Ihre Besucher auswählen kann; überwachen Sie die Fakten, die diese Partei vertrauenswürdig machten; entfernen Sie Autorität, die keine notwendige Funktion mehr erfüllt; und bewahren Sie genügend Beweise auf, um Exposition, Auslieferung und Schaden zu unterscheiden.

Ein Skript-Tag mag eine Zeile HTML sein, aber es schafft eine Betriebsbeziehung. Wenn der Eigentümer hinter dieser Zeile wechselt, ändert sich auch die Softwarebeziehung. Die Verantwortlichkeit der Website beginnt damit, diesen Wechsel zu erkennen, bevor ein Besucher ihn offenbaren muss.

Quellen

  1. https://sansec.io/research/polyfill-supply-chain-attack
  2. https://blog.cloudflare.com/polyfill-io-now-available-on-cdnjs-reduce-your-supply-chain-risk/
  3. https://community.fastly.com/t/new-options-for-polyfill-io-users/2540
  4. https://github.com/formatjs/formatjs/issues/4363
  5. https://blog.cloudflare.com/automatically-replacing-polyfill-io-links-with-cloudflares-mirror-for-a-safer-internet/
  6. https://cert.ssi.gouv.fr/actualite/CERTFR-2024-ACT-030/
  7. https://soc.cyber.wa.gov.au/advisories/20240626004-JavaScript-Polyfill-Supply-Chain-Attack/
  8. https://tag-security.cncf.io/community/catalog/compromises/2024/polyfill/
  9. https://www.akamai.com/blog/security/polyfill-supply-chain-attack-what-to-know
  10. https://socket.dev/blog/namecheap-takes-down-polyfill-io-service-following-supply-chain-attack
  11. https://www.cve.org/CVERecord?id=CVE-2024-38537
  12. https://nvd.nist.gov/vuln/detail/cve-2024-38537
  13. https://jellyfish.co/library/jellyfish-security-advisory-june-27-2024/
  14. https://www.wordfence.com/threat-intel/vulnerabilities/detail/various-plugins-various-version-use-of-polyfillio
  15. https://codeql.github.com/codeql-query-help/javascript/js-functionality-from-untrusted-domain/
  16. https://cwe.mitre.org/data/definitions/830.html
  17. https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html
  18. https://www.w3.org/TR/SRI/
  19. https://developer.mozilla.org/en-US/docs/Web/Security/Practical_implementation_guides/SRI
  20. https://semgrep.dev/blog/2024/protect-your-code-from-the-polyfill-supply-chain-attack/
  21. https://cert-agid.gov.it/news/scoperto-un-grave-attacco-alla-supply-chain-del-servizio-polyfill-io-piu-di-100-000-i-siti-coinvolti/
  22. https://isomer-user-content.by.gov.sg/36/8bee5efc-3166-44a1-89ae-0f0b095ecb17/03-July-2024.pdf