FYI SQL-Injection in JTL 4.06.17

Shopsysteme - Online Shop erstellen - Jimdo Shopify Shopware Gambio Magento etc
Antworten
JohnGalt
Beiträge: 1043
Registriert: 18. Feb 2013 23:19

FYI SQL-Injection in JTL 4.06.17

Hallo,

wer JTL benutzt und es vielleicht überlesen hat, aber in JTL 4.06.17 gab es eine neuentdeckte Sicherheitslücke die umgehend gepatcht werden sollte.
Jeder Kunde sollte eine E-Mail mit dem Download-Link bekommen haben.

Strategisch wurde die Nachricht heute schön spät gegen 17:30 verschickt, damit auch ja noch am Abend die richtigen Leute[tm] bescheid wissen. Die, die eher zu "Randzeiten" tätig werden ...


3 Monate gratis Händlerbund
Benutzeravatar
webtechnixx
PLUS-Mitglied
PLUS-Mitglied
Beiträge: 232
Registriert: 17. Feb 2009 16:28
Land: Deutschland
Firmenname: engelbrecht UG (hb)
Wohnort: Worms
Kontaktdaten:

Re: FYI SQL-Injection in JTL 4.06.17

Ja, der Zeitpunkt der eMail war etwas unglücklich ... Bei mir glüht jetzt seit 6 Uhr der FTP-Client um eine lange Liste von Shops zu patchen ...
Benutzeravatar
fossi
webmaster@sellerforum.de
webmaster@sellerforum.de
Beiträge: 28015
Registriert: 5. Okt 2007 11:53
Land: Deutschland
Firmenname: Sellerforum / Eifel Luftballons / Albatros Int.

Re: FYI SQL-Injection in JTL 4.06.17

Achtung bei der Mail: genau lesen!

Die Patchdatei ist nur für den 4.06.17 .
Ich habe z. b. noch einen älteren 4.05 für die PLUS-Mitgliedschaften laufen und da muss man manuell ran und einen Code-Fetzen ersetzen.
(...oder auf eine neuere Version updaten...) :kaffeesmily
---
Unterstütze das Sellerforum mit einer Supporter-Mitgliedschaft. Danke! :winken:
Benutzeravatar
arnego2
Beiträge: 477
Registriert: 6. Apr 2021 13:19
Land: Deutschland
Firmenname: Arnego2 LtD
Branche: Web & SEM
Kontaktdaten:

Re: FYI SQL-Injection in JTL 4.06.17

Den Server beobachten und reagieren ist notwendig um die Jungs von ihrem Handeln abzubringen. Mit einfachen Geo Blocks bekommt man viele zum schweigen. In einem vbulltin Forum konnte ich zusehen wir ein Inder experimentiert hatte.
Benutzeravatar
fossi
webmaster@sellerforum.de
webmaster@sellerforum.de
Beiträge: 28015
Registriert: 5. Okt 2007 11:53
Land: Deutschland
Firmenname: Sellerforum / Eifel Luftballons / Albatros Int.

Re: FYI SQL-Injection in JTL 4.06.17

Heute gegen 15:30 Uhr gab es wieder eine Mail dazu, mit "dringendem Handlungsbedarf".
In der neuen Mail gibts heine Anleitung um heraus zu finden, ob man bereits gehackt und eine Backdoor zum Abgreifen von Daten installiert wurde, sowie eine Auflistung diverser Hostinganbieter, welche sich mehr oder weniger um das Problem kümmern, oder auch nicht.

Meine Logdateien sind zum Glück clean und die Angelegenheit somit erledigt. :kaffeesmily
---
Unterstütze das Sellerforum mit einer Supporter-Mitgliedschaft. Danke! :winken:
Benutzeravatar
webtechnixx
PLUS-Mitglied
PLUS-Mitglied
Beiträge: 232
Registriert: 17. Feb 2009 16:28
Land: Deutschland
Firmenname: engelbrecht UG (hb)
Wohnort: Worms
Kontaktdaten:

Re: FYI SQL-Injection in JTL 4.06.17

Ja, ich hatte bisher auch glück bei knapp 2 Dutzend Shops, ein paar muss ich noch prüfen, gepatcht habe ich alle schon.
Benutzeravatar
aaha
PLUS-Mitglied
PLUS-Mitglied
Beiträge: 1386
Registriert: 9. Mär 2012 14:29

Re: FYI SQL-Injection in JTL 4.06.17

fossi hat geschrieben: 5. Nov 2021 16:24 Meine Logdateien sind zum Glück clean und die Angelegenheit somit erledigt. :kaffeesmily
Versucht wurde es anscheinend bei so ziemlich allen JTL-Shops auf breiter Front, also auf jeden Fall seeeehr vielen. Bei den meisten wohl jedoch erfolglos. Es ist auch bekannt, wo die "Abschussrampe" stand. Bei meinem Hoster (und ihm bekannten selbigen) wurde die entsprechende IP wohl enttarnt und somit entwaffnet.
Benutzeravatar
Xantiva
PLUS-Mitglied
PLUS-Mitglied
Beiträge: 4047
Registriert: 22. Okt 2010 17:52
Land: Deutschland
Firmenname: Xantiva.de
Branche: Entwickler, aber auch selber Seller!
Kontaktdaten:

Re: FYI SQL-Injection in JTL 4.06.17

Ich habe den Shop gestern direkt gepatcht. Im Log war aber schon der beschriebe "Test" Eintrag. Heute dann der Angriffsversuch, der somit glücklicherweise ins Leere lief.
aaha hat geschrieben: 5. Nov 2021 18:40Bei meinem Hoster (und ihm bekannten selbigen) wurde die entsprechende IP wohl enttarnt und somit entwaffnet.
Nur dass die Zugriffe von ganz unterschiedlichen IPs kamen. Der Test kam aus Russland (45.130. ..) , der Angriffsversuch aus Rumänien (193.29. ..). Die "Test-IP" hatte ich gestern auch schon über die Firewall gesperrt, aber hätte mir bei dem Angriff auch nicht geholfen.

Ich fürchte es wird den ein oder anderen Shop geben, der vielleicht nicht schnell genug reagiert hat. :(
webstar
PLUS-Mitglied
PLUS-Mitglied
Beiträge: 384
Registriert: 11. Jul 2009 08:49
Land: Deutschland

Re: FYI SQL-Injection in JTL 4.06.17

Laut einem Servicepartner waren die Angriffe wohl viel erfolgreicher als zuerst gedacht und laufen schon länger. Es gibt wohl ein eindeutiges Erkennungszeichen , welches ich hier aber nicht öffentlich machen möchte.
Bei uns war in den Logs letzte Woche nichts zu sehen, da diese aber nur 3 Tage zurückreichen, können wir leider einen Hack nicht ausschließen.
boden-piloten
Beiträge: 1836
Registriert: 24. Okt 2011 15:39

Re: FYI SQL-Injection in JTL 4.06.17

Setzt Mediamarkt Saturn auf JTL? Die sind haben auch größeres it Problem
Benutzeravatar
fossi
webmaster@sellerforum.de
webmaster@sellerforum.de
Beiträge: 28015
Registriert: 5. Okt 2007 11:53
Land: Deutschland
Firmenname: Sellerforum / Eifel Luftballons / Albatros Int.

Re: FYI SQL-Injection in JTL 4.06.17

@boden: MediaMarktSaturn nutzt diverses SAP-Zeugs und hostet via Google Cloud.
Da hat JTL eher nichts mit zu tun. :)
---
Unterstütze das Sellerforum mit einer Supporter-Mitgliedschaft. Danke! :winken:
JohnGalt
Beiträge: 1043
Registriert: 18. Feb 2013 23:19

Re: FYI SQL-Injection in JTL 4.06.17

webstar hat geschrieben: 8. Nov 2021 14:40 Laut einem Servicepartner waren die Angriffe wohl viel erfolgreicher als zuerst gedacht und laufen schon länger. Es gibt wohl ein eindeutiges Erkennungszeichen , welches ich hier aber nicht öffentlich machen möchte.
Ich finde das Handling von JTL hier eher sehr schlecht. Schlecht gewählter Zeitpunkt, Empfängerkreis eingeschränkt durch Newsletterabmeldungen, keine weiteren Details, kein öffentlicher Fix. Als ob die letzten 30 Jahre an denen komplett vorbei gegangen sind.
webstar hat geschrieben: 8. Nov 2021 14:40 Bei uns war in den Logs letzte Woche nichts zu sehen, da diese aber nur 3 Tage zurückreichen, können wir leider einen Hack nicht ausschließen.
Puh, ihr habt keine intrusion detection? Wie stellt ihr DSGVO-Konformität etc. sicher wenn ihr nicht wisst, was los ist? 3 Tage ist reichlich knapp.
Benutzeravatar
fossi
webmaster@sellerforum.de
webmaster@sellerforum.de
Beiträge: 28015
Registriert: 5. Okt 2007 11:53
Land: Deutschland
Firmenname: Sellerforum / Eifel Luftballons / Albatros Int.

Re: FYI SQL-Injection in JTL 4.06.17

Heute kam noch eine Mail zum Thema hinterher.

JTL Software GmbH hat geschrieben: Wichtige Erkenntnisse zur Sicherheitslücke in JTL-Shop 4

Sehr geehrter ...,
wir streben eine transparente Kommunikation bzgl. der Sicherheitslücke in JTL-Shop 4 an. Der JTL-Shop 5 ist nicht betroffen.

Nach internen Untersuchungen der Angriffe, die diese Sicherheitslücke bislang ausgenutzt haben, möchten wir unsere Erkennnisse mit Ihnen teilen. Teilen Sie bitte diese Informationen mit Ihrem Server-Administrator.

Alle von uns registrierten Angriffe liefen automatisiert und innerhalb von Sekunden ab:
Durch diese Lücke war es dem Angreifer möglich, eine Backdoor zu schaffen, indem eine PHP Datei hochgeladen wurde, die beliebigen Code auf dem Server ausführen konnte. Dadurch konnte die Tabelle tkunde, die Kundendaten enthält, sowie tadminlogin, die Adminbenutzerdaten enthält, ausgelesen und zum Angreifer übertragen werden. Dieser Angriff war jedoch nur unter bestimmten Voraussetzungen erfolgreich.

Zusätzlich hat diese Backdoor die Möglichkeit geschaffen, Shell-Befehle mit den Rechten des Webservers auszuführen, sofern der Server die Ausführung von dem PHP-Befehl 'system()' zuließ. Wir konnten bislang keine Hinweise auf die Ausnutzung dieser Möglichkeit finden. Wenn Sie Opfer eines Angriffs wurden und Sie die Lücke mit Hilfe unserer Anleitung bereits geschlossen haben, kann es potentiell möglich sein, dass zwar Ihr Shop sicher, aber der Server kompromittiert ist. Melden Sie das in dem Fall Ihrem Server-Administrator.

Beachten Sie bitte, dass auch andere Angriffsszenarien möglich wären. Wir haben keine Erkenntnisse über andere Angriffsszenarien.

Sollten Sie oder Ihr Hoster die Sicherheitslücke noch nicht in Ihrem Shop geschlossen haben, holen Sie das bitte dringend nach: https://www.jtl-software.de/hotfix-sicherheitsluecke

Mit freundlichen Grüßen
Ihr Team der JTL-Software-GmbH
---
Unterstütze das Sellerforum mit einer Supporter-Mitgliedschaft. Danke! :winken:
webstar
PLUS-Mitglied
PLUS-Mitglied
Beiträge: 384
Registriert: 11. Jul 2009 08:49
Land: Deutschland

Re: FYI SQL-Injection in JTL 4.06.17

Da es JTL mittlweile selbst gepostet hat, hier die Möglichkeit zu erkennen, ob ein Angriff stattgefunden hat (Zitat aus dem JTL-Forum):

Code: Alles auswählen

SELECT `AUTO_INCREMENT`
FROM  INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = '<Name-der-Datenbank>'
    AND TABLE_NAME = 'tadminlogin';
"Wenn man bisher nicht mehr 39 Admin-Logins angelegt hat, kann man damit einen ersten schnellen Test machen, ob der Shop angegriffen und ein Admin-Account angelegt wurde. Ist das Ergebnis der o.g. Abfrage 41 ist es sehr wahrscheinlich, dass die Lücke in diesem Shop ausgenutzt wurde. Ein Wert <> 41 bedeutet jedoch nicht zwangsläufig Entwarnung!"
webstar
PLUS-Mitglied
PLUS-Mitglied
Beiträge: 384
Registriert: 11. Jul 2009 08:49
Land: Deutschland

Re: FYI SQL-Injection in JTL 4.06.17

Nach meinen bisherigen Informationen zielte der Angriff auch auf das Wawi-Sync-Passwort und das SMTP-Mail-Passwort ab.
Es kann also gut sein, das die Angreifer noch was damit vorhaben. Jedem Betroffenem sei geraten beide Passwörter zu ändern.
JohnGalt
Beiträge: 1043
Registriert: 18. Feb 2013 23:19

Re: FYI SQL-Injection in JTL 4.06.17

webstar hat geschrieben: 11. Nov 2021 12:55
Ein Wert <> 41 bedeutet jedoch nicht zwangsläufig Entwarnung!"
Das ist ja mal eine tolle Hilfestellung. Vielleicht bedeutet es etwas, vielleicht nicht. Also in etwa Zen-Security. Man ist sich halt nicht sicher.
Mein Vorschlag wäre ja: Man nehme sich ein älteres Backup, verifiziere, dass all die Accounts rechtmäßig und gewollt angelegt wurden und dann vergleiche man dieses mit dem aktuellen Stand.

Und wenn man sich nicht sicher ist ob man alle Accounts so angelegt hat, muss man halt alle Accounts und alle Passwörter im System(!) resetten. Und natürlich sollte man aus den offiziellen Quellen neu installieren, da man sicher auch nicht weiß, ob etwas zum System hinzugekommen ist, was man gar nicht wollte (z.B. eine Webshell).
Verhindern kann man sowas mit z.B. AIDE (https://aide.github.io/) mit dem man direkt nach einem clean install (also aus dem Original vom Lieferanten) aufsetzt und das System nach geänderten Dateien monitoren lässt.

Ansonsten: Regelmäßige Backups off site der Datenbasis und ein Konzept wie man einen Shop "clean" automatisiert neu aufgesetzt bekommt (z.B. in Form eines Docker Images, das man einmal richtig baut und dann immer wieder benutzen kann). Dann tut restore auch viel weniger weh.
Benutzeravatar
Xantiva
PLUS-Mitglied
PLUS-Mitglied
Beiträge: 4047
Registriert: 22. Okt 2010 17:52
Land: Deutschland
Firmenname: Xantiva.de
Branche: Entwickler, aber auch selber Seller!
Kontaktdaten:

Re: FYI SQL-Injection in JTL 4.06.17

JohnGalt hat geschrieben: 11. Nov 2021 19:02Mein Vorschlag wäre ja: Man nehme sich ein älteres Backup, verifiziere, dass all die Accounts rechtmäßig und gewollt angelegt wurden und dann vergleiche man dieses mit dem aktuellen Stand.
Das setzt voraus, dass die missbräuchlichen Accounts nach dem Angriff nicht gelöscht worden wären, oder?

Die Angriffe sahen so aus, dass ein neues Konto angelegt, Backdoor installiert und später das Konto wieder gelöscht wurde. Um eben unerkannt zu bleiben.
JohnGalt
Beiträge: 1043
Registriert: 18. Feb 2013 23:19

Re: FYI SQL-Injection in JTL 4.06.17

Xantiva hat geschrieben: 11. Nov 2021 22:27 Das setzt voraus, dass die missbräuchlichen Accounts nach dem Angriff nicht gelöscht worden wären, oder?
Die Angriffe sahen so aus, dass ein neues Konto angelegt, Backdoor installiert und später das Konto wieder gelöscht wurde. Um eben unerkannt zu bleiben.
Vorneweg: Das gilt hier erstmal nur für MySQL / MariaDB, was ja aber von JTL genutzt wird.

Nein, die Auto-Increment-ID wird immer hochgesetzt und bleibt wie eine Wasserstandsmarke auf ihrem höchsten Wert hängen, auch wenn einzelne Tabellenreihen gelöscht werden(*). Das ist ja was der Schnipsel von JTL versucht: Der guckt nach AUTO_INCREMENT, was genau diese ID ist. Doch: Das ist halt nur die halbe Miete, wie JTL selbst schreiben, weil es ja durchaus Fälle geben kann, in denen ein User mit guter, eigener Absicht gelöscht wurde. Deshalb muss man versuchen, sich aus alten Backups den Stand zusammen zu klauben und dann nachvollziehen zu können, wann eine neue AUTO_INCREMENT ID generiert wurde.

(*) Könnte ein Angreifer die AUTO_INCREMENT ID zurücksetzen? Theoretisch geht das, aber dazu wird die Tabelle einmal temporär neu angelegt und umkopiert, die alte dann gelöscht. Würde aus der Hüfte vermuten, dass das eher nicht gemacht wird, wenn man eh keine persistente Zugriffsmöglichkeit will.

Was könnte man tun:
- Einen Datenbank-Trigger anlegen (das sind so kleine Programme, die an der Datenbank "kleben" und irgendwas tun, wenn eine Bedingung zutrifft), der überwacht, ob in der Tabelle rumgeschrieben wird. Zum Beispiel könnte der einen Log schreiben (der wiederum periodisch oder bei Änderung per E-Mail geschickt wird).
- Ansonsten hat man am besten ein Monitoring für - als Online-Händler - die geldbringende Kerninfrastruktur und da könnte sowas natürlich auch direkt einen Alarm geben (Monitoring guckt periodisch auf die Menge an Einträgen in der Tabelle: Ändert sich die Zahl, gibt es einen Incident der von einem Menschen geprüft werden muss)
- Die User-Datenbank, wenn man da nicht regelmäßig drin rumschreiben muss, read only mounten und dann kann ein Angreifer mal versuchen einen User anzulegen.
- Keine MySQL-User für den regulären Betrieb nutzen, der überhaupt in diese Tabelle schreiben darf.
Antworten

Zurück zu „Shopsysteme“

  • Information