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

[Fabrice]

Naja also bei mir wurde versucht etwas in die Datenbank zu schreiben und danach wieder zu löschen. Entwarnung würde ich das nicht nennen

 

[bebob]

Und woran erkenne ich, ob das versucht wurde?

 

[Fabrice]

Such ob weitere SQL Injection Versuche unternommen wurden. Access. log nach insert delete update select durchsuchen.

 

[bebob]

Danke Fabrice,

Insert nur bei Dropper einträgen
delete - keine
Update nur im Zusammenhang mit Amazon Pay einträgen
Select in Verbindung mit Dropper, Amazon pay, template bootstrap css

Das alles auch nie als Befehl hinter dem Zeitstempel (Also da, wo "Get und "Post steht), sondern in den URL´s dahiner oder so.

Sieht für mich unkritisch aus. Aber was weiß ich schon....

Drück dir die Daumen, dass nichts schlimmeres passiert ist.

Gruß
BeBoB

 

[Fabrice]

Hi
Also grad den Shop geprüft. Es wurden keine Dateien verändert und die Datenbank enthält keine auffälligen Strings im Dump. Es wurde versucht ein Nutzer anzulegen und direkt zu löschen sonst nichts. Keine Weiteren Aufrufe in der Zwischenzeit. Ich würde fast behaupten der Shop ist sauber.

Grüße
Fabrice

 

[TheOggy]

Hi
Also grad den Shop geprüft. Es wurden keine Dateien verändert und die Datenbank enthält keine auffälligen Strings im Dump. Es wurde versucht ein Nutzer anzulegen und direkt zu löschen sonst nichts. Keine Weiteren Aufrufe in der Zwischenzeit. Ich würde fast behaupten der Shop ist sauber.

Grüße
Fabrice

Bei uns das selbe

 

[JulianG]

Hi
Also grad den Shop geprüft. Es wurden keine Dateien verändert und die Datenbank enthält keine auffälligen Strings im Dump. Es wurde versucht ein Nutzer anzulegen und direkt zu löschen sonst nichts. Keine Weiteren Aufrufe in der Zwischenzeit. Ich würde fast behaupten der Shop ist sauber.

Grüße
Fabrice

Wenn es nur den insert und delete Befehl gab klingt es danach. Ggf. wird aber auch die admin/index.php aufgerufen. Das bedeutet je nach Widget auch schon, dass sensible Daten abgerufen werden konnten:

- Widget "Letzte Bestellungen": Letzte Bestellungen, den Namen der bestellenden Kunden und deren genutzte Zahlungsart und Warenwert
- Widget "Besucher (Online)": Die Besucher seit dem letzten Frontend-Zugriff. Gäste werden nur gezählt, aber bei eingeloggten registrierten Kunden wird Name und IP-Adresse ausgegeben. Letztere ist obfuskiert, wenn dies entsprechend eingestellt ist
- Weitere sensible Informationen könnten vorhanden sein, wenn Sie durch Plugins eigene Widgets auf dem Dashboard haben.

Also wenn ihr mit der Suche im access_log (ich empfehle übrigens das Programm "glogg") nach "/**/" "tadminlogin" und "bilder/banner" fündig geworden seid, schaut auch immer anschließend mit einer Suche nach den IP-Adressen der bisherigen Funde.

 

[KlausB]

Wenn es nur den insert und delete Befehl gab klingt es danach. Ggf. wird aber auch die admin/index.php aufgerufen. Das bedeutet je nach Widget auch schon, dass sensible Daten abgerufen werden konnten:

- Widget "Letzte Bestellungen": Letzte Bestellungen, den Namen der bestellenden Kunden und deren genutzte Zahlungsart und Warenwert
- Widget "Besucher (Online)": Die Besucher seit dem letzten Frontend-Zugriff. Gäste werden nur gezählt, aber bei eingeloggten registrierten Kunden wird Name und IP-Adresse ausgegeben. Letztere ist obfuskiert, wenn dies entsprechend eingestellt ist
- Weitere sensible Informationen könnten vorhanden sein, wenn Sie durch Plugins eigene Widgets auf dem Dashboard haben.

Also wenn ihr mit der Suche im access_log (ich empfehle übrigens das Programm "glogg") nach "/**/" "tadminlogin" und "bilder/banner" fündig geworden seid, schaut auch immer anschließend mit einer Suche nach den IP-Adressen der bisherigen Funde.

Wie ist das, wenn kein "bilder/banner" im log ist?
Und gleich nochmal meine Frage von vorhin:

Leider ist in der Mail von heute aus meiner Sicht nicht alles eindeutig beschrieben. Ich habe den Patch gestern Abend eingespielt und habe heute ein Angriffsmuster in der access. log
Unter 2. steht ".. insert UND delete in der gleichen Zeile ..." -> Bei mir ist insert UND delete nicht in einer Zeile.
3. "dort ... Statuscode "200" ..." -> Tja, wo dort? In der Zeile Insert UND delete? Die wurden mit "404" quitiert.
Es gibt Zeilen, die mit dem Code "200" und mit über 2000 Byte quittiert wurden. Wurden nun doch Daten abgegriffen, obwohl das System gepatcht war?

 

[Fabrice]

Also ich habe zusätzlich alle Adminkonten erneuert (2FA und Passwort). Ein Zugriff auf eine Adminseite war zwischen den SQL Befehlen nicht erfolgt.

 

[JulianG]

Wie ist das, wenn kein "bilder/banner" im log ist?

Das ist gut.

Und gleich nochmal meine Frage von vorhin:

Leider ist in der Mail von heute aus meiner Sicht nicht alles eindeutig beschrieben. Ich habe den Patch gestern Abend eingespielt und habe heute ein Angriffsmuster in der access. log
Unter 2. steht ".. insert UND delete in der gleichen Zeile ..." -> Bei mir ist insert UND delete nicht in einer Zeile.

Ist vllt nicht optimal formuliert: Da steht nicht "insert UND delete in der gleichen Zeile" sondern "Insert und delete... in der gleichen Zeile wie tadminlogin". Es sind also getrennte Zeilen, jeweils entweder "insert UND tadminlogin" oder "delete UND tadminlogin".

3. "dort ... Statuscode "200" ..." -> Tja, wo dort? In der Zeile Insert UND delete? Die wurden mit "404" quitiert.

Das ist der Nachteil an der Textmail :/ Hier ein Beispiel:

Hinweis: Dateiname kann sich immer unterscheiden.
1. Zahl im roten Kästchen ist das gemeinte Statuscode "200" in der Email. Heisst: Zugriff erfolgreich. Mit vorhandener, aktueller .htaccess im Bilderverzeichnis sollte das nicht möglich sein. Die Datei ist seit 4.06.12 mit blockierenden Einträgen für php-Dateien in den Shop-Versionen vorhanden. Leider fehlt sie trotzdem bei manchen Kunden.
2. Zahl im roten Kästchen: Byte

Es gibt Zeilen, die mit dem Code "200" und mit über 2000 Byte quittiert wurden. Wurden nun doch Daten abgegriffen, obwohl das System gepatcht war?

Wenn die bilder/banner php Datei mit 200 OK abgegriffen wurde und 2000 Byte, dann kannst du davon ausgehen, dass IRGENDWAS abgegriffen wurde. Selbst bei wie oben gezeigten 258 Byte könnte es ein einzelner Kundendatensatz sein. An der Stelle ist es leider Zeit deinen Datenschutzbeauftragten für weitere Schritte zu konsultieren. Ggf. ist das Meldepflichtig und das innerhalb von 72 Stunden (inkl. Feiertage/Wochende) nachdem es bekannt ist.
Bei anderen Dateien müsste man erst mal prüfen. Die Seiten selbst haben ja auch eine Dateigröße.

 

[microline]

Eine .php Datei im Ordner Bilder/Banner ist also schlecht, bzw gehört da nicht hin?

 

[Xantiva]

Genau, ausführbare Dateien (.php), womöglich mit kryptischen Namen haben dort nichts zu suchen.

 

[microline]

Danke

 

[andie28]

Wir haben das Update eingespielt, es gab auch einen Angriff aber laut Servicetechniker hat sich die Seite aufgrund zu vieler Anfragen abgeschaltet.
Den Eintrag hat unser Mitarbeiter hier gesehen und entsprechend gehandelt, den TEchniker konnten wir heute per Telefon nicht erreichen haben so auch keinen Zugang zur Access. log

Aber im Ordner Bilder/Banner haben wir nachgesehen, dort ist keine PHP Datei.
Die könnte aber auch woanders sein?
Wir durchsuchen gerade den Shop4 Ordner nach allen .PhP Dateien.
Sonst ein Hinweis wie man die identifiziert?

 

[KlausB]

Das ist gut.
...
Wenn die bilder/banner php Datei mit 200 OK abgegriffen wurde und 2000 Byte, dann kannst du davon ausgehen, dass IRGENDWAS abgegriffen wurde. Selbst bei wie oben gezeigten 258 Byte könnte es ein einzelner Kundendatensatz sein. An der Stelle ist es leider Zeit deinen Datenschutzbeauftragten für weitere Schritte zu konsultieren. Ggf. ist das Meldepflichtig und das innerhalb von 72 Stunden (inkl. Feiertage/Wochende) nachdem es bekannt ist.
Bei anderen Dateien müsste man erst mal prüfen. Die Seiten selbst haben ja auch eine Dateigröße.

Es wurde keine bilder/banner php abgegriffen, dies taucht im log nicht auf. Ich kann jedoch die Zugriffe auf /admin nicht richtig verstehen (habe vorher noch nie die Protokolle gesichtet).
Auszug, gekürzt:
GET ... /insert/.../tadminlogin...blabla... 404 7293 ...
GET /admin/index.php HTTP/1.1" 302 25
GET /admin/index.php HTTP/1.1" 200 2211
...
POST /admin/index.php HTTP/1.1" 302 25
GET ... /delete/.../tadminlogin...blabla... 404 7293 ...
Jetzt die Preisfrage: Wurden Daten abgegriffen?
Schonmal vorab danke für eine Antwort, damit ich am Wochenende "ruhig schlafen" kann.

 

[FPrüfer]

GET ... /insert/.../tadminlogin...blabla... 404 7293 ...

Ist ein KEIN gutes Zeichen. Hier wurde der Exploit versucht, auch wenn der Shop mit 404 antwortet.

POST /admin/index.php HTTP/1.1" 302 25

Ist dagegen ein gutes Zeichen. Hier wurde der Login-Versuch mit einer Weiterleitung (falscher User/Passwort) beantwortet

GET ... /delete/.../tadminlogin...blabla... 404 7293 ...

Hier wurden Spuren verwischt und der Admin-Account über die Lücke wieder gelöscht.
Wenn zwischen dem Insert und dem Delete KEINE erfolgreichen Aufrufe von Backend-Dateien (mutmasslich /admin/wawisync.php, admin/einstellungen.php, admin/banner.php) oder /bilder/banner/xyz.php enthalten sind, scheinen keine Daten abgeflossen zu sein.
Stelle bitte trotzdem sicher, dass sich KEINE .php-Dateien im Verzeichniss /bilder/banner befinden und die .htaccess in /bilder vorhanden ist und den Inhalt

Options -Indexes
<FilesMatch ".+\.ph(ar|(p[\d]?)|tml)$">
    <IfModule mod_authz_core.c>
        Require all denied
    </IfModule>
    <IfModule !mod_authz_core.c>
        Order Deny,Allow
        Deny from all
    </IfModule>
</FilesMatch>

hat, bzw. das die korrespondierenden Rules bei Verwendung eines NGINX-Servers aktiv sind.

***Anmerkung** Ich habe meine Antwort nochmal konkretisiert, da der Post von heute Nacht nicht ganz korrekt war!

 

[FPrüfer]

Aber im Ordner Bilder/Banner haben wir nachgesehen, dort ist keine PHP Datei.
Die könnte aber auch woanders sein?
Wir durchsuchen gerade den Shop4 Ordner nach allen .PhP Dateien.
Sonst ein Hinweis wie man die identifiziert?

Nach unseren bisherigen Erkenntnissen lief der Angriff automatisiert und immer über das Verzeichnis /bilder/banner. Ein Vorhandensein der Backdoor in einem anderen Verzeichnis ist nach aktueller Kenntniss unwahrscheinlich, aber leider nicht ausgeschlossen. Das fehlen der Datei ist auch nicht automatisch Entwarnung, da der Angreifer im Erfolgsfall seine Spuren durch Löschen der Backdoor verwischt hat. Ein erfolgreicher / fehlgeschlagener Angriff kann daher leider nur durch Analyse der Server Access-Logs festgestellt werden.

 

[FPrüfer]

Eine .php Datei im Ordner Bilder/Banner ist also schlecht, bzw gehört da nicht hin?

Die Datei gehört da definitv nicht hin, ist aber nicht unbedingt schlecht. Die Datei ist z.B. auch noch vorhanden, wenn der Exploit aufgrund einer korrekten .htaccess in /bilder gescheitert ist. In dem Fall konnte der Angreifer die Backdoor zwar hochladen, aber nicht ausführen. Entscheidend ist hier eine Analyse des Server-Access- Log im Zeitraum vor und nach dem Datum der Erstellung der PHP-Datei.
Wenn eine PHP-Datei in /bilder/banner vorhanden ist, dann diese für Beweiszwecke sichern und auf dem Webspace löschen!

 

[maestro]

Options -Indexes
<FilesMatch ".+\.ph(ar|(p[\d]?)|tml)$">
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order Deny,Allow
Deny from all
</IfModule>
</FilesMatch>

hat, bzw. das die korrespondierenden Rules bei Verwendung eines NGINX-Servers aktiv sind.

Es genügt aber, wenn die .htaccess nur im Verzeichnis /bilder liegt - diese muss nicht im Unterverzeichnis /banner liegen - korrekt?

Hätte die .htaccess den Angriff verhindert, bzw. die Ausführung des Schadcodes?

 

[microline]

Ja, .htaccess im Ordner Bilder reicht.
Bei uns hat sie das Auslesen der Daten verhindert, lieferte dementsprechend ein 404