Astroid Framework Angriffswelle

    Hallo Seppo,

    du solltest zwei aufeinanderfolgende POST-Anfragen finden.

    Die erste Anfrage auf das Loginformular im Backend ist notwendig, um das Sitzungstoken zu extrahieren; die zweite Anfrage geht dann an den Ajax-Endpunkt mit der Upload-Aktion (wie David gerade schrieb).

    Viel Erfolg!

    danke euch beiden, ich möchte gerne lernen. Folgende habe ich gefunden, könnten das die entsprechenden sein? Dann ist der Hack voraussichtlich vom 9.3.26


    Code
    185.209.199.155 - - [09/Mar/2026:14:59:39 +0100] "POST /administrator/index.php?option=com_ajax&astroid=media&format=json&action=upload&media=images&dir=images HTTP/1.0" 200 3826 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36"
185.209.199.155 - - [09/Mar/2026:14:59:39 +0100] "POST /administrator/index.php?option=com_ajax&astroid=media&format=json&action=rename&dir=images&name=100-q8ppitrfjh.svg&new_name=100-q8ppitrfjh.php&type=file HTTP/1.0" 200 3709 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36"

    Was mir sehr suspekt ist:

    Ich habe nur von dem Angriff erfahren weil ich hier ins Forum geschaut habe.

    Hätten SniperSister und WM-Loose nicht explizit und eindringlich auf den Angriff hingewiesen, wäre ich auch ins „offene Messer“ gelaufen.
    Vielen Dank nochmal dafür !

    Ich nutze Astroid mit der Pro-Variante, zahle also dafür.
    Dennoch erhielt ich keine Information vom Anbieter, das finde ich schon sehr bedenklich.

    Meine allgemeine Meinung dazu:

    - Von wem erwartet man eine pers. Nachricht, wenn Joomla gehackt wird?

    - Wenn die Seiten den entsprechenden, immer wieder empfohlenen, darauf hingewiesenen, Verzeichnisschutz hätten,

    wäre vermutlich der Hackangriff abgewehrt worden.

    - Wenn regelmäßige Backups angefertig werden, hätte man vielleicht einen Datenverlust von etwa 11 Tagen gehabt.

    Jeder so, wie er kann.

    Mir ging es genauso. Von 8 Seiten waren 2 schon infiziert. Zum Glück habe Akeeba drauf und konnte die Sicherung zurückspielen. Die Info kam von loose und Admin bei Joomlaplates.

    Dort habe ich es gelesen .

    Habe alle Seiten jetzt das administrator Verzeichnis mit passwort versehen. Hätte man viel früher machen müssen. Danke an alle fleißigen Programmierer die uns hier unterstützen und ihre Freizeit opfern.

    Zitat von Elwood

    - Von wem erwartet man eine pers. Nachricht, wenn Joomla gehackt wird?

    Wenn ich für eine Software zahle, in dem Fall Astroid-Pro, beworben mit gutem Support, erwarte ich von dem Anbieter dass die
    registrierten Kunden eine Benachrichtigung erhalten, schließlich ist eine E-Mail hinterlegt. Das wäre professionell.

    Nicht für Lapalien, aber bei solchen Angriffen.

    Noch eine weitere Lehre ziehe ich aus der Sache:

    Ich hatte auf einer Klonseite Astroid zum Testen installiert, so wie es aussieht reicht es ja für den Angriff, wenn das Framework installiert ist, auch wenn Cassiopeia weiter verwendet wird.

    Daher:

    Möglichst auf der produktiven Seite alle unbenutzten Frameworks und Plugins deinstallieren, um möglichst wenig Angriffsfläche zu haben.

    Grundsätzlich sinnvoll ist das deinstallieren von allen unbenutzen Erweiterungen und das schützen von Test-Websites bzw. Website-Kopien im Internet z.B. per entsprechender "Benutzername/Passwort" .htaccess im Joomla-Root Dateiordner. Also in dem Dateiordner in dem auch die configuration.php ist.

    Weitergehender zusätzlicher Schutz für die öffentliche Website siehe z.B. ab #4 dort:

    ...Firewall...

    Kleiner Hinweis:

    Wenn man noch eine ältere Datenbankversion in seinem Backup hat, dann sollte man bei einer neuen Datenbank im Restore von Kickstart noch folgende Parameter aktivieren.

    • Force UTF-8 collation on database
    • Force UTF-8 collation on tables
    • Allow UTF8MB4 auto-detection

    Es kann sonst sein, dass beim Import sonst Fehlermeldungen erscheinen.

    Der Fehler kommt daher, dass die MySQL/MariaDB-Version die Collation "utf8mb4_0900_ai_ci" nicht kennt.

    Man kann das auch vermeiden, indem man bei Akeeba vor der Backuperstellung einige Parameter umstellt:

    Backup-Einstellungen in Akeeba

    • Database Dump Engine: Wähle “Standard MySQL Dump” (nicht MySQL 8-spezifisch), das erzeugt kompatible SQL-Dateien.

    Charset / Collation

    • Aktiviere “Force UTF-8” sorgt dafür, dass Collations automatisch auf "utf8mb4_unicode_ci" gesetzt werden.
    • Split Archives: Behalte die Split-Option .s01 - s.xx nur, wenn dein Hosting Dateigrößenlimits hat. Sonst reicht ein einzelnes .jpa.
    Zitat von cms_5

    Wenn ich für eine Software zahle, in dem Fall Astroid-Pro, beworben mit gutem Support, erwarte ich von dem Anbieter dass die
    registrierten Kunden eine Benachrichtigung erhalten, schließlich ist eine E-Mail hinterlegt. Das wäre professionell.

    Nicht für Lapalien, aber bei solchen Angriffen.

    # Ich stimme voll und ganz zu und finde einige Argumentationen hier im Thread komisch.

    Selbst wenn man nicht dafür bezahlt wird, muss man bei einer eklatanten Sicherheitslücke, die quasi jeden hart betreffen kann, alle verfügbaren Kanäle nutzen, um seine Kunden zu benachrichtigen. Und zwar am Tag 0.
    Ich habe bei vielen Firmen/Projekten häufig den Eindruck, dass man die Sache möglichst klein halten möchte und die Verantwortung „dumm” abwälzen möchte.

    Natürlich sollte man sein Verzeichnis z. B. zusätzlich schützen, und darauf darf man sehr gerne auch wiederholt hinweisen. Aber das kann doch später kein Argument sein, dass der Kunde Schuld ist, wenn eine Sicherheitslücke in seiner Anwendung aufgetreten ist. Am Ende ist die Realität, dass es diese Lücke gab und dass viele eben keinen Verzeichnisschutz haben (weswegen auch immer).

    Wenn also jemand per E-Mail über ein Update informiert wird, warum dann nicht auch über eine solche Sicherheitslücke? Das ist jedenfalls kein Premium-Support.

    PS: Ein großes Lob hingegen für den Community Support hier von Einigen. <3

    Ich habe diese Antwort bereits in einem (bereits gelösten) Thread geschrieben.

    Da dieser aber (noch) nicht auf 'Erledigt' gesetzt ist, wiederhole ich hier meine Aussage:


    Ich weiß nicht, ob das gut ist, wenn man hier hunderte Websites öffentlich postet, die nicht gesichert sind.

    M.E. muss nicht jede Website gehackt worden sein. (Auch in anderen Threads hier im Forum).

    Schreibt sie doch per PN an. Viele davon, die hier nicht (mehr) reinschauen, haben vielleicht eine E-Mail-Benachrichtigung.

    Ist aber nur meine Meinung.

    Leute gehts noch? und was sollen diese Kommentare zu Informationspflicht?

    Vom Bekanntwerden bei Astroid (Github) bis zur Bereitstellung des Updates dauerte es genau 48 Stunden. Dann war das Paket im Backend bei den Updates im Backend sichtbar und bis heute haben zahlreiche User dieses dringende Update immer noch nicht installiert.

    Vielleicht sollte man wieder zum Realismus zurückkehren.

    Die Informationen zum Hack wurden auf diversen Plattformen publiziert.

    ich weiß nicht, ob die Diskussion über eine Informationspolitik im Kreise derer, die das weder verantworten noch beeinflussen können zielführend ist. Dass so ein Anspruch vorhanden ist kann ich nachvollziehen, man kann dafür auch den Support von Astroid anschreiben. Aus meiner Sicht hätte aber die schnelle Bereitstellung eines Updates höhere Priorität, weil dieses dann - wie Elwood schreibt - ja auch im Backend angezeigt wird.

    Ich bin dankbar für die Community hier und bei meinem Templateanbieter. So wurde ich aufmerksam, wusste was zu tun ist und habe inzwischen die Seiten gefixt. Schuld war ich selbst, weil ich einfach nachlässig war. Aber wieder muss ich Elwood zustimmen, bei mir war "nur" 1/3 der Seiten betroffen.

    Vielleicht bringt es wieder etwas Ruhe rein, wenn man sich wieder auf das Problem selbst konzentriert und den Hilfesuchenden Unterstützung gibt. beer