CONTENIDO Forum

Hi.

Mit der MR ist "nur" die front_content.php im Mandantenverzeichnis mehr oder minder vor dem gröbsten "geschützt". Da die ModRewrite (== MR) Regeln im Backend nicht greifen ist die MR keine Schutzmassnahme.

Bitte auf 4.6.24 bzw. 4.8.6 aktualisieren.

So long,
Holger

MR ist ModRewrite. Da werden die URLs Suchmaschinenfreundlich umgewandelt. Also anstatt lieber

Ein Bekannter von mir wurde heute gehackt.
Frontent sieht aus wie immer aber im Backend geht der Punk ab.

Mal eine Frage. Reicht es nach so einem Angriff nur das Backend, also alles außer dem ordner "cms" (in dem sich das Frontend abspielt grafisch gesehen) neu aufzuspielen oder muss man mehr tun? Z.B. die Datenbank leeren (dadurch geht jeglicher Content verloren) odercontenido komplett neu drauf machen inkl. dem "cms" Ordner was bedeuten würde, dass man die Seite komplett neu gestalten müsste.

Grüße
Matt

Ich würde an deiner Stelle den Link schnell wieder löschen und am Server die index.php durch das Original ersetzen. Sonst spielen sich noch ein paar Leute mit deinem Server...

Ist ein phpBackdoor Trojaner für Httpserver...

Bei meinen Projekten fiel mir auf, dass es innerhalb einer Sekunde viele Fehlermeldungen bezüglich des Login-Form gegeben hat:
Wer versucht sich da in einer Sekunde gut 50 mal einzuloggen?
Oder ist das etwas anderes und gar kein Hack-Versuch?

Wenn wir schon dabei sind:
Kann man im Admin-Login nicht eine Zeitsteuerung einbauen, so dass nach 5 vergeblichen Versuchen eine oder drei Stunden vergehen, bis man wieder 5 mal versuchen kann, sich einzuloggen?

Hi.

Nach erfolgreichen oder auch nur versuchten Hackversuchen würde ich komplett alles neu einspielen und auch Passwörter ändern! Man weiß leider nie was hinterlassen wurde.

Bei den Update auf 4.6.24 bzw. 4.8.6 werden zwar alle Dateien überschrieben, aber wer weiß was noch zusätzlich auf den Servern hinterlegt wurde. Wir hatten zum Fälle, in denen neue .log, logs und log Verzeichnisse angelegt wurden und dann dort Skripte für Remote-Shells hinterlegt wurden.

So long,
holger

holger.librenz_4fb hat geschrieben:Man weiß leider nie was hinterlassen wurde.

Ich habe alles durchsucht *uff*

...und nur bei den Cronjobs etwas gefunden, was ich nicht eingestellt hatte und beim Access-Log des Servers siehe da, mein anhänglicher Freund vor zwei Tagen: ...versuchte von aussen genau auf die mir verdächtigen job-Dateien zuzugreifen.

Kennt jemand diesen ominösen Anhängsel, der jedesmal beim Hack mit im Paket ist?
libwww-perl/...
Taucht in den Stats auch als Browser auf.
Googelt mal jemand und kann mir sagen, was der macht?
http://search.cpan.org/dist/libwww-perl/

libwww-perl ist eine Bibliothek, die es Perl-Programmierern leicht macht, http-clients zu schreiben. Bei den ganzen Angriffen sitzt natürlich keiner am Browser und macht das per Hand. Statt dessen wird ein Perl Script geschrieben, mit dem die Anfragen automatisiert gestellt werden. Diese Perl Scripte benutzen libwww-perl, damit man sich nicht um die Details auf Protokolebene kümmern muss. Siehe auch http://de.wikipedia.org/wiki/Library_for_WWW_in_Perl. Viele Grüße, quacon

Wenn libwww-perl ein offizielles Tool ist, macht es dann Sinn, es per .htaccess auszusperren?

Und das hier habe ich auf meiner Contenido Installation unter contenido/includes/ gefunden:
bjorks.txt
anakbugis.jpg

...mit schön viel Programmcode statt nur Text und einem netten Bild des Besuchers.

Eigentlich ist es einfach, den zu finden, nach einem Update:
Alle Dateien haben logischerweise das heutige Datum durch das Update, bis auf wenige von der ursprünglichen Installation.
Nur der Trojaner taucht mit einem ganz anderen Datum auf...

Nach meiner Einschätzung schadet es zumindest nicht, libwww-perl als Client auszusperren, da wohl fast kein normaler Benutzer diese Zeichenkette als Browsername übermittelt. Allerdings ist es natürlich kein Schutz, denn der Angreifer kann anstelle von libwww-perl natürlich jeden anderen beliebigen Wert übermitteln. Viele Grüße, quacon

@Faar: Daher löscht man ja auch bevor man updatet die Verzeichnisse contenido, pear und conlib

Ich habe mir heute diese ominösen txt - Dateien heruntergezogen und ein wenig angeschaut. Im Prinzip wird immer versucht eine .txt Datei aufzurufen, das könnte man aber per Default bei allen Request unterbinden, da Contenido keine .txt Dateien includet, oder?

mko hat geschrieben:..., das könnte man aber per Default bei allen Request unterbinden, da Contenido keine .txt Dateien includet, oder?

Noch besser wäre es, gar keine entfernten Dateien includen zu können (Stichwort: allow_url_fopen und allow_url_include).

Tja - da braucht man aber PHP5 und das geht nur ab Apache2 usw.

Ausnahme ersteres...

@mko: Für allow_url_fopen doch nicht.

holger.librenz_4fb hat geschrieben:Hi.
Bitte auf 4.6.24 bzw. 4.8.6 aktualisieren.

So long,
Holger

Kann das Update auch auf Contenidos mit MR aufgespielt werden oder verliert man dadurch die MR-Funktion?