Sicherheit: Joomla-Lücke könnte absichtlich platziert worden sein

Im populären Content-Management-System Joomla ist vor kurzem eine sehr kritische Sicherheitslücke gefunden worden. Der Code mit der Sicherheitslücke ist schon seit sehr langer Zeit Teil des Joomla-Projekts - allerdings ist die Lücke in älteren Versionen nicht ausnutzbar. Erst ein Bugfix, der vor etwa einem Jahr durchgeführt wurde, ermöglicht die Ausnutzung der Lücke. Handelt es sich um bewusste Sabotage?

Joomla-Lücke erlaubt Accounterstellung

Das Joomla-Projekt hat am Dienstag die Version 3.6.4 veröffentlicht, die mehrere kritische Sicherheitslücken behebt. Ein Fehler im Modul zur Nutzerverwaltung erlaubt es, unberechtigt einen Account anzulegen. Durch weitere Sicherheitslücken kann dieser Nutzeraccount dann zu einem Administratoraccount aufgewertet werden. Ein Angreifer kann also die komplette Joomla-Installation übernehmen.

In einem Blogpost weist die Webdesignerin Fiona Coulter darauf hin, dass der fehlerhafte Code zur Accounterstellung bereits seit der Version 1.6 und damit seit 2011 in Joomla vorhanden ist. Trotzdem lässt sich der Bug in älteren Joomla-Versionen nicht ausnutzen. Denn ein weiterer Bug sorgt dafür, dass die entsprechende Funktion im Modul zur Benutzerverwaltung schlicht nicht funktioniert. Doch dieser Bug wurde in Version 3.4.4 behoben.

Das dürfte einiges dazu beitragen, dass die Auswirkungen des Bugs begrenzt bleiben, denn viele Webseiten nutzen noch die nicht mehr unterstützte Version 2.5 von Joomla. Es bietet aber auch Raum für Spekulationen: Wusste die Person, die den Bug gefixt hat, von der Sicherheitslücke und hat sie durch den Bugfix erst geöffnet?

Der Bugfix wurde auf Github als Pull-Request eingereicht. Der Account, über den der Bugfix eingereicht wurde, ist offenbar ausschließlich hierfür angelegt worden - denn der entsprechende Patch und der Pull-Request sind die einzigen Aktivitäten, die mit diesem Account jemals durchgeführt wurden.

Natürlich gibt es auch unschuldige Erklärungen für den Vorfall. So könnte ein Webentwickler, der ansonsten nicht auf Github aktiv ist, den Bug gefunden und einen Patch eingereicht haben.

Ähnlicher Vorfall bei Angular.js

So weit hergeholt ist die Idee, dass durch einen Bugfix eine Sicherheitslücke erst geschaffen wird, nicht. Einen ähnlichen Vorfall gab es beim Javascript-Framework Angular.js - allerdings ohne bösartigen Hintergrund. Darüber hatte Mario Heiderich von der Berliner Firma Cure53 in einem Vortrag auf der Ruhrsec-Konferenz berichtet (ab Minute 33).

Mitarbeiter von Cure53 hatten einen Fehler in der Sandbox von Angular.js entdeckt. Dieser Fehler führte dazu, dass ein Bypass für die Sandbox nicht funktionierte. Die Cure53-Mitarbeiter wollten austesten, ob sie den Bugfix einreichen konnten, ohne dass der Sandbox-Bypass bemerkt wurde.

Die Entwicklung von Angular.js wird von Google unterstützt. Die Cure53-Mitarbeiter informierten das Google-Sicherheitsteam über ihren Plan, nicht jedoch die Angular.js-Entwickler selbst. Der entsprechende Pull-Request wurde angenommen. Cure53 informierte anschließend die Angular.js-Entwickler und vor der Veröffentlichung eines neuen Releases wurde der Sandbox-Bypass ebenfalls behoben.

Joomla-Lücke wird bereits aktiv ausgenutzt

Die Joomla-Sicherheitslücken werden bereits aktiv ausgenutzt. Laut der Firma Sucuri begannen erste Massen-Angriffsversuche auf Joomla-Installationen wenige Stunden nach der Veröffentlichung der Lücke. Wer Joomla betreibt und dieses bislang nicht aktualisiert hat, muss also damit rechnen, dass seine Webseite mit hoher Warscheinlichkeit bereits kompromittiert wurde.

Nutzer von populären Content-Management-Systemen müssen dafür sorgen, dass diese immer aktuell gehalten werden, oftmals innerhalb von Stunden. Anders als der Konkurrent Wordpress besitzt Joomla von Haus aus keine automatische Update-Funktion. Es gibt ein Auto-Update allerdings als inoffizielle Erweiterung.

Immer wieder werden sehr kritische Lücken in Joomla oder anderen populären Content-Management-Systemen entdeckt. Im vergangenen Jahr war Joomla zweimal Opfer von ähnlich kritischen Schwachstellen. Auch Drupal war vor einiger Zeit betroffen. Jedesmal, wenn derart kritische Lücken in einer populären Webanwendung gefunden werden, gibt es kurz danach Versuche, diese mittels Internet-weiter Scans auszunutzen.