Hallo, ich habe jetzt alle Updates eingespielt und auch das Sicherheitsupdate. Ich habe nun im Admin auf machen Seiten in einem Shop den Fehler: Unexpected error occurred... Invalid Gambio shop version identifier provided: v26.03.0 Was kann ich da machen. Ich habe bereits die ürsprünglichen Dateien wieder eingespielt und alle Updates nochmals gemacht, Cache gelöscht.... Was kann ich hier machen?
Wichtiger Hinweis, hatte gerade jemande von All-inkl. Ihr müsst, wenn das Tool nur die Gambio Logs findet, noch den Pfad zu den Serverlogs manuell hinzufügen. Die liegen bei jedem Hoster woanders. Erst dann kann das Tool sauber scannen. Die Hniweise stehen NUR in den Serverlogs.
Update für alle, die betroffen sind. Da einer der Angriffe via StyleEdit kam, befinden sich bei betroffenen Shops sehr viele Kopien der Hauptordner im Ordner "themes". Normal sollten da nur die Themeordner via Malibu, Honeygrid, Malibu_preview usw. (ggf. eigene Namen, wenn euer Theme einen eigenen Namen hat) liegen. Bei allen gehackten Shops sind da ein großteil der Hauptordner wie admin, includes, apps usw. zu ginden. Ebenso die Dateien. Außer einer .htaccess sollte da gar nix drin liegen. Wobei die auch mit weg müsste, weil die eh überschrieben ist. Soweit ich das sehe, kann man diese Kopien einfach entfernen. Da hier aber wahrscheinlich auch die Config mit dabei ist: Auf jeden Fall das Datenbank Passwort ändern.
Nur nochmal zum Verständnis. Da beim POST der request body nicht geloggt wird, ist völlig unklar was die Angreifer gemacht haben, richtig? Es könnte alles gewesen sein? Aber ein Abzug der Datenbank oder Kundendaten halte ich für äußerst unwahrscheinlich bei einer Response Größe von 6000 Bytes?!
Prüft mal auch nochmal ob es im Ordner uploads/tmp Ordner mit "import_xxx" gibt die eine cache.php enthalten. Falls ja, wurde die Backdoor angelegt und das muss bereinigt werden.
ABSOLUTER Wahnsinn ist das hier! Mal ganz ehrlich: Welcher Laie soll hier noch durchblicken? Das ist wirklich seitens GAMBIO eine absolute Katstrophe. Und ja: Jeder hier meint es nur gut. Aber 8 Seiten für ein dringendes Update, welches wohl auch noch fehlerhaft war und wieder korrigiert wurde. Das ist ALLES nicht professionell. Sorry.
Ja, durchsucht txt, log, json, gz usw. Es zeigt dir ja auch an, wieviele Dateien durchsucht wurden. Wenn du da tausende Logs hast und er sagt nur 3, dann klappt was nicht und du kannst mir gern eine Info zukommen lassen.
Ein großes Danke an alle, die Sonntags zu dieser Uhrzeit helfen und arbeiten. Das ist die Konstante über all diese Jahre. Wenns bei Gambio mal wieder hart auf hart kommt, kann man sich auf die Community verlassen! Danke!
Ich bin ja auch betroffen. Es wurden einige Themes Ordner angelegt aber ich habe die xxxxxxxxxxxxxx/cache.php NICHT! Die Frage ist nur, ob Daten geklaut wurden oder nicht. Es würde eine Menge Arbeit sparen. Ich habe die Log Einträge mal in die KI eingegeben da ich jetzt kein Fachmann bin. 1. Was die IP gemacht hat (Angriffsanalyse) Diese IP hat nicht einfach nur Produktdaten „kopiert“, sondern aktiv versucht, Sicherheitslücken in deinem Gambio-Shop (StyleEdit) auszunutzen. Exploit-Versuche (RCE): Die IP hat gezielt versucht, PHP-Code in Cache-Verzeichnisse zu schreiben und diesen dann auszuführen. Beispiel: GET XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX RCE_OK steht für „Remote Code Execution“. Der Angreifer testet hier, ob sein hochgeladener Schadcode funktioniert. Manipulation des StyleEdit-Moduls: Es wurden massenhaft PUT und POST Anfragen an die api.php von StyleEdit gesendet, inklusive Versuchen, Themes zu importieren (/IMPORT). Das Ziel hierbei ist oft, eine Hintertür (Webshell) ins System zu schleusen. DDoS-ähnliches Verhalten: Am Ende der Logs sieht man eine extrem hohe Frequenz an Anfragen auf calculate_price. Das sieht nach einem Versuch aus, den Server durch Last in die Knie zu zwingen oder weitere Parameter-Lücken zu finden. 2. War der Angriff erfolgreich? Die HTTP-Statuscodes geben einen Hinweis: Status 404 & 403: Viele Versuche, den Schadcode aufzurufen, scheiterten (Datei nicht gefunden oder Zugriff verweigert). Das ist gut. Status 500: Die Versuche, Themes zu importieren oder Preise zu berechnen, endeten in Serverfehlern. Das bedeutet meist, dass das Skript abgestürzt ist oder der Angriff (noch) nicht wie gewünscht funktionierte. Status 200 bei PUT-Anfragen: Vorsicht! Die API hat auf einige PUT-Anfragen mit 200 (OK) geantwortet. Das könnte bedeuten, dass der Angreifer erfolgreich Einstellungen im StyleEdit-Modul ändern konnte. 3. Sofort-Maßnahmen Da es sich hier um einen gezielten automatisierten Angriffsversuch handelt, solltest du sofort handeln: IP Sperren: Blockiere die IP xxxxxxxxxx sofort in deiner Firewall oder über die .htaccess. Da sie aus dem Azure-Netzwerk kommt, handelt es sich sicher nicht um einen echten Kunden. StyleEdit prüfen: Da Gambio-Shops oft über das StyleEdit-Modul angreifbar waren (vor allem ältere Versionen), prüfe, ob dein Shop auf dem neuesten Stand ist. Es gab in der Vergangenheit spezifische Sicherheitswarnungen für dieses Verzeichnis. Dateien prüfen: Schau in die Ordner StyleEdit. Liegen dort neue .php oder .phtml Dateien, die du nicht kennst? (Achte besonders auf Dateien mit Namen wie cache.php oder seltsamen Zeichenfolgen). Admin-Passwörter ändern: Falls der Angreifer über die API Zugriff erlangt hat, könnten Session-Daten oder Admin-Zugänge gefährdet sein. Zusammenfassend: Die IP hat keine Produktdaten „geklaut“, sondern versucht, die Kontrolle über deinen Server zu übernehmen. Ein Großteil der Versuche scheint blockiert worden zu sein, aber die erfolgreichen PUT-Anfragen (Status 200) erfordern eine genaue Prüfung deines Shop-Backends.
Mega, vielen Dank dafür wirklich toll. Bei ionos (1und1) musste ich nichts anpassen, Skript lief ohne probleme und alles grün.
Nicht nur. Auffällig ist eher, dass in den meisten betroffenen Shops die ganzen Shopordner (includes, admin usw.) in den themes Ordner kopiert wurden. Außerdem wurden im uploads/temp Ordner Ordner mit entsprechenden Dateien angelegt. Unter anderem auch cache.php, die wiederrum Schadcode enthielt. Nur weil die Abrufe aus der Datenbank nicht geloggt sind, heißt dass nicht, dass sie nicht abgefragt wurden. Über die Backdoor hatte der Angreifer im Prinzip freien Zugang zum Shop, der Datenbank etc. Es gibt auch noch weitere IP Adressen. Sofortmaßnahme daher auch: Datenbank Passwort ändern und in der Config anpassen, sowie die Nutzerpasswörter aller Admins ändern.
Bedeutet das, wenn dein Tool alles geprüft und nichts gefunden hat, das ein "Befall" trotzdem vorliegen könnte und eine genauer Prüfung manuell in den von dir genannten Ordnern und Pfade durchgeführt werden sollte?