Technische Maßnahmeempfehlungen für betroffene Shop4/3-Kunden
Legende: HOSTING-OK bedeutet, dass dieser Schritt für JTL-Shop-Hostingkunden bereits von JTL geprüft / übernommen wurde.
Laden Sie den Patch über diesen Link herunter und entpacken diesen (z.B. mit 7zip, WinZip oder der Windows-Funktion) „hier“):
Wenn Sie danach einen „classes“ Ordner sehen, sind Sie bereit für den nächsten Schritt:
Um den Patch manuell in Ihrer JTL-Shop-Version 4.06.17 einzuspielen, benötigen Sie ein Programm wie FileZilla, das Sie z. B. hier downloaden können.
Nach dem Start von FileZilla sehen Sie folgenden Screen:
Links oben bei „Host“, „Username“, „Passwort“ und „Port“ müssen Sie Ihre FTP-Zugangsdaten eintragen. Sollten Ihnen diese nicht vorliegen, kann Ihr Hosting-Dienstleister helfen. Große Hoster bieten häufig auch Guide/FAQ-Einträge an, in denen der Vorgang beschrieben wird.
Haben Sie die Zugangsdaten hinterlegt und sich erfolgreich verbunden, sehen Sie auf der linken Seite die Dateistruktur ihres eigenen Rechners. Navigieren Sie hier zu dem Downloadverzeichnis des Patches:
Auf der rechten Seite sehen Sie die Dateistruktur auf Ihrem Webspace. In unserem Fall sind wir im Wurzelverzeichnis des Hostings, nicht im Hauptverzeichnis des JTL-Shop. In dieses müssen wir via Doppelklick auf, in diesem Fall, „httpdocs“ wechseln.
Welches Verzeichnis Sie nach dem Verbinden sehen und wo sich das Hauptverzeichnis Ihres JTL-Shops befindet, kann sich bei jedem Hoster unterscheiden. Sollten Sie Ihr JTL-Shop Hauptverzeichnis nicht finden, bitten Sie Ihren Hoster um Unterstützung.
Ihr Shop-Hauptverzeichnis sollte so aussehen:
Machen Sie nun auf der linken Seite auf den Ordner „classes“ einen Rechsklick und wählen Sie „Upload“:
Sie erhalten dann eine Bestätigungsabfrage zum Überschreiben der vorhandenen Datei. Bestätigen Sie diese mit OK:
Die Datei wird nun hochgeladen. Achten Sie darauf, dass die Übertragung auch bei den erfolgreichen Übertragungen steht. Sollte dies nicht der Fall sein, versuchen Sie es erneut. Sollte es nicht klappen, bitten Sie Ihren Hoster um Unterstützung.
Wurde erfolgreich übertragen („Successful transfers“), haben Sie den SecurityFix erfolgreich eingespielt.
Prüfen, ob die Lücke im Shop ausgenutzt wurde.
Indizien, die auf einen in der Vergangenheit erfolgten Angriff hindeuten:
- Die Logfile-Analyse des access.log zeigt Zugriffe auf Pfade, in denen „tadminlogin“ vorkommt und der Zugriff erfolgte VOR Einspielen des Patches.
- Befinden sich unter /bilder/banner/ .php-Dateien mit kryptischen Namen?
- Ist der Auto-Increment von tadminlogin.kAdminlogin > 40?
Wenn Sie sich an dieser Stelle sicher sind, dass Ihr Shop nicht betroffen ist, müssen Sie die folgenden Maßnahmen nicht ausführen.
Wenn sich durch die Logfile-Analyse herausstellt, dass die SQLInjection ausgenutzt und ein Adminlogin angelegt wurde oder immer dann, wenn Sie sich unsicher sind, ob die Sicherheitslücke ausgenutzt wurde, führen Sie zusätzlich die folgenden Maßnahmen aus:
Prüfen, ob unter /bilder/banner/ Dateien mit kryptischen Namen und der Endung .php existieren. Wenn ja, handelt es sich dabei wahrscheinlich um PHP-Backdoors.
Diese Dateien sind zu sichern (Beweise sichern) und auf dem Webspace zu entfernen.
Stellen Sie außerdem sicher, dass die Datei /bilder/.htaccess existiert und den Inhalt aufweist, der unter folgender URL einsehbar ist: https://gitlab.com/jtl-software/jtl-shop/core/-/blob/release/4.06/bilder/.htaccess
Wenn die Datei existiert und o.g. Inhalt aufweist, dann konnte die Backdoor mit großer Wahrscheinlichkeit nicht ausgenutzt werden und die nachfolgenden Maßnahmen müssen unter Umständen nicht durchgeführt werden.
Maßnahme Nr. 2.1:
Ändern des SMTP-Passwortes für das im Shop-Backend hinterlegten E-Mail-Konto.
Wo zu ändern: Im Shop-Backend „E-Mail-Einstellungen“ sowie im Admin-Panel des Webhosters (E-Mail-Postfach-Konfiguration).
Grund dieser Empfehlung: In manchen Access-Logs wurde beobachtet, dass die Backend-Seite /admin/einstellungen.php?kSektion=3 besucht wurde.
Wir gehen davon aus, dass über den Angriff die SMTP-Daten inkl. Klartext-Passwort abgerufen wurden.
Ändern des Datenbank-Passworts.
Wo zu ändern: Datei includes/config.JTL-Shop.ini.php (define(‚DB_PASS‘, ’neuesPasswort‘);) sowie im Admin-Panel Ihres Webhosters (Datenbank-Konfiguration)
Grund dieser Empfehlung: Die Nutzung der PHP-Backdoor ermöglichte den Abruf des Dateiinhalts der Konfigurationsdatei inkl. der dort hinterlegten Datenbankverbindungssparameter im Klartext inkl. BLOWFISH_KEY zur Entschlüsselung von Daten aus der Datenbank). Anhand verschiedener Logfile-Analysen bestätigte sich der Verdacht, dass zunächst die Konfigurationsdatei abgegriffen wurde, um danach Massendaten (tkunde und tadminlogin) aus der Datenbank zu stehlen.
Maßnahme Nr. 2.3:
Ändern der Wawi-Syncdaten (User und Passwort)
Wo zu ändern: Im Shop-Backend (Wawi-Syncdaten) sowie in JTL-Wawi in den Webshop-Einstellungen: https://guide.jtl-software.com/jtl-shop-4/systemverwaltung/synchronisationsdaten-mit-jtl-wawi-hinterlegen/
Grund dieser Empfehlung: In manchen Access-Logs wurde die Seite /admin/wawisync.php abgerufen. Die dort hinterlegten Zugangsdaten wurden wahrscheinlich gestohlen.
Maßnahme Nr. 2.4:
Ändern der Passwörter von Admin-Logins.
Wo zu ändern: Im Shop-Backend unter /admin/benutzerverwaltung.php.
Grund dieser Empfehlung: In den von uns gesichteten PHP-Backdoors wurde konkret der Inhalt der Datenbanktabelle tadminlogin inkl. Passwort-Hashes abgerufen.
Es besteht prinzipiell die Möglichkeit, insbes. einfache Passwörter per Brute Force und Nutzung von Wörterbüchern zu „erraten“.
Zusätzliche Maßnahmen zur Erhöhung der Sicherheit:
Maßnahme Nr. 3.0:
Kundenpasswörter zurücksetzen.
Wie zu ändern:
Das einfachste ist direkt auf der DB
SET cPasswort = 'xxx***xxx' WHERE (cPasswort IS NOT NULL AND cPasswort != '')
OR nRegistriert = 1;
Anschließend sind alle Passwörter für registrierte Kunden ungültig, da ‚xxx***xxx‘ kein gültiger Password-Hash ist und zu KEINEM Passwort passt. Die Kunden müssen sich dann per „Passwort vergessen“-Funktion ein neues Passwort erstellen. Es bietet sich an, Kunden über diese Maßnahme gesondert zu informieren (z.B. Mailing).
Hinweis: JTL-Shop nutzt ab Version 4 für Kundenpasswörter die Funktionen password_hash() und password_verify(), welche nach Stand der Technik als sehr sicher angesehen werden.
Trotz Nutzung von starken Einweg-Hashes besteht ein Restrisiko, dass die Passworthashes über Brute-Force-Angriffe ermittelt werden können.
Der Aufwand, um Passwörter über Brute Force zu knacken hängt direkt mit der Passwortstärke der jeweiligen Passwörter zusammen.
Es besteht zumindest für einfache Passwörter (welche z.B. in Wörterbüchern existieren) die Gefahr, dass diese mit entsprechendem Aufwand über Brute Force ermittelt werden können.
Nicht-technische Maßnahmen und Risikoeinschätzung
Maßnahme 4.0 - Datenschutzbeauftragten informieren:
Wenn Sie vermuten, dass Daten in Ihrem Shop abgeflossen sind oder durch Analyse bestätigt ist, dass ein Admin-Login über die SQL-Injection angelegt wurde, dann informieren Sie bitte umgehend Ihren Datenschutzbeauftragten. Dieser Schritt ist ggf. vor technischen Analysen / Sofortmaßnahmen vorzuziehen bzw. kann parallel erfolgen.
Haben Sie keinen eigenen Datenschutzbeauftragten, dann informieren Sie den Landesbeauftragten für Datenschutz: https://www.bfdi.bund.de/DE/Service/Anschriften/Laender/Laender-node.html
Maßnahme 4.1 - Risikoeinschätzung und ggf. Meldung an die Landesdatenschutzbehörde (Dabei hilft der Datenschutzbeauftragte!):
Wichtig zu wissen: Nicht jeder Fall muss gemeldet werden. Stellen Sie jedoch fest, dass personenbezogene Daten abgeflossen oder manipuliert wurden (wie es im Fall des Anlegens eines Admin-Logins der Fall ist), dann ist eine Meldung zu machen: https://www.bfdi.bund.de/DE/Service/Anschriften/Laender/Laender-node.html
Maßnahme 4.2 (Meldung an Betroffene (Kunden, deren Daten in tkunde oder tadminlogin stehen):
Wichtig zu wissen: Nicht in jedem Fall ist eine Meldung an Betroffene notwendig. Eine Pflicht zur Benachrichtigung greift dann, wenn „hohe Risiken für die individuelle Freiheit oder die persönlichen Rechte der Personen entsteht, deren Daten betroffen sind“ (Quelle: https://www.dataguard.de/magazin/reaktionsplan-datenpanne-muster). Ein hohes Risiko liegt z.B. dann vor, wenn Sie Bankdaten Ihrer Kunden in Ihrer Shopdatenbank speichern.
Gewöhnliche Adressdaten sowie E-Mail-Adressen fallen lt. unserem Datenschutzbeauftragten nicht in die Kategorie „sensible Daten“/“hohes Risiko“.
