Leider wird die .htaccess allen Anschein nach woanders überschrieben.
Ich suche nun mal nach allen Dateien in denen .htaccess vorkommt.
irgendeine muss ja die Datei neuschreiben.
Wer suchet der findet.
Die schuldige Datei ist die /wp-includes/nav-menu.php
Dort gibt es eine Funktion my_correct an der folgendes als Parameter übergeben wird ‚/home/www/web17/html/werbeagentur/wp-includes/..‘, demnach das Hauptverzeichnis /werbeagentur.
Dort steht der Code base64 decodiert drin. Auch eine chmod-Anweisung mit 0444 habe ich dort gefunden und darauf in die Funktion ein file_put_contents eingefügt. Volltreffer.
Sobald die Datei geladen wird, wird der Code ausgeführt und die .htaccess überschrieben. Das Einbinden passiert beim Aufbau der Seite, wenn die Menüs erstellt werden.
Beim require durch wp-settings.php wird ja der Code durch den PHP-Interpreter gejagt. Die Anweisung my_correct(dirname(__FILE__) . ‚/..‘); (Zeile 549) sorgt für das Neuerstellen der .htaccess.
Damit scheint das Problem ein Bug in WordPress zu sein.
Auch wenn das sicher nicht die schönste Lösung ist,
Das Auskommentieren der Zeile 549, hat das Rewrite-Problem gelöst.
Warum allerdings diese Funktion die Anweisungen als base64-dekodierten String enthält ist mir schleierhaft ebenso ihr Sinn.
Auffällig ist, dass diese Funktion im Gegensatz zu den anderen Funktionen in der nav-menu.php nicht dokumentiert ist.
Bei allen anderen Funktionen findet sich ein Kommentarblock wie z.B. bei mytime
/**
* Returns all navigation menu objects.
*
* @since 3.0.0
* @since 4.1.0 Default value of the 'orderby' argument was changed from 'none'
* to 'name'.
*
* @param array $args Optional. Array of arguments passed on to {@see get_terms()}.
* Default empty array.
* @return array Menu objects.
*///istart
wie ich erwähnte, diese WP Installation ist gehackt
https://de.forums.wordpress.org/topic/htaccess-wird-standig-falsch-erneuert?replies=20#post-545491
Lösungen dazu schrieb ich ziemlich weit oben
suche nach Malware in nav-menu.php und du wirst sehr oft fündig.
Aber ich habe vorm Hochladen von WordPress die deutsche Version direkt von wordpress.org heruntergeladen und das System über das WP-Backend erneut neu installiert. Demnach ist der Hack doch wohl in der zip-Datei die man von wordpress.org herunterlädt.
Zur Sicherheit lade ich mir gleich nochmal die aktuelle deutsche Version von WordPress runter und prüfe ob da auch der Code drin ist.
Spitze!!!
Habe die Datei, die ich auf meinem Arbeitsrechner habe auf diesen Code überprüft. Dort ist er nicht drin.
Dann werde ich nochmal unseren Hoster bitten, auf dem Server einen Malware-Check zu machen. Denn wenn meine Dateien den Code nicht beinhalten, dann muss die Datei doch auf dem Server geändert worden sein.
ja weil diese Datei doch nur ein Teil des Hacks ist
Nervig ist der Fehler allemal.
Nur was bezweckt man damit.
Das der Server aufgrund von Weiterleitungsschleifen abraucht?!
Habe die Dateien alle abgeglichen.
Nur diese Datei war unterschiedlich.
Weitere Änderungen konnte ich nicht feststellen.
Bleib abzuwarten, ob unser Hoster etwas findet.
Danke für die guten Tipps mit der nav-menu.php.
Ich hatte gestern das gleiche Problem. Mit der neusten WP-Version. Auch da war diese von dir beschriebene gehackte drin.
Nachdem ich sie durch das Original ersetzt hatte lief alles wieder richtig.
Strange.
Oder wir haben den gleichen Hoster…… 🙂
Hy fk59,
freut mich dass ich dir helfen konnte.
Noch ein Tipp, schau doch mal nach, ob bei dir evtl. Scripte sind, die preg-Funktionen nutzen. Bei mir war es ein altes FCKeditor-Skript das gehackt wurde. Dort wurde eine Schwachstelle ausgenutzt. stand etwas in der Art
preg_replace(Muster\e,““,$_POST[‚xyz‘]) drin.
Näheres findest du z.B. in diesem Youtube-Video https://youtu.be/iuqv-2DC1g8 (französisch) oder http://blog.benny-baumann.de/?p=332.
Im Prinzip nutzt der Angreifer darüber die Möglichkeit aus, mittels preg_replace ein eval auszuführen, dass er i.d.R. base64-kodiert in der Post-Variablen übergibt.
Betroffen sind quasi alle Hoster, da diese i.d.R. eval erlauben um z.B. Backups durch den Kunden durchführen zu lassen, wenn dieser an der Webseite etwas ändern will.
Ab PHP 5.5 ist der Modifier veraltet und wir zum Glück mit Version 7.0.0 komplett entfernt.
Evtl. kann man diesen Modifier auch verbieten. Kannst du deinen Hoster ja mal darauf ansprechen.
