Wert Posted January 4, 2020 Share Posted January 4, 2020 (edited) Hallo, ich benutze Prestashop 1.7.5.2 und habe von 1und1 die folgende meldung erhalten. Angriff auf Ihren Webspace - Wichtige Hinweise zu Ihrer Sicherheit Unser Anti-Viren-Scanner meldet, dass folgende schädliche Datei auf Ihren Webspace geladen wurde: modules/ps_facetedsearch/vendor/phpunit/phpunit/src/Util/PHP/XsamXadoo_deface.php Kann mir jemand weiter helfen? Ich weiß nicht was ich jetzt machen soll. Edited January 6, 2020 by selectshop.at Title expanded to XSAM_XADOO problem (see edit history) Link to comment Share on other sites More sharing options...
selectshop.at Posted January 4, 2020 Share Posted January 4, 2020 Dein ps_facetedsearch Modul ist die letzte Version ? In der letzten Version (v.3.4.0) gibt es den Unterordner modules/ps_facetedsearch/vendor/phpunit/ garnicht. Es kann sein, dass dein Prestashop aufgrund einer anderen Lücke durch ein Theme oder anderes addon diesen Ordner mitsamt Datei angelegt hat. Link to comment Share on other sites More sharing options...
Wert Posted January 4, 2020 Author Share Posted January 4, 2020 (edited) vor 9 Minuten schrieb selectshop.at: Dein ps_facetedsearch Modul ist die letzte Version ? In der letzten Version (v.3.4.0) gibt es den Unterordner modules/ps_facetedsearch/vendor/phpunit/ garnicht. Es kann sein, dass dein Prestashop aufgrund einer anderen Lücke durch ein Theme oder anderes addon diesen Ordner mitsamt Datei angelegt hat. Hallo, VIelen Dank für die Antwort. ich habe die Version v3.4.0. Die Folgende liste habe ich von 1und1 erhalten. Folgende Dateien wurden aller Wahrscheinlichkeit nach von Dritten hochgeladen. Bitte überpruefen Sie diese Dateien und löschen Sie diese gegebenenfalls. ~/Xsam_Xadoo.html ~/modules/ps_facetedsearch/vendor/phpunit/phpunit/src/Util/PHP/XsamXadoo_deface.php Folgende Dateien wurden aller Wahrscheinlichkeit nach von Dritten modifiziert. Bitte überpruefen Sie diese Dateien und laden Sie diese gegebenenfalls aus einem nicht infizierten Backup erneut auf Ihren Webspace. ~/Xsam_Xadoo.html ~/cmodules/ps_facetedsearch/vendor/phpunit/phpunit/src/Util/PHP/XsamXadoo_deface.php Edited January 4, 2020 by Wert (see edit history) Link to comment Share on other sites More sharing options...
Claudiocool Posted January 4, 2020 Share Posted January 4, 2020 Als erstes ändert man nach solchen Mails sämtliche Passwörter. Danach kann man dann die betreffenden Dateien untersuchen und ggf. löschen. Hilfreich sind hier natürlich immer Logs, mit denen man genau sehen kann, was da passiert ist. Und: Auch wenn die Backoffice-Bereiche mit einem Passwort für den Login gesichert sind, empfiehlt es sich immer, auch die betreffenden Verzeichnisse zusätzlich mit Passwort zu sichern, damit ist dann eine Sicherheitsstufe mehr drin. Ein Umbenennen des Admin-Verzeichnisses ist dann noch eine weitere Erhöhung der Sicherheit. Link to comment Share on other sites More sharing options...
Wuschel Posted January 4, 2020 Share Posted January 4, 2020 (edited) Wichtiger noch als Passwörter sind die z.Z. geöffneten Ports. Man findet zwar im Internet viele Webseiten, die für das XsamXadoo-Botnetz gehackt wurden, aber wengi konkrete Informationen, was das bedeutet. Auf jeden Fall solltest du die monierte html-Datei sofort löschen, und auch die gesamte Verzeichnisstruktur /phpunit... unterhalb des Modulverzeichnisses ps_facetedsearch/vendor/ - samt Inhalt! Denn die hat dort nichts zu suchen. Ich bezweifle allerdings, dass das ausreichen wird. Aber da muss man abwarten und das Beste hoffen. Ist das Folgende eigentlich ein Schreibfehler, oder existiert ein solches Verzeichnis? ~/cmodules/ Edited January 4, 2020 by Wuschel (see edit history) Link to comment Share on other sites More sharing options...
Wuschel Posted January 5, 2020 Share Posted January 5, 2020 Nähere Infos hier: https://nvd.nist.gov/vuln/detail/CVE-2017-9841 Link to comment Share on other sites More sharing options...
selectshop.at Posted January 5, 2020 Share Posted January 5, 2020 (edited) Es ist noch nicht genau klar wie sich der XsamXado einschleiht, aber im Französischen Prestashop Forum wird empfohlen, dass folgende /vendor/phpunit/ Unterordner in folgenden Modul-Ordnern gelöscht werden (persönlich würde ich diese /vendor/phpunit/ Unterordner nur umbenennen anstatt komplett zu löschen): - Modul autoupgrade (Version 4) - Modul pscartabandonmentpro ; Version v2.0.1 und 2.0.2 - falls installiert, weil das kein natives Modul ist. - Modul ps_checkout ; Versionen v1.0.8 & v1.0.9 - falls installiert, weil das kein natives Modul ist. - Modul ps_facetedsearch ; Version v3.0.0 und v2.2.1 - Modul gamification Originalpost findet ihr hier: https://www.prestashop.com/forums/topic/1012095-hack-prestashop-avec-xsamxadoo-bot/?tab=comments#comment-3186584 Edited January 6, 2020 by selectshop.at /phpunit/ ergänzt (see edit history) Link to comment Share on other sites More sharing options...
Wuschel Posted January 5, 2020 Share Posted January 5, 2020 Es scheint also nicht zu stimmen, dass PrestaShop nur unter PHP bis 5.6.2 von XsamXadoo befallen wird, denn ich gehe mal davon aus, dass PrestaShop 1.7.5.2 mindestens PHP 7 benötigt. Nähere Infos für PHP < 5.6.3 hier: https://nvd.nist.gov/vuln/detail/CVE-2017-9841 Die Verzeichnisse dürften ziemlich beliebig sei, da der Bot ja auch ja seit 2015 auch von anderen Shopsystemen oder Webseiten her bekannt ist. PrestaShop 1.7 bietet nur halt eine große Angriffsfläche, wegen der unzähligen verschachtelten Dateien. Die eigentlich spannende Frage ist allerdings: Liegt es an PHP, oder ist das für 1.7 genutzte Framework Symfony die verwundbare Plattform? Link to comment Share on other sites More sharing options...
selectshop.at Posted January 5, 2020 Share Posted January 5, 2020 Wuschel, in dem von dir angehängten Link und dem XsamXadoo geht es um die PHPUnit versionen 4 und 5, welche php versionen 5.3 bis 7.1 unterstützen. PHPUnit hat nichts mit php Versionen zu tun. PHPUnit ist ein programmiererorientiertes Testframework für php. Link to comment Share on other sites More sharing options...
Wuschel Posted January 6, 2020 Share Posted January 6, 2020 3 hours ago, selectshop.at said: die PHPUnit versionen 4 und 5, welche php versionen 5.3 bis 7.1 unterstützen. PHPUnit hat nichts mit php Versionen zu tun. Ich glaube, hier bist du auf dem Holzweg. Denn das stimmt nicht. Du solltest dir erst einmal die Dokumentation durchlesen, auf die du verlinkt hast. Link to comment Share on other sites More sharing options...
selectshop.at Posted January 6, 2020 Share Posted January 6, 2020 7 hours ago, Wuschel said: Ich glaube, hier bist du auf dem Holzweg. Denn das stimmt nicht. Du solltest dir erst einmal die Dokumentation durchlesen, auf die du verlinkt hast. Das bin ich nicht. Wie im Link, den du gepostet hast ersichtlich ist, sind in phpunit Teile enthalten, welche das System mittels HTTP POST angreifbar macht. In der Zwischenzeit hatte ich auch schon Kontakt mit dem Prestashop Team. Die Antwort dazu heißt: Es wird am Problem gearbeitet und sie empfehlen vorsichtshalber alle Unterordner /vendor/phpunit/ aus allen Modulen zu löschen. Link to comment Share on other sites More sharing options...
JBW Posted January 6, 2020 Share Posted January 6, 2020 Wobei PHPUnit eigentlich eh nur bei einer DEV installation geladen wird und dann aktuell in 5.7. womit die Gefärdung gar nicht erst geschehen dürfte. Link to comment Share on other sites More sharing options...
selectshop.at Posted January 6, 2020 Share Posted January 6, 2020 @JBWDas stimmt, man ist sich trotzdem nicht sicher, weil es so einige Meldungen gibt, dass Server bereits mit dem XSAM_XADOO infiziert wurden. Es gilt die Lücke zu schliessen und vorsichtshalber alle /vendor Unterverzeichnisse im Modul Ordner zu löschen. Es ist eine potenzielle Gefährdung. Link to comment Share on other sites More sharing options...
JBW Posted January 6, 2020 Share Posted January 6, 2020 14 minutes ago, selectshop.at said: vorsichtshalber alle /vendor Unterverzeichnisse im Modul Ordner zu löschen Dann werden die Meisten dieser Module aber nicht mehr funkionieren, diese Drittanbieter-Bibliotheken sind ja nicht ohne Grund dabei. phpunit Verzeichnisse kann man m.E. aber entfernen da diese nur Tests enthalten sollten. Link to comment Share on other sites More sharing options...
selectshop.at Posted January 6, 2020 Share Posted January 6, 2020 Kleine Korrektur und genauere Anweisung: man sollte vorsichtshalber alle /phpunit/ Unterordner löschen welche unter dem Ordner /modules/xxxx sind. DIES GILT FÜR PS 1.5, PS 1.6. und auch für PS 1.7. Das sind dann folgende: /modules/autoupgrade/vendor/phpunit /modules/ps_facetedsearch/vendor/phpunit - falls vorhanden, da in den neueren Versionen des Modules dieser Ordner nicht existiert /modules/gamification/vendor/phpunit - falls vorhanden, da in den neueren Versionen des Modules dieser Ordner nicht existiert Sowie etwaige Drittmodule wie: /modules/pscartabandonmentpro/vendor/phpunit /modules/ps_checkout/vendor/phpunit Die Liste hier wird evtl. erweitert, falls nötig. Wer einen Root Server besitzt, kann dies auch via SSH Kommando Zeile mit folgendem Befehl im Ordner /modules und natürlich mit Superuser Rechten erledigen: find . -type d -name "phpunit" -exec rm -rf {} \; Link to comment Share on other sites More sharing options...
paddy83 Posted January 6, 2020 Share Posted January 6, 2020 (edited) Wir betreiben einen 1.6er Prestashop, auch wir haben die besagte Mail von 1&1 am 29.12 erhalten. Bei uns wurde ebenfalls die XsamXadoo_deface.php über die eval-stdin.php aus dem phpunit Framework im Autoupgrade Modul hochgeladen. Laut meinen recherchen ist das wohl aber phpunit 5.7 in dieser wohl die oft genannte CVE-2017-9841 bereits geschlossen ist. Das Autoupgrade Modul sowie alle anderen werden immer brav natürlich in regelmäßigen Abständen aktualisiert. Wir haben im August 2018 das Autoupgrade Modul 4.0 installiert. Seit dem befand sich das phpunit Framework nachweislich mit im modules Ordner. Selbst bei einem update bleibt dieses bestehen, auch wenn das Modul deinstalliert wird. Es muss daher immer manuell gelöscht werden. Die Frage ist nun, welche Schwachstelle nutzen die Angreifer mittlerweile bzw. seit kurzem massiv aus? Ich würde jedem so lange empfehlen das komplette Prestashop Verzeichnis nach phpunit Ordner zu durchsuchen und diese anschließend zu löschen. Edited January 6, 2020 by paddy83 (see edit history) Link to comment Share on other sites More sharing options...
paddy83 Posted January 6, 2020 Share Posted January 6, 2020 27 minutes ago, Wuschel said: Bei 1.6 scheint es wirklich nur das Modul autoupgrade zu sein, aber die Verwundbarkeit von 1.7 ist weit höher, wie eine Verlautbarung von PrestaShop von heute Morgen zeigt, die ich hier übersetzt habe: Leider scheint mich irgendein Moderator auf dem Kieker zu haben, denn meine Posts müssen immer erst freigeschaltet werden. Bei uns (1.6) war auch das phpunit Framework im Modul gamification enthalten, welches ausschließlich immer über das Shop Backend aktualisiert wurde. Daher empfiehlt sich das komplette Shop Verzeichnis zu durchsuchen. Danke für deine top Übersetzung! Echt bestimmt super hilfreich für viele! Link to comment Share on other sites More sharing options...
selectshop.at Posted January 6, 2020 Share Posted January 6, 2020 1 hour ago, Wuschel said: Leider scheint mich irgendein Moderator auf dem Kieker zu haben, denn meine Posts müssen immer erst freigeschaltet werden. Keiner hier hat dich auf dem Kieker. Die Forum-Software ist so eingestellt, dass bestimmte Wörter nicht ohne Moderation verwendet werden dürfen UND auch gibt es ein Zeitlimit, wo User nacheinander Antworten einstellen können. Evtl. bist du zu schnell? Außerdem frage ich mich, warum du nachträglich einen eigenen Thread aufgemacht hast, wo hier schon darüber diskutiert wird? Du hättest deine Sammlung auch hier anfügen können. Und damit das ganze auch übersichtlich in einem einzigen Topic bleibt, wurde deiner gelockt und den Link zu diesem hier gesetzt. Es ergibt keinen Sinn über das ganze Forum mehrere Topics zur Diskussion offen zu halten. Da wirst du mir wohl zustimmen, oder nicht ? Auch ist das Problem bei den letzten PS 1.5. Versionen genauso enthalten, weil dort ebenso Fremdbibliotheken schon enthalten waren, die betroffen sein können. Link to comment Share on other sites More sharing options...
selectshop.at Posted January 6, 2020 Share Posted January 6, 2020 Die Lösung des Problems wird einige Posts weiter oben beschrieben. 22 hours ago, selectshop.at said: vorsichtshalber alle /phpunit/ Unterordner löschen welche unter dem Ordner /modules/xxxx sind. DIES GILT FÜR PS 1.5, PS 1.6. und auch für PS 1.7. Das sind dann folgende: /modules/autoupgrade/vendor/phpunit /modules/ps_facetedsearch/vendor/phpunit - falls vorhanden, da in den neueren Versionen des Modules dieser Ordner nicht existiert /modules/gamification/vendor/phpunit - falls vorhanden, da in den neueren Versionen des Modules dieser Ordner nicht existiert Sowie etwaige Drittmodule wie: /modules/pscartabandonmentpro/vendor/phpunit /modules/ps_checkout/vendor/phpunit Die Liste hier wird evtl. erweitert, falls nötig. Wer einen Root Server besitzt, kann dies auch via SSH Kommando Zeile mit folgendem Befehl im Ordner /modules und natürlich mit Superuser Rechten erledigen: find . -type d -name "phpunit" -exec rm -rf {} \; Link to comment Share on other sites More sharing options...
itnomic Posted January 7, 2020 Share Posted January 7, 2020 Hmm habe mal per SSH das Such/Lösch-Kommando über einen Demoshop laufen lassen, es werden dabei aber nur die Ordner mit dem Namen "phpunit" gelöscht. Es gibt auch Dateien die "phpunit" heißen, siehe ./www/demo-prestashop/modules/ps_facetedsearch/vendor/bin/phpunit ./www/demo-prestashop/modules/ps_legalcompliance/tests/phpunit ./www/demo-prestashop/modules/autoupgrade/vendor/bin/phpunit Habt ihr die Dateien auch gelöscht? Scheinbar sind sie laut github bei den neuen Modulversionen auch nicht mehr vorhanden. Es ist auch immer nur die Rede von Ordnern, aber keine Dateien? Link to comment Share on other sites More sharing options...
selectshop.at Posted January 8, 2020 Share Posted January 8, 2020 Wenn du einen Ordner über Kommando Zeile löscht dann werden auch alle Dateien, welche sich in diesem Ordner befinden auch gelöscht. Das Gleiche gilt, wenn du die Ordner via FTP löscht. Um das Kommando auszuführen, musst du wie oben beschrieben auch das Verzeichnis wechseln. Du führst das Kommando direkt im Ordner /modules aus. Wie heißen die Dateien? Das was du geschrieben hast (/phpunit), sind keine Dateien, sondern Ordner. Link to comment Share on other sites More sharing options...
ostsee Posted January 8, 2020 Share Posted January 8, 2020 ich habe neben der bekannten HTML Datei im / auch noch 2 weitere verdächtige Dateien gefunden: licence.php und invoice.php beide enthalten base64 verschlüsselten php code eine XsamXadoo wurde auf dem server nicht mehr gefunden Betroffen ist ps 1.6.1.24 mit 1-click upgrade 4.8 Ein update auf 4.10.1 scheint die Lücke zuschließen Link to comment Share on other sites More sharing options...
fox@dog1 Posted January 8, 2020 Share Posted January 8, 2020 Uns hats voll erwischt. Wir haben in den Modulen sowie im Verzeichnis Vendor den Ordner «phpunit» gehabt. Natürlich haben wir alles gelöscht und die Module wieder installiert. Unsere Frage: Was ist mit diesen Dateien? Wenn wir nach dem Begriff «phpunit» suchen erhalten wir folgende Dateien: phpunit.xml phpunitxml.dist /modules/blockassurance/vendor/symfony/css-selector/ und im Verzeichnis /modules/autoupgrade/vendor/symfony/yaml phpunit.travis.xml /modules/blockassurance/vendor/doctrine/cache/tests/travis phpunitintegration.xml build.xml (mit folgendem Befehl: install phpunit Run unit tests with PHPUnit $ {basedir}/vendor/bin/phpunit true…. , Die Datei war im Verzeichnis /ps_facetedsearch/vendor/sebastian/global-state map.rsti.inc travis-ci.xml Wir haben das Modul Facettennavigation gelöscht und neu installiert. Jetzt sind build.xml, map.rsti.inc und travic-ci.xml weg. Wie können wir uns schützen. Wir haben gesehen, dass Hacker Homosexuelle Pornos auf unseren Server laden wollten, bis jetzt ohne Erfolg. Wir wollen nicht Drehscheibe für solche und schlimmeren Sachen werden. Können wir uns mit den folgenden Modulen schützen? TOR and IP Blocker Modul und Protect Shop PRO / Anti Hack Modul Besten Dank für euere Hilfe Gruss aus der Schweiz ANjAS-SHOP Link to comment Share on other sites More sharing options...
fox@dog1 Posted January 8, 2020 Share Posted January 8, 2020 Wir haben den Shop runtergeladen und die Verzeichnis durchsucht mit dem Suchwort "phpunit". Hier ist das JPG. Link to comment Share on other sites More sharing options...
fox@dog1 Posted January 8, 2020 Share Posted January 8, 2020 Gut wäre auch, wenn man im HTML-Code über all Prestashop entfernen könnte. Leider taucht das Wort «Prestashop» über all auf der Seite auf. Im Logo und im Footer konnte ich es entfernen. Aber ich finde die Module mit dem Eintrag nicht. Bei der alten PS Version 1.5.6 war das kein Problem. Da war nirgends das Wort Prestashop ersichtlich. Die Script Kiddies versuchten über Monate sich mit dem Anmelde-Link von WordPress meinen Shop zu hacken. Aber jetzt beim neuen Shop 1.7.5 weiss jeder, dass es nicht WordPress ist, sondern Prestashop. Das heisst, jetzt geht’s los. Prestashop downloaden. Lücke suchen. Und dann kanns jeder Mal versuchen, vor allem die Scripts Kiddies. Die haben Zeit. Link to comment Share on other sites More sharing options...
itnomic Posted January 8, 2020 Share Posted January 8, 2020 (edited) 5 hours ago, selectshop.at said: Wie heißen die Dateien? Das was du geschrieben hast (/phpunit), sind keine Dateien, sondern Ordner. Danke für die rasche Antwort. Es sind allerdings keine Ordner sondern nur Dateien (gehörenden vermutlich irgendwelche Bibliotheken) ohne Dateiendung. Finden diese Dateien auf allen Shops, selbst auf die welche von außen gar nicht erreichbar sind. Im Anhang ein Beispiel. ---- edit: OK hat sich erledigt, siehe auch https://github.com/PrestaShop/PrestaShop/issues/17059 . Die Dateien können bleiben! phpunit Edited January 8, 2020 by itnomic New Info (see edit history) Link to comment Share on other sites More sharing options...
ostsee Posted January 8, 2020 Share Posted January 8, 2020 ebenfalls solltet Ihr in den Ordner /js/jquery /js/admin sehen, dort war bei mir eine loader.php und login.php , insgesamt waren 6 fremde Dateien über alle Ornder verstreut zu finden. ich habe es über die Suche nach Datum gefunden. Link to comment Share on other sites More sharing options...
Wuschel Posted January 8, 2020 Share Posted January 8, 2020 4 hours ago, fox@dog1 said: Wir haben den Shop runtergeladen und die Verzeichnis durchsucht mit dem Suchwort "phpunit". Hier ist das JPG. XML-Dateien kannst du löschen oder auch nicht. Da dieser Dateityp nicht ausführbar ist, kann davon auch keine Gefahr ausgehen. 1 Link to comment Share on other sites More sharing options...
Shad86 Posted January 16, 2020 Share Posted January 16, 2020 Ich habe mir aus Zeitmangel jetzt nicht den ganzen thread durchgelesen aber ich weiß um das Thema grundsätzlich Bescheid. Meine kleine Frage wäre nur: dürfen auf dem ganzen Server keine Phpunit Ordner existieren oder dürfen diese nur nicht im Vendor Ordner und im Vendor Ordner jedes Moduls existieren? Bei mir gibt es den Ordner 3 mal: modules/autoupgrade/vendor/bin/phpunit modules/ps_facetedsearch/vendor/bin/phpunit modules/ps_legalcompliance/tests/phpunit Ist damit getan was Presta wollte oder muss ich die 3 Ordner trotzdem noch löschen? Link to comment Share on other sites More sharing options...
rictools Posted January 16, 2020 Share Posted January 16, 2020 Es dürfte kein Fehler sein, diese Ordner zu löschen, da ja PHPUnit für die Funktion der Module sowieso nicht erforderlich sein soll. Link to comment Share on other sites More sharing options...
Shad86 Posted January 17, 2020 Share Posted January 17, 2020 Klingt gut, wird gemacht. Habe für den Notfall ja ein Backup. Danke dir. Link to comment Share on other sites More sharing options...
Wert Posted February 9, 2020 Author Share Posted February 9, 2020 (edited) Heute habe ich eine neue E-mail von 1und1 erhalten. Folgende Dateien wurden aller Wahrscheinlichkeit nach von Dritten modifiziert. Bitte überpruefen Sie diese Dateien und laden Sie diese gegebenenfalls aus einem nicht infizierten Backup erneut auf Ihren Webspace. ~/cbprtoizwx.php ~/rwtcdrnuec.php ~/2031207836.php ~/modules/ollx.php Edited February 9, 2020 by Wert (see edit history) Link to comment Share on other sites More sharing options...
Claudiocool Posted February 9, 2020 Share Posted February 9, 2020 Und was beinhalteten diese Dateien? Link to comment Share on other sites More sharing options...
fox@dog1 Posted February 10, 2020 Share Posted February 10, 2020 (edited) Ich habe auch noch eine lustige Datei gefunden. findpro.php. Die war im Root Verzeichnis. Wenn man den Browser öffnet und https://www.anjasshop.ch/findpro.php eingab, hatte man eine Eingabemaske auf Thailändisch oder Vietnamesisch (eine Schriftsprache mit runden Buchstaben). Wahnsinn… Edited February 10, 2020 by fox@dog1 (see edit history) Link to comment Share on other sites More sharing options...
Wuschel Posted February 10, 2020 Share Posted February 10, 2020 Sag mal, geht`s dir noch gut? Selbst wenn du ihn nicht verstehst, solltest du den Viruscode sofort hier löschen, damit sich nicht noch Nachahmer finden. So naiv kann man doch nicht sein! 👎 Link to comment Share on other sites More sharing options...
fox@dog1 Posted February 10, 2020 Share Posted February 10, 2020 vor 32 Minuten schrieb Wuschel: Soweit habe ich nicht überlegt. Du hast recht. Mir gings mehr darum, ob jemand die Datei entschlüsseln kann und mir sagt, ob noch mehrere Dateien im Shop betroffen sind. Damit ich endlich ruhe habe. 1 Link to comment Share on other sites More sharing options...
FreddyMan Posted February 10, 2020 Share Posted February 10, 2020 Bei mir lagen direkt im Root 3 Dateien: Vertrieb.php altbdy.php google-site-verification Datei Außerdem im Ordner Moduls (direkt im Stammordner nicht in einzelnen Modulordnern) welcome.php statsorigin.php php.ini Die welcome.php und die statsorigin.php enthielten beide base64 verschlüsselten php code! Nachdem ich vor 3 Tagen die 3 Dateien aus dem Root gelöscht hatte, waren sie heute bei einer Kontrolle wieder da. Nach weiterer Suche bin ich dann auf die Dateien im Modul-Ordner gekommen. Die Dateien sind alle gelöscht, Auswirkungen auf den Shop selbst gab es nicht. Kann mir einer sagen was der Zweck des Angriffs ist? ----------------------- Prestashopversion 1.7.2.4 // PHP-Version 7.0.33 Link to comment Share on other sites More sharing options...
Shad86 Posted February 17, 2020 Share Posted February 17, 2020 Hi FreddyMan, die php.ini ist kein Virus oder ähnliches. (Je nachdem was da drin steht) Die Datei an sich ist vollkommen normal und gibt dem Server einige Einstellungen vor. Kannst du mal nach googeln. Und der Zweck eines Angriffs ist schwierig. Jemand zündet dien Auto an, warum hat er das getan? Es kann versucht werden Kundendaten aus zu spähen, es kann versucht werden dir schaden zu zu fügen, es kann versucht werden mehr Traffic auf deren Seiten zu generieren, es kann versucht werden explizit dich aus zu spähen oder über deinen Server andere Leute. Link to comment Share on other sites More sharing options...
FreddyMan Posted February 17, 2020 Share Posted February 17, 2020 3 hours ago, Shad86 said: Hi FreddyMan, die php.ini ist kein Virus oder ähnliches. (Je nachdem was da drin steht) Die Datei an sich ist vollkommen normal und gibt dem Server einige Einstellungen vor. Kannst du mal nach googeln. Und der Zweck eines Angriffs ist schwierig. Jemand zündet dien Auto an, warum hat er das getan? Es kann versucht werden Kundendaten aus zu spähen, es kann versucht werden dir schaden zu zu fügen, es kann versucht werden mehr Traffic auf deren Seiten zu generieren, es kann versucht werden explizit dich aus zu spähen oder über deinen Server andere Leute. Hallo Shad86 Die php.ini war jedoch 1Woche zuvor im Ftp-Backup nicht vorhanden. Durch das entfernen der Datei wurde die Funktion des Webshops auch nicht beeinträchtigt. Wie gesagt, lag die Datei im Ordner Modules zusammen mit den Dateien die Base64 verschlüsselten Code enthielten. Die php.ini enthielt u.a. die Anweisung: exec = ON shell_exec = ON Ich nehme wie gesagt an, dass die php.ini im Modules Ordner nichts verloren hat und eher den Verseuchten Dateien neue Türchen öffnet. Oder bin ich hier komplett auf dem Holzweg? LG Freddy Link to comment Share on other sites More sharing options...
ostsee Posted February 17, 2020 Share Posted February 17, 2020 30 minutes ago, FreddyMan said: Ich nehme wie gesagt an, dass die php.ini im Modules Ordner nichts verloren hat und eher den Verseuchten Dateien neue Türchen öffnet. Richtig erkannt. Achte mal auf das Datum. Wann wurde Diese Datei hochgeladen bzw das letzte Mal geändert? Daran kannst Du evlt weitere Dateien erkennen, die dort nicht hingehören. Link to comment Share on other sites More sharing options...
Shad86 Posted February 17, 2020 Share Posted February 17, 2020 Deshalb schrieb ich ja, kommt drauf an was drin steht. Exec ist schon auffällig und problematisch. Da würde ich auch mal genauer gucken wann sich da etwas geändert hat, hast du jemandem einen Zugang weiter gegeben? Module installiert? Link to comment Share on other sites More sharing options...
FreddyMan Posted February 17, 2020 Share Posted February 17, 2020 Bei täglichen Check waren die Vertrieb.php und die altbdy.php wieder da. Die Google Authentifizierung auch! Ftp Zugang hab nur ich 🤔 und klar sind Module installiert. Modul für pdf-templates, Custom-Fields, Cookie, Datev und div. andere. Link to comment Share on other sites More sharing options...
Shad86 Posted February 18, 2020 Share Posted February 18, 2020 Sorry, falsch ausgedrückt. Ich hätte gedacht, ob zu der Zeit als das los ging mit den Dateien, irgendwas installiert wurde. Link to comment Share on other sites More sharing options...
JBW Posted February 18, 2020 Share Posted February 18, 2020 15 hours ago, FreddyMan said: Ftp Zugang hab nur ich 🤔 und klar sind Module installiert. Modul für pdf-templates, Custom-Fields, Cookie, Datev und div. andere. Hast du denn die Sicherheitlücke durch PHPUnit wie hier beschrieben ist entfernt? Ansonsten entfernst du ja nur die Syntome... Link to comment Share on other sites More sharing options...
fox@dog1 Posted March 6, 2020 Share Posted March 6, 2020 Guten Morgen Ich habe heute schon wieder 3 Viren Dateien gefunden. Zwei im Root Verzeichnis: hodderjz.php / kajbjx.php Und eine im Verzeichnis /upload/fbloginblock/: wso2.php Die IPs sind von Russland und der Ukraine: 185.181.39.254 - - [05/Mar/2020:14:59:54 +0100] "GET /upload/fbloginblock/wso2.php HTTP/1.0" 200 11017 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0" 185.181.39.254 - - [05/Mar/2020:14:59:54 +0100] "GET /favicon.ico HTTP/1.0" 404 38785 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0" 185.5.248.250 - - [05/Mar/2020:15:06:57 +0100] "GET / HTTP/1.0" 301 274 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36" 185.5.248.250 - - [05/Mar/2020:15:06:58 +0100] "GET / HTTP/1.0" 200 143170 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36" 185.181.39.254 - - [05/Mar/2020:15:07:08 +0100] "POST /upload/fbloginblock/wso2.php HTTP/1.0" 200 37062 "https://xxx/upload/fbloginblock/wso2.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0" 185.181.39.254 - - [05/Mar/2020:15:07:13 +0100] "POST /upload/fbloginblock/wso2.php HTTP/1.0" 200 37713 "https://xxx/upload/fbloginblock/wso2.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0" 185.5.248.250 - - [05/Mar/2020:15:07:15 +0100] "GET /hodderjz.php HTTP/1.0" 404 38420 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36" 185.5.248.250 - - [05/Mar/2020:15:07:19 +0100] "GET /hodderjz.php HTTP/1.0" 404 38787 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36" 185.5.248.250 - - [05/Mar/2020:15:07:21 +0100] "GET /hodderjz.php HTTP/1.0" 404 38787 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36" 185.181.39.254 - - [05/Mar/2020:15:07:24 +0100] "POST /upload/fbloginblock/wso2.php HTTP/1.0" 200 37703 "https://xxx/upload/fbloginblock/wso2.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0" 185.181.39.254 - - [05/Mar/2020:15:07:35 +0100] "POST /upload/fbloginblock/wso2.php HTTP/1.0" 200 38361 "https://xxx/upload/fbloginblock/wso2.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0" 185.5.248.250 - - [05/Mar/2020:15:07:38 +0100] "GET /hodderjz.php HTTP/1.0" 200 410 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36" 185.5.248.250 - - [05/Mar/2020:15:07:38 +0100] "GET /hodderjz.php HTTP/1.0" 200 896 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36" 185.5.248.250 - - [05/Mar/2020:15:07:40 +0100] "GET / HTTP/1.0" 301 274 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36" 185.5.248.250 - - [05/Mar/2020:15:07:41 +0100] "GET / HTTP/1.0" 200 144526 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36" 185.5.248.250 - - [05/Mar/2020:15:07:42 +0100] "GET /hodderjz.php HTTP/1.0" 200 1768 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36" 185.5.248.250 - - [05/Mar/2020:15:07:42 +0100] "GET /hodderjz.php HTTP/1.0" 200 896 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36" Ich habe mit meinem Hoster telefoniert. Dieser meinte, dass die Dateien nicht über FTP hochgeladen wurden. Hat jemand eine Ahnung wie die P..... das immer wieder schaffen? Das Modul Fbloginblock habe ich jetzt gelöscht. Zusätzlich habe ich im Modul Antivirus "Schutz gegen SQL/XSS/SHELL/CODE injektion" und "Hochgeladene Datei hochladen(.php, .exe, etc.)" aktiviert und die IPs gesperrt. Wird das reichen? Link to comment Share on other sites More sharing options...
JBW Posted March 6, 2020 Share Posted March 6, 2020 6 minutes ago, fox@dog1 said: . Hat jemand eine Ahnung wie die P..... das immer wieder schaffen? Hast du denn die beschreibene Sicherheitslücke in PHPUnit auf deinem Server geschlossen? Ansonsten kann ja jederzeit wieder neu auf deinen Server zugegriffen werden, die Files die du da neu siehst sind ja nur die Symtone der Infektionen aber nicht die Lücke selber. Link to comment Share on other sites More sharing options...
fox@dog1 Posted March 6, 2020 Share Posted March 6, 2020 Ja, die Module habe ich alle angepasst und upgedatet. Streng nach Ablauf. Link to comment Share on other sites More sharing options...
JBW Posted March 6, 2020 Share Posted March 6, 2020 4 minutes ago, fox@dog1 said: Ja, die Module habe ich alle angepasst und upgedatet. Streng nach Ablauf. Was ergibt denn die Suche auf dem Server mit find . -type d -name "phpunit" Link to comment Share on other sites More sharing options...
fox@dog1 Posted March 6, 2020 Share Posted March 6, 2020 ich habe das ganze per FTP durchsucht und noch folgendes gefunden (siehe jpg) Link to comment Share on other sites More sharing options...
fox@dog1 Posted March 6, 2020 Share Posted March 6, 2020 Link to comment Share on other sites More sharing options...
fox@dog1 Posted March 6, 2020 Share Posted March 6, 2020 Der Hoster hat die Suche per SSH Kommando Zeil durchgeführt und nichts gefunden. Aber wieso braucht das Modul "blockreassurance" den Ordner "guzzlehttp/ Streams"? Das sollte ja nur die Vorteile von unserem Shop anzeigen mehr auch nicht. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now