Polyfill-Supply-Chain-Angriff schleust Malware in JavaScript-CDN-Dateien ein

Artikel von

26. Juni 2024

0 Min. Lesezeit

Uncovering the Polyfill.io Supply Chain Attack

Am 25. Juni 2024 gab das Sicherheitsforschungs- und Malware-Team von Sansec bekannt, dass ein beliebtes JavaScript-Polyfill-Projekt von einem ausländischen Akteur übernommen worden war, bei dem es sich um ein Unternehmen chinesischer Herkunft handelt. Dabei wurde schädlicher Code in JavaScript-Dateien eingebettet, die über die CDN-Quelle des Unternehmens unter cdn.polyfill.io abgerufen wurden. Sansec zufolge waren mehr als 100.000 Websites von diesem Polyfill-Angriff betroffen, darunter börsennotierte Unternehmen wie Intuit und andere.

Häufig gestellte Fragen

Ist Snyk von dem Supply-Chain-Angriff auf Polyfill betroffen?

Nein, die Snyk-Plattform einschließlich unserer Tools ist von dem aktuellen Supply-Chain-Angriff auf Polyfill nicht betroffen.

Kann Snyk das Polyfill-Sicherheitsproblem erkennen?

Snyk Code, unsere SAST-Engine auf Basis von Echtzeitverarbeitung und maschinellem Lernen, erkennt vielfältige URL-Verwendungen in funktionalem Code, unter anderem in JavaScript, PHP und vielen weiteren Programmiersprachen.

Hier sehen Sie ein Beispiel für eine benutzerdefinierte Snyk-Code-Regel, die Sie hinzufügen können:

1custom_rules:
- id: Polyfill supply chain compromise
  description: >-
    The polyfill.js is a popular open source library to support older
    browsers. This domain was caught injecting malware on mobile devices via
    any site that embeds cdn.polyfill.io.
  severity: high
  cwe:
    - CWE-506
  fix_analysis: Use alternatives provided at https://cdnjs.cloudflare.com/polyfill
  rule_code: >-
    StringLiteral<~".*http(s)?://((cdn\.)?polyfill\.io).*">
  languages:
    - html
    - javascript
    - php
    - java

Eine solche Regel erkennt zuverlässig jede Verwendung einer cdn.polyfill.io-URL in JavaScript- oder PHP-Code. Im folgenden Codeausschnitt wird beispielsweise die manuelle Einbindung eines Skripts erkannt:

1<!DOCTYPE html>
2<html lang="en">
3<head>
4    <meta charset="UTF-8">
5    <meta name="viewport" content="width=device-width, initial-scale=1.0">
6    <title>Load Polyfill</title>
7</head>
8<body>
9    <script>
10        // Load the polyfill for Array.prototype.includes from cdn.polyfill.io
11        (function() {
12            var script = document.createElement('script');
13            script.src = "https://cdn.polyfill.io/v3/polyfill.min.js?features=Array.prototype.includes";
14            script.onload = function() {
15                // Polyfill is loaded, you can use Array.prototype.includes safely now
16                console.log([1, 2, 3].includes(2)); // Should log 'true'
17            };
18            document.head.appendChild(script);
19        })();
20    </script>
21</body>
22</html>
23

Hinweis: Die benutzerdefinierte Regel erkennt nur JavaScript- oder PHP-Code, keine einfachen <script src=“…”></script>-Tags in HTML.

Sollte ich nur eine Denylist-Regel für die Website cdn.polyfill.io hinzufügen?

In zahlreichen Berichten wurde dokumentiert, dass der Angreifer weitere Domains hinzugefügt hat. Dazu gehören unter anderem: polyfill[.]site, polyfill[.]com, bootcdn[.]net, bootcss[.]com, staticfile[.]net, staticfile[.]org, unionadjs[.]com, xhsbpza[.]com, union.macoms[.]la und newcrbpc[.]com. Es wird dringend empfohlen, diese Berichte aufmerksam zu verfolgen und Ihre benutzerdefinierte Snyk Code-Regel entsprechend zu aktualisieren.

Was ist mit der schädlichen Polyfill-Bibliothek passiert?

Im Februar 2024 kündigte ein chinesisches Unternehmen an, die Website polyfill.io vom Ersteller der Node.js-Bibliothek polyfill-library, Jake Champion, und dem Website-Inhaber zu übernehmen. Das chinesische Unternehmen Funnull, das CDN- und Hosting-Dienste anbot, übernahm daraufhin die Inhaberschaft der Domain sowie der GitHub-Organisation und des Repositorys.

Funnell-Website mit der Überschrift „Übernahme von Polyfill“ und Text zur Übernahme von Polyfill durch Funnell.

Kurz nach der Ankündigung der Übernahme erhielt die Domain polyfill.io einen neuen CNAME-Eintrag für polyfill.io.bsclink.cn.

In Entwicklerkreisen gab es bereits Anzeichen für die bevorstehende Katastrophe, etwa den folgenden GitHub-Kommentar von Renaud Chaput:

Polyfill.io gehörte dem Webteam der Financial Times, wurde dann von der Community betreut und schließlich vom letzten Maintainer an ein zwielichtiges chinesisches CDN-Unternehmen verkauft. Dieses verlegte das Projekt von Fastly weg (der CDN- und Edge-Computing-Plattform, auf der der Open-Source-Code für den Dienst lief) und begann, die ausgelieferten Dateien zu manipulieren.

Renaud Chaput

Weitere Anzeichen für ein Fehlverhalten zeigten sich im April und Juni, als Mitglieder der Community wegen der Übertragung der Inhaberschaft an ein Drittunternehmen Alarm schlugen. Der Verdacht erhärtete sich noch, als ihre Kommentare in einem GitHub-Issue gelöscht wurden:

Verdächtige Anzeichen beim Übergang von polyfill.io an ein chinesisches Drittunternehmen, dem später vorgeworfen wurde, Schadcode für eine JavaScript-Polyfill-Bibliothek verbreitet zu haben

Andrew Betts, ein Kollege von Jake Champion bei Fastly, war der ursprüngliche Autor des Polyfill-Webdienstes. Dieses Projekt ermöglichte es, JavaScript-Polyfill-Bibliotheken automatisch in Websites einzubinden – basierend auf dem User-Agent oder anderen Eigenschaften. Andrews Aussagen gehen auf den Februar zurück, als er davor warnte, dass er nichts mit der offiziellen Website cdn.polyfill.io zu tun habe.

Uns ist keine bestimmte Polyfill-Bibliothek auf npm bekannt, die Teil dieser konkreten Kampagne eines schädlichen Akteurs zur Einschleusung von Schadcode ist. Allerdings kann Code aus verschiedenen Software-Ökosystemen, etwa aus Content-Management-Systemen wie Magento und anderen, statische Skriptimporte von JavaScript-Code aus cdn.polyfill.io enthalten. Insbesondere haben wir CVE-2024-38526 entdeckt, einen Sicherheitsbericht zur pdoc-Bibliothek im PyPI-Registry, die API-Dokumentation für Python-Projekte bereitstellt. Wenn Dokumentation mit dem Befehl pdoc --math generiert wurde, enthielt sie Links zu JavaScript-Dateien von polyfill.io. Dieses Verhalten der pdoc-Bibliothek wurde in pdoc Version 14.5.1 behoben. Wir empfehlen Ihnen dringend, so schnell wie möglich ein Upgrade durchzuführen.

Wie ist der aktuelle Stand der Website polyfill.io?

Die Website polyfill.io ist mittlerweile praktisch offline. Zum weiteren Schutz von Endnutzern haben Werbeblocker-Browsererweiterungen wie uBlock Berichte zur Website polyfill.io berücksichtigt und verhindern aktiv den Zugriff darauf, um Nutzer zu schützen.

Am 21. Juni wurde berichtet, dass Google auf der Google-Ads-Anwendungswebsite die Fehlermeldung „kompromittierte Website“ einführen wollte. Anlass dafür waren unter anderem Berichte über Spoofing-Versuche durch die Website der Domain googie-anaiytics[.]com.

Welche Auswirkungen hat die Polyfill.io-Malware?

2017 berichtete Andrew Betts, der ursprüngliche Autor der auf Fastly gehosteten Website polyfill.io, dass täglich sage und schreibe 91 Millionen Browser Anfragen zum Importieren der Bibliothek stellten und pro Monat bis zu 700 Millionen Anfragen eingingen, um ältere Browser auf moderne Webstandards zu aktualisieren.

91 Millionen Browser werden täglich automatisch mit den neuesten Webfunktionen aktualisiert.

In sozialen Medien und anderen Quellen wurde darauf hingewiesen, dass die Website des Unternehmens Hulu die JavaScript-Bibliothek von der Website cdn.polyfill.io einbindet, die als schädlich eingestuft wurde (Bericht von Theo).

Die Hulu-Website bindet den schädlichen JavaScript-Bibliothekscode von cdn.polyfill.io ein

In einem weiteren Bericht von Germán Fernández wurde festgestellt, dass auch die Atlassian-Community-Website die JavaScript-Polyfill-Bibliothek von der schädlichen Domain polyfill.io importiert.

Die Atlassian-Community-Website bindet JavaScript-Quellcode von der Domain polyfill.io ein, von der Malware-Injektionen gemeldet wurden.

Auch auf Regierungswebsites wurde die schädliche Quelle polyfill.io entdeckt. Silent Push Labs meldete dies der CISA.

Was ist ein JavaScript-Polyfill?

Ein JavaScript-Polyfill ist in der Regel ein eigens entwickelter Code, der moderne Funktionen in älteren Browsern bereitstellt, die diese nicht von Haus aus unterstützen. Früher waren Polyfills für Webentwickler unverzichtbar, wenn sie Anwendungen erstellen wollten, die in verschiedenen Browserversionen reibungslos funktionieren. Sie dienen als Brücke, über die ältere Browser neuere JavaScript-Funktionen ausführen können. So bleibt das Nutzererlebnis unabhängig vom Alter und den Funktionen des Browsers einheitlich.

In den Anfangsjahren der Webentwicklung entwickelten sich Browser unterschiedlich schnell. Dadurch entstand eine fragmentierte Umgebung, in der derselbe Code nicht auf allen Plattformen einheitlich ausgeführt werden konnte. Die Unterstützung von Browser-APIs war im Allgemeinen nicht überall gleich. Da Entwickler keinen Einfluss auf die von Endnutzern verwendeten Browserversionen hatten, konnten sie nicht sicherstellen, dass beim Ausführen von JavaScript-Code in Browsern dieselben APIs verfügbar waren. Polyfills lösten dieses Problem: Mit Polyfill-Bibliotheken konnten Entwickler modernen JavaScript-Code schreiben, ohne sich Gedanken über Kompatibilitätsprobleme machen zu müssen. Methoden wie Array.prototype.includes und Promise wurden beispielsweise von älteren Browsern wie Internet Explorer nicht unterstützt. Mit einer im Browser geladenen Polyfill-Bibliothek konnten Entwickler diese Funktionen dennoch bereitstellen.

Die Rolle eines JavaScript-CDN bei Polyfill-Bibliotheken

Ein Content Delivery Network (CDN) ist ein System aus weltweit verteilten Servern, die Webinhalte je nach geografischem Standort an Nutzer ausliefern. Bei JavaScript-Polyfill-Bibliotheken spielen CDNs eine wichtige Rolle, da sie diese Bibliotheken effizient weltweit hosten und bereitstellen. Durch die Nutzung von CDNs können Entwickler Polyfills schnell und zuverlässig an Nutzer ausliefern, Latenzen minimieren und Ladezeiten verkürzen. Ein CDN half Entwicklern außerdem dabei, JavaScript-Bibliotheken nicht selbst bündeln zu müssen.

Ein typischer Anwendungsfall für ein CDN, dem Sie wahrscheinlich begegnen, ist die Nutzung cloudbasierter Mess- und Anwendungsleistungstools wie Google Analytics. Dort wird offiziell empfohlen, den folgenden Code zu Ihrer Website hinzuzufügen:

1<script async custom-element="amp-analytics" src="https://cdn.ampproject.org/v0/amp-analytics-0.1.js"></script>
2<amp-analytics type="gtag" data-credentials="include">
3<script type="application/json">
4{
5  "vars" : {
6    "gtag_id": "<GA_MEASUREMENT_ID>",
7    "config" : {
8      "<GA_MEASUREMENT_ID>": { "groups": "default" }
9    }
10  }
11}
12</script>
13</amp-analytics>

Bei der schädlichen Übernahme von polyfill.io war cdn.polyfill.io ein weit verbreitetes CDN, das Polyfills dynamisch anhand der HTTP-Header eingehender Anfragen bereitstellte. So wurde das passende Polyfill entsprechend dem Browser und der Version des Nutzers ausgeliefert, um optimale Kompatibilität sicherzustellen.

Sicherheitsrisiken von Polyfills, die auf einem CDN gehostet werden

Die Verwendung von Polyfills, die auf einem CDN gehostet werden, birgt erhebliche Sicherheitsrisiken. Das liegt vor allem daran, dass beliebiger JavaScript-Code im Kontext der Anwendung ausgeführt werden kann. Dieses Risiko wird für eine Webanwendung oft als Cross-Site-Scripting-Schwachstelle (XSS) gemeldet.

Wird eine Polyfill-Bibliothek von einem CDN abgerufen, ist die Anwendung auf die Integrität und Sicherheit des externen Servers angewiesen – also auf die CDN-Quelle selbst. Wird das CDN oder die dort gehostete Bibliothek kompromittiert, wie beim jüngsten Angriff auf cdn.polyfill.io, kann der neu eingeschleuste Schadcode im Browser des Nutzers ausgeführt werden. Dieser Code kann verschiedene schädliche Aktionen ausführen, etwa Nutzer auf Phishing-Websites umleiten, sensible Informationen stehlen oder sogar weitere Malware verbreiten. Für die Browser-Sicherheit ist eine solche XSS-Schwachstelle die schwerwiegendste Folge.

Schutz vor CDN-Supply-Chain-Angriffen

Der jüngste Angriff auf das JavaScript-Polyfill-Projekt zeigt, wie wichtig unterstützende Ressourcen im gesamten Web-Ökosystem sind – und dass CDNs dabei eine bedeutende Rolle spielen. Bei der Supply-Chain-Sicherheit geht es oft um Open-Source-Paket-Registrys wie PyPI und npm. Der JavaScript-Polyfill-Angriff hat uns jedoch daran erinnert, dass auch CDNs ein wesentlicher Baustein des Webs sind.

Mit den folgenden Best Practices können Sie sich vor solchen Angriffen schützen:

Vertrauenswürdige CDNs verwenden: Nutzen Sie nur CDNs von renommierten Anbietern. Cloudflare ist beispielsweise für seine robusten Sicherheitsmaßnahmen und Zuverlässigkeit bekannt.
Polyfill-Klon verwenden: Cloudflare hat unter https://cdnjs.cloudflare.com/polyfill einen Polyfill-Klon bereitgestellt, den Sie laut Empfehlung als direkten Ersatz verwenden sollten.
Abhängigkeiten überwachen: Prüfen und überwachen Sie regelmäßig alle Skripte und Abhängigkeiten von Drittanbietern.
Subresource Integrity: Tools wie Subresource Integrity (SRI) können dazu beitragen, sicherzustellen, dass die von einem CDN ausgelieferten Inhalte nicht manipuliert wurden. Außerdem lässt sich damit eine erwartete Version oder ein erwarteter Hash festlegen, der geprüft wurde und bekanntermaßen frei von schädlichem oder anderweitig unerwünschtem Verhalten ist.
Content Security Policy (CSP): Implementieren Sie eine strenge CSP, um die Quellen einzuschränken, aus denen Skripte geladen werden dürfen. So lässt sich die Ausführung schädlicher Skripte verhindern. Da Polyfills oft in den kritischen Pfad des Anwendungsstarts eingebunden sind, werden sie mit denselben Berechtigungen wie jeder andere JavaScript-Code auf der Seite ausgeführt. Damit sind sie ein bevorzugtes Ziel für Angreifer, die dieses Vertrauen ausnutzen wollen. Dieses Risiko unterstreicht, wie wichtig die Verwendung sicherer und renommierter CDNs, robuste Sicherheitsmaßnahmen wie Content Security Policy (CSP) und regelmäßige Prüfungen von Drittanbieter-Abhängigkeiten sind, um sich vor solchen Schwachstellen zu schützen.
Regelmäßige Updates: Halten Sie alle Bibliotheken und Abhängigkeiten auf dem neuesten Stand. Viele Angriffe nutzen bekannte Schwachstellen aus, die in späteren Versionen behoben wurden.
Alternative Lösungen: Prüfen Sie, ob Polyfills für Ihr Projekt noch erforderlich sind. Da Browser immer moderner werden, werden viele der von Polyfills bereitgestellten Funktionen inzwischen nativ unterstützt. Erwägen Sie ausdrücklich, Abhängigkeiten zusammen mit den Assets Ihres eigenen Projekts bereitzustellen, statt sich auf Drittanbieter wie CDNs zu verlassen.