Das Joomla Security Strike Team möchte mehr Details über die in Joomla 3.8.8 korrigierte Sicherheitslücke beim Löschen von Backend-Sessions bekannt geben.
Dabei handelt es sich um ein sogenanntes Race Condition-Problem, dass man mit dem Update behoben, resp eingeengt hat.
Einleitung
Das JSST wurde über ein gelegentliches Problem im Zusammenhang mit einem „Random Logout-Fehler“ für das Backend informiert.
Das JSST führte daraufhin eine Untersuchung durch und konnte den Fehler reproduzieren. Das Problem war, einen richtigen Patch dazu zu schreiben. Doch fangen wir von vorne an.
Problem aus Anwendersicht
Wenn sich ein Benutzer im Backend anmeldet und sich sofort wieder abmeldet, kann es vorkommen, dass unter sehr seltenen Umständen die Sitzung des Benutzers nach einigen Sekunden wieder aktiv wurde.
Das bedeutet, dass, obwohl der Anmeldebildschirm korrekt angezeigt wird und dem Benutzer ein starkes visuelles Feedback von „alles funktionierte gut“ gibt, ein einfaches Aktualisieren der Seite ausreichen würde, um den Benutzer erneut anzumelden.
Technisch gesehen wird die Sitzung des Benutzers kurz nach ihrer Zerstörung als Zombie wiederbelebt. Aus der Sicht des Benutzers ist es, als ob die Abmeldung nie stattgefunden hätte.
Was unter der Haube passiert
Was passiert unter dieser Haube an diesem Punkt? Du musst an dieser Stelle zwei Dinge wissen:
- Im Backend-Control-Panel gibt es zwei AJAX-Checks zum Prüfen der Erweiterungen- und Joomla-Updates
- Diese beiden AJAX-Requests laufen mit deiner Sitzung und schreiben die Sitzungsdaten nach Beendigung in den Session-Handler zurück.
Also, was passiert hier?
Wenn du dich im Backend anmeldest, werden mehrere AJAX-Anfragen mit deinen Sitzungsinformationen gestartet. Wenn du dich von der Website abmeldest, setzt Joomla die Sitzungsdaten für die angegebene Sitzungs-ID zurück, meldet den Benutzer ab und leitet dich dann an das Anmeldeformular weiter, um eine neue Sitzung anzufordern. Wenn beim Abmelden einige AJAX-Requests noch aktiv sind (wie z.B. die Prüfung auf Core- und Extension-Updates), wird das Cookie nicht korrekt zerstört, der Browser behält die Session-ID und Joomla erstellt eine neue Session mit den gleichen Session-Informationen wie zuvor.
Wenn jetzt die AJAX-Prozesse enden, nachdem du dich abgemeldet hast, schreiben diese Prozesse deine Sitzungsdaten für die ID zurück in den Sitzungsdatenspeicher und überschreibt den leeren Datensatz, den du gerade beim Zugriff auf die Anmeldeseite erstellt hast. Wenn der Benutzer die Seite aktualisiert, ist er wieder angemeldet.
Im Normalfall dauern die AJAX-Anfragen nur ein paar Sekunden und zeigen dir das Ergebnis. Doch je nach Netzwerkverbindung können diese Abfragen länger dauern und dann diese Art von Problemen verursachen.
Die folgende Abbildung soll das Geschehen etwas verdeutlichen:
Geändertes Bild – Originalquelle: http://thwartedefforts.org
Realistisches Szenario
Nun, wie kann das zu einem Sicherheitsproblem werden? Denk mal an einen öffentlichen (oder fremden) Computer, mit dem du dich auf deiner Joomla-Seite anmeldest und einen Artikel bearbeitest. Sobald du damit fertig bist, gehst du zurück zum Control Panel und meldest dich dann ab, um zum Login-Bildschirm deiner Joomla-Seite zurückzukehren.
Was jetzt passieren könnte, ist, dass du den PC-Standort verlässt und jemand anderes an den PC kommt und auf Aktualisieren im Browser klickt und sich so mit deinen Berechtigungen im Backend einloggt.
So erhält ein Fremder unbefugten Zugriff auf deine Website und kann all das tun, was du auf deiner Website auch tun kannst.
Unsere Lösung
Unsere Lösung ist grundsätzlich sicherzustellen, dass beim Abmelden nicht nur die Sitzung aus der Speicher-Engine gelöscht wird, sondern auch das Browser-Session-Cookie.
Das eigentliche Race Condition-Problem bleibt zwar bestehen. Aber dieser Ansatz macht ihn nahezu harmlos, da auf die möglicherweise noch aktive Sitzung nicht mehr zugegriffen werden kann. Weil das Wissen über die für die Nutzung der Sitzung erforderliche Session-ID beim Löschen des Session-Cookie verloren geht.
Auswirkungen auf einige Session-Handler
Wir haben hier zwei mögliche Fälle:
- Fall A: Der Handler unterscheidet zwischen „UPDATE“ und „ADD“ Tasks
Einige Handler (Datenbank, Memcache, Redis und Wincache) haben spezielle Befehle, um eine neue Sitzung hinzuzufügen oder eine bestehende zu aktualisieren. In diesem Szenario würde ein lang laufender AJAX-Prozess versuchen, die Benutzersitzung zu aktualisieren, die fehlschlägt, weil die betreffende Sitzung beim Abmelden gelöscht wurde. - Fall B: Der Handler differenziert die Tasks nicht
Andere Handler erzeugen oder überschreiben blind die Session (XCache, APC). In diesem Fall erstellen sie eine Orphan-Session, die einen Klon der Daten „vor dem Logout“ enthält, den niemand verwenden wird und der bald abläuft.
Wir müssen darauf hinweisen, dass im zweiten Fall, obwohl die Abmeldung tatsächlich funktioniert hat und auch verhindert hat, dass jemand anderes mit demselben Browser sich wieder anmeldet, der Benutzer glaubt, dass seine Sitzung zerstört wurde, es aber immer noch eine Schattensitzung auf dem Server existieren könnte. Hier hat der Benutzer aber kein grösseres Risiko, als bei einer regulären Backend-Aktivität, da das Wissen über die Session-ID erforderlich ist, um die Shadow-Session wieder zu verwenden.
Quelle: developer.joomla.org
