Doppelte Schwachstellenkombination im beliebten CMS Joomla könnte zu einer „vollen Systemkompromittierung“ führen

    https://portswigger.net/daily-…to-full-system-compromise


    Habe es mal übersetzen lassen im Firefox:


    Doppelte Schwachstellenkombination im beliebten CMS Joomla könnte zu einer „vollen Systemkompromittierung“ führen


    AKTUALISIERT Sicherheitsforscher haben die Details von zwei enthüllt, Schwachstellen in Joomla – dem beliebten Content-Management-System – die, wenn sie miteinander verkettet werden, ihrer Meinung nach verwendet werden könnten, um eine vollständige Systemkompromittierung zu erreichen.


    Die beiden Sicherheitslücken – eine Sicherheitslücke zum Zurücksetzen von Passwörtern und ein gespeicherter Cross-Site-Scripting- (XSS)-Fehler – wurden beide von Sicherheitsforschern bei Fortbridge entdeckt und im Februar bzw. März verantwortlich an die Entwickler von Joomla weitergegeben.

    Spezifische Konfiguration


    Nach einigen Verzögerungen hat Joomla mit der Version 3.9.27 des CMS ( einen Patch für die XSS-Schwachstelle veröffentlicht veröffentlicht im Mai) . Die (wohl weniger schwerwiegende) Sicherheitslücke beim Zurücksetzen des Passworts kann mit einer „ gemildert werden trusted_hosts Konfiguration von “ .


    Diese Passwort-Schwachstelle ist laut Fortbridge noch nicht gepatcht, was Joomla-Benutzern rät, die " $live_site Variable " in der Datei configuration.php als Workaround zu setzen, bis ein Patch für das Problem mit dem Zurücksetzen des Passworts geliefert wird.


    Laut Joomla erfordert diese HOST-Header-Injection-Schwachstelle jedoch "extrem spezifische Umstände", die in der Joomla-Community "extrem ungewöhnlich" sind, um ausgenutzt werden zu können.

    Kombinationsangriff


    Die beiden Schwachstellen in Joomla sind beide hochgradig und „wenn sie miteinander verkettet sind, ermöglichen sie einem Angreifer, eine Joomla-Website vollständig zu übernehmen“, sagte Adrian Tiron, geschäftsführender Gesellschafter bei Fortbridge, gegenüber The Daily Swig .


    „Sobald der Angreifer vollen Zugriff auf die Joomla-Website hat, können [sie] eine PHP-Shell hochladen, die es [ihnen] ermöglicht, Befehle auf dem Server auszuführen“, warnte Tiron.


    Informieren Sie sich über die neuesten Nachrichten aus der Sicherheitsforschung


    Die erste Schwachstelle ermöglicht es dem Angreifer, das eines Administrators zurückzusetzen Passwort .


    Tiron erklärte: „Der Angreifer löst den Vorgang zum Zurücksetzen des Passworts aus und kann den Link zum Zurücksetzen des Passworts so manipulieren, dass er auf den Server des Angreifers verweist, wo [sie] das Token des Opfers erfassen und [ihr] Passwort zurücksetzen, sobald das Opfer auf den Link oder den Link klickt wird von einer AV/EDR-Scanlösung [Antivirus/Endpoint Detection and Response] abgerufen.


    „Sobald der Angreifer in der Lage war, das Passwort des Administrators zurückzusetzen und Administratorrechte erhalten hat, [sie] nutzen die zweite Schwachstelle, ein gespeichertes XSS, um den ‚Super Admin‘-Benutzer anzugreifen.“


    Durch die Ausweitung der Privilegien auf 'Super Admin' kann ein Angreifer vollen Zugriff und die Möglichkeit erhalten, einen Remote Code Execution (RCE)-Angriff gegen ein anfälliges Joomla-CMS auszuführen, warnt Fortbridge.


    Als Antwort auf Fragen von The Daily Swig gaben die Entwickler von Joomla eine detaillierte Erklärung ab, in der sie die angebliche Schwere der von Fortbridge entdeckten Fehler bestritten:


    Fortbridge hat zunächst zwei separate Probleme gemeldet:


    1. eine sogenannte HOST-Header-Injection


    2. ein Angriffsvektor, der letztendlich zu einem XSS-Angriff führen würde, während er die Existenz eines privilegierten, aber nicht Super-Admin-Kontos auf der Joomla-Installation erfordert requiring


    Der XSS-Vektor wurde in Joomla 3.9.27 korrigiert.


    Die HOST-Header-Injection erfordert extrem spezifische Umstände, um ausgenutzt werden zu können, nämlich ein Webserver-Setup mit entweder:


    a) keine vhosts konfiguriert werden oder


    b) eine Joomla-Installation, die sich im konfigurierten Standard-vhost befindet


    Ein solches Setup ist in der Joomla-Community äußerst ungewöhnlich, da die überwiegende Mehrheit der Sites in Shared-Hosting-Umgebungen ausgeführt wird, in denen diese Bedingungen nicht erfüllt sind.


    Aber selbst wenn eine Joomla-Site in einer solchen Umgebung läuft, kann eine Joomla-Site bereits geschützt werden, indem das vorhandene $live_site Konfigurationsflag in der configuration.php verwendet wird.

    Wider lessons


    Fortbridge hat eine detaillierte technische Zusammenfassung diese Woche seiner Ergebnisse veröffentlicht. Der zugehörige Proof-of-Concept-Code wurde auf GitHub veröffentlicht .


    Joomla ist mit mehr als 1,5 Millionen Installationen weltweit eine der beliebtesten CMS-Plattformen. Fortbridge stieß bei einem Penetrationstest auf die Fehler, die es in der Plattform entdeckte.


    Abgesehen von der Bedeutung der Ergebnisse an sich bieten sie anderen Entwicklern Lektionen, so Tiron von Fortbridge.


    Zum einen wäre der gespeicherte XSS-Fehler durch die Verwendung von Zulassungslisten anstelle von Sperrlisten vermeidbar gewesen. Zweitens vermeiden Sie das Passwort-Reset-Links mit Erstellen von $_SERVER['HTTP_HOST'] / $_SERVER['SERVER_NAME'] , da diese "Variablen tatsächlich Benutzereingaben sind", riet Tiron.


    Diese Geschichte wurde aktualisiert, um zu verdeutlichen, dass das Problem mit dem Zurücksetzen des Passworts laut Sicherheitsforschern von Fortbridge ungelöst bleibt, und um einen Kommentar von Joomla hinzuzufügen, der dies und die allgemeine Schwere der Mängel bestreitet.

    Hier noch mal etwas lesbarer, das Statement seitens JST:


    Ja. Es ist halt so, dass diese Meldung seit gut einer Woche herumgeistert, und auch von Leuten wie Nicholas, Phil und Michael genüsslich auf Twitter diskuiert wird. Als nicht-Programmierer ist es schwierig, den Sachverhalt richtig einzuordnen.

    Eigentlich würde ich mir wünschen, dass das Security Strike Team bei solchen Dingen entschlossener auftritt mit einem Statement und klar sagt, was Sache ist. Und nicht nur à la 'In response to questions from The Daily Swig'. Ich habe von dieser Sache auch andernorts gelesen, ohne ein Statement vom JSST

    Problem beim Publizieren von Sicherheitslücken ist eben, dass man sie, wenn, eben verzögert bekannt macht. Zusätzlich: Im Joomla-Team herrscht eben einfach Personalmangel. Außerdem: Wer liest denn die Statements dann, egal, wo sie sind? Von meinen Kunden keiner, selbst, wenn sie prominent positioniert werden.


    Es wäre auch nicht weniger Hektik, wenn obiger Text in Joomla angezeigt würde. Wenn es eine gravierende Lücke für viele User wäre, würde das schon größer publik gemacht und es wäre ein schnelles Zwischen-Release rausgekommen.


    Zwei der drei von dir genannten Twitter-Typen (weiß nicht, wer mit Michael gemeint ist) sind nebenbei welche, die Big-Business mit Joomla machen und trotdem meines Empfindens nach reichlich oft "rechthaberische, klugsch., selbstverliebte, arrogante Giftzwerge" sind. Bei mir ist es so weit, dass ich die PRs und Issues von PhilETaylor gar nicht mehr öffne, selbst, wenn ich weiß, dass er schon reichlich unausgegorenen, undurchdachten Kram ins Joomla 4 bringen wollte oder konnte oder ganze Codeblöcke entfernt oder entfernen will mit Test-Instruktionen "Code Review". Andere dürfen sich das nicht erlauben. Forscht man dann nach, was sein Job wäre, stellt sich raus, dass er halt doch Murx redet, weil Codes einen Kontext haben. Soll ich das twittern?


    Und auch über PHP8 wird weiterhin behauptet, dass es eine riesige Sicherheitslücke enthält, obwohl nie in einem Stable-Release gelandet und, weil irgendwelche Dingsbumsens Spektakelmeldungen mit missverständlichen Spektakelformulierungen rausbringen. Auch bei PHP sind die offiziellen Statements dazu nicht so leicht zu finden, nebenbei. Und von einem Land-und-Wiesen-Provider habe ich neulich erfahren, dass Joomla sowie JCE unsicher seien. Dabei verwies er auf Artikel von 1888 oder so im Netz.


    Wollt ich nur mal gesagt haben ;)

    Zitat von firstlady

    Und hast du auch den Kommentar des Joomla Security Teams dazu gelesen und gepostet?

    Ja, im Eröffnungspost:


    Fazit:

    Fehler betrifft nur Joomla-Websiten die nicht auf in Shared-Hosting-Umgebungen ausgeführt werden und nicht korrekt konfiguriert sind und die Joomlaversionen vor 3.9.27 und wieder mal mehr ein Grund darauf hinzuweisen:

    Die wohl wichtigste Sicherheitsmaßnahme ist Joomla! und alle Erweiterungen auf dem neuesten Stand zu halten!

    Siehe z.B. auch:

    https://www.joomla.de/wissen/j…nt/479-tuerchen-nummer-17

    und:

    https://www.joomla.de/wissen/j…1x1-der-joomla-sicherheit

    Michael (mbabker) war lange Zeit einer der zentralen Figuren bei Joomla. Die üblichen Verdächtigen auf Twitter kennen
    wohl den Slogan aus Toms Signatur nicht: "Wir werden nicht größer, wenn wir andere kleiner machen." Phil Bosmans


    Natürlich erschrickt man erst mal wenn solch eine Meldung auftaucht und eine Anfrage: Ich habe das gefunden - was ist da dran? wäre völlig verständlich. Aber wem nützt eine solche BILDZeitungszeile?

    Zitat von CurlY BracketS

    Eigentlich würde ich mir wünschen, dass das Security Strike Team bei solchen Dingen entschlossener auftritt mit einem Statement und klar sagt, was Sache ist. Und nicht nur à la 'In response to questions from The Daily Swig'. Ich habe von dieser Sache auch andernorts gelesen, ohne ein Statement vom JSST


    Dazu mal ein Statement vom JSST ;)


    Wir wussten vorab, dass der Blog Post kommen würde, haben uns aber erstmal bewusst dagegen entschieden, ein eigenes offizielles Statement rauszugeben - das würde dem entsprechenden Post der Forscher nämlich sehr viel Aufmerksamkeit bringen und macht die Sache viel größer als sie ist. Es ist auch hier, wie so vieles im Security-Bereich, ein Balance-Akt.

    Ich habe in der DACH Facebook-Gruppe ein paar Zeilen zur Lücke in deutsch geschrieben, ich re-poste das mal hier:


    Thänx, SniperSister - das hab ich nicht gesehen, weil ich kaum auf FB unterwegs bin.

    Vielleicht lebe ich in einer Bubble, aber ich habe das Gefühl, dass bei solchen Berichten/Gerüchten/Anwürfen Joomla immer viel mehr einen schlechten Ruf kriegt, als andere CMS (Lücke in WP? Na und? / Lücke in Joomla? Ist ja echt shitty, diese Ding!)

    Verärgerte Kunden klopfen dann an die Tür, es gibt rote Köpfe, und wenn man dann das Arumentarium nicht parat hat, hat man einen schweren Stand.

    Das ist der Grund für meine Bemerkung und ich bleibe bei meiner Aussage.

    FB ist schön und gut, aber da rauschen die Meldungen mit Schallgeschwindigkeit vorbei und finden tut man nach 2 Tagen eh nichts mehr ;)

    Sorry falls ich Unfrieden gestiftet habe.

    Mir haben das 3 ITler aus Firmen zugeschickt die ich kenne und die im Intranet Joomla einsetzen in Ihren Firmen.

    Ich selbst bin damit nicht so bewandert, dachte aber vielleicht ist es hilfreich für jemanden anderen.


    Wenn dies falsch war entschuldige ich mich hiermit.