Eintritt frei

Mit einem Content-Management-System installiert man unter anderem die Grundlage für jetzige und zukünftige Sicherheitslücken.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 18 Min.
Von
  • Jürgen Baum
  • Clemens Pflüger
Inhaltsverzeichnis

Mit fortschreitender Perfektionierung sind Open-Source-CMS zu einer echten Alternative zu kommerziellen Angeboten avanciert: vielseitig, kostengünstig und zuverlässig. Aber sind sie für einen privaten Anwender, ein Unternehmen oder eine öffentliche Einrichtung tatsächlich sicher genug? Mutiert ein solches CMS nicht in kürzester Zeit zu einer Virenschleuder oder Botnetz-Plattform? Diese Fragen hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) in einer Sicherheitsstudie untersucht (siehe den Kasten „CMS-Sicherheitsstudie…“).

Es gibt eine ganze Reihe von Open-Source-Systemen, die die gewünschten Funktionen kostenlos und „von der Stange“ bieten und deshalb beliebt sind. Aber gerade bei häufig eingesetzten Produkten hat deren Sicherheit eine besondere Bedeutung, denn eine bekannte Sicherheitslücke gefährdet viele damit erstellte Websites gleichzeitig. Ein CMS ist meist an der Schnittstelle zwischen dem öffentlichen Internet und dem privaten oder firmeninternen Netz platziert. Angriffe auf das System könnten daher den Weg in den zu schützenden inneren Bereich des Netzes öffnen. Ein erfolgreiches Eindringen in die Management-Komponente eines solchen Systems, das meist nicht separat betriebene Backend, wäre besonders fatal, da damit die Inhalte der Website mit den regulären Mechanismen unbemerkt verändert oder zerstört werden könnten. Das gefährdet letztlich sogar die Besucher der Website durch dort deponierten Schadcode (Drive-by-Downloads).

Mehr Infos

iX-TRACT

  • Gängige Content-Management-Systeme als Open Source bieten neben vielfältigen Funktionen ein ausreichendes Maß an Sicherheit. Das größte Risiko liegt in der Verwendung ungeprüfter Plug-ins und Erweiterungen.
  • Keines der Systeme sollte direkt aus der „Box“ online gehen und unbeaufsichtigt betrieben werden.
  • Sicherheits-Patches müssen zeitnah eingespielt werden, um breit angelegte Angriffe gegen Systeme gleichen Typs zu vermeiden.

Bei der Auswahl eines CMS sollten Interessenten gründlich prüfen, ob und wie häufig Sicherheitsprobleme zu erwarten sind, wie schnell und angemessen der Hersteller die Lücken beseitigt und wie viel Aufwand der Administrator des CMS haben dürfte, das System sicher zu betreiben. Neben dem naheliegenden Auswahlkriterium, ob ein CMS die benötigten Funktionen bietet, gibt es vier sicherheitsrelevante Bereiche, die Kunden hinterfragen sollten:

– Transparenz: Sind Sicherheitsaspekte berücksichtigt und die Schutzmechanismen dokumentiert, sodass eine Produktauswahl darauf aufbauen kann?

– Architektur und Entwicklungsprozess: Ist das System so gebaut, dass es Sicherheitsprobleme von vornherein vermeidet, und arbeiten die Entwickler so, dass Lücken nicht nachträglich hineinrutschen können?

– Installation und Konfiguration: Führen Beschreibungen, Anleitungen und Scripts den Administrator so, dass er eine sichere Konfiguration erhält?

– Betrieb: Lässt sich das System leicht überwachen oder in ein Systemmanagement einbinden? Wie steht es um die Versorgung mit Updates und Security Patches?

Fünf quelloffene CMS hat das BSI nach diesen Fragestellungen in einer Studie untersuchen lassen und die Ergebnisse veröffentlicht (siehe „Alle Links“): Drupal, Joomla, Plone, TYPO3 und WordPress. Die Studie enthält unter anderem die Beschreibung aller 81 verwendeten Bewertungskriterien und kann dadurch dazu dienen, die Sicherheit anderer als der dort geprüften CMS einzuschätzen.

Für eine Einschätzung der Bedrohung durch Sicherheitslücken ist es zunächst interessant, wie viele Schwachstellen es in der Vergangenheit gegeben hat, wie gravierend sie waren und wie schnell der Hersteller Abhilfe geschaffen hat. CMS erhalten oft erst durch Plug-ins oder Zusatzmodule den benötigten Funktionsumfang. Deswegen ist es wichtig zu wissen, ob die Lücken im Basissystem oder in den Erweiterungen aufgetreten sind. Für diese Untersuchung können die Liste der Common Vulnerabilities and Exposures (CVE) sowie die National Vulnerability Database (NVD) – beide frei zugänglich, siehe wiederum „Alle Links“ – zusammen mit den Release-Mitteilungen des jeweiligen Herstellers herangezogen werden.

Verhältnis der Schwachstellen untereinander sowie im Vergleich von Erweiterungen und Basisinstallation. Auffallend, dass Plone insgesamt die geringste Zahl an Lücken enthält (rechts) und relativ die meisten innerhalb des Basissystems (Abb. 1).

Die BSI-Studie ergab, dass für TYPO3 die meisten und für Plone die wenigsten Angriffspunkte gemeldet wurden. Im Mittel waren es 14 Schwachstellen pro CMS und Jahr (siehe Abb. 1). Bei Plone fiel auf, dass im Gegensatz zu den anderen Systemen 70 % der Sicherheitslücken im CMS-Kern und nur 30 % in externen Erweiterungen entdeckt wurden. Jedoch ist zu berücksichtigen, dass Plone im Vergleich insgesamt geringfügig weniger Schwachstellen aufweist und viele Zusatzfunktionen schon Teil der Basisinstallation sind.

Besonders hilfreich für die Auswahl eines Systems ist es, das Produkt ohne großen Aufwand ausprobieren zu können. Wenn Dokumentation, Schulungen oder Anleitungen zu Sicherheitsthemen vorliegen, kann man sich im Vorfeld informieren, welche Mechanismen es gibt und ob sie für das eigene Anwendungsszenario geeignet sind. Für eine Einschätzung, wie schnell und sorgfältig der Hersteller auf gemeldete Sicherheitsprobleme reagiert, sollte man prüfen, ob eine Kontaktadresse leicht zu finden, ein Bug-Tracking-System einsehbar ist und ob es Advisories oder Ähnliches zu Sicherheitsthemen gibt.

Da die in der Studie betrachteten CMS Open-Source-Systeme sind, kann man sie immer selbst installieren; Joomla und TYPO3 bieten dafür spezielle Pakete mit Beispieldaten an. Für alle Systeme gibt es außerdem öffentliche Demoserver. Alle haben die Kontaktadresse für Sicherheitsmeldungen gut auffindbar genannt, bieten umfangreiche Dokumentationen und Anleitungen und betreiben ein Bug-Tracking-System. Noch nicht geschlossene Sicherheitslücken werden in diesen Systemen allerdings nicht veröffentlicht, damit potenzielle Angreifer vor der Behebung des Fehlers keine Informationen zur Ausnutzung der Lücke erhalten.

Architektur eines CMS: die logischen Funktionen wie Auslieferungssystem, Inhaltsserver und Datenhaltung bleiben getrennt (Abb. 2).

Wesentliche Voraussetzung für ein sicheres System ist die Architektur des Systems. Für ein CMS heißt das beispielsweise, dass die logischen Funktionen wie Auslieferungssystem (liefert die Seiten an den Leser), Inhaltsserver (stellt unter anderem die Inhalte bereit; auf ihm arbeiten die Redakteure) und Datenhaltung getrennt sind und sich auf mehrere Server verteilen lassen (siehe Abb. 2). Die einzelnen Bestandteile sind weniger komplex und lassen sich leichter absichern.

Alle fünf in der BSI-Studie untersuchten Systeme setzen diese Anforderung im Grundsatz um. Plone, das auf dem Applikationsserver Zope aufsetzt, ist in dieser Hinsicht noch flexibler als die vier übrigen, PHP-basierten CMS. Dass keine veralteten Bibliotheken oder Sprachversionen wie PHP 4.x verwendet werden, sollte selbstverständlich sein, denn bekannte, in aktuellen Versionen längst behobene Lücken würden die Sicherheit des Systems bedrohen. Durch die Unterstützung von RSS, XHTML, jQuery, WebDAV oder WS-Security und die Verwendung der zugehörigen Bibliotheken vermeidet man Fehler in eigenen, proprietären Lösungen. Die Anbindung gängiger Authentifizierungsverfahren wie OpenID, OAuth oder über LDAP sollte im Grundsystem schon vorgesehen und für komplexere Lösungen sollten Webservices, Payment-Funktionen, SOAP und WS-Security integrierbar sein.

Die betrachteten CMS bringen keine Standardbibliotheken mit, sondern setzen sie voraus. Es ist deshalb Aufgabe des Administrators, die CMS auf dem aktuellen Stand zu halten und Sicherheits-Patches zeitnah einzuspielen. Der Unified Installer von Plone installiert neben Plone selbst die passende Python-Version und das Zope-2-Framework, setzt aber abgesehen davon ebenfalls einige Standardkomponenten voraus.

Webservices werden kaum unterstützt; erfahrene Administratoren können sie, wenn erforderlich, einbinden. Eine Payment-Funktion bieten alle CMS, Joomla, Drupal und Plone mit eigenen Erweiterungen, Joomla über Drittanbieter. Authentifizierungs-Standards können ebenfalls allen Systeme nutzen; um Sicherheitslücken zu vermeiden, müssen Admins sie aber sorgfältig konfigurieren.

Sollen mehrere Autoren an einer Website mit unterschiedlichen Bereichen arbeiten, sind abgestufte Zugriffsrechte nötig. Alle Systeme haben ein rollen- oder gruppenbasiertes Rechtesystem; die Gliederungsmöglichkeiten der Site-Inhalte nach Zugriffsrechten sind bei TYPO3, Joomla, Drupal und Plone detailliert. Rechtevererbung stellte die Studie dagegen nur bei WordPress und Joomla fest.

Grundsätzlich ist für ein CMS eine sichere Ablage der Daten wichtig; die Inhalte dürfen immer nur dazu berechtigte Benutzer lesen oder ändern. Der Speicherung der Zugangsdaten kommt eine besondere Bedeutung zu, denn wer sich unter falscher Identität anmelden kann, hat Zugriffsrechte, die ihm nicht zustehen.

Sichere Verfahren für die Registrierung und Anmeldung sind ebenfalls essenziell. Ein Angreifer darf beispielsweise aus einer Login-Fehlermeldung nicht erkennen können, ob der verwendete Benutzername oder das Passwort falsch war. Automatisierte Massenregistrierungen dürfen das System nicht überlasten. Ein Schutz gegen das systematische Ausprobieren aller denkbaren Passwörter (Brute-Force-Angriff) muss vorhanden sein.

Die Ablage der Zugangsdaten setzen die betrachteten CMS unterschiedlich um. Drupal und Plone nutzen einen SHA-basierten Algorithmus. Joomla verwendet einen MD5-Hash. TYPO3 und WordPress bieten neben MD5 noch andere Verfahren an. Das MD5-Hashing-Verfahren entspricht allerdings nicht mehr heutigen Mindestanforderungen an die Sicherheit von Hash-Algorithmen.

Zum Schutz vor gängigen Angriffsszenarien sollten Maßnahmen gegen Cross-Site Request Forgery (CSRF oder XSRF) implementiert sein und für zur Sessionverwaltung eingesetzte Cookies sollte das HttpOnly-Flag gesetzt werden können, um Angriffe durch Cross-Site Scripting (XSS) zu verhindern. Alle Systeme unterstützen Schutzmaßnahmen in dieser Richtung.

In Open-Source-Projekten, bei denen die Entwickler in verteilten Teams arbeiten und vielleicht häufig wechseln, sind einheitliche Qualitätskriterien eine Voraussetzung für die Vermeidung von Fehlern und damit von Sicherheitsproblemen im Produkt. Damit Entwickler diese Regeln beachten, sollten organisatorische oder technische Mittel zum Einsatz kommen, sie durchzusetzen. Design Reviews, Code Reviews und Sicherheitstests sind probate Mittel dafür.

Öffentlich einsehbare Richtlinien und Qualitätskriterien gibt es bei allen untersuchten CMS. Organisatorische Maßnahmen für ihre Durchsetzung sind mit Ausnahme von Joomla dokumentiert. Über Sicherheitsanalysen der CMS ist nur wenig veröffentlicht, aber da es bei allen Herstellern ein Security Team gibt, kann man von einer internen Prüfung ausgehen. Für externe Erweiterungen oder Plug-ins haben TYPO3, Drupal und Plone Richtlinien aufgestellt, die vor der Aufnahme einer Erweiterung in die offizielle Liste geprüft werden. Teilweise sind außerdem automatisierte Tests oder eine Begutachtung durch ein Community Member vorgesehen. Von Dritten angebotene Plug-ins haben diese Prüfungen möglicherweise nicht durchlaufen.

Selbstverständlich soll man ein CMS nicht mit Root-Rechten auf einem Server betreiben; das Risiko, dass ein Angreifer nach Ausnutzen einer Lücke im CMS uneingeschränkten Zugriff auf den Server hat, wäre nicht akzeptabel. Und solche Rechte für die Installation sind ebenfalls nicht gut, falls das System bei einem Provider laufen soll, bei dem man üblicherweise dieses Privileg nicht bekommt.

Die BSI-Studie ergab, dass TYPO3, WordPress und Joomla mit den Rechten des Webservers Apache beziehungsweise IIS laufen; Drupal und Plone mit einem eigenen Benutzerkonto ohne administrative Rechte.

Eine häufige Quelle von Sicherheitsproblemen ist es, wenn vor oder nach der Installation noch viele manuelle Einstellungen erforderlich sind. Hier vergessen Admins oft wichtige Konfigurationsschritte oder übernehmen Unsauberkeiten aus dem nicht so kritischen Test- in den Produktivbetrieb.

Joomla und Plone installieren sich komplett über einen geführten Dialog ohne weitere Schritte. Für TYPO3, WordPress und Drupal müssen die Zuständigen zunächst die Datenbank anlegen und deren Zugangsdaten in einer Konfigurationsdatei angeben. Ein Skript erfragt weitere Einzelheiten und erledigt Installation und Konfiguration. Bei TYPO3 und Drupal sind allerdings anschließend Nacharbeiten nötig: Den Zugriff auf sicherheitsrelevante Dateien oder Verzeichnisse muss der Admin wieder sperren und vom Skript angelegte CMS-interne Nutzer-Accounts löschen oder deren allgemein bekannte Passwörter ändern.

Durch eine sichere Default-Installation können Zuständige die Risiken für den späteren Betrieb minimieren. Außer den schon genannten Standardkonten oder -passwörtern betrifft das beispielsweise die Einstellungen für Cookies oder den verschlüsselten Zugang zum Backend.

Bei TYPO3 ist in der Grundeinstellung der Schalter für Secure Cookies deaktiviert und für den Backend-Zugang wird das Protokoll HTTPS nicht erzwungen. WordPress und Joomla erlauben in der Standardkonfiguration ebenfalls den unverschlüsselten Zugang zum Administrator-Backend über HTTP.

Oft muss man Einstellungen für das CMS in einer zentralen Datei konfigurieren. Wenn die Einträge dort nicht oder nicht ausreichend durch Kommentare beschrieben sind, mutieren Änderungen zu einem Ratespiel und führen zu Risiken durch Fehleinträge. Hinweise zur Bedeutung der Parameter findet man in den Konfigurationsdateien von TYPO3 kaum. Die Datei von WordPress ist ausführlich dokumentiert. Die von Joomla mitgebrachte Template-Datei enthielt zwar einige Kommentare, die daraus durch die Installation erzeugte, im Betrieb aktive Konfigurationsdatei aber leider keinen mehr. Drupal und Plone haben keine zentrale Konfigurationsdatei.

Wichtig ist außerdem, dass man diese Konfigurationseinstellungen bei einem Update des CMS problemlos übernehmen kann und nicht erneut einstellen muss. Bei TYPO3, WordPress und Joomla läuft das automatisch; bei Drupal muss der Admin die wichtige Datei .htaccess retten und wiederherstellen; bei Plone war dies für die Studie nicht überprüfbar.

Eins der wichtigen Ziele beim Betrieb eines CMS ist es, das System auf einem sicheren Stand zu halten und beim Auftreten einer Sicherheitslücke schnell und angemessen zu reagieren. Dabei ist es für den Administrator wichtig, ausreichende Informationen über die Security Patches, Updates oder Releases zu erhalten und sich in schwierigen Fällen in Foren oder direkt an Entwickler, die sich mit Sicherheitsfragen befassen, wenden zu können.

Die Begleitinformationen zu Security Patches sind bei den untersuchten CMS unterschiedlich detailliert: Nicht alle nennen die behobenen Fehlermeldungen oder die betroffenen Versionen. Alle Entwicklergruppen haben Security Teams. Foren speziell zu Sicherheitsfragen gibt es bei Joomla und Drupal.

Alle betrachteten Systeme sind flexibel genug, angepasst zu werden. Jedoch müssen die Zuständigen den Aufwand jeweils abschätzen. Hier ist es hilfreich, wie die Studie es empfiehlt, sich beispielhaft an Szenarien zu orientieren. Diese reichen vom „Private Event Site“ bis hin zum „mittelständischen Unternehmen mit mehreren Standorten“ (siehe den Kasten „CMS-Sicherheitsstudie…“).

Aktuelle Open-Source-Web-Content-Management-Systeme sind flexibel, kostengünstig und sicher. Jedoch muss man für den Betrieb einige Regeln beachten. Die vollständige Studie kann kostenlos von den Seiten des BSI heruntergeladen werden (siehe „Alle Links“).

Bei der Nutzung von Plug-ins und Erweiterungen sollte man mit Bedacht vorgehen. Jedes CMS möchte gepflegt werden, und man sollte dementsprechend viel Zeit für die Wartung und das Einspielen von Patches einplanen, bei einem professionellen System mindestens 15 Minuten pro Tag. Handelt man dementsprechend, kann man mit einem Open-Source-CMS (fast) jeden Internetauftritt professionell realisieren. 

Jürgen Baum und Clemens Pflüger
sind Wissenschaftler beim Fraunhofer-Institut für Sichere Informationstechnologie SIT und Mitautoren der „Sicherheitsstudie Content Management Systeme“ des BSI.

Alle Links: www.ix.de/ix1312094