Eierlegende Wollmilchsau – WordPress Sicherheit Teil2

1. Fragwürdige Designentscheidungen

WordPress ist zu einer Eierlegenden Wollmilchsau geworden. Es bietet »nur Vorteile, befriedigt alle Bedürfnisse und genügt allen Ansprüchen«. Worauf ich hinaus möchte: WordPress bietet für fast jeden Anwendungsfall eine Lösung – wurde dazu aber derart mit (unnötigen) Funktionen überfrachtet, dass ein sicherer und datenschutzkonformer Betrieb nahezu unmöglich ist.

Das Entwicklerteam von WordPress ergänzt auf Basis von Community-Vorschlägen oder eigenen Designvorstellungen immer neue Funktionen. Viele dieser neuen »Features« wirken sich allerdings negativ auf die Sicherheit von WordPress aus und werden den Nutzern geradezu aufgezwungen. Zu allem übel wird dem WordPress-Betreiber dann nicht einmal die Freiheit gewährt, die »lästige« Funktion über das WordPress-Backend zu deaktivieren.

WordPress-Betreiber stehen vor einem Dilemma: Einerseits können sie über den Funktionsumfang von WordPress nahezu jeden Anwendungsfall realisieren, andererseits ist genau dieser Funktionsumfang problematisch, wenn dieser als Einfallstor für Hacker dient oder den datenschutzkonformen Betrieb erschweren. Im vorliegenden Beitrag möchte ich fragwürdige Designentscheidungen vorstellen und euch vor Augen führen, dass eine Standard-Installation von WordPress für den sicheren Praxisbetrieb ungeeignet ist.

Dieser Beitrag ist Teil einer Artikelserie:

Tipps zum Absichern eurer WordPress-Installation:

2. WordPress Sicherheit: Unbedachte Risiken

Mittlerweile ist WordPress bei der Version 4.x angekommen. Die erste stabile Version ist am 3. Januar 2004 erschienen. Zwischen der ersten Version und heute liegen gut 12 Jahre und etliche Neuerungen. Aus meiner Sicht stellen einige dieser Neuerungen allerdings ein unbedachtes Sicherheits- und Datenschutzrisiko dar. Das WordPress-Entwicklerteam agiert getreu dem Motto »Triff Entscheidungen und stelle den User nicht ständig vor die Wahl«.

Im Folgenden möchte ich euch WordPress-Funktionen vorstellen, auf die ein Nutzer über das Dashboard keinen Einfluss hat. Erst die Installation von zusätzlichen Plugins oder durch Eingriffe in die functions.php lassen sich diese »Features« deaktivieren. Wer sich Gedanken um die Sicherheit und den Datenschutz macht, der muss sich über eines klar werden: Ihr müsst selbst tätig werden.

2.1 Tracking durch das Nachladen von Google-Schriften

Update

02.10.2016: Das WordPress-Team hatte endlich ein Einsehen. Seit Version 4.6 wurde die Google-Schrift wieder aus dem Backend entfernt.

Ende 2013 wurde in einer Diskussion erörtert, wie die Integration von Web-Fonts technisch umgesetzt werden soll, die Google kostenlos auf seinen Servern bereitstellt. Argumente gegen die Integration bzw. dem ständigen Nachladen von Schriftarten von Google Servern wurden vom WordPress-Entwicklerteam beiseite gewischt. Im Fokus standen demnach nicht die Datenschutzbedenken der Nutzer, sondern die kosmetische »Aufhübschung« von WordPress.

Die Diskussion war allerdings reine Augenwischerei, denn die Entscheidung war längst gefallen: Ab der Version 3.8 von WordPress wurde die Schrift Open Sans von der Quelle »fonts.googleapis.com« in das WordPress-Backend eingebunden. Das bedeutet: Jedes mal wenn sich ein Nutzer in das Dashboard einloggt, wird eine Verbindung zu den Google Servern aufgebaut und Open Sans vom Browser nachgeladen. Hinsichtlich des Datenschutzes ist dies eine sehr fragwürdige Entscheidung und wurde auch entsprechend kritisiert. Doch bis heute hat sich nichts geändert. Das WordPress-Team hält an seiner Entscheidung von damals fest.

Einziger Ausweg ist die Installation eines Plugins, wie bspw. Disable Google Fonts oder die Deaktivierung über ein Code-Snippet in der WordPress functions.php:

/* Remove Google Open Sans that WP adds from frontend */
function remove_wp_open_sans() {
   wp_deregister_style( 'open-sans' );
   wp_register_style( 'open-sans', false );
}
add_action('wp_enqueue_scripts', 'remove_wp_open_sans');
add_action('admin_enqueue_scripts', 'remove_wp_open_sans');

2.2 XML-RPC-Schnittstelle

Die XML-RPC-Schnittstelle stellt eine weitere fragwürdige Designentscheidung dar. Im Grunde erfüllt sie zwei Hauptfunktionen: Die Pingback-API ermöglicht eine Art »Vernetzung« zwischen WordPress-Blogs und dient gleichzeitig als Schnittstelle, um WordPress über externe Programme oder Apps (bspw. WordPress for Android) verwalten zu können. In den meisten Fällen benötigen Nutzer diese Schnittstelle allerdings nicht, weil sie ihre Artikel bzw. Seiten direkt in WordPress erstellen.

Seit der WordPress-Version 3.5 ist diese XML-RPC-Schnittstelle nun standardmäßig aktiv und lässt sich nicht einfach im Dashboard deaktivieren. Das ist hinsichtlich der Sicherheit äußerst problematisch, da sie gerne als Einfallstor für Brute-Force-Angriffe genutzt wird. Ein Angreifer kann über die XML-RPC-Schnittstelle beliebig oft Kombinationen aus Benutzername und Passwort durchprobieren. Das funktioniert mit einem Tool (das ich nicht verlinke!) vollkommen automatisch und ist dazu auch effizient durchführbar. Bis zu 500 Passwörter lassen sich pro Aufruf an die xmlrpc.php unterbringen und reduzieren den zeitlichen Aufwand damit erheblich, irgendwann auf die korrekten Login-Daten zu stoßen. Selbst aktuelle WordPress-Versionen (4.x) sind davor nicht geschützt. Das Mindestmaß an Sicherheit wäre ein Schutzmechanismus, mit dem der Login-Prozess nach einer Anzahl von Fehlversuchen verzögert oder blockiert wird.

WordPress auf Schwachstellen und Konfigurationsfehler prüfen

Für Deine WordPress-Installation habe ich ein spezielles Leistungspaket im Angebot:

Scan Deiner WordPress-Installation auf Schwachstellen
Auswertung und Beurteilung der gefundenen Schwachstellen
Auf Basis der Ergebnisse erhälst Du von mir individuelle Maßnahmenempfehlungen zur Behebung und Absicherung

Wenn du Deine WordPress-Installation nachhaltig absichern möchtest, kannst Du mich gerne kontaktieren.

Gut zu wissen: Sicherheit erlangst Du nicht durch die Installation unzähliger Security-Plugins, sondern durch eine saubere Konfiguration, stetige Updates und proaktive Maßnahmen zur Absicherung. Kontakt aufnehmen

Es ist nur eine Frage der Zeit, bis ein Angreifer die korrekten Login-Daten findet. Im Anschluss kann er sich über die XML-RPC-Schnittstelle im WordPress-Backend anmelden. Was vielen nicht klar ist: Es ist demnach völlig unzureichend nur den WordPress-Adminbereich bspw. über eine .htaccess Modifikation vor Eindringlingen zu schützen. Das greift leider zu kurz. Solltet ihr die XML-RPC-Schnittstelle nicht benötigen, so kann sie über ein Plugin (bspw. Disable XML-RPC) deaktiviert werden. Leider funktioniert dies nicht immer zuverlässig, weshalb eine komplette Zugriffssperre über eine .htaccess Modifikation empfehlenswert ist:

Apache Zugriffsschutz für die xmlrpc.php und weitere »interessante« Informationen:

# Bis einschließlich Apache 2.3
# Disallow access to important files
<FilesMatch "(^\.|wp-config\.php|xmlrpc\.php|(?<!robots)\.txt|(liesmich|readme)\.*)"> 
   Order deny,allow 
   Deny from all 
</FilesMatch>

# Ab Apache 2.4
# Disallow access to important files
<FilesMatch "(^\.|wp-config\.php|xmlrpc\.php|(?<!robots)\.txt|(liesmich|readme)\.*)">
   Require all denied
</FilesMatch>

nginx Zugriffsschutz für die xmlrpc.php und weitere »interessante« Informationen:

# Disallow access to important files
location ~* (/\.|wp-config\.php|xmlrpc\.php|(?<!robots)\.txt|(liesmich|readme).*) {
   return 444;
}

Wer partout nicht auf die xmlrpc.php Schnittstelle verzichten möchte, um bspw. weiterhin über externe Programme (Weblog Client) seinen Blog zu verwalten, der findet im Artikel »Serverseitiger Schutz – WordPress absichern Teil5« eine Lösungsvariante mit Passwortschutz für Apache oder nginx.

Hinweis: Im Beitrag WordPress: Angriffe auf die XMLRPC-Schnittstelle (xmlrpc.php) unterbinden sind zu diesem Thema noch weitere Informationen abrufbar.

Der Kuketz-Blog ist spendenfinanziert!

Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.

Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.

Mitmachen ➡

2.3 Performance Bremse Emoticons

Seit der Version 4.2 sind in WordPress sog. Emoticons integriert. Diese werden bei jedem Seitenaufruf direkt im HTML-Header eingebunden – unabhängig davon, ob sie benutzt werden oder nicht. Dies verdeutlicht zum wiederholten Mal: Die WordPress-Entwickler integrieren fragwürdige Funktionen direkt in den WordPress-Kern, ohne dem Anwender die Möglichkeit zu geben, das »Feature« bei Nichtgefallen wieder zu deaktivieren.

WordPress-Emoticons

Die Einbindung der Emoticons kann sich negativ auf die Ladezeit von WordPress auswirken – gerade im Hinblick auf Suchmaschinenoptimierung und Geschwindigkeit stellt diese Designentscheidung für viele ein Problem dar. Professionelle Webauftritte wie Unternehmensseiten, Webshop-Betreiber oder andere Projekte auf Basis von WordPress können auf die Emoticons vermutlich auch verzichten. Es muss also die Frage gestellt werden: Möchte WordPress langfristig auch im professionellen Bereich mitmischen oder eher die Spaß- und Lifestyle-Community bedienen? Oder anders gefragt: Wie lange tolerieren WordPress-Betreiber diese fragwürdigen Designentscheidungen noch, bevor sie Konsequenzen ziehen und WordPress womöglich den Rücken kehren?

Über das WordPress-Backend lassen sich die Emoticons nicht deaktivieren. Mit dem Plugin Disable Emojis oder dem nachfolgenden Code-Snippet für die functions.php ist eine Deaktivierung möglich:

/* Disable the emoji's */
function disable_emojis() {
   remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
   remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
   remove_action( 'wp_print_styles', 'print_emoji_styles' );
   remove_action( 'admin_print_styles', 'print_emoji_styles' ); 
   remove_filter( 'the_content_feed', 'wp_staticize_emoji' );
   remove_filter( 'comment_text_rss', 'wp_staticize_emoji' ); 
   remove_filter( 'wp_mail', 'wp_staticize_emoji_for_email' );
   add_filter( 'tiny_mce_plugins', 'disable_emojis_tinymce' );
}
add_action( 'init', 'disable_emojis' );

/* Remove the TinyMCE emoji plugin */
function disable_emojis_tinymce( $plugins ) {
   if ( is_array( $plugins ) ) {
      return array_diff( $plugins, array( 'wpemoji' ) );
   } else {
      return array();
   }
}

3. Fazit

Ohne die hervorragende WordPress-Community wäre WordPress längst nicht da, wo es heute steht: An der Spitze der Blog- und CMS-Systeme. Die Plugins und Code-Snippets der Community konnten die »Fehlentscheidungen« der WordPress-Entwickler bisher immer wieder abfedern. Ich muss es noch einmal in aller Deutlichkeit sagen: Eine Standard WordPress-Installation ist für den professionellen Betrieb ungeeignet. Die genannten Beispiele sollten dies verdeutlichen.

Es gleicht einem Katz-und-Maus-Spiel: Mit nahezu jeder WordPress-Version werden neue Funktionen integriert, die sowohl in Bezug auf Sicherheit, als auch Datenschutz auf den Prüfstand gestellt werden müssen. Eine Aufgabe, die nicht jeder leisten kann oder möchte. Insbesondere den Betreibern von professionellen WordPress-Seiten sei dies allerdings dringend angeraten.

Abermals zeigt sich: Zwischen Sicherheit und Funktionsumfang besteht oftmals ein Widerspruch – beides zusammen geht nicht oder endet in einem faulen Kompromiss. Und dennoch wird die WordPress-Wollmilchsau weiter gemolken.

Bildquellen:

WordPress Logo: WordPress, Free license
Eierlegende Wollmilchsau: Pixelrausch, Creative Commons CC0

Über den Autor | Kuketz

Mike Kuketz

In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.

Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.

Mehr Erfahren ➡

Unterstützen

Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.

Folge dem Blog

Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:

Bleib aktuell ➡

Diskussion

6 Ergänzungen zu “Eierlegende Wollmilchsau – WordPress Sicherheit Teil2”

Hendrik sagt:

2. März 2016 um 11:50 Uhr

Leider sieht es mit anderen Systemen wie Drupal oder Joomla nicht besser aus, welches System kann man denn noch empfehlen ohne das Rad selbst neu erfinden zu müssen?
Anonymous sagt:

2. März 2016 um 13:24 Uhr

Das kann doch eigentlich auch nicht sein, dass man bei so einem populären Blog-CMS noch derart nachbessern muss um ein einigermaßen sicheres WordPress zu bekommen.
Die einfachsten Dinge werden nicht mitgeliefert und müssen entweder per Plugin nachgerüstet, oder oder durch mehr oder weniger aufwendige Regeln in der Webserver-Konfiguration geblockt/limitiert werden. PHP hilft da in Sachen Sicherheit auch oft nicht wirklich nach. (?-s)

Da muss man eine xmlrpc.php blocken, die auch durchaus nützliche Funktionen (Pingback/Trackback) mit sich bringt, weil sie ein riesengroßes Einfallstor ist.
Man wird dazu verleitet, fragwürdigen, veralteten, nicht auditierten Code in Form von (Sicherheits)Plugins auf seinen Server zu laden. Es gibt für eine Funktion dutzende verschiedener Plugins. Die einfachsten Funktionen, die eigentlich mit dem System mitgeliefert werden sollten, können nur mit Plugins nachgerüstet werden.

Vielleicht sollte man mal einen komplett neuen Ansatz verfolgen und ein Massen-taugliches Blog-System in die Welt werfen bzw. bestehende unterstützen ( in Form von Anleitungen, Wikis und Foren mit Inhalt befüllen, ausreichend und vor allem gute Themes und Plugins), die sich in Sachen Datenschutz und Sicherheit in die richtige Richtung bewegen.
Dank der großen Massenhoster beschränkt es sich hier allerdings auch wieder auf in PHP geschriebene Systeme. Habe bisher keinen der größeren Hoster gesehen, die Python/Django oder nodeJS „erlauben“. So kann das nichts werden.

Ich denke da grade an die Menschen, die einfach nur „losbloggen“ wollen. Seien es jetzt Lifestyle-, Food-, Fashion-, Tech- oder Travel-Blogs von Leuten, die eben keine Ahnung von der Materie haben, sich im besten Fall grade so ein WordPress auf ihrem 2,50€ Webspace zusammen klicken können und sich erst gar keinen Kopf um die Sicherheit machen.

Wie oft sehe ich Webseiten, auf denen vielleicht einmal im Jahr was geändert wird, also nahezu rein statische Inhalte, und dahinter eine komplette, oft veraltete WordPress-Installation.

So. Jetzt hab ich mich mal ausgek***t.
- Anonymous sagt:
  
  2. März 2016 um 21:10 Uhr
  
  bezüglich der deiner Meinung nach sinnvollen Pingback Funktion im xmlrpc.php:
  Neben der von Mike bereits angerissenen Vulnerability in XML-RPC, birgt genau diese Pingback Funktion erhebliche Gefahren.
  Wenn ein Angreifer sich nur die Funktionsbeschreibung von Pingbacks durchließt, sind die ersten Dinge die im in den Sinn kommen DDOS und Traffic Amplification. Damals hat es nicht lange gedauert bis auch dafür die ersten Tools aus dem Boden geschossen sind (ist ein paar Jahre her).
  Keine Ahnung ob das in irgendeiner Weise je gepatched wurde. Vielleicht kann Mike auch dazu etwas sagen, ob das Ganze bereits gefixt wurde.
  
  Wenn du Pingback trotzdem nutzen möchstest kannst du einfach deine IP whitelisten (sofern du nich über eine dynamische IP aus dem Internet drauf zugreifen möchtest)
  Dazu hier ein Snippet:
```
Order Deny,Allow
Deny from all
Allow from 123.321.123.321
```
  Die meisten Nutzer lassen sich von Features blenden. Auf die Sicherheit achtet der Durchschnittsnutzer in der Regel nicht. Einige Entscheidungen von WordPress sind sehr fragwürdig. Dennoch, wenn WordPress minimalistisch und sicher wäre, hätte es weniger Features und wäre aufgrund der sicheren Konfiguration etwas umständlicher zu nutzen. Damit würde sich der Durchschnittsnutzer eine andere Lösung mit vielen Features und wenig Sicherheit suchen.
  Außerdem werden sie die Installation wahrscheinlich sowieso nie patchen. Somit wäre sie auch mit sicherer Konfiguration angreifbar.
  - Anonymous sagt:
    
    3. März 2016 um 13:58 Uhr
    
    Vielleicht habe ich die Funktion von Pingback falsch verstanden, aber es macht doch keinen Unterschied, ob ich nun meine IP whiteliste. Die Schnittstelle ich doch unter anderem dazu da, dass Blog A, Blog B darüber informieren kann dass Blog B auf Blog A verlinkt/erwähnt wurde. Oder habe ich da was falsch verstanden? Das jedenfalls halte ich für eine sinnvolle Funktion, die dann eben in ihren Rechten so weit beschnitten werden muss, dass auch nur DAS möglich ist und keine 500 Passwörter pro Aufruf auszuprobieren.
    
    Man muss WordPress ja nicht massiv in seiner Funktion beschränken, nur dass es sicherer wird. Ausnahmen bestätigen die Regel. Aber man könnte direkt in der Installationsroutine anfangen Sicherheitsrelevante Einstellungen direkt richtig zu machen.
    Also admin-User nicht per default id 0 geben, sondern eine zufällige 4-5 stellige. Unter Apache direkt eine .htaccess so anlegen, dass PHP-Dateien, die nur irgendwo inkludiert werden gar nicht erst aufrufbar sind. Dann schreibt man halt in den PluginCodex mit rein, das PHP-Dateien im Plugin-Verzeichnis nicht ausführbar sind und das doch bitte beachtet werden soll. Von google-Fonts im Adminbereich und Emojies will ich jetzt gar nicht anfangen.
    
    Einem Stück Software, dass dazu da ist, offen irgendwo auf abertausenden Webservern zu liegen, dem sollte man in Sachen Sicherheit doch ein wenig mehr Beachtung schenken.
Daniel sagt:

19. April 2016 um 00:37 Uhr

Klar ist es schade, dass WP nicht von Haus aus die Sicherheit mitbringt, die eigentlich notwendig wäre. Nur zeigt sich hier der Unterscheid zwischen Marketing (welches WP erst zu dem gemacht hat, was es heute ist) und den Sicherheitsgedanken. Und ich bin auch als routinierter Entwickler (nicht WP) dankbar über solche Quick-Tipps, so dass ich das System nicht erst wochenlang nach Schwachstellen absuchen muss. Im Grunde steht es jedoch jedem frei, einen gehärteten Fork von WP zur Verfügung zu stellen. Statt Schimpfen sollte der Community-Gedanke gelebt werden.
JenZzzz sagt:

11. Mai 2016 um 13:10 Uhr

Ich finde es so grausam, es gibt ein so gutes CMS Contao, das sehr sicher ist, sehr viele Funktionen und Module von Haus aus mitbringt, was man sich in WordPress erst mühsam zusammen-pluginieren muss und es ist anfangs „nackt“, man muss/kann/darf sich seine Seite so erstellen, wie man es will (klar bei WordPress klicke ich mir Theme und Plugins zusammen, dafür brauch ich ERSTMAL keinen Webdesigner, aber irgendwann kommen sie dann doch zu uns ;)). Aber gewollt wird von den Kunden trotzdem WordPress, weil sie irgendwo ein wahnsinnig toll animiertes Klickibunti-Theme gesehen und dazu den Begriff WordPress aufgeschnappt haben, denen kann man dann leider kein Contao mehr „verkaufen“, die wollen WordPress … der Kunde ist König, wenn er es unbedingt will, ich bau es ihm ein …

Wenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-Forum

Abschließender Hinweis

Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.

Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.

Artikel (400)

WordPress (13)