Vielen Dank für die Klarstellung und die Info. Dann harre ich der Dinge, die da kommen
Das Problem ist behoben
Vielen Dank für die Klarstellung und die Info. Dann harre ich der Dinge, die da kommen
Das Problem ist behoben
Nur allgemein gemeint, weil man das bei einem Hack halt vorsichtshalber tut? Oder haben sich da auch Wege aufgetan?
Die Lücke erlaubt Code Execution und somit Zugriff auf die configuration.php
Siehe auch:
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
Hab ich hier irgendwo einen Denkfehler? Ich hätte erwartet, dass "Joomla! Next" weiterhin Joomla 4 anbietet.
Du hast keinen Denkfehler ist ein bekanntes Problem, sind bereits an der Lösung dran.
Hintergrund: der Joomla "Next" Server gibt eine Liste von verfügbaren Updates je Joomla Version raus - in der aktuellen Liste ist aber nur 3.10.12 aufgeführt, unsere eLTS fehlt dort noch. Fix ist in Arbeit!
Das mit der Richtung stimmt aber der Entschluss und Konditionen waren für uns zu spät.
Da stimme ich dir völlig zu. Der Entschluss kam schon spät, die Bürokratie die Ausschreibung durchlaufen war und der Vertrag unter Dach und Fach war hat dann nochmal knapp 4 Monate gedauert, das war alles in allem einfach super ärgerlich.
Mit diser Verlängerung wird das ganze nur herausgeschoben und macht aus meiner Sicht keinen Sinn. Die Entwickler hatten wahrlich Zeit genug Ihre Erweiterungen anzupassen und wer dies bis heute nicht geschafft hat erscheint mit nicht zuverlässig genug um zukünftig mit dessen Erweiterungen und Plugins planen zu können.
Warten wir mal ab wie es mit Ablauf von eLTS aussehen wird. Ich vermute dass genau diejenigen, die heute noch mit J3 unterwegs sind auch die sein werden, die zum eLTS noch immer bei Joomla3 verweilen.
In meiner Wahrnehmung gibt es 3 Sorten von J3 Seiten, bei denen die Migration ansteht:
a) Seiten die sich mit überschaubarem Aufwand migrieren lassen. Die sind längst erledigt und für die ist der eLTS somit kein Thema. Super, Problem gelöst.
b) Seiten bei denen sich der Betreiber nicht für Updates interessiert: auch hier macht der eLTS keinen Unterschied. Diese Seiten sterben einfach, wenn der Hoster mal ein großes PHP-Update macht.
c) Seiten bei denen die Migration nicht so trivial ist, weil z.B. wichtige Erweiterungen fehlen, das Template nicht kompatibel ist oder gar Individualentwicklungen im Spiel sind. Hier ist es ein simples Ressourcenproblem: Ist Zeit und Geld vorhanden um die Migration jetzt zu machen - und wenn es dabei darum geht, den Betreiber von dieser Investition zu überzeugen, ist die Frage, ob die aktuelle J3 Seite die Investition schon "reingespielt" hat nunmal eine wichtige. Und genau in diesem spezifischen Szenario kommt der ELTS ins Spiel: J3 Seiten bekommen dadurch kostengünstig weitere 18 Monate, um Ihre Initialkosten reinzuspielen.
Nachtrag: Für uns als Joomla Agentur ist es ein Schlag ins Gesicht.
Seit Monaten beraten wir Kunden und weisen auf den end of support hin, dessen Weiterführung uns alle nun unglaubwürdig erscheinen lässt (auch mit dem kostenpflichtigen Aspekt). Vielleicht hätte man auch daran mal denken sollen.
Man hat daran gedacht und hat dieses berechtigte Interesse gegen den möglichen Mehrwert eines eLTS abgewogen. Wenn sich der eLTS für J3 bewährt (und ob das so ist kann ich überhaupt nicht abschätzen), wäre ein vergleichbares Program für J4 denkbar, dass dann auch mit ordentlichem Vorlauf angekündigt werden kann.
Also muss der Kunde u.U. dann 2x zahlen?
1x für den eLTS und 1x monatlich für die Nutzung von PHP 7.4?
Ja, das ist durchaus ein plausibles Szenario, wobei J3 als Core-Software ja unter 8.0 und meines Wissens nach auch unter 8.1 lauffähig ist - hier sind also eher Extensions das Problemkind.
Es wird keine erneute Verlängerung nach dem eLTS geben, der Vertrag schließt das explizit aus.
PHP Datei und htaccess gehören beide ins Root der Joomla Instanz und NICHT in den zu schützenden Unterordner.
Die weiteren Inhalte sind vermutlich Module? Falls ja: Menüeintrag für die Ergebnisliste anlegen und im Suchindex Modul als Zielseite hinterlegen.
In der Vergangenheit gab es immer wieder Nutzerbeschwerden, weil Änderungen an Bestandsbildern (Bild ersetzt, Größe angepasst etc) im Backend nicht sofort sichtbar wurden, weil besagte Bilder im Browser-Cache waren. Der Timestamp hebelt den Cache aus um das Problem zu lösen.
Grundsätzlich also durchaus eine gute Idee, eventuell aber wäre es sinniger, den Timestamp an das modification Date der Datei zu binden.
wilderer wenn ich dich richtig verstehe, vermischst du hier zwei Dinge:
1. die Dateigröße der Update-Pakete
2. die Frage ob jedes neue Feature in jedem Update mit drin sein muss
Das sind völlig unterschiedliche Fragestellungen, die nichts miteinander zutun haben.
Das Dateigrößen-Thema ist ein technisches Thema, das ist mit überschaubarem Aufwand lösbar.
Die Frage, ob neue Features Core-Bestandteil sind oder nicht ist hingegen etwas völlig anderes. Dein Wunschszenario ist dabei, dass du dir quasi wie beiden Extensions genau die Core-Features aktivieren kannst, die du auf deiner Seite brauchst. Durchaus eine charmante Idee, die man mal bei der com_weblinks ausprobiert hat. Ergebnis: das ist garnicht so einfach. Denn es gibt fest verdrahtete Abhängigkeiten zwischen vielen Core-Erweiterungen, die man dafür erstmal auflösen müsste. Und da stellt sich die Frage, warum man dafür Ressourcen investieren sollte - welches Problem wird dadurch gelöst?
Offenbar bist Du dann bei einem Hoster, der nicht vom Joomla-Security-Teams über Core-Lücken informiert wird. Es wurde bei Erscheinen der Sicherheitslücke entsprechende Filterregeln verteilt, um solche Angriffe bereits auf Firewall-Ebene zu blocken.
Strato wurde informiert.
Also: um es erstmal in aller Deutlichkeit zu sagen: der Umstand, dass ein System Fehlermeldungen mit Pfaden ausgibt bedeutet an sich erstmal noch nicht, dass man die Seite erfolgreich angreifen kann. Die Fehlermeldungen geben einem Angreifer "nur" interessante Hinweise zu verwendeten Systemkomponenten, Pfadstruktur, Betriebssystem und co - diese Hinweise kann man dann nutzen, um nach anderen Lücken zu suchen bzw. sie können helfen, andere Lücken auszunutzen.
Voraussetzung für einen erfolgreichen Angriff ist dabei aber immer, dass es eben solche vorhanden Lücken überhaupt gibt. Ohne Lücke, kein erfolgreicher Angriff.
Dennoch ist es natürlich Best Practice, das Error Reporting auf Produktivsystem möglichst "stumm" zu halten. Wenn in der Joomla Konfiguration das Error Reporting deaktiivert ist, werden dabei etwaige Vorgaben auf Betriebssystemlevel überschrieben. Es wäre dann somit egal, was Ionos da eingestellt hatte.
Google entscheidet bei Recaptcha auf Grundlage des Nutzerverhaltens, ob eine explizite Aufgabe abgefragt wird, oder ob der Nutzer auch ohne Aufgabe vertrauenswürdig genug ist.
Ich denke die vom Security-Team für die Hoster mitgeteilten mod-security-Regeln kann man auch mit htaccess realisieren.
Ich möchte das hier nicht veröffentlichen, weil das ggf. auch potentiellen Angreifern hilft.
Siehe Mitigation Option B:
Bin ich ab dem Update auf Joomla 4.2.8 geschützt und wenn bisher noch keine Angriffe erfolgt sind, bedeutet dies, dass die Daten über API noch nicht abgegriffen wurden? Kann ich dann auf die Passwortänderungen verzichten?
Wenn du sicher sagen kannst, das keine Daten abgegriffen worden sind dann ja, dann kann man darauf verzichten.
tatsächlich durch eine Kompromitierung passieren kan
Datenbank Daten abgreifen, eigene Verbindung zum Datenbank Server aufbauen, neuen Super User erzeugen, einloggen, backdoor installieren. Zack: Seite gehackt.
Wenn ich mal spaßeshalber quer-beet über die Server schaue sind nicht einmal 50% aller 4er-Joomla geupdated worden - trotz direkter Anspache an alle Kunden, als das Update das erste mal angekündigt wurde.
Ich habe nichts anderes erwartet...
in die Firewall? Wie wo was? Kannst Du das bitte mal näher erklären?
Das Security Team ist in Kontakt mit einer Vielzahl von Hostern. Zum Zeitpunkt des Release stellen wir den Hostern Regelsätze bereit, die in die von den Hostern betriebenen Firewall-Applikationen eingespielt werden können.