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

[Einrad-Shop]

select cMail from tkunde

Mehr fällt mir da nich ein

 

[Einrad-Shop]

Kann das jemand erweiteren für insert into cPasswort tkunden
Das muß ja dann noch gehashed werden vor dem schreiben in die DB

-------------------------------------------------------------------------
DECLARE @char CHAR = ''
DECLARE @charI INT = 0
DECLARE @password VARCHAR(100) = ''
DECLARE @len INT = 12 -- Length of Password
WHILE @len > 0
BEGIN
SET @charI = ROUND(RAND()*100,0)
SET @char = CHAR(@charI)

IF @charI > 48 AND @charI < 122
BEGIN
SET @password += @char
SET @len = @len - 1
END
END
SELECT @password [PassWord]
----------------------------------------------------------
Codeschnippsel
? Insert into tkunde (cPasswort) where cPasswort NOT NULL ? MD5(PassWord) ? CONVERT(VARCHAR(254), HashBytes('MD5', 'PassWord'), 2)

 

[Eric-M]

Über den Punkt wurde ja bereits gesprochen und ich wollte, nach Rücksprache mit unserer Datenschutzbeauftragten, nur noch einmal das Vorgehen bestätigen. Es muss eine Meldung an die für Euch zuständige Datenschutzbehörde gehen. Zudem wird empfohlen die Kunden zu informieren, ggf. mit dem Hinweis das Passwort zu ändern.

Wir haben uns für solche Fälle externe Unterstützung (Fa. pridatect) geholt und ich kann gerne den Kontakt herstellen, schickt mir einfach eine PN.

 

[sah]

Codeschnippsel
? Insert into tkunde (cPasswort) where cPasswort NOT NULL ? MD5(PassWord) ? CONVERT(VARCHAR(254), HashBytes('MD5', 'PassWord'), 2)

Sind die Passwörter wirklich unsicher? Man hat doch einen Hash und keinen Klartext durch Blowfish-Entschlüsselung.

 

[sah]

Über den Punkt wurde ja bereits gesprochen und ich wollte, nach Rücksprache mit unserer Datenschutzbeauftragten, nur noch einmal das Vorgehen bestätigen. Es muss eine Meldung an die für Euch zuständige Datenschutzbehörde gehen. Zudem wird empfohlen die Kunden zu informieren, ggf. mit dem Hinweis das Passwort zu ändern.

Wir haben uns für solche Fälle externe Unterstützung (Fa. pridatect) geholt und ich kann gerne den Kontakt herstellen, schickt mir einfach eine PN.

In erster Linie Kunden mit Zahlungsinformationen.

 

[Cevitt]

Hab die Mail am 4.11 um 17:30 bekommen, 17:45 uhr hab ich den Patch hochgeladen. am 5.11 15:30 kam noch eine Mail. Mein Shop wurde nicht angegriffen, Log sieht sauber aus.. Verstehe nicht warum hier einige einfach auf die Betreiber losgehen mit lächerlichen Vorwürfen. Der Absender der Mail ist ja wohl klar und Wenn da noch ganz groß wichtiger Hinweis drauf steht und Sicherheitslücke dann sollten alle Alarmglocken läuten

 

[Einrad-Shop]

Hab die Mail am 4.11 um 17:30 bekommen, 17:45 uhr hab ich den Patch hochgeladen. am 5.11 15:30 kam noch eine Mail. Mein Shop wurde nicht angegriffen, Log sieht sauber aus.. Verstehe nicht warum hier einige einfach auf die Betreiber losgehen mit lächerlichen Vorwürfen. Der Absender der Mail ist ja wohl klar und Wenn da noch ganz groß wichtiger Hinweis drauf steht und Sicherheitslücke dann sollten alle Alarmglocken läuten

Hast du Glück gehabt. Bei mir kam die Mail am 5.11. 15:23 Uhr, angegriffen wurden die Shops bereits am 4.11.. Wenn du bereits einen Tag vorher eine Mail bekommen hast, dann sollte dir klar sein das man zumindest Verwundert ist.
Und die Vorwürfe sind nicht lächerlich, sondern ein Großflächigerangriff auf die Software, und ja, selbst redent ist da natürlich der Softwerhersteller in der Verantwortung.
Bei einer Sicherheitslücke mit so epischemausmaß sollte auch jegliche Newslettereinstellung egal sein und eine Mail an alle raus gehen!

 

[microline]

Bei mir startete der (erfolglose) Angriff bereits am 29.10.

 

[Einrad-Shop]

Sind die Passwörter wirklich unsicher? Man hat doch einen Hash und keinen Klartext durch Blowfish-Entschlüsselung.

Wenn die Passwörter ausgelesen wurden ja, denn im eigenen System kann der Angreifer mit der vollen Rechenpower den Hashknacken, sicher ist da dann nichts mehr. wenn du dann noch von schlechter Passwortqualität bei den Kunden ausgehst, dann muß man die selbst redent sofort ändern
Außerdem sieht der Backdoor so aus, wie wenn da auf deinem Systhem schon versucht wurde die Passwörter zu entschlüsseln. Mit Erfolg oder nicht, weis man nicht.

 

[Einrad-Shop]

Kann das Bitte jemand mit SQL Kenntnisen prüfen, ob das so duchläuft?
-----------------------------------------------------------------------------------------------------------------
DECLARE @char CHAR = ''
DECLARE @charI INT = 0
DECLARE @password VARCHAR(100) = ''
DECLARE @len INT = 12 -- Length of Password
WHILE @len > 0
BEGIN
SET @charI = ROUND(RAND()*100,0)
SET @char = CHAR(@charI)

IF @charI > 48 AND @charI < 122
BEGIN
SET @password += @char
SET @len = @len - 1
END
END
Declare @HashPassword = Convert (Varchar(254), HashBytes('MD5',
@password),2)

Insert into tkunde (cPasswort) value (@HashPassword) where cPasswort NOT
NULL

 

[Einrad-Shop]

Gibt es auch Infos zu den Veränderungen in den Zahlungsmodulen? Von dem wird nicht mal in der Infomail gesprochen. Ist da bei jemandem Geldraus getragen worden? Bei mir sahs aus wie wenn die Paypal Umleitung nicht funktioniert hat.

 

[301Moved]

Von den Zahlungsmodulen war aber auch noch nichts zu hören, oder? Vielleicht kann da ja mal jmd aufklären...

Wäre vielleicht auch spannend, wenn der Punkt aus der heutigen Mail mit den Shell Befehlen etwas annähernder erläutert würde.

 

[LSG]

Moin, ich hatte am 4.11. am frühen Nachmittag ein Upgrade auf den 5-er Shop durchgeführt. Muss ich nun auch aktiv werden und die vorherigen logs prüfen?

 

[sebjo82]

Moin, ich hatte am 4.11. am frühen Nachmittag ein Upgrade auf den 5-er Shop durchgeführt. Muss ich nun auch aktiv werden und die vorherigen logs prüfen?

Ja, die Lücke existiert seit Anfang an, d.h. im Idealfall den kompletten access. log prüfen

 

[FPrüfer]

Guten Morgen,
ich kann mich erstmal nur für die vielen Unannehmlichkeiten entschuldigen. Aber der Angriff wurde ziemlich massiv geführt, wahr offensichtlich gut vorbereitet und der Angreifer hatte gute Kenntnisse von JTL- Shop. Wir versuchen alle Infos so transparent wie möglich mit euch zu teilen. Deshalb auch gestern nochmal die zusätzliche E-Mail, die in erster Linie als Information für euren Serverbetreiber gedacht ist. Die analysierten Backdoors enthielten einen Teil mit ziemlich offensichtlichem PHP-Code über dessen mögliche Auswirkungen wir bereits am 4. und 5.11. informiert haben. Zudem gab es einen Bereich mit obfuskiertem Code, der nicht auf den ersten Blick lesbar ist. Nach Analyse dieses Teils ist es mit diesem Backdoor-Script möglich auch Shell-Befehle direkt auf dem betroffenen Server im Rechte-Bereich des Webservers auszuführen. Ob dieser Teil der Backdoor ausgenutzt wurde können wir aktuell nicht sagen, da die Befehle mittels POST-Request übertragen werden konnten und sowas nicht in den normalen Server-Logs auftaucht.
Deshalb die vorsorgliche Information für euren Webmaster / Provider / Hoster, dass der Server kompromitiert sein könnte, wenn auf eurem Shop die Lücke ausgenutzt, das Backdoor-Script hochgeladen und ausgeführt wurde. Habt ihr solche Aufrufe /bilder/banner/xyz.php (xyz kann ein beliebiger Name sein) die nicht den StatusCode 400 oder 403 haben in euren Log-Files, dann wurde das Script erfolgreich ausgeführt. Mit welchem Code wissen wir aktuell noch nicht.
Da unser eigenes Hosting betroffen ist (die betroffenen Kunden dort kontaktieren wir direkt), sind wir mit Hochdruck dabei zu analysieren ob auf den Systemen weitere Änderungen stattgefunden haben. Über das Ergebnis der Analyse werden wir informieren.
Der Handlungsbedarf der gestrigen E-Mail besteht also in erster Linie in der Information eures Webmaster, Provider und / oder Hosters.

Kann das Bitte jemand mit SQL Kenntnisen prüfen, ob das so duchläuft?

Das SQL sieht auf einen schnellen, ersten Blick nicht erfolgversprechend aus. Ich werde zeitnah eine Lösung probieren und zur Verfügung stellen, mit denen man Kunden-Passwörter einfach invalidieren kann.

 

[Farbtoner]

Bei uns in der access log ist tadminlogin nicht zu finden, /bilder/banner ebenfalls nicht. Die .htaccess Datei liegt auch im Bilderverzeichnis und in /bilder/banner liegt auch keine Datei. Ich gehe dann davon aus, dass wir nicht betroffen sind. Den Fix habe ich natürlich sofort umgesetzt.

 

[FPrüfer]

Zum Thema Passwörter
Passwörter werden in JTL- Shop mit einem starken Algorithmus gehashed. Nach aktuellem Stand der Technik lassen sich diese nicht "entschlüsseln" und es kann auch nicht von gleichen Hashes auf gleiche Passwörter geschlossen werden. Durch s.g. Brute-Force-Verfahren oder durch Verwendung von Passwortlisten ist es - entsprechende Rechenpower vorausgesetzt - jedoch möglich, einzelne Passwörter durch "einfaches" ausprobieren zu knacken. Passwörter wie "geheim123" o.ä. lassen sich damit relativ schnell finden. Ein Passwort aus mindestens 8 Zeichen mit Buchstaben, Zahlen und Sonderzeichen wohl eher nicht. Je nach Komplexität der Passwörter eurer Kunden ist es also im Bereich des Möglichen, dass zumindest einige Passwörter geknackt werden. Aus diesem Grund werde ich niemandem abraten die Passwörter seiner Kunden zurückzusetzen oder diese zumindest darüber zu informieren, dass sie es selber tun sollten. Ich bin aber nur Techniker und kann und darf hier keine Rechtsberatung leisten, kann also nicht über das MUSS urteilen. Das muss bitte jeder mit seinem DSB klären!

Wie mache ich Passwörter ungültig
Wer die Passwörter seiner Kunden einfach ungültig machen möchte, kann folgendes SQL-Statement direkt auf der Datenbank ausführen:

UPDATE tkunde
SET cPasswort = 'xxx***xxx'
WHERE (cPasswort IS NOT NULL AND cPasswort != '') OR nRegistriert = 1;

Das 'xxx***xxx' ist ein absolut ungültiger Password-Hash, der zu KEINEM Passwort passt. Damit ist ein Login in den Kunden-Account nicht mehr möglich. Eure Kunden müssen sich dann mittels der "Passwort vergessen"-Funktion ein neues Passwort für ihren Account erstellen.
Anmerkung (keine Rechtsberatung!): Bei der Information über das Zurücksetzen des Passwortes sollte der Kunde darauf hingewiesen werden, dies auch bei allen anderen Diensten zu tun, bei denen er dasselbe Passwort verwendet.

 

[sah]

Gibt es eine Aussage zur SOFORT Überweisung oder BillPay?
Sind DB-Spalten mit ENABLE KEYS sicher?

 

[holzpuppe]

Hallo Gemeinde.
So, da hamwa nun den Salat. Aber, eigentlich ist so etwas immer nur eine Frage der Zeit. Kein System ist sicher.
Also, wir sind ebenfalls von dem Angriff betroffen.
Bei uns liegt der Angriff aber etwas länger zurück. Am 25.10. und am 26.10. wurde ein Angriff gestartet, der aber nicht erfolgreich war. Unsere DB ging in die Knie und der Shop war nicht mehr erreichbar.
Selbst unser Provider konnte erstmal keinen Angriff erkennen und man hat die DB wieder neu gestartet.
Nach den Logauswertungen konnten wir dann aber für den 28.10. und dem 29.10. einen erfolgreichen Angriff feststellen. Also "Scheiße". xD

Was ich damit schreiben möchte, alle die jetzt nur die Logs vom 4.11. aufwärts überprüft haben, sollten mal wenigstens bis zum 25.10. zurück gehen!
Oder besser noch den gesamten Monat. Ich denke nicht, dass ausgerechnet wir die Ersten waren die daran glauben mussten. Wäre zwar eine gewisse Ehre, aber nee, da sind bestimmt andere schneller im Fokus.
Nur weil JTL erst am 4.11. eine Rundmail schickt, heißt es nicht, dass bis dahin definitiv keine erfolgreichen Angriffe statt fanden.
An dieser Stelle würde mich aber interessieren: Ist der Angriff immer über die gleiche IP erfolgt, oder gibt es Verschiedene?

---------------------------------------------------------
Wer jetzt nicht in der Lage ist mehrere Logs in einem Rutsch zu prüfen, kann mich gerne per PM kontaktieren.
Es gibt eine Lösung die zumindest dem Laien schnell eine Übersicht bringt. Ich bin auch erst darüber fündig geworden.
---------------------------------------------------------
Dazu hätte ich aber auch noch allgemein eine Frage in die Gemeinde:
Mit welchem Tool kann man zuverlässig Logs auswerten. (AwStats und Webalizer bringt hier echt nichts.)
Wenn möglich auch auf einem Webspace laufend, oder Windowsoberfläche.
Am Ende des Tages habe ich Logs in der Excel verarbeitet, ist aber auch Mist und hat eine gewisse Fehlerquote.

Grüße
holzpuppe

 

[mischael134]

Man kann die Logs lokal mit Notepad++ prüfen (das hier https://notepad-plus-plus.org/, nicht das Windows-Standard-Notepad).
Also die Access-logs runterladen und in einem Verzeichnis ablegen.
Notepad++ starten und "suche in Dateien" auswählen (Strg-F , den richtigen Reiter auswählen)
Das Verzeichnis welches man durchsuchen will auswählen und dann die Suchbegriffe suchen.
Funktioniert auch bei großen Datenmengen ziemlich gut.