Es gab einen Lieferketten-Angriff gegen das JavaScript-Framework Polyfill, und der neue chinesische Besitzer hat begonnen, Malware über das Content Delivery Network dieser Domain auszuliefern. Google hat zwar begonnen, ADs zu blockieren, wenn Webseiten Polyfill verwenden. Sicherheitsforscher gehen aber davon aus, dass mehr als 100.000 Webseiten gefährdet sind.
Anzeige
Was ist Polyfill?
Bei polyfill.js handelt es sich um eine beliebte Open-Source-Bibliothek zur Unterstützung älterer Browser. Der JavaScript-Code soll in älteren Browsern neuere, von diesen nicht unterstützte Funktionen mittels eines Workarounds nachrüsten. Beispielsweise sind Features von HTML5 und CSS in älteren Browsern nicht verfügbar.
Polyfill-JavaScript-Code bzw. Polyfill-Skripte im Allgemeinen lassen sich direkt in das HTML-Dokument eines Webprojekts einbetten. Dabei integrieren sie sich nahtlos in den bestehenden Quellcode und werden bei korrekter Programmierung nur dann ausgeführt, wenn der zugreifende Browser das jeweilige Webfeature tatsächlich nicht unterstützt. IONOS hat hier eine umfangreichere Beschreibung zu Polyfill erstellt.
Nennenswerte Nutzer sind JSTOR, Intuit und das Weltwirtschaftsforum. Polyfill wird auch in verschiedenen Webpaketen wie Magento (eCommerce-Shop) oder WordPress (CMS) eingesetzt. Hier ist aber ein genauer Blick erforderlich, was genau eingesetzt wird.
Lieferkettenangriff, was ist passiert?
Es gibt eine Domain poliyfill.io, die den Polyfill-JS-Code über ein Content-Delivery-Network ausliefert. Im Februar 2024 ging diese Domain und das GitHub-Konto an einen chinesischen Eigentümer und jetzt liefert dieser über cdn.poliyfill.io Malware aus. Die betreffende Information ist mir bereits vor Tagen untergekommen (Urlaubs-bedingt habe ich es nicht thematisiert).
Anzeige
Die Leute von Sansec haben den Sachverhalt im Artikel Polyfill supply chain attack hits 100K+ sites dokumentiert. Der Polyfill-Code wird dynamisch auf der Grundlage der HTTP-Header generiert, so dass verschiedene Angriffsmethoden denkbar sind. Die Leute von Sansec haben eine bestimmte Malware entschlüsselt und dokumentiert, die mobile Nutzer über eine gefälschte Google-Analytics-Domain (www.googie-anaiytics.com) auf eine Sportwettseite umleitet. Der Code verfügt über einen speziellen Schutz gegen Reverse Engineering und wird nur auf bestimmten mobilen Geräten zu bestimmten Zeiten aktiviert. Er wird auch nicht aktiviert, wenn er einen Admin-Benutzer erkennt. Außerdem verzögert er die Ausführung, wenn ein Webanalysedienst gefunden wird, vermutlich um nicht in den Statistiken zu landen.
Google hat bereits am 25. Juni 2024 damit begonnen, Google Ads für eCommerce-Seiten zu blockieren, die polyfill.io verwenden. Und die Sansec-Webseite ist inzwischen Ziel von DDoS-Angriffen um deren Infrastruktur und den Artikel aus dem Internet zu bekommen. Im Tweet wird erwähnt, dass diese Seite in Magento-Modulen eingebettet wird und so über 110.000 Webseiten betroffen seien. Sansec hat die Details der ausgelieferten Malware in seinem Artikel dokumentiert. Hinweise auf dieses Verhalten wurden schnell aus dem Github-Repository entfernt (Archiv hier).
Die Kollegen von Bleeping Computer haben den Sachverhalt hier zeitnah dokumentiert. Die Domain polyfill.io wurde vom Registrar Namecheap abgeschaltet, nachdem Forscher den Malware-Befall aufgedeckt hatten. Zudem hat Clouflare damit begonnen, die Polyfill-Codebestandteile aus ausgelieferten Webseiten zu entfernen. Bleeping-Computer hat dies in diesem Beitrag aufgegriffen und einige Informationen dazu zusammengetragen.
Laut diesem Bleeping Computer-Beitrag haben die Besitzer der Domain Polyfill.io den JavaScript-CDN-Dienst auf einer neuen Domain wieder gestartet (siehe dieser Tweet). Weiterhin behaupten sie, der Polyfill-Dienst sei "böswillig verleumdet" worden und es habe "Medienmeldungen gegeben, die Polyfill verleumden" (siehe auch diesen Tweet). Der Dienst als solcher dürfte aber verbrannt sein und es gibt die Empfehlung, diesen Dienst aus Webprojekten auszubauen.
Polyfill ist nicht polyfill.io
Ich habe mal kurz im Quellcode des Blogs nachgesehen – auch in WordPress wird Polyfill verwendet – und in diesem Artikel beschreibt jemand diesen Einsatz als unverantwortlich. Denn viele Experten sind der Meinung, dass Polyfill längst nicht mehr benötigt wird und eigentlich entfernt gehört. Dem kann ich mich anschließen, aber ob eine Seite durch den Polyfill-Lieferkettenangriff gefährdet ist, hängt davon ab, ob cdn.polyfill.io eingebettet wurde. heise hat es in diesem Artikel thematisiert, die Seiten, die sich auf diese Domain stützen, binden den Code des chinesischen Anbieters ein. Es gibt aber von Fastly und Cloudflare Alternativen zum oben genannten Dienst.
Denn nur diese (inzwischen abgeschaltete) Domain bzw. das CDN ist unter chinesischer Kontrolle und liefert(e) sporadisch Malware aus. Das Open-Source-Projekt selbst ist nicht betroffen.
In WordPress werden die Polyfill-Routinen aber direkt als .js-Dateien aus diesem Open Source-Projekt eingebunden (siehe folgenden Codeauszug sowie den Screenshot), haben also mit obigem CDN nichts zu tun.
<script type="text/javascript" src="https://www.borncity.com/blog/wp-includes/js/dist/vendor/wp-polyfill-inert.min.js?ver=3.1.2" id="wp-polyfill-inert-js"></script> ... <script type="text/javascript" src="https://www.borncity.com/blog/wp-includes/js/dist/vendor/wp-polyfill.min.js?ver=3.15.0" id="wp-polyfill-js"></script>
Daher gibt es diesbezüglich imho auch keine Gefährdung von WordPress-Seiten. Ich bin aber gespannt, ob der Vorfall dazu führt, dass der Polyfill-JS-Code künftig in WordPress ausgebaut wird.
Anzeige
Externe Quellen und Ressourcen in eine Website einzubinden war noch nie gut. Viel zu viele Angriffsflächen, keine Kontrolle was da eigentlich geladen wird.
Die Webentwicklung hat schon vor einigen Jahren dieselbe Richtung eingeschlagen wie die Softwareentwicklung: Bibliotheken hier und Bausteine dort, sodass das Internet vielerorts nach einem Einheitsbrei aussieht.
Ich wurde seinerzeit belächelt, dass ich bei der Umsetzung von Projekten nicht auf "etablierte Frameworks" gesetzt habe.
Mein erstes Argument: Ich kann nicht den Quellcode von so vielen Drittanbieter-Lösungen analysieren, einen Risikobericht schreiben und die Sicherheit garantieren.
Mein zweites Argument: Warum soll ich Ressourcen laden lassen, die gar nicht benötigt werden? Lasse mich mal 10 % eines Frameworks tatsächlich nutzen. Das bedeutet im Umkehrschluss, dass 90 % des Frameworks ungenutzt bleiben, aber Ressourcen verbrauchen, wenngleich wir bei solchen Bibliotheken von Kilobytes sprechen. Aber wer weiß, was das Framework noch so alles lädt…
Bei Aktualisierungen von Projekten habe ich nicht mehr benötigten Code entfernt und den Quellcode als solchen kommentiert.
Und wenn ich Drittanbieter-Lösungen eingesetzt habe, lud ich deren Lösung runter und hostete es selbst auf dem Webserver. Das verpflichtete mich allerdings dazu, den Herstellern zu folgen.
Wir bekommen seit dem 26.06. Meldungen in der Endpoint-Projection zu geblockten Malware URLs mit Bezug auf Polyfill.io. Die Software scheint wirklich recht weit verbreitet zu sein. Am 26.06. haben wir die Verbindungen zu polyfill.io aus den letzten zwei Wochen ausgewertet. Rund 20% der Clients hatten einmal oder mehrmals Kontakt mit diesem Webservice. Anzeichen für eine Infektion haben wir trotz intensiver Analyse aber nicht gefunden.
Gibt es Hintergründe wie der Hack von Westfalia mit polyfill.io zusammenhängt?
Leider ist mir wegen Westfalia nichts an Details bekannt – die betreffenden Tor-Seiten habe ich mir nicht angesehen.
Selbiges bei uns. Einige Clients haben sich zu cdn.polyfill.io verbunden. Was genau da passiert und ob man sich Sorgen machen muss, ist die große Preisfrage. Ich sollte mir Sorgen machen.
Weiß jemand genauer, inwiefern Websites oder auch Clients betroffen sein könnten? Reicht nur der Besuch einer verwundbaren Website, um als Client infiziert zu werden?
Bei heise gab im Artikel zu polyfill diesen Absatz:
"Offenbar ist der Inhalt von den HTTP-Headern abhängig, sodass er nur auf bestimmten mobilen Geräten aktiv wird. Laut dem Blogbeitrag ist der Code nicht nur verschleiert, sondern setzt auch auf verzögerte Ausführung und andere Techniken, um unentdeckt zu bleiben."
Schenkt man dem Glauben, dann würde es ehr um Mobilgeräte gehen. Alte Handys, ohne Support und Updates sind ja ein Zielmarkt von polyfill und sicherlich auch leichter per Malware zu infizieren. Mehr habe ich bisher leider auch nicht gefunden.
auf der Webseite steht nur, das ein Skript von dort geladen werden soll. Das macht dann der Client oder nicht (Skriptblocker).
Irgendwie muss dann noch die Ausführung getriggert werden, z.B. weil der Anwender irgendwo draufklickt. Hier speziellen auf eine über Google-Ads eingeblendete Werbung – auch irgendein Skript aus fremder Quelle, die selbst wieder von irgendwoher etwas nachladen kann. Seit einiger Zeit läuft das alles in einer Sandbox aus der es nicht rauskommt, außer da ist ein Fehler drin, der ausgenutzt wird. Aktuell größtenteils harmlos und kein Grund zur Panik.
Unter "https[:]//urlscan.io/search/#task.tags:%22magecart%22"
gibt es seit Montag tausende Treffer, viele, aber bei weitem nicht alle mit einem erkennbaren Bezug zu "Polifill"
("Magecart" ist der Oberbegriff für Web-Seiten-Malware, die Kredit-Karten-Nummern stiehlt)
Ein schöner Super GAU.
Wer extern einbindet, lebt gefährlich. Gilt auch für jQuery und andere Frameworks. Wer das nicht erkennt, hat in der Webwelt eher nichts verloren.
Was kann man tun? Viele Webseitenbetreiber von den 100.000+ werden nicht schnell reagieren. Ich würde cdn.polyfill.io kurzerhand blocken, so wie es @Singlethreaded am Endpoint/FW erlebt.
Engagierte User könnten dies auch privat, was denkt Ihr? Ist Blocken allein (temporäre) User-Lösung?
reicht das im uBlock aus?
||cdn.polyfill.io^$all
————————
Habe ich das richtig verstanden:
Prinzipiell sollte ja eigentlich bei JS und dem Browser nichts ausbrechen können? Natürlich wenn Polyfill gerade für ältere Browser eingesetzt wird, ist das taktisch gut User mit einem Browser mit Sicherheitslücken zu finden…?
Hier wurde einfach per window.location.href auf andere Webseiten weitergeleitet.
das Problem ist ja schon seit Ende Februar (!) bekannt und zumindest Clouflare hat damals schon alle Verweise der bei ihnen liegenden Seiten auf eine eigene Kopie des Polyfill umgebogen. Ebenso im eigenen DNS und ich denke die großen Anbieter sind spätestens jetzt aufgewacht und haben das auch geblockt.
Ad- und Skriptblocker schützen ganz unabhängig davon und ich bin etwas überrascht, dass uBlock Origin das erst jetzt explizit in eine Sperrliste übernommen hatte.
Ich für meinen Teil habe das der Sperrliste in der Fritzbox hinzugefügt und zumindest zu Hause besteht da keine Gefahr mehr. Bis demnächst der nächste Fall bekannt wird und alle wild herumfuchteln werden…
Ansonsten hatten Analysen ergeben, dass die Malware erstmal nur bei bestimmten Mobiltelefonen überhaupt geladen wurde und dort nur Werbung von Google auf eine Wettseite umgebogen hat, die auch nur angezeigt wurde, wenn man draufklickte. Das macht ja eh niemand, also keine Gefahr.
unsere Qualitätsmedien haben das Thema aber erst einen Tag oder noch später aufgegriffen, da waren die Kommentare bei HN schon nicht mehr lesbar, weil so viel ankam. Fachkräftemangel soweit das Auge reicht.
https://www.borncity.com/blog/wp-includes/js/dist/vendor/wp-polyfill.min.js ist core-js und hat nichts mit polyfillio zu tun. Polyfill als Begriff ist gebräuchlich in der Web-Welt. polyfillio ist ein Dienst von einem Entwickler.
Laut Golem sind neben polyfill.io auch andere Domains unter Verdacht:
bootcdn.net, bootcss.com, staticfile.net und staticfile.org.
Quelle: https://www.golem.de/news/grossteil-aus-deutschland-fast-400-000-webhosts-verbreiten-malware-via-polyfill-io-2407-186716.html