AN ALLE AUS NRW. Die Dame vom Datenschutz ist wirklich chillig und nett! (0)211 / 38424 - 254 Frau Nürnberg und auf der 253 Herr Meis. Sie notiert sich nur den Namen und alles gut. Sie sagt selber wir sollen uns nicht irre machen und warten erst einmal ab was Gambio zu sagen hat. Wir können einfach das Telefonat notieren und alles ist gut. Ob Daten geflossen sind kann man so genau nicht sagen. Einfach anrufen und weiter schauen
1.1 aktuell wenn installiert: sicher wenn nicht vorher gehackt. gute hoster bieten mehr backups, z.b. 7 tage, und dann noch wochen/monatsweise.
hat eigentlich irgendjemand schon mal nach instalation sec patch 1.1 (ganz konkret in einen 4.4.0.2er shop) das problem gehabt dass auf einemal massig php fehlerin logs kommen? template seite geht nicht mehr (500) im admin, massig paypal fehler in konsole, und layout auch nett geschrottet...kann mir kaum vorstellen dass der patch die ursache ist, aber betreiber behauptet ist exakt seit installation so.
Orange Raven, Gestern um 20:38 Uhr ↑ Hallo, Durchsucht das o.a. script auch gezipte logs ? Meist sind nur die letzten nicht gezipt 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. www.orange-raven.de - Gambio Hosting | Marketingberatung | Backupmanager Ausprobiert bei df und nix gefunden - passt, danke! (hatte vorher schon händisch durchsucht die Logs) Tolles Programm.
ich hatte das problem das mein layout geschrottet wurde slider plötzlich an anderer position konnte auch nicht verschoben werden im style edit, kategorien konnte ich nicht mehr aufrufen teilweise alles weiß geblieben trotz geleerten cache usw. v4.4.0.3 ende vom lied backup eingespielt und gambio hat es heute manuell installiert jetzt ist alles wie gewohnt
Das Security Update Paket 2026-03 v1.1 (v4.0-v4.6).zip ist definitiv fehlerhaft. Da gibt es an einigen Stellen leider Unterschiede die fehlerhaft sind. Es sieht so aus als wurde da eine neuere Version wie die 4.6 als Basis benutzt. Wir hatten gestern den ersten 4.6er Shop zu patchen - da ist es uns sofort aufgefallen. Wir haben das an Gambio gemeldet und uns schlichtweg unser eigenes Updatepaket erstellt welches von den Fehlern bereinigt ist. Grüße Walter
Wie viele Zugriffe haben betroffene Shops auf /themes/gx_cache/cache.php laut Logfiles? Ist das immer gleich oder unterschiedlich? @Orange Raven Danke nochmal für das Skript
Habe ebenfalls die gx_se_Cache in den Logs, aber immer mit Status 403 oder 404. Kann ich davon ausgehen, das hier dann die Angriffe erfolgreich abgewehrt wurden und keine Daten geflossen sind?
Meine Meinung: Requests mit 403 oder 404 waren ja nicht erfolgreich, darüber ist zumindest in diesen Fällen wahrscheinlich kein Schaden entstanden. Nur weil z. B. gx_se_cache gefunden wurde, heißt das nicht automatisch, dass alle Kundendaten abgeflossen sind – auch wenn das theoretisch möglich gewesen wäre. Umgekehrt gilt ja genauso: Nur weil nichts gefunden wurde, heißt das nicht automatisch, dass nichts passiert ist. Es könnte theoretisch auch Fälle geben, in denen Spuren besser entfernt wurden. Die Sicherheitslücke hat ja alle Shops betroffen. Man sollte ganz genau prüfen was man konkret in den Logs und im System sieht – nicht nur, was theoretisch alles möglich wäre. Daher interessiert mich auch: Gibt es Shops in denen Dateien / Daten manipuliert wurden? Und was sieht man dort in den Logs?
Ich habe konkret einen Kundenshop bei dem wurde in den ordner /themes/ der komplette Shoproot reinkopiert. In dieser Ordnerstruktur ist im themes wieder der komplette Shop usw... Das geht bis in die achte Ebene. Der gesamt Shop-PHP-Baum wurde achtmal kopiert. Da gibt es jede Menge Daten zum löschen.
Das habe ich hier schon sehr häufig gehört. Und wie spiegelt sich das in den Logs wieder? Gibt es viele gx_se_cache Zugriffe? (laut Skript von Orange Raven?)
Was ihr teilweise fragt, lässt sich so pauschal nicht sagen. Die Anzahl der Logeinträge ist grundsätzlich völlig irrelevant. Wobei ich mittlerweile Logeinträge bei Kunden gefunden habe, wo am 29.03. ein Angriff versucht wurde. Den Patch drin zu haben ist also enorm wichtig. 404 heißt nicht, dass der Angriff nicht erfolgreich war. Es heißt nur, dass zu diesem Zeitpunkt eine Datei (es gab neben cache.php auch z.B. cache.phtml u.a., mein Skript prüft in der Version 3 seit gestern Morgen auf alle) nicht mehr verfügbar war. Ablauf bei einem meiner Kunden: 04:47 Uhr IP Nr. 1: Scan auf Attribut-Exploit mit HTTP 500 05:03 Uhr IP Nr. 1: PUT ins styleedit theme Verzeichnis, HTTP 200 10:00 Uhr IP Nr. 2: POST & GET auf die cache.php --> 404 In diesen 5 Stunden kann alles passiert sein. Nichts davon muss in den Logs stehen. Das ist der Witz an einer Backdoor. Habe mich gestern nochmal mit einem Kollegen ausgetauscht, der in dem Bereich deutlich mehr Kenntnisse hat als ich. Der hats mir auch nochmal bestätigt. Entweder hat die IP 2 versucht den gleichen Angriff zu starten, war aber zu spät. Wahrscheinlich ist aber, dass verschiedene Rechnernetzwerke (hier vermutlich Azure) verwendet wurden um nacheinander alle Schritte abzuspulen und am Ende zu testen ob die Dateien noch vorhanden sind. Nachdem 404 kommt, ist der Anfriff vorbei. Macht euch bitte auch keine falschen Vorstellungen, wie so ein Angriff passiert. Da sitzt nicht der eine Böse und geht die einzelnen Gambioshops durch. Mal stark vereinfacht: Irgendwoher hat der Angreifer (das kann auch eine Gruppe sein) die Info über die Sicherheitslücke bekommen. Danach bereiten sie alles automatisiert vor. Crawler sammeln Adressen ein, wo Gambioshops laufen und dann wird das ganze programmiert und in eine leistungsstarke Umgebung geladen. Dann startet der Angriff und die Shops werden auf die Lücke geprüft. Da werden dutzende Shops in Minuten durchgespielt. Alle Adressen, wo eine positive Meldung kommt, werden dann mit dem nächsten Schritt angegriffen und so weiter. Das heißt, dass jeder Shop wo die Skripte "hier nicht" zurück liefern, warum auch immer...und sei es weil der Shop an dem Tag wegen eines Serverausfalls genau zu dem Zeitpunkt nicht erreichbar war..., sind aus dieser Angriffswelle wahrscheinlich erstmal raus. Bedeutet wir haben also mehrere Kategorien von Shops: Shops die nie in die Liste gekommen sind, weil der Angreifer sie nicht gefunden hat Shops die Logeinträge haben, wo der Angriff aber abgebrochen wurde Shops die Logeinträge haben, wo aber nichts hochgeladen wurde Shops die Logeinträge haben, wo die Verzeichnisse aber wieder weg sind, weil der Angreifer alles bereinigt hat (sieht hier aus meiner Warte bisher nicht so aus) Shops, welche die volle Breitseite abbekommen haben Insofern ist eigentlich nur safe, wer keinerlei Logeinträge hat. Wert nur Logeinträge hat, hat vermutlich nur einen Versuch gehabt, sollte aber dennoch Datenbankpasswort und Admin-Passwörter ändern. Und mal noch ein paar Worte zu Gambio. Nein, die Kommunikation von Gambio war nicht glücklich und wirkt bisweilen überfordert. So als wenn niemand bei Bekanntwerden sofort einen Plan in der Schublade hat, nach dem nun zu verfahren ist. Und Nein, dass es offenbar beim Überarbeiten der Varianten vor einigen Jahren kein ordentliches Codereview gab ist ein Mangel, den man abstellen sollte. Aber zu denken, dass man einen so komplexen Code wie den von Gambio, in dem nochdazu sehr viele Altlasten von XT:C stecken einfach durch eine KI jagdt um dann eine Liste mit kritischem Code zu haben der dann flux behoben ist, ist absolut naiv und unrealistisch. Natürlich kennt Gambio zahlreiche Schwachstellen im Code. Die zu beheben ist aber unfassbarer Aufwand, selbst für ein Team. Und ein großes Team hat dann wieder das Koordinierungsproblem. VIele Codes haben Abhängigkeiten voneinander, die nicht so simpel zu beheben sind. Auch eine KI wird hier nur teilweise helfen. Das Risiko dass die Murks macht ist hoch, weswegen sowieso einer drauf schauen muss. Zeitersparnis vielleicht 10-15 %, weil man sich hier und da das Schreiben spart. Priorisieren ist auch schwierig. Potenziell ist jede Lücke gefährlich. Ist auch nicht so, dass Gambio da allein betroffen ist. Würde sogar sagen, Gambio ist weniger betroffen, weil Gambio im Vergleich zu Shopware oder WooCommerce kleiner ist und sich Angriffe weniger lohnen. Beispiel? März 2026 - Kritische Sicherheitslücke in Shopware. Angreifer konnten recht einfach Shopsysteme auf registrierte Mailadressen prüfen August 2025 - Adobe Commerce/Magento: Via Session-Übernahme konnte Schadcode eingespielt werden, Sicherheitspatch erst im September, bis Oktober waren geschätzt 50 % aller Shops angegriffen März 2026 - Adobe Commerce hat laut Sansec eine Schwachstelle die es erlaubt via API Fremddateien ohne Begrenzung in den Shop zu laden, scheinbar bisher ohne (mir bekannten) Patch Dezember 2025 - WooCommerce hat seit Jahren eine Lücke, die es registrierten Kunden möglich machte Bestellungen von Gastkunden zu durchsuchen, Lücke schnell gepatcht war davor aber für Jahre schon drin Könnte endlos so weiter schreiben. Wir leben in einer digitalen Welt. Kein Code ist perfekt. Was Gambio dringend lernen muss und was seit Monaten schlecht funktioniert, ist ihr Kommunikationsverhalten.
Habe ich auch so vorgefunden. Die Frage ist: Lief da der Angriff schief und es ist nichts passiert, oder war der Angriff erfolgreich?
Das Update hat nicht so richtig funktioniert bei mir. Nach dem Datenbankupdate kam die Meldung, dass ich den Cache leeren soll und ein Link darauf, nun komme ich nicht mehr in den Adminbereich, da kommt nur diese Fehlermeldung: https://oversized-t-shirts.de/admin/ Aktuell läuft/lief da die Version 5.0.2.0 Das Frontend scheint so weit in Ordnung zu sein. ----------------------------------------------------------------------------------------------------------------- Ich habe das Update nun zurückgedreht und werde es später nochmal versuchen.
Wahrscheinlich erfolgreich. Check noch den uploads/tmp Ordner. Wenn da was drin ist, also Ordner und/oder Dateien wie cache.php oder cache.phtml
Und was sagt Gambio dazu? Mein Shop sagt auch nach dem v1.1 Patch immer noch "Gambio Version: v4.9.6.0" Oder kommt da noch ein Update von Gambio?
Das Security Update ändert nichts an der Versionsnummer und ist auch kein Update, sondern ein Patch. Es werden einfach nur einige Dateien überschrieben.
Ich habe hier einen Serverlog mit über 1000 Versuchen von Code: "POST /ADRESSE.php?module=SAGICHNICHT&action=calculate-IRGENDWAS HTTP/1.1" 500 380 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36" 1873 4605 Die Datenbankabfragen dazu sehe ich im Gambio Log. Die poste ich hier aber nicht. Die 500 sagt daß er nicht erfolgreich war, er sollte somit keine Daten zurückerhalten haben...
Können firewalls oder Malware-Scanner direkt auf dem Server das verhindern oder laufen solche Angrife unter dem "Radar"?