Joomla! Documentation™

Diese Seite enthält Details zu den mit Joomla 3.9.25 veröffentlichten Sicherheitspatches hinsichtlich der Einrichtung von 2FA (Zwei-Faktor-Autorisierung). Hier findet man eine Analyse der Auswirkungen und auch Empfehlungen für bestehende Seiten.

Berichtete Fehler

Das JSST (Joomla! Security Strike Team) wurde von dem Sicherheitsforscher Hanno Böck kontaktiert und auf zwei Probleme im Code aufmerksam gemacht, die durch dieses Update behoben wurden.

Betroffene Versionen

Allgemeine Informationen

Die Ursache ist

Seit Joomla 3.2.0 wird der Joomla-Kern mit einer 2FA / TOTP-Unterstützung versehen. Bis zur Version 3.9.25 hatte die Implementierung zwei kleinere Sicherheitslücken:

• Einsatz der unsicheren Funktion rand() innerhalb des Prozesses zur Erzeugung des 2FA-Geheimschlüssels.
• Anwenden einer zu geringen Länge für den 2FA-Geheimschlüssel von 10 Bytes gegenüber 20 Bytes nach RFC 4226.

So wurde das Problem behoben

Ab Joomla 3.9.25 wurde die Implementierung des Joomla-Kerns aktualisiert:

• Verwenden einer sicheren Zufallsfunktion (random_int; von der Bibliothek paragonie/random_compat in ältere PHP-Versionen zurückportiert).
• Verwenden von 20 Bytes statt des alten Wertes von 10 Bytes, um den 2FA-Geheimschlüssel zu generieren.

Dieses Problem wurde mit Akeeba Ltd. abgestimmt, da sie die ursprüngliche FOF-Codebasis für den Kern beigesteuert haben.

Hat dies Auswirkungen auf meine Website

Wie im ursprünglichen Bericht von Hanno Böck beschrieben, sagte er hinsichtlich der Verwendung der unsicheren rand-Funktion:

[...] Ich schätze das praktische Risiko hierfür als gering ein. Um dies anzugreifen, müsste ein Angreifer den ungefähren Zeitpunkt kennen, zu dem die Person ihren TOTP-Geheimschlüssel erstellt hat. Intern verrechnet PHP in Mikrosekunden zweimal, sodass man die möglichen Optionen für den Schlüssel vielleicht auf ein paar Millionen reduzieren könnte, was für einen echten Angriff immer noch sehr wenig praktikabel ist. [...]

Und für die Verwendung von 10 gegenüber 20 Bytes sagte er Folgendes:

[...] Der Code verwendet standardmäßig 10 Bytes für den Geheimcode. 10 Byte sind 80 Bit. Das Risiko ist hier gering. 80 Bits sind immer noch außerhalb jedes praktikablen Angriffs. Dennoch denke ich, dass die Sicherheitsanforderungen (und sogar Empfehlungen) des RFC befolgt werden sollten, daher empfehle ich, dies auf 20 Byte (aka 160 Bit) zu ändern. [...]

Basierend auf diesen Informationen kam das JSST zu dem Schluss, die Änderungen wie oben beschrieben zu implementieren. Dies bedeutet jedoch ausdrücklich nicht, dass praktisch alle 2FA-Token, die vor dem Patch generiert wurden, neu generiert werden müssten, da sie immer noch wie erwartet funktionieren und aus einer praktischen Sicht immer noch sicher sind. Es sollte auch klar sein, dass die hier vorgenommenen Änderungen nur solche Geheimschlüssel betreffen, die nach dieser Änderung erzeugt wurden.