Ein Restrisiko bleibt immer. Halte ich aber für unwahrscheinlich. Die Logs sind der Schlüssel. Um die Schaddateien auf den Server zu bekommen, muss es eine Anfrage gegeben haben. Keiner der von mir geprüften Shops, wo alles grün war, hatte Schadcode. Habe ich gecheckt. Ein Restrisiko bleibt natürlich immer...und es kann auch schlicht sein, dass ein Shop Schadcode hat, der von ganz woanders stammt. Mein Skript prüft ja nur die Indikatoren DIESER Sicherheitslücke. Werde das Skript aber noch anpassen. Weiß nur nicht ob ich das noch heute schaffe, bin gerade am Bereinigen einiger Kundenshops.
Gegenfrage, Wie lange sind die Log-Einträge nachverfolgbar? Meine Ältester Eintrag ist vom 23.03 was wenn davor injeziert wurde?
Danke! Habe dort 4 solche Ordner mit jeweils einem Ordner gx_se_cache und diese haben alle theme.json, cache.phtml und .htaccess enthalten. Habe ich alle gelöscht und werde weiter suchen....
Angriff erfolgte nachweislich ab dem 24.03. Sollte bei dir also passen. Ansonsten einfach fix via FTP die genannten Ordner checken.
Hier muss ich nochmal genauer nachhaken. Die Backdoor war ja quasi eine Webshell. Der Angreifer konnte per GET / POST beliebigen Befehle ausführen. Dass er uneingeschränkten Zugriff hatte, da gehe ich mit. Aber jeder Zugriff sollte doch in den Logs zu finden sein?! Es sei denn die Spuren wurden beseitigt
Ich sage nicht, dass es keinen Logeintrag gibt. Ich sage nur, dass es möglich ist, dass sich für das Abgreifen der Daten kein Logeintrag findet. Bsp.: config wird mit allen anderen Dateien gezogen. Darüber gibts ggf. einen Logeintrag. Darin stehen sämtliche Zugangsdaten zur Datenbank. Die Datenbank muss ich dann nicht via http anfragen, ggf. sogar nur einen Dump ziehen. Selbst wenn der Server da was loggt (kommt wieder drauf an) kann ich dieses Log dann entfernen. Sogar per Skript, vollautomatisch in 100 Shops gleichzeitig. Daher auch die Aussage: Es gibt Hinweise, dass. Von Seiten Gambio wurde das schon Anfangs kommuniziert, dass dies möglich sein kann. Man muss hier schlicht von allem ausgehen. Es kann auch X andere Ziele oder Gründe geben. Es kann sogar sein, dass nur jemand zeigen wollte, dass es geht und die Backdoors schlicht nur vorhanden waren. Es kann auch sein, dass es ein Versuch war Backdoors anzulegen um sie später zu nutzen. Das werden wir schlicht nie erfahren. Wichtig ist, und das hat Gambio bei aller Kritik sehr gut gemacht, dass man sofort reagiert hat und sowohl einen Patch als auch (den Agenturen...zumindest Stück für Stück) umfangreiche Infos zur Verfügung gestellt hat. Nur durch diese Infos konnte ich so schnell das Skript schreiben zum testen. Hätte Gambio hier gemauert (kenne ich auch von anderen Software-Unternehmen) hätten alle noch länger rätseln können.
Laut Log gab es auch diese Zugriffe: POST /GXModules/Gambio/StyleEdit/Api/api.php/styleedit/en/theme/ POST /cache/gx_se_cache/cache.phtml POST /export/gx_se_cache/cache.phtml POST /media/content/gx_se_cache/cache.phtml POST /download/gx_se_cache/cache.phtml
wenn man das Passwort zur Shop-Datenbank ändern, muss man diesen in diese 2 Dateien einfügen? includes/configure.php admin/includes/configure.php Danke
Bekannt. Genau das gx_se_cache Verzeichnis wird z.B. von meinem Skript gesucht. Genau. Vorher Dateirechte auf 777 stellen, dann ändern, dann auf 444 zurück stellen. (Filezilla, Mausklick rechts, Dateirechte ändern)
Du hast schon recht – theoretisch war alles möglich. Aber wenn die Datenbank nicht von außen erreichbar ist, muss der Angreifer die Daten am Ende wieder über die Webshell rausziehen. Und das läuft dann über HTTP. Man würde normalerweise entweder viele Requests sehen oder deutlich größere Antworten. (Welche natürlich auch wieder durch den Angreifer manipuliert sein könnten....) In den Logs hier sieht man aber eher nur ein paar wenige Requests mit kleinen Responses (~6–7 KB). Das passt nicht zu einem größeren Datenabzug. Ganz ausschließen kann man natürlich nichts, aber nur weil es theoretisch möglich ist, würde ich hier nicht direkt von Datenabfluss ausgehen. Und wenn doch: Dann alle Kundenpasswörter löschen, Kunden informieren und Datenschutzbehörden informieren? Genau das versuche ich gerade noch herauszufinden. Und wie setze ich überhaupt alle Kundenpasswörter zurück, so dass der User über "Passwort vergessen" ein neues Passwort vergeben kann? Einfach alle Passwörter (außer Admin) in der DB löschen?