Kreditkarten-Skimming – der lange und kurvenreiche Weg zum Scheitern der Lieferkette

Forscher des Anwendungssicherheitsunternehmens Jscrambler haben gerade eine veröffentlicht warnendes Beispiel über Supply-Chain-Angriffe …

…das ist auch eine starke Erinnerung daran, wie lange Angriffsketten sein können.

Leider ist das nur in Bezug auf lang Zeit, nicht lange in Bezug auf den technischen Aufwand oder die Anzahl der Glieder in der Kette selbst.

Vor acht Jahren…

Die High-Level-Version der von den Forschern veröffentlichten Geschichte ist einfach erzählt und geht so:

• In den frühen 2010er Jahren bot ein Webanalyseunternehmen namens Cockpit einen kostenlosen Webmarketing- und Analysedienst an. Zahlreiche E-Commerce-Websites nutzten diesen Dienst, indem sie JavaScript-Code von den Servern von Cockpit bezogen und so den Code von Drittanbietern als vertrauenswürdigen Inhalt in ihre eigenen Webseiten einbauten.
• Im Dezember 2014 stellte Cockpit seinen Dienst ein. Die Benutzer wurden gewarnt, dass der Dienst offline gehen würde und dass jeder JavaScript-Code, den sie aus Cockpit importierten, nicht mehr funktionieren würde.
• Im November 2021 kauften Cyberkriminelle den alten Domainnamen von Cockpit auf. Wir können nur vermuten, dass eine Mischung aus Überraschung und Freude war, als die Gauner offenbar feststellten, dass mindestens 40 E-Commerce-Sites ihre Webseiten noch nicht aktualisiert hatten, um alle Links zu Cockpit zu entfernen, und immer noch zu Hause anriefen und JavaScript akzeptierten Code, der angeboten wurde.

Sie können sehen, wohin diese Geschichte führt.

Alle unglücklichen ehemaligen Cockpit-Benutzer, die ihre Protokolle seit Ende 2014 anscheinend nicht richtig (oder vielleicht gar nicht) überprüft hatten, bemerkten nicht, dass sie immer noch versuchten, Code zu laden, der nicht funktionierte.

Wir vermuten, dass diese Unternehmen bemerkt haben, dass sie keine Analysedaten mehr von Cockpit erhalten, aber weil sie erwarteten, dass der Datenfeed nicht mehr funktioniert, gingen sie davon aus, dass das Ende der Daten das Ende ihrer Cybersicherheitsbedenken bedeutet zum Dienst und seinem Domänennamen.

Injektion und Überwachung

Laut Jscrambler haben die Gauner, die die nicht mehr existierende Domain übernommen haben und sich so einen direkten Weg verschafft haben, Malware in alle Webseiten einzufügen, die dieser jetzt wiederbelebten Domain noch vertrauten und diese benutzten …

… begann genau damit, unautorisiertes, bösartiges JavaScript in eine Vielzahl von E-Commerce-Websites einzuschleusen.

Dies ermöglichte zwei Hauptarten von Angriffen:

• Fügen Sie JavaScript-Code ein, um den Inhalt von Eingabefeldern auf vordefinierten Webseiten zu überwachen. Daten in input, select und textarea Felder (wie Sie es in einem typischen Webformular erwarten würden) wurden extrahiert, verschlüsselt und auf eine Reihe von „Call Home“-Servern exfiltriert, die von den Angreifern betrieben werden.
• Fügen Sie auf ausgewählten Webseiten zusätzliche Felder in Webformulare ein. Dieser Trick, bekannt als HTML-Injection, bedeutet, dass Gauner Seiten untergraben können, denen Benutzer bereits vertrauen. Benutzer können glaubwürdig dazu verleitet werden, persönliche Daten einzugeben, nach denen diese Seiten normalerweise nicht fragen würden, wie Passwörter, Geburtstage, Telefonnummern oder Zahlungskartendetails.

Mit diesem Paar von Angriffsvektoren, die ihnen zur Verfügung stehen, könnten die Gauner nicht nur alles abschöpfen, was Sie in ein Webformular auf einer kompromittierten Webseite eingeben, sondern auch zusätzliche persönlich identifizierbare Informationen (PII) angreifen, zu denen sie normalerweise nicht in der Lage wären stehlen.

Durch die Entscheidung, welcher JavaScript-Code bereitgestellt werden soll, basierend auf der Identität des Servers, der den Code ursprünglich angefordert hat, konnten die Gauner ihre Malware so anpassen, dass sie verschiedene Arten von E-Commerce-Websites auf unterschiedliche Weise angreift.

Diese Art von maßgeschneiderter Antwort, die einfach zu implementieren ist, indem man sich die anschaut Referer: Header, der in den von Ihrem Browser generierten HTTP-Anforderungen gesendet wird, erschwert es Cybersicherheitsforschern auch, die gesamte Bandbreite der Angriffsnutzlasten zu ermitteln, die die Kriminellen im Ärmel haben.

Denn wenn Sie nicht im Voraus die genaue Liste der Server und URLs kennen, nach denen die Gauner auf ihren Servern Ausschau halten, können Sie keine HTTP-Anforderungen generieren, die alle wahrscheinlichen Varianten des von den Kriminellen programmierten Angriffs abschütteln in das System.

Falls Sie sich fragen, die Referer: Header, eine falsche Schreibweise des englischen Wortes „Referrer“, hat seinen Namen von einem typografischen Fehler im ursprünglichen Internet Normen Dokument.

Was ist zu tun?

• Überprüfen Sie Ihre webbasierten Lieferkettenglieder. Überall dort, wo Sie sich auf von anderen Personen bereitgestellte URLs für Daten oder Code verlassen, die Sie so bereitstellen, als wären es Ihre eigenen, müssen Sie regelmäßig und häufig überprüfen, ob Sie ihnen noch vertrauen können. Warten Sie nicht, bis sich Ihre eigenen Kunden darüber beschweren, dass „etwas kaputt aussieht“. Erstens bedeutet dies, dass Sie sich vollständig auf reaktive Cybersicherheitsmaßnahmen verlassen. Zweitens gibt es möglicherweise nichts Offensichtliches, das der Kunde selbst bemerken und melden könnte.
• Überprüfen Sie Ihre Protokolle. Wenn Ihre eigene Website eingebettete HTTP-Links verwendet, die nicht mehr funktionieren, dann stimmt eindeutig etwas nicht. Entweder hätten Sie diesem Link vorher nicht vertrauen sollen, weil es der falsche war, oder Sie sollten ihm nicht mehr vertrauen, weil er sich nicht mehr so ​​verhält wie früher. Wenn Sie Ihre Protokolle nicht überprüfen, warum sollten Sie sie dann überhaupt sammeln?
• Führen Sie regelmäßig Testtransaktionen durch. Halten Sie ein regelmäßiges und häufiges Testverfahren ein, das realistischerweise die gleichen Online-Transaktionssequenzen durchläuft, die Sie von Ihren Kunden erwarten, und verfolgen Sie alle eingehenden und ausgehenden Anfragen genau. Dies hilft Ihnen, unerwartete Downloads (z. B. Ihr Testbrowser saugt unbekanntes JavaScript ein) und unerwartete Uploads (z. B. Daten, die aus dem Testbrowser an ungewöhnliche Ziele exfiltriert werden) zu erkennen.

Wenn Sie JavaScript immer noch von einem Server beziehen, der vor acht Jahren stillgelegt wurde, insbesondere wenn Sie es in einem Dienst verwenden, der personenbezogene Daten oder Zahlungsdaten verarbeitet, sind Sie nicht Teil der Lösung, sondern Teil des Problems …

… also sei bitte nicht diese Person!

---

Hinweis für Sophos-Kunden. Die hier für die JavaScript-Injektion verwendete „revitalisierte“ Web-Domain (web-cockpit DOT jp, wenn Sie Ihre eigenen Protokolle durchsuchen möchten) wird von Sophos als blockiert PROD_SPYWARE_AND_MALWARE und SEC_MALWARE_REPOSITORY. Dies bedeutet, dass die Domain bekanntermaßen nicht nur mit Malware-bezogener Cyberkriminalität in Verbindung gebracht wird, sondern auch an der aktiven Bereitstellung von Malware-Code beteiligt ist.

---