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?
Unsere Shops sind alle sauber geblieben. Wir haben bei allen unseren Shops (gehostet bei Allinkl) einen Verzeichnisschutz aktiviert und zusätzlich mittels htaccess eine IP Sperre für Länder hinterlegt. Ob es nun daran lag das wir sauber geblieben sind weis ich nicht. Schaden kann es auf jeden Fall nicht. Code: # ----------------------------------------------------------------------------- # Ländersperre: Nur Deutschland, Großbritannien und USA zugelassen # ----------------------------------------------------------------------------- GeoIPEnable On SetEnvIf GEOIP_COUNTRY_CODE DE AllowCountry SetEnvIf GEOIP_COUNTRY_CODE GB AllowCountry SetEnvIf GEOIP_COUNTRY_CODE US AllowCountry Deny from all Allow from env=AllowCountry https://all-inkl.com/wichtig/anleit...htaccess/laendersperre-mit-mod_geoip_636.html
Code: # ----------------------------------------------------------------------------- # Ländersperre: Nur Deutschland, Großbritannien und USA zugelassen # ----------------------------------------------------------------------------- GeoIPEnable On SetEnvIf GEOIP_COUNTRY_CODE DE AllowCountry SetEnvIf GEOIP_COUNTRY_CODE GB AllowCountry SetEnvIf GEOIP_COUNTRY_CODE US AllowCountry Deny from all Allow from env=AllowCountry Kein Problem hiermit: https://www.bundesnetzagentur.de/DE/Fachthemen/Digitales/Schutz/Geoblocking/start.html ?
Für uns Laien....Wen ichmir dein Skript runterlade, wie verfahre ich damit weiter? Woher erhalte ich den Key? Ich versteh nur Bahnhof
oh wow das war mir neu. Dann müssen wir da wohl nochmal ran Ist zwar irgendwie unlogisch denn die Kunden aus anderen Ländern können zwar bei uns bestellen aber müssten die Waren dann Vorort abholen. Das ist ja auch irgendwie eine Art Diskriminierung. Drittstaaten: Sperren gegen Nutzer außerhalb der EU (z.B. USA) sind grundsätzlich erlaubt, so die IT-Recht Kanzlei. Habe es somit nun nur auf China und Russland ausgeweitet: Code: # ----------------------------------------------------------------------------- # Ländersperre mit mod_geoip # ----------------------------------------------------------------------------- GeoIPEnable On SetEnvIf GEOIP_COUNTRY_CODE RU BlockCountry SetEnvIf GEOIP_COUNTRY_CODE CN BlockCountry Deny from env=BlockCountry
hier kann man eine Datenpanne melden; da gibt es ein Formular: (Link nur für registrierte Nutzer sichtbar.)
ZIP Datei runterladen (gerade eine verbesserte Version hochgeladen), entpacken. Die darin enthaltene PHP Datei einfach in den Shop kopieren und aufrufen mit deine-domain.de/or-0326-test.php?key=or2603sec Der Key ist korrekt, wenn du sie einfach direkt hochlädst. Wer will kann ihn aber im oberen Bereich der Datei ändern und selbst einen vergeben. Ist aber nicht notwendig, wenn die Datei nur kurz online ist. Dann Scan starten.
Welches Datum hatten denn die Ordner? Die können natürlich immer anders heißen. Allgemein sollte in dem tmp Ordner in der Regel eigentlich nur eine index.html liegen.
Ok. Die import_ Ordner stammen meist von einer früheren Uhrzeit, dann wurden die Ordner mal so und später so benannt. Wollte nur sichergehen, dass es nicht von einem späteren Datum stammt. Hab das Skript entsprechend angepasst und einen kleinen Fehler bei Systemen mit php 7.x behoben. Neue Version im Blogbeitrag runterzuladen. https://www.orange-raven.de/sicherheitsupdate-gambio-03-2026/