Spam Skripte > dann Sperre

Fragen zur Installation von CONTENIDO 4.9? Probleme bei der Konfiguration? Hinweise oder Fragen zur Entwicklung des Systemes oder zur Sicherheit?
Antworten
jacke
Beiträge: 303
Registriert: Mi 25. Sep 2002, 19:37
Kontaktdaten:

Spam Skripte > dann Sperre

Beitrag von jacke » Sa 9. Dez 2017, 17:58

Hallo,

schön, dass es hier noch Hilfe gibt.
Men Provider candan sperrt meinen Webaccount täglich. Zu recht. Hier bilden sich täglich Skripte wie z.B. "vyfvitwk.php" in irgend einem Unterverzeichniss. Diese werden dann per:
182.50.135.66 - - [09/Dec/2017:17:26:29 +0100] "POST /contenido/contenido/includes/vyfvitwk.php HTTP/1.0.....
aufgerufen.
Ich habe einige Versionen contenido 4.8.20 drauf laufen und einige 4.9.x.
Lösung 1 kenne ich - alles auf den neusten Stand - und sehen ob es geht.

Gibt es noch anderer, schnellere Lösungen? Wo sind die Lücken für den Bösewicht?

Daba und FTP Passwörter habe ich schon öfter geändert.

Danke schon mal!

homtata
Beiträge: 1142
Registriert: Mi 14. Jan 2004, 14:41
Kontaktdaten:

Re: Spam Skripte > dann Sperre

Beitrag von homtata » So 10. Dez 2017, 17:59

Hast du AMR laufen? Normalerweise sind die /contenido Verzeichnisse dann nicht mehr von außen erreichbar.

jacke
Beiträge: 303
Registriert: Mi 25. Sep 2002, 19:37
Kontaktdaten:

Re: Spam Skripte > dann Sperre

Beitrag von jacke » So 10. Dez 2017, 21:13

HAllo,

nein AMR ha ich nicht laufen. Aber ist es dafür jetzt nicht zu spät?

mfg

homtata
Beiträge: 1142
Registriert: Mi 14. Jan 2004, 14:41
Kontaktdaten:

Re: Spam Skripte > dann Sperre

Beitrag von homtata » So 10. Dez 2017, 22:25

wäre ein versuch wert, ob dann immer noch neue php-dateien im ordner landen.

Oldperl
Beiträge: 4250
Registriert: Do 30. Jun 2005, 22:56
Wohnort: Eltmann, Unterfranken, Bayern
Kontaktdaten:

Re: Spam Skripte > dann Sperre

Beitrag von Oldperl » Mo 11. Dez 2017, 11:16

Servus,
jacke hat geschrieben:
Sa 9. Dez 2017, 17:58
Hier bilden sich täglich Skripte wie z.B. "vyfvitwk.php" in irgend einem Unterverzeichniss.
Eine bekannte Vorgehensweise, die mir schon des öfteren unter gekommen ist. In der Regel hat oder hatte der Hacker FTP-Zugang um seine Scripte auf dem Web abzulegen. Je nach Aufbau/Konfiguration auf dem Server habe ich aber auch schon Querverbindungen bei virtuell Hosts gesehen.
Man sollte in einem solchen Fall alle Server-Logs archivieren, Pfade, Dateinamen und -attribute der Fremddaten notieren, hier vor allem Dateizeiten, den kompletten Webspace entsprechend nach diesen und anderen auffälligen Dateien durchsuchen und bereinigen, sämtliche Caches und Temporäre-Verzeichnisse bereinigen, alle Passwörter, und wenn möglich Benutzernamen, ändern und auch auf den Clientrechner entsprechende Maßnahmen zur Prüfung und Beseitigung von Hackertools durchführen und schlussendlich kann man noch mit den gefunden Daten und den Logs versuchen das Einfallstor zu finden und dieses zu schließen.
Hört sich nicht nur nach viel Aufwand an, kann je nach Größe des Web, Umfang der Daten und zeitlichem Rahmen seit dem Befall recht umfangreich sein.
homtata hat geschrieben:
So 10. Dez 2017, 17:59
Hast du AMR laufen? Normalerweise sind die /contenido Verzeichnisse dann nicht mehr von außen erreichbar.
Das ist so nicht richtig, auch bei eingeschaltetem AMR-Plugin sind diverse Verzeichnisse, und hier gerade das contenido-Verzeichnis, nicht vor Zugriffen geschützt (siehe Ausnahmen in der htaccess).
Auch ändert ein nachträgliches Einschalten ja grundsätzlich nichts am "Befall" und an einer möglicherweise vorhandenen Sicherheitslücke über die ein Hacker Zugriff bekommen kann.

Gruß aus Franken

Ortwin
ConLite 2.1, alternatives und stabiles Update von Contenido 4.8.x unter PHP 7.x - Download und Repo auf Gitport.de
phpBO Search Advanced - das Suchwort-Plugin für CONTENIDO 4.9
Mein Entwickler-Blog

rethus
Beiträge: 1851
Registriert: Di 28. Mär 2006, 11:55
Wohnort: Mönchengladbach
Kontaktdaten:

Re: Spam Skripte > dann Sperre

Beitrag von rethus » Mo 11. Dez 2017, 17:52

Hier mal meine 50cent als Linux-Admin:
Oldperl hat viele wichtige Dinge erwähnt, wobei ich die Reihenfolge ändern würde. Vom "erstmal rumlöschen" [egal ob Cache oder sonstige als Schadcode erkannte Dateien] rate ich dringend ab!

Das Vorgehen ist folgendes:
  • Eine Datei finden, die Schadcode enthält (z.B. in deinem Fall vyfvitwk.php)
  • Die Zeitstempel der Datei mit Linux-Board-Mitteln (ssh nötig) genau eingrenzen (erstellung, letzte Änderung, letzter Zugriff) [das geht nicht, wenn man die zuvor schon gelöscht, hin oder her kopiert hat :wink: ]
  • Mit den Daten in den Logs (Serverlogs... aber auch Contenido-Logs nicht vergessen) den Weg verfolgen, den die Datei weist (meist ist führt dies über diverse andere Aufrufe, Dateien und Scripte).. das ist Fleißarbeit und MUSS wirklich akribisch bis zum ENDE durchgeangen werden. Halbherzig durchgeführte Analysen verbundenn mit voreiligem beseitigen von Schadcode-Dateien erschweren eher die arbeiten (und der Hacker [insofern kein BOT] ist gewarnt.

Ist klar, wann und wo der Schadcode auf den Server gekommen ist, hast du dein Sicherheitsloch gefunden... erst jetzt wirst du aktiv in Bezug auf Absicherung:
  • Du schließt das Sicherheitsloch (1. Hilfe für "schnelle" Workarrounds kann / muss nicht immer... .htaccess-Schutz für sensitive Unter-Verzeichnise sein.. Dennoch MUSS im Nachgang "ordentlich" abgesichert werden)
  • Du analysierts die Schadscripte und studierst deren Aufbau um Suchstrings zu ermitteln, die dort oft eingesetzt werden. Mit diesen Suchstrings und Linux-Board-Mitteln (via ssh) durchsuchst du den gesamten Webspace.
    Tip aus der Praxis: oft wird base64_decode, eval, getpw, unescape oder andere verwendet, wobei NICHT jedes vorkommen dieser Keywords Schadcode sein muss. Contenido verwendet z.B. das BÖSE eval auch recht häufig.... Also hier musst du mit einem gewissen Verständnis für die Materie an die Analyse gehen.
    Es gibt auch noch einige andere Schlüsselwörter, die zuvor erwähnten sollen dir nur die Richtung weisen, in die du dich bewegen solltest.
  • Nachdem du alle Schadscripte gefunden hast, löschst (ich sichere mir diese für spätere Analysen auch schon mal gerne) du diese und vermerkst dir den Zeitpunkt deiner Reinigung.
  • Dann änderst du - wie von Oldperl bereits beschrieben - alle Zugangsdaten der Software, die in dem Webspace lag (DB, CMS-Backend, Vorsichthalber auch FTP, SSH].
  • Hast du nen Wald/Wiesen Provider bei dem du z.B. auch nen Webmailer in deinem Webspace liegen hast, oder sogar irgendwie auf deine Mailaccounts über FTP/SSH zugreifen kannst ( :shock: ja, sowas solls geben... wenn du schlecht konfigurierten v-server hast liegen die schon mal unter /var/mail), musst du auch deine Maildaten ändern, und alle Zugangsdaten von Diensten, die dir ggf. in dem Zeitraum zugegangen sind.


Nachdem du alles bereinigt hast, solltest du weiter den Server täglich checken. Dabei z.B. via ssh und 'find' die täglich im Webspace neu erstellten Daten auf verdächtige Inhalte prüfen. Wenn da wieder eine Schadcode-Datei gefunden wird, wieder wie oben beschrieben vorgehen.

Aus meiner Erfahrung ist ein gehackter FTP-Account sehr viel seltener, als das ausnutzen von Programmier-Fehlern (häufig nicht abgesicherte Formulare), und unzureichend gesicherten Backends. Sehr oft durch veraltete (oder mal Testweise installierte und dann vergessene Software [phpbb, phpmyadmin usw.]), die bekannte und leicht auszunutzende Sicherheitslücken haben.


AMR: Beim AMR pflichte ich Oldperl bei... AMR sichert nicht wirklich gegen Zugriff ab. Es gibt sogar einen BUG, der nur in Verbindung mit AMR und der anzeige von Fehlerseiten Auftritt und das ausführen von Schadcode zulässt. Und je nachdem wie deine .htaccess aussieht, lässt diese auch den direkten Zugriff auf Dateien zu, wenn Sie real existieren (Stichort -f Flag).


BTW: Wenn du ein Contenido 4.9.6 - 4.9.9 einsetzt, muss du zwingend auf 4.9.12 upgraden... hier helfen keine Maßnahmen der Absicherung.
Could I help you... you can help me... buy me a coffee . (vielen ❤ Dank an: Seelauer, Peanut, fauxxami )

xstable.com: - HighSpeed Hosting, Domains, DomainReselling, Linux-Administration
suther.de: - App-Programierung, High-Performance-Webpages, MicroServices, API-Anbindungen & Erstellung

Software... ein Blick wert: GoogleCalender Eventlist, xst_dynamic_contentType

jacke
Beiträge: 303
Registriert: Mi 25. Sep 2002, 19:37
Kontaktdaten:

Re: Spam Skripte > dann Sperre

Beitrag von jacke » Mo 11. Dez 2017, 18:14

Vielen, vielen Dank erst mal.

ne das freiweg löschen habe ich schon ausprobiert - natürlich ohne Erfolg. Zugänge außer Backend habe ich mehrfach geändert.
Alle Skripte z.B. heute: zarvckwd.php
haben das Entstehungsdatum 15.11.2017 14.02Uhr

Allerdings habe ich die Orner vor einigen Tagen gesichert und da gibt es nichts was nicht reingehört oder dieses Datum hat. (habe danach schon gesucht).
Bestes Beispiel der classes-Ordner von letzter Woche. Alle Dateien heißen classes.....php
Heute ist Besuch von zarvckwd.php drin.


97.74.24.4 - - [10/Dec/2017:06:08:10 +0100] "POST /contenido/contenido/classes/contenido/vbcxzhin.php HTTP/1.0" 200 71 "http://......./contenido/classes/contenido/vbcxzhin.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36" - ......

Oldperl
Beiträge: 4250
Registriert: Do 30. Jun 2005, 22:56
Wohnort: Eltmann, Unterfranken, Bayern
Kontaktdaten:

Re: Spam Skripte > dann Sperre

Beitrag von Oldperl » Di 12. Dez 2017, 08:56

Servus,
rethus hat geschrieben:
Mo 11. Dez 2017, 17:52
Aus meiner Erfahrung ist ein gehackter FTP-Account sehr viel seltener, als das ausnutzen von Programmier-Fehlern (häufig nicht abgesicherte Formulare), und unzureichend gesicherten Backends.
Jein. Sicherlich sind schlecht programmierte Module und Co. sehr oft ein Einfallstor, jedoch ist es mir schon recht häufig vorgekommen, das gar nicht der Server selbst gehackt wurde, sondern ein Client-PC, über den der Zugang zur Datenpflege des Servers läuft. So werden beispielsweise noch immer beim gerne genommen Filezilla Passwörter im Klartext in den entsprechenden Konfigurationsdateien gespeichert. So benötigt ein Hacker nicht mal ein spezielles Tool, sondern einen einfachen Remote-Zugriff auf den Rechner und das Wissen, wo die Dateien liegen, um FTP-Passwörter auszuspähen.
Noch einfach ist es als Man-In-The-Middle in einem Netzwerk, wenn Passwörter per unverschlüsselter E-Mail inklusive Nutzername verschickt werden.

Daher lautet bei einem Hackerangriff auf den Webspace/Server, wenn klar ist das er per FTP erfolgt, die Devise auch immer, alle genutzten Client-Rechner entsprechend zu prüfen bevor man die Passwörter ändert.

Gruß aus Franken

Ortwin
ConLite 2.1, alternatives und stabiles Update von Contenido 4.8.x unter PHP 7.x - Download und Repo auf Gitport.de
phpBO Search Advanced - das Suchwort-Plugin für CONTENIDO 4.9
Mein Entwickler-Blog

rethus
Beiträge: 1851
Registriert: Di 28. Mär 2006, 11:55
Wohnort: Mönchengladbach
Kontaktdaten:

Re: Spam Skripte > dann Sperre

Beitrag von rethus » Di 12. Dez 2017, 09:51

Oldperl hat geschrieben:
Di 12. Dez 2017, 08:56
Daher lautet bei einem Hackerangriff auf den Webspace/Server, wenn klar ist das er per FTP erfolgt, die Devise auch immer, alle genutzten Client-Rechner entsprechend zu prüfen bevor man die Passwörter ändert.
Jep, sehe ich genau so. Und FileZilla rate ich auch immer dringend von ab... aber in der Windows-Welt ist er leider recht weit verbreitet.
Wollte mit meiner Aussage zu FTP-Angriffen nicht sagen, das man die kategorisch ausschließen sollte.. nein im Gegenteil finde ich deine Anregung wichtig, sich Gedanklich nicht nur auf den Webspace zu konzentrieren, sondern einen weiteren Blick für mögliche Gefahren zu bekommen.

Bei Angriffen über FTP sprach ich eher aus eigener Erfahrung. Werde recht häufig zum reparieren gehackter Seiten rangezogen... dabei ist sehr selten FTP das Einfallstor, und wenn... dann meist eher über eine BruteForce-Attacke.

Ich persönlich denke das es für einen "Webseiten-Hacker" auch viel zu Mühsam wäre, erst einen Clientrechner zu infiltrieren, oder eine Men-In-The-Middle Attack auszuführen, um danach eine Webseite zu manipulieren. Xss, SQLInjection, oder nicht abgesicherte Software (ich sag nur Contenido 4.6 & admin-Login) mit Schwachstellen oder Upload-Funktionen gibt es zu Hauf im Netz. Und wenn ein Hacker es nicht gerade auf genau deine Seite abgesehen hat, macht er sich die Mühe nicht, so schwere Geschütze aufzufahren.

Die Mühe für solche Attacken sind dann eher bei den Webseiten der großen Liga zu finden. Auf die kleinen Shops und CMS-Systeme werden meistens eher Bots auf Sicherheitslücken in der Software losgelassen... da machen sich die Hacker nicht mal selbst die Finger schmutzig.

Aber auch hier: Das soll nicht heißen, das dies nie passiert. Wollte nur meine persönlichen Erfahrungen mit Hackerangriffen hier teilen.
Could I help you... you can help me... buy me a coffee . (vielen ❤ Dank an: Seelauer, Peanut, fauxxami )

xstable.com: - HighSpeed Hosting, Domains, DomainReselling, Linux-Administration
suther.de: - App-Programierung, High-Performance-Webpages, MicroServices, API-Anbindungen & Erstellung

Software... ein Blick wert: GoogleCalender Eventlist, xst_dynamic_contentType

jacke
Beiträge: 303
Registriert: Mi 25. Sep 2002, 19:37
Kontaktdaten:

Re: Spam Skripte > dann Sperre

Beitrag von jacke » Do 28. Dez 2017, 15:15

Vielen Dank für euer Anteilnahme und Hilfe. Es hat aufgehört. Ich habe ein 4.18 Version komplett gelöscht und neu installiert. Die Bösen Dateien hatten das datum der Installation aus meienm ersten Rettungsversuch. Aber hier mal ein Auszug aus einer der 100 BÖSEN DATEIen:
<?php
andere kleinere böse Datei:
<?php $
Einen Guten Rutsch ins neue Jahr!!

jacke

Hinweis der Moderation: Der PHP-Code wurde entfernt, um nicht irgendwelche Personen zu "inspierieren". Vielen Dank aber, wir haben das seitens der CONTENIDO-Entwicklung zur Kenntnis genommen!
Zuletzt geändert von frederic.schneider_4fb am Fr 29. Dez 2017, 15:48, insgesamt 1-mal geändert.

jacke
Beiträge: 303
Registriert: Mi 25. Sep 2002, 19:37
Kontaktdaten:

Re: Spam Skripte > dann Sperre

Beitrag von jacke » Di 6. Feb 2018, 09:49

Hallo,

es hat doch nicht aufgehört....
Ich denke der Sowjetbürger hatte nur kurz Urlaub. Ich muss jeden Tag meinen Tarif freigeben und die entsprechenden Spam-Skripte suchen und löschen.
Kann mir eine(r) helfen? Ein schmaler Taler ist auch drin.

jacke

Oldperl
Beiträge: 4250
Registriert: Do 30. Jun 2005, 22:56
Wohnort: Eltmann, Unterfranken, Bayern
Kontaktdaten:

Re: Spam Skripte > dann Sperre

Beitrag von Oldperl » Di 6. Feb 2018, 10:11

Servus,
jacke hat geschrieben:
Di 6. Feb 2018, 09:49
es hat doch nicht aufgehört....
Ist inzwischen klar wo der Hacker rein kommt?
jacke hat geschrieben:
Di 6. Feb 2018, 09:49
Kann mir eine(r) helfen? Ein schmaler Taler ist auch drin.
Klar, einfach eine PM schicken.

Gruß aus Franken

Ortwin
ConLite 2.1, alternatives und stabiles Update von Contenido 4.8.x unter PHP 7.x - Download und Repo auf Gitport.de
phpBO Search Advanced - das Suchwort-Plugin für CONTENIDO 4.9
Mein Entwickler-Blog

Antworten