DE
Sprechen wir miteinander
  1. Startseite
  2. Leistungen
  3. Sicherheitslücke in PrestaShop Checkout

Sicherheitslücke in PrestaShop Checkout

Wir raten Ihnen, zu handeln und Ihr Geschäft dagegen abzusichern.

PrestaShop-Sicherheitslücke: rund 200 Shops weltweit betroffen

In den letzten Monaten haben wir deutlich mehr gehackte PrestaShop-Shops gesehen, obwohl das System für seine Sicherheit bekannt ist. Hatten wir in den vergangenen 10 Jahren nur wenige Fälle (3–4) gehackter Shops im PrestaShop-Umfeld, erhielten wir in den letzten 4 Monaten über 10 Anfragen, einen gehackten Shop zu analysieren oder zu reparieren.

Das Hauptziel dieser Angriffe ist es, JavaScript-Skimmer in die Checkout-Seiten von E-Commerce-Websites einzuschleusen.

Für diesen Angriff verschafften sich die Hacker direkt oder über Drittanbieterdienste Zugang zu Websites und schleusten dann schädliches JavaScript ein, um die Daten zu stehlen, die Kunden in Online-Zahlungsformulare eingeben – die sich meist auf den Checkout-Seiten befinden.

Onlineunternehmen fehlt meist der Überblick über ihre öffentlich erreichbaren Angriffsflächen, die Hacker ausnutzen. Die Opfer merken oft nicht, dass das JavaScript auf ihrer Website verändert wurde, sodass der Schadcode unbegrenzt dort bleiben kann. Bei Supply-Chain-Angriffen ist dem Opfer typischerweise nicht bewusst, welche Gefahr vom gehackten Drittanbieter-JavaScript auf seiner Website ausgeht oder dass es Code des kompromittierten Anbieters ausführt.

Die Hacker veränderten die Checkout-Seite und ersetzten das Standard-Kreditkartenformular durch ein eigenes.

Die folgenden Beispiele zeigen die verschiedenen Probleme, die dadurch entstehen konnten:

  • Diebstahl personenbezogener Daten: Auch wenn es bei diesen Angriffen vor allem um Kreditkartendaten geht, können die Täter auch personenbezogene Daten stehlen. Potenziell könnten Millionen von Verbrauchern betroffen sein.
  • Umsatzverluste: Bei einem kleinen bis mittelgroßen Onlinehändler, der bereits Opfer solcher Angriffe war, können die Onlineumsätze deutlich sinken. Kunden verlieren womöglich das Vertrauen, dass der Händler künftige Datenlecks verhindern kann.
  • Weitere Infektionen: Stiehlt eine Hackergruppe Anmeldedaten von Administratoren und Nutzern, kann sie den Angriff ausweiten und weitere Websites infizieren. So kann eine Hackergruppe nicht nur die Hauptwebsite einer Marke, sondern auch deren Nebenwebsites kompromittieren.
  • Rechtliche Schäden: Ein Hackerangriff setzt ein Unternehmen Klagen von Kunden aus, rechtlichen Konsequenzen, wenn es Gesetzen wie der DSGVO unterliegt, sowie Sanktionen der Branche wie einem PCI-DSS-Audit und dem Verlust der Möglichkeit, Kreditkarten zu akzeptieren.
Hackerangriffe

Was kann man tun?

  • Die Shopdateien gründlich auf Eindringlinge prüfen und unerwünschte Änderungen erkennen
  • Die Ausführung kompromittierter Dateien lässt sich verhindern, indem man Imunify auf dem Server einsetzt.
  • Wir haben intensiv das Modul Clarity Pro eingesetzt, um die Probleme zu finden und festzustellen, ob Kartendaten kompromittiert wurden.
  • Empfehlenswert ist die Aktivierung der Zwei-Faktor-Authentifizierung für den Admin-Bereich.

Die oben genannten Maßnahmen kosten einmalig 200 € und monatlich 15 €.

Vorbeugen ist immer besser als heilen. Wir empfehlen dringend, die oben genannten Vorkehrungen zu treffen, um Ihren Shop zu schützen.

Hackerangriffe

Fallstudie

Das Problem:

Ein Shopbetreiber stellte fest, dass in den letzten Stunden keine Bestellungen eingegangen waren – für ihn sehr ungewöhnlich, da er normalerweise über 60 Bestellungen pro Tag erhielt.

Die Reaktion:

Der Inhaber wandte sich an uns, um den fehlerhaften Bestellprozess reparieren zu lassen – in der Annahme, es handle sich um einen einfachen Fehler, der sich leicht beheben lässt.

Unser Vorgehen:

Zunächst vermuteten wir, dass der Fehler von einem Modul stammte, das er in den Tagen zuvor installiert hatte, und begannen mit der Untersuchung. Schnell stießen wir auf erhebliche Codeänderungen und entdeckten, dass das ursprüngliche Checkout-Formular vollständig durch ein betrügerisches ersetzt worden war.

Die Lösung:

Je nachdem, ob Ihr Server über Imunify360 Proactive Defense verfügt oder nicht, stehen zwei Optionen zur Verfügung:

  1. Automatische Entfernung der kompromittierten Dateien mit dem Schutz durch Imunify360 PROACTIVE DEFENSE (https://www.imunify360.com/getting-started-proactive-defense/, https://www.imunify360.com/imunify360/#proactive-defense-info) Sobald der Echtzeit-Dateiscanner infizierte Dateien auf dem Server findet, können sie sofort bereinigt bzw. entfernt werden. Jede Datei wird automatisch gescannt, wenn sie ins System geladen wird. Ist sie schädlich, wird sie entfernt. Das mindert den Schaden auf einem ungeschützten System und ist besonders bei einem bereits infizierten System von Vorteil.
  2. Manuelle Suche nach den schädlichen Dateien Bei diesem Verfahren werden die Dateien auf dem Server manuell nach base64-kodierten Code-Strings durchsucht, die dann von Hand entfernt werden, ohne die Funktion des Shops zu beeinträchtigen. Typischerweise sind diese 6 Dateien am häufigsten infiziert: classes/db/Db.php Der Code befindet sich am Ende der Datei und sendet den Wert des Parameters 'statistics_hash' an die IP-Adresse 106.15.179.255. classes/controller/FrontController.php Diese Datei wird typischerweise so verändert, dass die Checkout-/Bestellseite eine zusätzliche JavaScript-Datei mit einem zufälligen Namen wie /js/HQf6b.js lädt, die den Zahlungsbereich der Bestellseite durch ein eigenes Kartenzahlungsformular ersetzt. /public_html/js/STRANGENAME.js Diese Datei wird beim Laden der Bestellseite mitgeladen und ersetzt den Zahlungsbereich der Checkout-Seite durch ein eigenes Zahlungsformular, das die Gelder höchstwahrscheinlich auf das Konto des Angreifers umleitet. !!! Sobald die Infektion entdeckt ist, ist dies die wichtigste Datei, die gelöscht werden muss. !!! classes/modulle/module.php Auch diese Datei muss bereinigt werden, denn sie enthält kodierten PHP-⁠Code, über den kodierte Parameter übergeben werden können, um kodierten PHP-⁠Code auszuführen. controllers/admin.AdminLoginController.php Dieser Code sendet die URL des Administrationsbereichs zusammen mit der Login-E-Mail-Adresse und dem Passwort an 45.197.141.250/statystics.php. app/Mage.php Enthält ähnlichen Code wie classes/module/module.php. Diese Datei sollte gelöscht werden.

Wenn auf Ihrem Server oder Hosting die kostenlose Version von Imunify AV installiert ist, müssen Sie den Dateiscan regelmäßig manuell starten und Schadcode manuell aus infizierten Dateien löschen, da dieser Version aktive Schutzfunktionen fehlen:

https://support.cpanel.net/hc/en-us/articles/360049068973-What-s-the-difference-between-ImunifyAV-ImunifyAV-and-Imunify360-

Was kommt als Nächstes
für Ihren Shop?

Erzählen Sie uns, was Sie vorhaben. Sie sprechen direkt mit den Leuten, die es auch bauen würden.

Sprechen Sie mit uns auf

  • Englisch
  • Rumänisch
  • Ungarisch
  • Deutsch
  • Französisch
  • Spanisch

Wir antworten innerhalb eines Werktags.

Leo Jozsa
Peter Szamosan
Attila Karacson
Szilamer Balogh

Leo, Péter, Attila und Szilamér