Contenido gehackt?

[malsdgtac]

Hallo,

wir haben eine Contenidoinstallation mit mehreren Mandanten. Nun haben wir das Problem, dass in einem Mandantenverzeichnis (und teilweise im root) fremde Dateien eingeschleust werden. Als ersten Schritte hatten wir mehrfach die fremden Dateien gelöscht, dann haben wir letzte Woche das Contenido der Version 4.9.3 auf 4.9.9 geupdatet. Das System hat also nun die aktuelle Version. Zum Upgrade haben wir auch alle alten Dateien gelöscht und auch alle Mandantenordern, wo möglich, mit Sicherungen geupdatet. Davon ausgenommen waren eigentlich nur die Uploadordner.

Leider hat das nichts gebracht. Am ersten Tag nach dem Update, dachte ich noch, das Problem wäre gelöst, ist es aber leider nicht. Könnt ihr mir weiterhelfen? Lt. provider werden die Dateien nicht per FTP sondern über das CMS eingeschleust.

[Faar]

Es gibt einen (aktuellen?) Virus, der sich in den Browser einklinkt.
So ziemlich gleiches Verhalten fand ich bei einem Kunden, der aber eine Joomla-Installation laufen lässt.
Ziel war fast immer die index.php oder .html Datei.
Es gibt dann eine Reihe von seltsamen Dateien, die ebenfalls Schadcode enthalten.

In den index-Dateien war eine fast endlose Meta-Tag-Zeile, die vermutlich irgendetwas nachlädt.
Alternativ tritt auch ein Javascript-Code auf.
Und dann gibts da noch den Cyb3rMan1ac, der sich in x.htm Dateien verewigt. Googelt man danach, findet sich so einiges.
Vieles davon wird ein Joomla-Problem sein, aber Teils kann man auch Provider verdächtigen, dass ihr Server nicht dicht ist.

Jedenfalls haben wir mit Contenido absolut keine Probleme.
Wenn, dann war der PC des Kunden gehackt und so wurde Contenido immer wieder neu infiziert, sowie der Kunde sich eingeloggt hatte.
Das ging so lange, bis sich der Kunde erweichen ließ, dass er mal einen alternativen Virusscanner installierte, der dann auch sofort fündig wurde.

[rethus]

Ich habe schon sehr viele gehackte Server ( und auch Contenido-Systeme) erfolgreich bereinigt und abgesichert. Das einfache Löschen von fremden Dateien bringt überhaupt nichts. Es ist wie das rausschaufeln von Wasser aus einem Boot mit loch... Wenn du das Loch nicht findest und stopfst, ist es nur verbrannte Zeit.
Erfahrungsgemäß muss man sich auch recht gut auf einem Linux-Server auskennen um die Fährte in richtiger Weise aufzunehmen und zurück zu verfolgen... (Logfiles sind ein entscheidender Startpunkt... aber halt auch nicht "der Weisheit letzter Schluss").

Hier muss man wirklich gezielt vorgehen, das Einfallstor aufspüren, und entsprechende Gegenmaßnahmen ergreifen.
Gerne kann ich dich dabei unterstützen - bei Interesse kannst du mich per PN anschreiben.

[malsdgtac]

Hallo Faar,

vielen Dank für deine Antwort. Ich bin mich auch noch nicht sicher, ob es am Contenido liegt, wir haben bei vielen anderen Installationen und auch bei den anderen Mandanten keine Probleme - und ich hoffe, das bleibt auch so.

Bei der Variante mit dem (Browser)virus - könnte ich also feststellen, wenn die fremden Dateien nach dem Login des betroffenen Users entstehen? Oder gab es dazu keinen direkten Zusammenhang? ich werde da mal beobachten.
Wegen dem anderen Tipp werde ich googeln.

Das was du beschreibst klingt ähnlich dem was passiert. Es gibt fremde Dateien im Mandantenordner, in manchen Unterordnern im Mandantenordner und auch neue Ordner im Mandantenordner, die sehr "typische" Namen haben wie "news", "html", "uploads" oder "blog" heute waren auch Dateien dabei, die sehr nach Wordpress geklungen haben. Am verstecktesten sind immer die Ergänzungen im Root, die sich heute z.B. hinter includes/js/jquer-ui.js versteckt haben und dann Schrott im Code. Die hochgeladenen Dateien haben eigentlich fast immer (alle habe ich mir nicht angesehen) ähnlichen Code - um Schadecode von fremden Servern aufzurufen. Teils als .php-Dateien, teilweise auch als .txt-Dateien. Heute habe ich auch mal eine Datei gefunden, die Schadcode auf den Rechner laden sollte.

Falls also noch jemand Tipps haben, bin ich euch sehr dankbar dafür.

[Faar]

Hallo Smac,
es ist teils auch so wie Rehtus es sagt aber meistens sind einem bei shared Hosting die Hände gebunden. Und was die Logfiles anbelangt, z.B. 11 MB Logfile an einem Tag wollen erst einmal durchsucht sein. Da bewegt sich der inzwischen winzige Scrollbutton am rechten Rand kaum, wenn man Zeile für Zeile durch sieht. Und wenn du da nicht weiß, welcher Tag, dann wird es ganz aussichtslos.

Aber wenn du das beobachtest, dann siehst du am Datei-Datum, zu welcher Zeit der Täter zugeschlagen hat.
Das Datum verrät die neuen Hackerdateien meistens.

Was mir zum geschilderten Fall noch einfällt: Ein Passwort des Kunden war so kurz und einfach, dass ein Brute-Force Angriff erfolgreich war. So kamen sie als Admin ins Backend und konnten weitere Dateien hochladen.
Brute-Force konnte man das fast nicht mehr nennen, es kam nur alle halbe Sekunde eine Anfrage, aber da es keine Login-Kontrolle* gab, war irgendwann mal der Treffer da.
Bei Dir könnte also irgendein User "1234" oder "passwort" als Passwort haben. Wie sieht denn die Einstellung in der config.misc.php unter Password Settings aus?
Wenn da z.B. nur 6 Zeichen erlaubt sind und alles andere eine 0 hat, dann siehts böse aus.
Mach da mindestens 12 Zeichen und mindestens eine 1 hinter jeder anderen Einstellung.

Das nützt aber nichts, wenn die Hacker bereits das Passwort eines Users haben und dann über das Upload-Verzeichnis ein Script hochladen, das ihnen alle Rechte in dem Websapce geben.
Du könntest das UserLog anschauen, wenn Du weißt, in welcher Zeit etwa der Hacker aktiv war.


* Ich warte immer noch auf das "Login-Attempt" seitens 4fb

[rethus]

es ist teils auch so wie Rehtus es sagt aber meistens sind einem bei shared Hosting die Hände gebunden. Und was die Logfiles anbelangt, z.B. 11 MB Logfile an einem Tag wollen erst einmal durchsucht sein. Da bewegt sich der inzwischen winzige Scrollbutton am rechten Rand kaum, wenn man Zeile für Zeile durch sieht. Und wenn du da nicht weiß, welcher Tag, dann wird es ganz aussichtslos.

Naja ganz so langwierig ist die Analyse zum Glück nicht, das man Zeile für Zeile durchgehen müsste. Wenn man ein wenig Erfahrung gesammelt hat, weiß was man Sucht, oder wie man Suchen muss (sich also z.B. auf der Linux-Konsole auskennt) entwickelt man Vorgehensweisen solche Lücken recht schnell aufzufinden, bzw. kennt man gewisse Schwächen in den jeweiligen Contenido-Versionen und kann dort direkt ansetzen.

Das hier ist schon eher der Anfang des Wollknäuels:

Aber wenn du das beobachtest, dann siehst du am Datei-Datum, zu welcher Zeit der Täter zugeschlagen hat.
Das Datum verrät die neuen Hackerdateien meistens.

Hier kommt es auch wieder auf die Mühe und Fähigkeit des Hackers an. Datei-(Meta)Daten kann man auch manipulieren. Viele Angriffe passieren aber auch durch BOT-Netze... die machen sich solche Mühen (zum Glück) nicht.
Aber wie du schon richtig sagst: Bei shared-Hosting ohne SSH-Zugang wird es richtig zäh - aber d.h. nicht das es in jedem Fall unmöglich ist.