AcyMailing User, kontrolliert eure Seite

    Wenn ihr auf euren Seiten AcyMailing in egal welcher Edition in der Version 6.5 oder höher einsetzt oder eingesetzt habt, solltet ihr dringend prüfen ob die Seite gehackt ist. AcyMailing hatte von Version 6.7.0 bis 8.5.0 eine schwere Sicherheitslücke, die beliebige Code-Ausführung erlaubt hat. Die Lücke wurde im Februar gemeldet, im März dann gefixt - der Fix war aber fehlerhaft und die Lücke weiter ausnutzbar. Ab spätestens Mitte April gab es automatisierte Angriffe, der erste Patch der die Lücke zumindest abmildert war erst Mitte Mai verfügbar.


    Wenn ihr die Seiten checkt, achtet besonders auf:
    * Dateien mit dem Namen thumbnail_*.php (z. B. thumbnail_999.png?.php); gängige Angriffsmuster schreiben diese Dateien nach media/com_acym/images/thumbnails, diese Dateien können aber auch überall sonstwo auf dem Webspace abgelegt worden sein

    * Die häufigsten Angriffsmuster schreiben Backdoor-Dateien in die folgenden Verzeichnisse (XXX sind zufällige Buchstaben - das Datum dieser Dateien kann älter als Mai sein)

    - /api/includes/xxx.php

    - /Komponenten/com_ajax/xxx.php

    - /layouts/joomla/icon/xxx.php

    - /media/com_XXX/xxx.php

    - /media/com_tags/js/xxx.php

    - /Vorlagen/System/xxx.php

    * Sucht auf dem Webspace nach Dateien, die $_COOKIE enthalten, da häufige Angriffsmuster Hintertüren geschrieben haben, die zusätzlichen, in Cookies platzierten Code auswerten - etwaige Findings müssen dann aber einzeln ausgewertet werden, weil es auch viele legitime Nutzungen von $_COOKIES gibt

    Ich hatte schon im August 2020 mit der Version 5.10.14 drastische Sicherheitsprobleme. Seit der Veröffentlichung der Version 6.1.1 im Februar 2019 wurde wie es scheint, Acymailing 5 nicht mehr wirklich gewartet.


    Zu dieser Zeit war es u.a. auch möglich, dass sich bei höchsten Sicherheitseinstellungen hunderte Accounts in wenigen Stunden Anmelden und Freischalten konnten.


    Rein vorsorglich sollten User der Version 5 sich ebenfalls diese besagten Ordner ansehen!


    Gruß Faro

    Zitat von HorstG

    Reicht es denn diese Dateien zu löschen? Meine Acy Mailing sind alle auf aktuellsten Stand!

    Das reicht leider nie verlässlich, da Infektionen sich halt ausbreiten können. Heißt, man weiß nie, was zusätzlich im Laufe der Zeit ins System geschaufelt wurde, was möglich gemacht wurde, abseits von dem Bekanntgemachten und Bekannten. Wenn nun also z.B. irgendwie Backdoor-Skripte und anderes Tralala hochgeladen wurden. Gibt so viele Variationen.


    Wie viel hinter dem Satz auf der Acy-Seite steckt, weiß man auch nicht so recht. Nur allgemein gemeint, weil man das bei einem Hack halt vorsichtshalber tut? Oder haben sich da auch Wege aufgetan?

    Zitat

    If you find malicious files, it might be wise to update your FTP, DB and SMTP accounts passwords.

    ich sag mal so, ich hab die

    AcyMailing Enterprise 8.7.1

    laufen und noch nie Probleme gehabt, selbt bei der Umstellung von 5 auf 8. Naja, werden das mal ein wenig beobachten! letztendlich ist ein System nur so anfällig, wie die eigenen Sicherheitsmaßnahmen dann genutzt werden.

    mfG
    LSG



    „Es gibt keine dummen Fragen. Nur dumme Antworten. Allerdings – gibt es Fragen, die eindeutig die Dummheit des Fragestellers selbst beweisen.“

    Ok! Auf einer meiner Seiten habe ich in den oben genannten Ordnern auch jeweils solch eine .php mit $_COOKIE.

    Unter media heißt die "Komponente" bei mir dann "com_pecyzagopa". Muss mal schauen, ob ich noch weitere entsprechende Dateien irgendwo anders finde.


    Alle Dateien haben übrigens das Datum vom 02.10.2022.


    Die beiden thumbnail_98.php.png und thumbnail_98.png?.php sind hingegen vom 04.05.2023.

    Moin zusammen -

    ich habe bei einigen Installationen auch verdächtige Dateien (vom 1.4.2023) entdeckt und würde nun wie folgt vorgehen:


    - Sichern der bestehenden Installation

    - Zurückspielen eines Backups von 3/23

    - Sofortiges Update aller Komponenten

    - Ändern aller Passwörter (Datenbank, FTP-Benutzer, Joomla-Benutzer)

    - erneutes Einpflegen des Contents, der nach März 23 auf den Seiten angelegt wurde.

    Das scheint mir schlüssig.

    Bei den FTP-Zugangsdaten bin ich nicht sicher. Sofern ich die nicht in der Konfiguration hinterlegt habe, sollen die doch safe sein? Spricht was dagegen den Content via Datenbankexport und -Import zurückzusichern?

    Freu mich auf euer Feedback

    Weil es kein Ja oder Nein auf deine Fragen gibt, die vielleicht paranoiden Antworten:


    .htaccess-Verzeichnisschutz zuvor, weil Sekunden reichen können, wenn irgendwas, irgendwo, irgendwie bei der Wiederherstellung Zugang haben könnte. Man weiß es schlicht nicht.


    Passwörter würde ich dann zuerst ändern, auch, wenn die Wiederherstellung etwas mühsamer ist. Ob FTP auch, kann man pauschal nicht beurteilen. Kommen ja auch andere Erweiterungen, Webspace-Aufbau und Kram über Ecken in Frage, wo welche rumdümpeln könnten.


    Komplettes Löschen der alten Installation fehlt.

    Zitat von tbachner

    pricht was dagegen den Content via Datenbankexport und -Import zurückzusichern?

    Kann man nicht mit Sicherheit wissen. Wenn Script-AUsführung möglich war, ist auch Datenbankänderung möglich gewesen.


    Ich habe die Backups mit den Server-Access-Logs ermittelt (Erstangriff auf "setNewThumbnail"), hatte aber auch ausreichende Log-Dateien dafür. Weil Datei-Datum Schall und Rauch sein kann, wenn jemand Script-Zugang hatte. Im Moment gehen wir ja von exakt dem selben Szenarien bei allen Betroffenen aus. Nach ein paar Spielereien, weiß ich aber, dass auch Variationen möglich sind. Das fängt schon mit dem "COOKIE" an.

    Zitat von tbachner

    - Sofortiges Update aller Komponenten

    Warum Mehrzahl? Die Drittanbieter-Erweiterungen und Joomla sollten im Idealfall immer aktuell sein.


    Passwörter würde ich auch als erstes ändern. Später eventuell noch ein zweites Mal.


    Bei mir hatten die gefundenen Dateien verschiedene Datumsangaben. Ob bei dir ein Backup von 03/23 reichen würde, ist ungewiss. Du solltest den Webspace zumindest mal auf $_COOKIE untersucht haben. Vielleicht findest du ältere Problemdateien.

    Unser Systemscanner hat folgende Dateien gefunden und umbenannt:



    Eine Frage: Kann auch der Administrator-Bereich betroffen sein, obwohl er durch eine .htacces Datei geschützt ist?

    Viele Grüße

    Sven Rinklin

    Zitat von srinklin

    Eine Frage: Kann auch der Administrator-Bereich betroffen sein, obwohl er durch eine .htacces Datei geschützt ist?

    Wenn Scripte auf dem Server ausgeführt werden können, kann nebenbei auch die .htaccess-Datei verändert werden. Auch das gab es schon in der Vergangenheit, z.B. für Umleitungen auf eingeschleuste Spam-Inhalte. Weshalb ich auch immer .htaccess-Dateien bei Hacks prüfe. Den Scripten, die via "Browser" aufgerufen und ausgeführt werden können, ist ein Verzeichnisschutz danach wurst, der ja nur "Browser"aufrufe blockiert.