Jump to content
Wert

Prestashop VIRUS - XSAM_XADOO Lücke

Recommended Posts

Posted (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 by selectshop.at
Title expanded to XSAM_XADOO problem (see edit history)

Share this post


Link to post
Share on other sites

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.

grafik.png.b426162269a91e3b1786abd6e97dc0b6.png

Share this post


Link to post
Share on other sites
Posted (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.

grafik.png.b426162269a91e3b1786abd6e97dc0b6.png

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 by Wert (see edit history)

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites
Posted (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 by Wuschel (see edit history)

Share this post


Link to post
Share on other sites
Posted (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 by selectshop.at
/phpunit/ ergänzt (see edit history)

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

grafik.png.32d10371f1571cf585e9d3aac51d9b8e.png

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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 {} \;

 

Share this post


Link to post
Share on other sites
Posted (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 by paddy83 (see edit history)

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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 {} \;

 

 

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Wir haben den Shop runtergeladen und die Verzeichnis durchsucht mit dem Suchwort "phpunit". Hier ist das JPG.

InkedPHPUNIT_LI.jpg

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Posted (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-screen.jpg

phpunit

Edited by itnomic
New Info (see edit history)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

  • Thanks 1

Share this post


Link to post
Share on other sites

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?

 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Klingt gut, wird gemacht. Habe für den Notfall ja ein Backup. Danke dir.

Share this post


Link to post
Share on other sites

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 by Wert (see edit history)

Share this post


Link to post
Share on other sites

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 by fox@dog1 (see edit history)

Share this post


Link to post
Share on other sites

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! 👎

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

 

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Sorry, falsch ausgedrückt. Ich hätte gedacht, ob zu der Zeit als das los ging mit den Dateien, irgendwas installiert wurde.

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Ja, die Module habe ich alle angepasst und upgedatet. Streng nach Ablauf.

 

Share this post


Link to post
Share on other sites
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" 

 

Share this post


Link to post
Share on other sites

ich habe das ganze per FTP durchsucht und noch folgendes gefunden (siehe jpg)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More