Neu E-Mail / WICHTIG: Sicherheitslücke in JTL-Shop 4 - Dringender Handlungsbedarf

[jaquesbubu]

Hallo,
wir haben die Datei .gitkeep im Verzeichnis banner (auch in anderen Verzeichnissen).
Ich gehe mal davon aus, dass diese Datei was mit github und JTL zu tun hat?

 

[webstar]

Hallo,

mit dem Release von Shop 5.1.0 im September wurde auch ein Sicherheitsupdate für Shop 4.06.18 angekündigt. Was ist denn daraus geworden?
https://forum.jtl-software.de/threads/jtl-shop-5-1-aktuell-5-1-1.166239/

 

[FPrüfer]

Hallo,
wir haben die Datei .gitkeep im Verzeichnis banner (auch in anderen Verzeichnissen).
Ich gehe mal davon aus, dass diese Datei was mit github und JTL zu tun hat?

Die .gitkeep ist unkritisch und gibt es eigentlich nur, wenn der Shop mal direkt aus dem Repo installiert wurde. In den Installationspaketen sollten diese Dateien eigentlich nicht drin sein.

 

[FPrüfer]

Hallo,

mit dem Release von Shop 5.1.0 im September wurde auch ein Sicherheitsupdate für Shop 4.06.18 angekündigt. Was ist denn daraus geworden?
https://forum.jtl-software.de/threads/jtl-shop-5-1-aktuell-5-1-1.166239/

Die 4.06.18 ist aktuell in QA und der Fix für diese Lücke ist dort auch enthalten. Wir mussten das aber als Patch vorziehen, da dringender Handlungsbedarf bestand.

 

[Roadrider]

Ich bin leider wirklich nicht fit in Sachen Datenbanken etc. pp. und daher um Hilfe dankbar.

Wir haben wegen den Access Logs bei unserem Webhosting nachgefragt. Hier wurde uns der logs Ordner auf dem FTP Server gezeigt. Hier werden für jeden Tag und für jede Domain Archive angelegt mit den entsprechenden Log-Dateien. Sind das diese Dateien in denen man nach Auffälligkeiten schauen soll? Oder sind wir hier falsch?
Denn hier kann ich nirgendswo "tadminlogin" finden? Ist der Schnipsel "tadminlogin" nur aufgeführt, wenn versucht wird ein neues Admin Konto zu erstellen? Wie werden denn normale Admin-Logins, bspw. durch mich, geloggt?

In unserem Banner Ordner war(en) auch keine .php Datei(en). Wenn ich dann richtig gesucht habe und kein "tadminlogin" Schnipsel gefunden habe ist davon auszugehen das alles in Ordnung ist? In welcher Zeitraum sollen denn die Log Dateien untersucht werden?

 

[FPrüfer]

Wir haben wegen den Access Logs bei unserem Webhosting nachgefragt. Hier wurde uns der logs Ordner auf dem FTP Server gezeigt. Hier werden für jeden Tag und für jede Domain Archive angelegt mit den entsprechenden Log-Dateien. Sind das diese Dateien in denen man nach Auffälligkeiten schauen soll? Oder sind wir hier falsch?

Ja, um diese Log-Files geht es. Ein typischer Eintrag sieht dort in etwa so aus:
xxx.xxx.xxx.xxx - - [04/Nov/2021:09:54:48 +0100] "GET /admin/index.php HTTP/1.1" 200 2152 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) ...."

Denn hier kann ich nirgendswo "tadminlogin" finden? Ist der Schnipsel "tadminlogin" nur aufgeführt, wenn versucht wird ein neues Admin Konto zu erstellen? Wie werden denn normale Admin-Logins, bspw. durch mich, geloggt?

Wenn im gesamten Access-Log kein einziger Treffer für tadminlogin gefunden wurde, ist es sehr unwahrscheinlich, dass der zugehörige Shop betroffen ist.

In welcher Zeitraum sollen denn die Log Dateien untersucht werden?

Sicherheitshalber solange zurück wie möglich.

 

[Roadrider]

Ja, um diese Log-Files geht es. Ein typischer Eintrag sieht dort in etwa so aus:
xxx.xxx.xxx.xxx - - [04/Nov/2021:09:54:48 +0100] "GET /admin/index.php HTTP/1.1" 200 2152 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) ...."

Wenn im gesamten Access-Log kein einziger Treffer für tadminlogin gefunden wurde, ist es sehr unwahrscheinlich, dass der zugehörige Shop betroffen ist.

Sicherheitshalber solange zurück wie möglich.

Danke für die schneller Antwort.

Und zum Verständnis: Der Log "tadminlogin" wird nur gespeichert wenn ein neuer Admin Zugang erstellt wird?

Solche Einträge wie genannt "xxx.xxx.xxx.xxx - - [04/Nov/2021:09:54:48 +0100] "GET /admin/index.php HTTP/1.1" 200 2152 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) ....""
finde ich viele. Aber das sind dann normale Einträge in Zusammenhang mit meinen Arbeit im Backend etc.?

 

[FPrüfer]

Ja, genau. tadminlogin ist keine gültige Resource für einen Web-Zugriff und taucht nicht in diesen Logs auf. Für dieses Angriffszenario ist das Vorhandensein von tadminlogin in einem Logfile deshalb ein sicheres Zeichen für einen Angriffsversuch.

 

[Roadrider]

Wir haben jetzt die access.logs vom 01.10-05.11. mit Notepad ++ kontrolliert. Wir konnten kein einziges Mal "tadminlogin" finden. Im Ordner bilder/banner waren auch keine php's. Bedeutet das jetzt, dass wir sicher sind und kein Zugriff von außen stattgefunden hat? Wie ist hier eure Handlungsempfehlung, nachdem wir gestern bereits die Lücke geschlossen haben?

 

[FPrüfer]

Wir haben jetzt die access.logs vom 01.10-05.11. mit Notepad ++ kontrolliert. Wir konnten kein einziges Mal "tadminlogin" finden. Im Ordner bilder/banner waren auch keine php's. Bedeutet das jetzt, dass wir sicher sind und kein Zugriff von außen stattgefunden hat? Wie ist hier eure Handlungsempfehlung, nachdem wir gestern bereits die Lücke geschlossen haben?

In diesem Fall würde ich mit sehr hoher Wahrscheinlichkeit davon ausgehen, dass es keinen Zugriff durch unbefugte Dritte gegeben hat. Auf alle Fälle sicherstellen das es die bereits gen. .htaccess im Ordner /bilder gibt und zur Sicherheit auch die Access-Logs in den nächsten Tagen im Auge behalten.

 

[Roadrider]

In diesem Fall würde ich mit sehr hoher Wahrscheinlichkeit davon ausgehen, dass es keinen Zugriff durch unbefugte Dritte gegeben hat. Auf alle Fälle sicherstellen das es die bereits gen. .htaccess im Ordner /bilder gibt und zur Sicherheit auch die Access-Logs in den nächsten Tagen im Auge behalten.

Ok. Danke.

Ja, eine .htaccess gab es, war aber nur die erste Zeile drin. Da habe ich noch den von dir angegebenen Code eingefügt.

 

[Harald Weingaertner]

Mir ist nicht ganz klar, was aus der Datenbanktabelle tkunde ersichtlich ist. Wenn ich mir die mit phpmyadmin angucke, dann sehe ich da den Vornamen, Hausnummer, PLZ, Ort, E-Mail, Land und Registrierdatum. Alles andere (Nachnahme, PW, etc.) sieht für mich verschlüsselt aus. Scheinbar wurde in einem Shop zumindest mal eine PHP Datei hochgeladen. Falls wir herausfinden, dass auch Daten aus tkunde abgerufen wurden, dann würden wir natürlich auch gerne genau wissen, ob das oben die "einzigen" Daten im Klartext waren. Die Passwörter scheinen für mich jedenfalls dann nicht im Klartext angesehen worden sein, oder?

 

[Derdiedas]

Wir haben gerade ein Ticket geöffnet und wären sehr dankbar wenn das schnellstmöglich beantwortet würde. Wir haben keine .php Files in /banner/bilder und hatten auch die htaccess darin.
Lediglich in den Firewall Logs waren 4 Einträge 2 mit insert und 2 mit delete die, so vermuten wir, ein Adminkonto einrichten und dann löschen sollten. Das ganze geschah innerhalb von 8 Sekunden. Der String entspricht aber nicht den kommunizierten, oder den hier beschriebenen!

 

[FPrüfer]

Mir ist nicht ganz klar, was aus der Datenbanktabelle tkunde ersichtlich ist. Wenn ich mir die mit phpmyadmin angucke, dann sehe ich da den Vornamen, Hausnummer, PLZ, Ort, E-Mail, Land und Registrierdatum. Alles andere (Nachnahme, PW, etc.) sieht für mich verschlüsselt aus. Scheinbar wurde in einem Shop zumindest mal eine PHP Datei hochgeladen. Falls wir herausfinden, dass auch Daten aus tkunde abgerufen wurden, dann würden wir natürlich auch gerne genau wissen, ob das oben die "einzigen" Daten im Klartext waren. Die Passwörter scheinen für mich jedenfalls dann nicht im Klartext angesehen worden sein, oder?

Da der Angreifer über das Backdoor-Script u.U auch die config.JTL-Shop.ini.php ausgelesen hat, ist er im Besitz des BlowfishKey und kann die Kundendaten entschlüsseln.
Leider lässt sich das nicht genau ermitteln. Beim Zugriff miitels POST auf die Backdoor kann man nur Rückschlüsse auf die abgegriffenen Daten ziehen anhand der zurückgegeben Größe im Access-Log. Das ist die Zahl hinter dem Status-Code 200.
Passwörter werden grundsätzlich nur als Hash gespeichert, diese können also nicht "entschlüsselt" werden.

 

[Diane B.]

Wir haben gerade ein Ticket geöffnet und wären sehr dankbar wenn das schnellstmöglich beantwortet würde. Wir haben keine .php Files in /banner/bilder und hatten auch die htaccess darin.
Lediglich in den Firewall Logs waren 4 Einträge 2 mit insert und 2 mit delete die, so vermuten wir, ein Adminkonto einrichten und dann löschen sollten. Das ganze geschah innerhalb von 8 Sekunden. Der String entspricht aber nicht den kommunizierten, oder den hier beschriebenen!

Hallo Derdiedas,

bitte einmal noch die Ticketnummer durchgeben, danke! 🙂

 

[Derdiedas]

Hallo Derdiedas,

bitte einmal noch die Ticketnummer durchgeben, danke! 🙂

Hallo, ist schon in Bearbeitung. Danke!

 

[maestro]

Liebe Kunden,

wir entschuldigen uns für die Verwirrung, den der gestrige Newsletter bzw. die darin enthaltenen Links bei einigen von Ihnen ausgelöst haben. Da wir in dem Newsletter sehr detaillierte Informationen zu den technischen Hintergründen dieser Sicherheitslücke geben, haben wir uns bewusst dazu entschieden, die Inhalte nicht öffentlich zu machen. Zukünftig werden wir aber einen entsprechenden Hinweis im Forum oder Kundencenter (hier klären wir aktuell die Möglichkeiten) veröffentlichen, der die Echtheit der Information sowie die Sicherheit der geteilten Links bestätigt.

Bitte beachten Sie, dass es sich wirklich um eine kritische Sicherheitslücke handelt, die, wie in unserer Anleitung beschrieben, schnellstmöglich behoben werden muss.

Wir wünschen Ihnen viel Erfolg und ein schönes Wochenende!

Nur am Rande:
https://forum.jtl-software.de/threads/kritischer-hotfix-fuer-jtl-shop-3-4.105310/

Déjà-vu? Ich dachte doch, dass ich noch was im Kopf hatte... Und da war es... Auch hier war es anfangs nicht klar, ob die E-Mail real ist. Das ist schade, gerade weil dadurch auch wertvolle Zeit vergeht, bis z.B. technische Umsetzung des Shopbetreibers erfolgen kann - aufgrund der Verifzierung. Ihr solltet das wirklich generell besser lösen.

An der Stelle jedoch auch ein Danke an die direkte Hilfe und schnellen Antworten auf (unsere) Fragen, ohne Ticket, etc. Pragmatische Löusung 👍

 

[Matze_G]

Hallo zusammen,

wir haben eben aktualisierte Infos zum Thema an unsere Shop-Kunden versendet. Ihr solltet die Mail als reinen Text erhalten haben, also anders als sonst im gelayouteten Stil. Alle Links darin stammen von uns, die Infos ebenfalls. Wichtig: Es gab gesonderte Infos für (die noch übrigen) Shop 3-Nutzer und Shop 4-Nutzer. Sollte euch also eine Mail erreicht haben, die deutlich textlastiger, aber weniger farbprächtig war: Ja, ist von uns und ja, sie enthält aktualisierte Infos. Bitte bedenkt auch diesmal, dass es nur bedingt sinnvoll ist, Inhalte daraus öffentlich zu teilen - unser Ziel ist es, wirklich nur gefährdete Kunden zu informieren. Den Fall "Gelegenheit macht Diebe" möchten wir so gut es geht weiterhin vermeiden.

Auch bei uns ist diese zweite Mail nicht angekommen (der erste Sicherheitshinweis am Freitag schon. Im KC ist der Haken bei "Kritische Info" gesetzt, die Daten sind aktuell und auch nicht geändert. Dennoch die zweite Mail nicht angekommen.

 

[gboehm]

Ich bin etwas verwirrt.
Mein Shop war noch auf 4.06.16. Daher habe ich mir erstmal den Patch v4.06.16 auf v4.06.17 gezogen und dann die class.JTL-Shop.Redirect.php aus patch-sqlinject-v4.06.17.zip und 4.06.17 verglichen. Bei mir waren sie identisch.
Wie kann denn der Security Patch im Patch von v4.06.16 auf v4.06.17 schon enthalten sein, wenn dieser schon im Februar 2020 released wurde? Oder habe ich da etwas übersehen?

 

[david]

Wie kann denn der Security Patch im Patch von v4.06.16 auf v4.06.17 schon enthalten sein, wenn dieser schon im Februar 2020 released wurde? Oder habe ich da etwas übersehen?

Guten Morgen, wir hatten das Release-Zip 4.06.17 am Freitag Abend noch gepatched, da offenbar einige Shops vorab noch diesen Update-Schritt auf 4.06.17 vollziehen müssen.
Das erklärt, warum der Vergleich jetzt keinen Unterschied mehr zeigte.
Wir möchten damit auf Nummer Sicher gehen, dass es danach auch wirklich wirklich bei allen behoben ist.