Ok, das erklärt es natürlich. Allerdings wäre ein bisschen mehr Transparenz schön gewesen. Mir was das nicht ersichtlich. Die Hinweise im entsprechenden Release Post zu einem Sicherheitsfix beziehen sich ja wohl auf ein anderes Problem. Mann kann doch nicht so mir nichts dir nichts Dateien ohne Hinweis austauschen.
Neu E-Mail / WICHTIG: Sicherheitslücke in JTL-Shop 4 - Dringender Handlungsbedarf
- Ersteller des Themas maestro
- Erstellungsdatum
Hinweis: bilder/.htaccess wurde irgendwie gelöscht, damit das Hacker-Skript dort ausgeführt werden konnte.
Zwischen anlegen und löschen sind bei uns 27 Sekunden vergangen, leider genug Zeit.
Jo. Nur kein Aufruf der Seite in den zwei Sekunden dazwischen. Wie geschrieben habe ich alle Dateien im Shop geprüft ( automatisches neu aufsetzen und diff) und den Datenbank dump überprüft.
D.h.
301 unproblematisch?
HTTP/1.1" 301 250 "-"
HTTP/1.1" 301 251 "-"
403 unproblematisch
HTTP/1.1" 403 1008 "-"
200 mit 0 unproblematisch
HTTP/1.1" 200 0 "-"
HTTP/1.1" 200 0 "-"
HTTP/1.1" 200 0 "-"
404 unproblematisch
HTTP/1.1" 404 5260 "
HTTP/1.1" 404 5258 "-"
HTTP/1.1" 404 5258 "
!!!!!
200 !hier wurde abgegriffen, oder?
HTTP/1.1" 200 387 "-"
HTTP/1.1" 200 23497 "-"
301 unproblematisch?
HTTP/1.1" 301 250 "-"
HTTP/1.1" 301 251 "-"
403 unproblematisch
HTTP/1.1" 403 1008 "-"
200 mit 0 unproblematisch
HTTP/1.1" 200 0 "-"
HTTP/1.1" 200 0 "-"
HTTP/1.1" 200 0 "-"
404 unproblematisch
HTTP/1.1" 404 5260 "
HTTP/1.1" 404 5258 "-"
HTTP/1.1" 404 5258 "
!!!!!
200 !hier wurde abgegriffen, oder?
HTTP/1.1" 200 387 "-"
HTTP/1.1" 200 23497 "-"
Wenn Tkunden 41,4 KiB in der DB hat, könnten das dann alle sein? entspricht 251 Zeilen
Kann man sicher sein, dass der Schlüssel für Passwort, Nachname, Firma und Straße nicht abgefragt werden konnte?
Hat übrigens jemand festgestellt, dass sein MySQL-Passwort geändert wurde?!
Ein paar Punkte stoßen mir gerade sehr negativ hier auf:
A. Laut bereitgestelltem Updatefile war der Patch bereits um 13:15 fertig. Die Kommunikation erfolgte erst nach Feierabend um 17:30.
B. Es ist mittlerweile klar, dass die Angriffe bereits Donnerstagvormittag liefen, in dem Newsletter vom Donnerstagabend will JTL davon noch nichts gewusst haben.
C. Spätestens seit dem Wochenende weiß JTL nachweislich, dass es diese Angriffe gibt und welche Merkmale für einen erfolgreichen Angriff mit meldepflichtigem Datenabfluss vorhanden sind: PHP-Dateien im bilder/banner-Ordner, access.log-Einträge mit insert in die tadminlogin.
Die Daten in der Datenbank an sich sind zwar verschlüsselt, bei dem Angriff wird der Schlüssel für die Entschlüsselung aber mitkopiert.
Mit fehlt ein aktualisierter Newsletter mit den wichtigsten neuen Informationen:
Jeder JTL Shop 4 Betreiber muss seine Logfiles prüfen (lassen) und bei Einträgen die den Merkmalen aus C entsprechen unverzüglich eine Meldung gem. Artikel 33 DSGVO durchführen und den Shop entweder von möglichen Backdoors bereinigen oder neu aufsetzen.
Auf diese Pflicht muss meiner Meinung nach JTL die Shopbetreiber noch einmal explizit hinweisen.
Die Lücke ist nicht schön und wir alle würden die negative Presse gerne vermeiden, aber damit muss nun verantwortungsvoll umgegangen werden.
Nur den Patch einspielen reicht leider nicht aus.
A. Laut bereitgestelltem Updatefile war der Patch bereits um 13:15 fertig. Die Kommunikation erfolgte erst nach Feierabend um 17:30.
B. Es ist mittlerweile klar, dass die Angriffe bereits Donnerstagvormittag liefen, in dem Newsletter vom Donnerstagabend will JTL davon noch nichts gewusst haben.
C. Spätestens seit dem Wochenende weiß JTL nachweislich, dass es diese Angriffe gibt und welche Merkmale für einen erfolgreichen Angriff mit meldepflichtigem Datenabfluss vorhanden sind: PHP-Dateien im bilder/banner-Ordner, access.log-Einträge mit insert in die tadminlogin.
Die Daten in der Datenbank an sich sind zwar verschlüsselt, bei dem Angriff wird der Schlüssel für die Entschlüsselung aber mitkopiert.
Mit fehlt ein aktualisierter Newsletter mit den wichtigsten neuen Informationen:
Jeder JTL Shop 4 Betreiber muss seine Logfiles prüfen (lassen) und bei Einträgen die den Merkmalen aus C entsprechen unverzüglich eine Meldung gem. Artikel 33 DSGVO durchführen und den Shop entweder von möglichen Backdoors bereinigen oder neu aufsetzen.
Auf diese Pflicht muss meiner Meinung nach JTL die Shopbetreiber noch einmal explizit hinweisen.
Die Lücke ist nicht schön und wir alle würden die negative Presse gerne vermeiden, aber damit muss nun verantwortungsvoll umgegangen werden.
Nur den Patch einspielen reicht leider nicht aus.
Nein kann man leider nicht. Wie ein Moderator hier schon geschrieben hat:
Der Angreifer konnte ggf. über ein Backdoorscript u.U die config.JTL- Shop.ini.php auslesen und im Besitz des BlowfishKey und kann die Kundendaten entschlüsseln.
Es soll nicht möglich sein das Passwort zu enschlüsseln, da nur ein Hashwert gespeichert wird.
Kommt von einem Moderator hier, nicht von mir.
Ich werde es über die WAWI machen.
Wahrscheinlich so:
1) Vorlage erstellen
2) maximale Nachrichten pro Stunde in der Konfiguration des E-Mail Accounts hochsetzen
3) Temporären Filter auf Shop setzen
4) mehrere Kunden (ca. 50 gleichzeitig) markieren
5) Nachricht an Kunden senden
6) Vorlage auswählen
7) Eigene E-Mail in CC - eingeben (zu Beweiszwecken)
8) versenden
Bin aber noch am überlegen
NACHTRAG:
Kunden ohne Anmeldung im SHOP irgendwie rausfiltern (haben ohne Anmeldung bestellt)
Zuletzt bearbeitet:
Wenn ihr eure Kunden informiert, achtet unbedingt darauf, dass nicht alle in einer Mail im An- oder CC-Feld stehen, das wäre die nächste Datenschutzpanne. Nutzt dafür das BCC-Feld.
Prüft auch den Empfängerkreis. Es sind wohl nur die Kunden betroffen, die über euren Shop bestellt haben. Ebay/Amazon/...-Kunden müsst ihr vermutlich nicht informieren.
Als Datenquelle daher am besten die Adressen aus dem JTL-Shop nutzen:
SELECT cMail FROM tkunde
ja, das stimmt. Keine Kunden E-Mailadressen in CC.
Ich würde das CC Feld immer mit meiner eigenen E-Mail versehen um irgendwie beweisen zu können, dass die Mails rausgegangen sind.
Klingt schon gut, nur sollte man sicher sein, dass der Mail-Provider wegen Massenmails nicht dicht macht.
Könnte JTL nicht eine "offizielle" Lösung anbieten..?
Das wäre natürlich das Beste. Ich bin aber schon am schauen, da ich es zeitnah durchführen möchte.
Bin direkt bei JTL und habe bisher nur eine Begrenzung von 500 Mail in einer Stunde gefunden.
Eine Vorlage von JTL was man dem Kunden genau schreiben soll, wäre auch nicht schlecht.
Hat jemand schon eine Idee was in die Mail genau rein soll?
Der Hinweis von JTL "Alles weitere sollten Sie erstmal mit ihrem Datenschutzbeauftragten besprechen." hilft leider nicht viel bei kleinen Shops (Einzelunternehmungen) die so einen Beauftragten gar nicht haben 🙁
Was meint Ihr mit Shop neu Aufsetzen?
Nur die php dateien löschen und neuhochladen?
In der DB und vorallem den Zahlungsmodulen wurden ja auch sachen geändert, das liegt ja alles in der DB?
Bin hier echt überfordet
Ich habe auch keine Lust jetzt eine E-Mail an die Kunden rauszusenden mit dem Hinweis, dass die Sicherheitslücke durch den Patch geschlossen wurde und dann am nächsten Tag irgendeine Überraschung zu erleben...