Astroid Framework Angriffswelle

    Joomla Version
    alle
    PHP Version
    Unbekannt
    Hoster
    egal

    SICHERHEITSWARNUNG – Nutzer von Astroid Framework: Schaltet eure Websites JETZT mithilfe einer .htaccess-Datei oder einer anderen Schutzmaßnahme auf Serverebene ab.

    Derzeit gibt es eine Angriffswelle, die auf Websites mit Astroid Framework abzielt. Der Angriff installiert eine Hintertür, ein System-Plugin namens plg_system_blpayload. Wenn ihr dieses Plugin auf eurer Website findet, wurde diehre Website gehackt und ihr müsst eine saubere Sicherung wiederherstellen, die aus der Zeit vor der Installation des Plugins stammt.

    Es ist noch kein Patch verfügbar. Lasst die Websites daher offline, bis das Problem behoben ist, um eine Ausnutzung zu verhindern.

    myrtus Die Antwort auf Deine Frage ist ein klares Jein!

    • Nach den derzeitigen Erkenntnissen verhindert ein .htaccess-Schutz für das Administratorverzeichnis die Infektion (s. Link in #3).
    • Trotzdem würde ich auf verdächtige Plugins prüfen:
      Image
      und alle Passwörter ändern.

    Freundliche Grüße aus Wächtersbach, Rolf Dautrich

    Zitat von Rolf Dautrich
    • Nach den derzeitigen Erkenntnissen verhindert ein .htaccess-Schutz für das Administratorverzeichnis die Infektion (s. Link in #3).

    Korrekt. Bisher konnte ich aber keine weiteren, verdächtigen Plugins im Verzeichnis auf dem Server bei den betroffenen Kunden finden. Ob eine tatsächliche Änderung der Passwörter für Joomla Admins, FTP oder Datenbank notwendig ist, konnte ich bis jetzt noch nicht genau ermitteln. Vielleicht kann dabei jemand noch unterstützen.

    * die Version 3.3.11 schließt die Lücke

    * ein .htaccess Schutz für das admin Verzeichnis konnte, nach derzeitigem Kenntnissstand, eine Ausnutzung der Lücke verhindern

    * wenn die Seite infiziert ist dann reicht es nicht, das betroffene Plugin zu löschen. Stellt eine sauberen Stand vor dem Angriff aus einem Backup wieder her oder wendet euch an einen Profi zur Bereinigung. Diese Art von Backdoors verteilt sich oft im gesamten System und ist schwer wieder weg zu bekommen

    Zitat von HorstG

    Es gibt seit heute das 3.3.11 Framework Plugin in den Updates.

    Hilft das schon?

    Ja aber es gibt andere Bugs in dieser Version.

    1. Megamenü Bug

    2. Videos im Layout als HG werden nicht mehr angezeitg.

    Die Behebung ist im vollen Gange und wird hoffentlich in Kürze bereitgestellt. Alles im Link #3 nachvollziehbar.

    Wer keinen zusätzlichen Schutz für das Backend hatte und die beiden Plugins gefunden hat muss handeln. David und Viktor haben ja Hinweise dazu bereits gegeben.

    Die Tatsache, dass die beiden Plugins installiert wurden ist wohl noch kein Indiz dafür, dass es zu einer tatsächlichen Ausführung und Aufnahme von Schadcode kam. Bevor diese Lücke noch nicht proaktiv ausgenutzt wurde, kann man auch wie bei Github beschrieben vorgehen.

    Zitat von WM-Loose

    Die Tatsache, dass die beiden Plugins installiert wurden ist wohl noch kein Indiz dafür, dass es zu einer tatsächlichen Ausführung und Aufnahme von Schadcode kam.

    Da möchte ich entschieden widersprechen: die Plugins SIND der Schadcode und sind in der Art und Weise, wie sie angelegt sind, dazu in der Lage beliebigen weiteren Schadcode nachzuladen und auszuführen.

    Zitat von WM-Loose

    Die Tatsache, dass die beiden Plugins installiert wurden ist wohl noch kein Indiz dafür, dass es zu einer tatsächlichen Ausführung und Aufnahme von Schadcode kam. Bevor diese Lücke noch nicht proaktiv ausgenutzt wurde, kann man auch wie bei Github beschrieben vorgehen.

    Siehe auch

    Zitat von Kubik-Rubik

    Bitte nicht raten oder nur nach irgendwelchen Plugins schauen, sondern die Server-Logs gründlich auf schädliche Aufrufe analysieren.


    Am besten vorgehen wie hier angegeben :

    Zitat von SniperSister

    * die Version 3.3.11 schließt die Lücke

    * ein .htaccess Schutz für das admin Verzeichnis konnte, nach derzeitigem Kenntnissstand, eine Ausnutzung der Lücke verhindern

    * wenn die Seite infiziert ist dann reicht es nicht, das betroffene Plugin zu löschen. Stellt eine sauberen Stand vor dem Angriff aus einem Backup wieder her oder wendet euch an einen Profi zur Bereinigung. Diese Art von Backdoors verteilt sich oft im gesamten System und ist schwer wieder weg zu bekommen

    Korrekt. Ich habe nur noch nicht herausfinden können, ob das bloße vorhanden sein noch eine Aktion benötigt, die Dateien in die Installation lädt. Mir geht es darum, dass wenn ich nichts auf dem Server finde außer den installierten Plugins, ob adnn tatsächlich ein Backup vor dem 22.02. erfoderlich ist. Dazu habe ich noch keine Infos gefunden.

    Aus aktuellem Anlass nochmal eine ausführlichere Einschätzung:
    * der Angreifer, der die Plugins installiert hat, hat für die Installation der Plugins Schadcode-Dateien genutzt, die er über die ungeschützt Astroid Funktion hochgeladen hat
    * in dem mir vorliegenden Log sind mindestens zwei Iterationen dieser Schadcode Dateien hochgeladen worden - bei der ersten iteration ist Inhalt und zweck völlig unbekannt, bei der zweiten Iteration werden mindestens die Plugins installiert
    * der Zweck der Plugins ist das Nachladen von Spam Links
    * der Angreifer hat die hochgeladenen Dateien immer gelöscht

    Und jetzt kommt die Kernaussage: es ist unmöglich zu sagen, welcher Zweck der temporär hochgeladene Schadcode über die Plugins hinaus hatte. Es könnte dort beliebiger Code ausgeführt sein und es ist bei solchen Angriffsszenarien übliches Pattern, dass man sich mit zahlreichen weiteren Backdoors im gesamten System ausbreitet. Es reicht daher nicht, die Plugins zu löschen. Kompromittierte Seiten müssen gründlich überprüft (Dateisystem, Datenbank, Passwörter rotieren etc) werden und sind als infiziert zu betrachten, bis das Gegenteil bewiesen ist.

    also ich würde nicht zurück gehen wollen.

    Zitat von cms_5

    Zwei Seiten sind mit AF 3.3.11 aktualisiert, eine davon hat danach massive Probleme mit dem Menü.
    Verschwommene, zittrige Darstellung, keine Navigation möglich.

    Eventuell bezieht sich das auf diesen Issue bzw. Info:

    Astroid 3.3.11: Megamenu: width setting is not working for dropdown alignment: left, right, center · Issue #1429 · templaza/astroid-framework
    Describe the bug The WIDTH parameter is not working for a dropdown align: left, right, center in Astroid 3.3.11, while iy was correct in 3.3.10. To Reproduce…
    github.com

    Liebe Grüße
    Christine

    Ich habe auf meiner Seite das Plugin blpayload gefunden.

    Daraufhin habe ich eine subdomain angelegt und hier ein Akeeba Backup vom 28.02.2026 eingespielt.
    Danach habe ich dieser neuen Joomla Installation nach dem Plugin gesucht, es aber nicht gefunden.
    Dann habe ich für diese Neuinstallation das Passwort und den Benutzer geändert.
    Ausserdem habe ich Astroid Framework Version 3.3.11 installiertem.

    Ist diese Vorgehnsweise richtig?
    Ich habe das Gefühl die neue Installation ist im Backend langsamer.

    Ich möchte jetzt unbedingt diesen Verzeichnisschutz mit htaccess einrichten.
    Finde dazu hier im Forum eine Anleitung, die auch ein Laie wie ich versteht?

    Hallo Blixi!

    Zum langsamen Backup:

    Neue Aktualisierung - Mehre Websites laufen langsam
    Neue Aktualisierung - Mehre Websites laufen langsam
    www.joomlaplates.de

    Bei der Neuinstallation musst du den alten Webspace und die alte DB löschen!

    Bei welchem Hoster bist du?

    Bei einigen Hostern kann man den Verzeichnisschutz direkt im Kundenaccount anlegen.

    Ansonsten hier mal schauen:

    Administrator-Verzeichnis per htaccess schützen

    Ich würde den Verzeichnisschutz vor der Installation anlegen.

    Gruß Elwood

    Ich habe eine neue Datenbank erstellt und darin dann das Backup installiert.
    Das heißt das Verzeichnis war leer - ist das nicht richtig??

    Also die alte DB löschen, dann neue DB anlegen und dann das Backup in die neue DB?
    Verstehe ich als Laie nicht so ganz warum ich alles löschen muss, wenn ich eine neue DB installiere.

    Ich bin bei IONOS