Kryptomining Supply Chain Attack befällt Regierungs-Webseiten

Cryptomining-Supply-Chain-Attack

Kryptomining durch Supply Chain Angriff

Cryptomining Supply Chain AttackIn den vergangenen 24 Stunden hat der Sicherheitsforscher Scott Helme festgestellt, dass das Browser-Plug-in eines Drittanbieters mit der Bezeichnung “Browsealoud” seine Server kompromittiert hat. Das Plugin verwendet eine Website auf der Javascript geladen wurde. Durch das laden der Java-Script Datei in den Browser wurden mehr als 4.000 Webseiten mit Krypto-Malware korrumpiert.

Die Malware verwendet die CPUs der Besucher um die Kryptowährungen Monero zu minen. Zu den Websites, die Browsealoud verwenden, gehören u.a. das Büro des britischen Datenschutzbeauftragten, Websites des britischen Gesundheitsdienstes, eine Website der australischen Provinzregierung und viele mehr.

Texthelp ist die Firma, die das Browsealoud Plugin erstellt. Sie berichten, dass ihr Produkt vier Stunden lang infiziert war. Dies betrifft Webseiten die das Browsealoud-Plug-in verwenden, bevor es offline geschaltet wurde. Das Produkt bleibt während der Untersuchung offline.

Supply-Chain-Angriffe haben weitreichende Auswirkungen

Diese Form der Angriffe auf Webseiten und ihre ahnungslose Besucher hat gegen Ende 2017 erheblich zugenommen. Es wird befürchtet, dass das die Anzahl derartiger Angriffe in 2018 signifikant ansteigen wird.

Die Supply-Chain Attack ist eine Form von Angriff, welche die “vertrauenswürdige Beziehung zwischen Softwareanbietern oder Autoren und ihren Kunden” beeinflussen. Der Webseitenbetreiber vertraut einem Dienst der Javascript verteilt, um die Sicherheit der Website zu gewährleisten. Wenn dieser Dienst kompromittiert wird, wirkt sich dies auf jede Website aus, die diesen Code verwendet. Und das können potenziell Tausende von Webseiten sein. Wie bei einem WordPress-Plugins können Angreifer mit JavaScript-Angriffen eben durch die “Lieferkette” (Supply-Chain) tausende von Websites mit einem einzigen Hack kompromittieren.

Im Fall von Browsealoud hätte der Vorfall viel schlimmer sein können. Der Angreifer hätte auch Anmeldedaten von Websites der Regierung in mehreren Ländern stehlen können. Stattdessen nutzten sie einfach die CPU-Ressourcen der Website-Besucher, um die Kryptowährung Monero zu minen.

So schützt du deine Webseite sowie deine Website-Besucher vor JS Supply Chain Attacks

Es gibt eine einfache Möglichkeit sich vor Angriffen von Supply Chain Attacks zu schützen, indem du eine Sicherheitsfunktion namens Subresource Integrity (SRI) verwendest. Wenn du JavaScript-Code aus einer externen Quelle mit dem Tag SCRIPT einfügst, dann füge einfach noch ein Integritätsattribut mit hinzu. Dieses bewirkt, dass der Browser das Skript nicht laden wenn es von der ursprünglichen Version abweicht.

Normalerweise sieht ein Java-Skript Eintrag wie folgt aus:
unsicheres jquery

Um deine Webseite gegen JS Supply Chain Attacks abzusichern, ändere dies in:
sicheres jquery

Diese Änderung ist einfach einzufügen. Besuche diese Seite um einen Hash und den Einschlusscode aus einer Skript-URL zu generieren.

Das Attribut ‘Integrität’ enthält einen ‘Hash’, der den Inhalt des Skripts eindeutig identifiziert. Wenn sich dieser Inhalt ändert kann der Browser erkennen, dass er sich geändert hat und das Laden des fremden oder geänderten Skripts ablehnen. Dadurch können Webseiten Besitzer die Kontrolle darüber behalten was sie von Remote-Servern laden, indem sie das Laden von Code verweigern der sich von der ursprünglichen Version unterscheidet.

Beim verwenden von SRI besteht allerdings folgendes Problem. Sollte der Hersteller das Script ändern und zur Verfügung stellen, wird es vom Browser auch nicht mehr geladen.

Du hats also den Vorteil, dass deine Website-Besucher geschützt werden, wenn ein Hacker die Anbieter-Website kompromittiert und Malware in das von dir benutzte JavaScript einschleust. Es hat aber auch den Nachteil, dass das gleiche Skript nicht mehr geladen wird wenn der Anbieter seinen Code unter derselben URL aktualisiert.

Einige Legacy-Anbieter können sich darauf verlassen, dass sie ihren Code jederzeit bei einer URL aktualisieren können und Ihre Website einfach den neuen Code automatisch lädt. Wenn ein Anbieter eine Versionsnummer in der Skript-URL einbindet, wie in der obigen jQuery-URL, musst du dir wahrscheinlich keine Gedanken darüber machen. Wenn die URL jedoch in etwa so aussieht //example.com/source/code/lives/here.js – also ohne Versionsnummer – dann erkundige dich beim Anbieter ob er das von dir verwendete Skript aktualisieren wird.

Im Allgemeinen würde ich jeden Anbieter meiden der darauf besteht den Code remote zu aktualisieren, ohne dass du den Code deiner Website ändern müsst. Es ist ein Sicherheitsrisiko, wie dieser Fall ja zeigt.

Javascript Supply Chain Attacken finden in Echtzeit statt

JS-Supply-Chain-Angriffe unterscheiden sich von anderen Angriffsarten dadurch, dass die Opfer unmittelbar infiziert werden sobald der Angreifer seinen schädlichen Code installiert hat. Der Webseiten-Administrator oder der Webseiten Besucher müssen gar nichts aktiv unternehmen. Der Code wird pro Besuch vom kompromittierten Server geladen. Und sobald eine Codeänderung vorgenommen wird, ist er in den Browsern der Opfer aktiv.

Dies unterscheidet sich von Application Supply Chain-Angriffen oder WordPress-Plug-in-Supply-Chain-Angriffen. Ein Anwendungs-Supply-Chain-Angriff benötigt eine kompromittierte Anwendung die verteilt werden muss, bevor sie die Benutzer ausnutzt. Desktop- oder mobile Benutzer müssen auf die neue Version aktualisieren, bevor sie ausgeführt werden. Selbst wenn ein Auto-Update vom Angreifer irgendwie heraus geschoben wird kommt es zu einer gewissen Verzögerung bevor es wirksam wird.

Ein WordPress-Plugin-Supply-Chain-Angriff erfordert zu deren Aktivierung, dass der Webseiten Besitzer die neue kompromittierte Plugin-Version aktualisiert. Javascript Supply Chain Attacken hingegen sind sofort aktiv und werden von Webseiten Besuchern geladen, sobald der Angreifer die Datei auf dem Distributions-Webserver speichert. Aus diesem Grund ist es für Website Administratoren äußerst wichtig, SRI für alle externen Skripts auf ihrer Seite zu verwenden.

Quelle: Wordfence

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.