IT-Security (4/4): Gezielte Untersuchungs- und Absicherungsmethoden für mehr WordPress-Sicherheit

Dieser Artikel setzt die Reihe »IT-Security« fort und beleuchtet Aspekte der Sicherheit von Webanwendungen am Beispiel von WordPress sowie die Themen Transportverschlüsselung und Sicherheitsheader eines Webservers. In den vorhergehenden Artikeln dieser Artikelserie haben wir zuerst unsere IT-Sicherheitsaudits vorgestellt und anschließend einen wichtigen Bestandteil einer IT-Sicherheitsüberprüfung: die Penetrationstests. Der darauffolgende Artikel diskutierte die Verwundbarkeiten und zeigte, wie man sie beheben kann.

IT-Sicherheit bei Webanwendungen

Wenn man die IT-Sicherheit bei Webanwendungen genauer untersuchen will, muss man mehrere Ebenen betrachten. Die nachfolgende Grafik stellt diese Ebenen grafisch dar:

Das Betriebssystem eines Webservers ist das Fundament jeder Webanwendung. Es sollte sicher konfiguriert, d.h. gehärtet sein.

Auf dem Betriebssystem läuft ein Webserver, der die notwendigen Dateien der Webanwendung ausliefert. Seine sichere Konfiguration ist ebenfalls essenziell, da er direkt mit dem Internet und potenziellen Angreifern kommuniziert. Zur Verarbeitung von Skript-Dateien wie beispielsweise PHP nutzt er weitere Software, wie z.B. den PHP Interpreter. Die zusätzlich verwendete Software muss deshalb ebenfalls sicher konfiguriert werden.

Bevor die Webanwendung an den Browser eines Clients ausgeliefert wird, findet im Rahmen des Verbindungsaufbaus die Aushandlung der Transportverschlüsselung statt. Hierbei sollte sichergestellt sein, dass sichere Verfahren und Protokolle verwendet werden.

Mit Beginn der Auslieferung der ersten Dateien der Webanwendung können in den Headern der http-Verbindungen auch Sicherheitsheader übermittelt werden. Diese weisen den Browser auf weitere von ihm zu treffende Schutzmaßnahmen hin.

Anschließend kann die Webanwendung, z.B. WordPress, auf dem Client verwendet werden. Diese sollte ebenfalls sicher konfiguriert werden, da auch diese Sicherheitslücken aufweisen kann, mit denen dann der Server kompromittiert werden kann. Neben der Kompromittierung des Webservers besteht außerdem die Gefahr des Abfischens von Zugangsdaten, die Gefahr einer Entstellung oder Verunstaltung (»Defacement«) der Webseite oder z.B. die Verbreitung anderer rufschädigender Inhalte über die Webseite. Die Open Web Application Security Project Foundation (OWASP Foundation) listet unter https://owasp.org/www-project-top-ten/ die Top Ten möglicher Sicherheitsrisiken auf.

Dieser Artikel beleuchtet die Aspekte Transportverschlüsselung, Sicherheitsheader und die Sicherheit der Webanwendung WordPress.

Überprüfen einer WordPress-Installation

WordPress ist ein sehr beliebtes und freies Content-Management-System (CMS). Mit einem Anteil von etwa 37 % (Stand 14. Juli 2020) an den im Web verwendeten CMS führt WordPress mit großem Abstand das Feld an. Das PHP-basierte System bietet die Möglichkeit einer rollenbasierten Benutzerverwaltung. Es lässt sich außerdem mit Plug-ins in seinem Funktionsumfang erweitern. Während sich das Hauptsystem selbstständig updaten kann, können Plug-ins nicht selbstständig aktualisiert werden. Ein solches Feature ist erst zu einem späteren Release geplant. Häufig entstehen durch veraltete Plug-ins Verwundbarkeiten, die das Gesamtsystem negativ beeinflussen können.

Mit WPScan existiert ein Tool, das von Sicherheitsexperten zur Untersuchung von WordPress-Installationen verwendet wird. Es ist für die nicht kommerzielle Nutzung frei verfügbar und wird zur Demonstration in diesem Artikel zur Untersuchung unseres Testservers verwendet. Es sucht und findet verwendete Plug-ins, die eingesetzten Versionen der Plug-ins und von WordPress, Konfigurationsbackups und vieles mehr. Die wichtigsten Optionen, die auch im Rahmen dieses Artikels verwendet werden, sind:

• –url
  Die URL der zu scannenden WordPress-Instanz.
• –enumerate
  Auflistung aller verwendeten Plug-ins mit Detaildaten.

Der Befehl zum Scannen einer WordPress-Installation setzt sich daher wie folgt zusammen:

wpscan –enumerate –url 192.102.162.236

Auswertung der Ergebnisse der Überprüfung von WordPress

Der Ergebnisbericht der Überprüfung listet verschiedene Verwundbarkeiten auf. Aufgrund der Menge wurde die Ergebnisliste verkürzt. Bezüglich der im Einsatz befindlichen Version wurde Folgendes identifiziert:

[+] WordPress version 4.9.7 identified (Insecure, released on 2018-07-05).
 | Found By: Emoji Settings (Passive Detection)
 |  – http://192.102.162.236/, Match: ‚wp-includes\/js\/wp-emoji-release.min.js?ver=4.9.7‘
 | Confirmed By: Meta Generator (Passive Detection)
 |  – http://192.102.162.236/, Match: ‚WordPress 4.9.7‘
 |
 | [!] 20 vulnerabilities identified:
 |
 | [!] Title: WordPress <= 5.0 – Authenticated File Delete
 |     Fixed in: 4.9.9
 |     References:
 |      – https://wpvulndb.com/vulnerabilities/9169
 |      – https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20147
 |      – https://wordpress.org/news/2018/12/wordpress-5-0-1-security-release/

Die im Einsatz befindliche WordPress-Version ist also veraltet und muss aktualisiert werden. Die bestehenden Verwundbarkeiten hat WPScan aufgelistet. Laut der obigen Meldung kann ein Autor z.B. Metadaten ändern, die zur Löschung einer Datei führen (was er aufgrund seiner Berechtigung nicht dürfte).

Darüber hinaus wurde noch ein Plug-in in einer verwundbaren Version identifiziert. Die Verwundbarkeit kann mit einer Aktualisierung behoben werden:

[+] contact-form-7
 | Location: https://192.102.162.236/wp-content/plugins/contact-form-7/
 | Last Updated: 2018-12-18T18:05:00.000Z
 | [!] The version is out of date, the latest version is 5.1.1
 |
 | Detected By: Urls In Homepage (Passive Detection)
 |
 | [!] 1 vulnerability identified:
 |
 | [!] Title: Contact Form 7 <= 5.0.3 – register_post_type() Privilege Escalation
 |     Fixed in: 5.0.4
 |     References:
 |      – https://wpvulndb.com/vulnerabilities/9127
 |      – https://contactform7.com/2018/09/04/contact-form-7-504/
 |      – https://plugins.trac.wordpress.org/changeset/1935726/contact-form-7
 |      – https://plugins.trac.wordpress.org/changeset/1934594/contact-form-7
 |      – https://plugins.trac.wordpress.org/changeset/1934343/contact-form-7
 |      – https://plugins.trac.wordpress.org/changeset/1934327/contact-form-7
 |      – https://www.ripstech.com/php-security-calendar-2018/#day-18
 |
 | Version: 4.9.2 (100% confidence)
 | Detected By: Readme – Stable Tag (Aggressive Detection)
 |  – https://192.102.162.236/wp-content/plugins/contact-form-7/readme.txt
 | Confirmed By: Readme – ChangeLog Section (Aggressive Detection)
 |  – https://192.102.162.236/wp-content/plugins/contact-form-7/readme.txt

Behebung der WordPress-Befunde

Die Befunde bei WordPress lassen sich bereits durch eine Aktualisierung der WordPress-Installation und aller Plug-ins beheben. Unabhängig von den WordPress-Befunden in diesem Artikel sollten WordPress-Installationen gehärtet und einer regelmäßigen Wartung unterzogen werden. Die Entwickler von WordPress geben hierzu entsprechende Tipps zur Härtung, die man bei jeder produktiv eingesetzten Instanz umsetzen sollte.

Überprüfung der Header des WordPress Server

Bei jeder Anfrage eines Browsers sendet der Webserver mit der Auslieferung des angeforderten Datums einen HTTP Response Header. Typischerweise enthält dieser Header verschiedene Metadaten wie beispielsweise zur »Cache-Steuerung«, zum »Inhaltstyp« (z.B. text/html) oder zu den »Fehlercodes«. Darüber hinaus ist es möglich, zusätzlich besondere Sicherheitsheader zu senden. Diese weisen den Browser zu einem speziellen Verhalten an, der dies nach dem Laden der Seite dann umsetzt. Ein Beispiel hierfür ist der Strict-Transport-Security-Header. Dieser erteilt dem Browser die Anweisung, ausschließlich über HTTPS zu kommunizieren. Derzeit kennen die Browser sieben Sicherheitsheader:

• Strict-Transport-Security
  Dieser Header wird nur bei HTTPS-Webseiten benötigt. Er weist den Browser an, die Webseitenelemente nur über eine gesicherte HTTPS-Verbindung zu beziehen. Darüber hinaus verhindert er einen Zugriff auf die Webseite, sobald ein Zertifikat nicht mehr als vertrauenswürdig gilt. Es schützt den Benutzer vor dem Datenabruf über eine unsichere Verbindung.
  Die Einstellmöglichkeiten lauten wie folgt:
  • max-age
    Zeitdauer in Sekunden, innerhalb der der Browser die verschlüsselte Verbindung erzwingen soll.
  • includeSubDomains
    Erzwingt die sichere Verbindung auch für Subdomains.

Empfehlung: Strict-Transport-Security: max-age=31536000; includeSubDomains

• X-Frame-Options
  Mit dieser Header-Option lässt sich sicherstellen, dass die Webseite nicht in einem Frame ausgeführt wird. Diese Option ist sehr praktisch, wenn man verhindern möchte, dass Content-Diebe Teile der Webseite bei sich einbinden.
  Nachteil: Dieser Header verhindert natürlich, dass die Webseite in einem Frame angezeigt wird. Damit sind auch die Responsive Layouts der Webentwickler-Toolbars der Browser Firefox und Chrome verbunden. Der Header sollte demnach erst im Produktionsmodus gesetzt werden.

Die Einstellmöglichkeiten lauten wie folgt:

• • DENY
    Verhindert die Darstellung in einem Frame komplett.
  • SAMEORIGIN
    Erlaubt die Darstellung in einem Frame für die eigene Seite.
  • ALLOW-FROM https://…./
    Erlaubt die Darstellung in einem Frame von explizit genannten fremden Seiten.

Empfehlung: X-Frame-Options „SAMEORIGIN“
oder:             X-Frame-Options „DENY“

• X-Content-Type-Options
  Dieser Header wird nur von den Browsern Internet Explorer und Google Chrome verstanden. Er verhindert, dass ein Browser versucht, den MIME-Typ einer übermittelten Ressource selbst zu erkennen und zu verwenden. Stattdessen wird der Browser angewiesen, den im Header angegebenen Content-Type zu verwenden. Dies reduziert das Risiko von Drive-by-Downloads und dass ein Benutzer etwas hochlädt, das aufgrund des Dateinamens falsch behandelt werden würde. Empfehlung: X-Content-Type-Options „nosniff“

• X-XSS-Protection
  Mit diesem Header kann der im Browser enthaltene Schutzfilter gegen XXS (Cross-Site-Scripting) aktiviert werden. Auch wenn dieser in der Regel bereits aktiv ist, kann er durch diesen Header erzwungen werden. Die Einstellmöglichkeiten lauten wie folgt:
  • 0
    Schaltet den Schutz aus.
  • 1
    Schaltet den Schutz ein.
  • 1; mode=block
    Schaltet den Schutz ein und weist den Browser an, die Antwort komplett zu blocken.

Empfehlung: X-Xss-Protection „1; mode=block“

• Content-Security-Policy
  Bei der Umsetzung dieses Headers muss man sehr vorsichtig sein, da er die Webseite negativ beeinflussen kann. Der Header kann XSS und Code-Injection-Angriffe verhindern, indem er dem Browser seine Whitelist schickt. In dieser Whitelist sind alle erlaubten Ressourcen aufgeführt, d.h. welche Inhaltstypen und -arten explizit zum Laden erlaubt sind. Teilweise müssen hier sehr lange Code-Snippets erzeugt werden. Hierbei helfen Tools wie beispielsweise https://report-uri.com/.

• Referrer-Policy
  Wenn ein Benutzer auf einen Link klickt, öffnet der Browser für ihn die verlinkte Seite. Die Zielseite erhält vom Browser dabei Informationen, wo der Benutzer herkam, also welche Seite zuvor geöffnet war. Dies macht sich z.B. auch Google Analytics zu Nutze und hilft Webseitenbetreibern herauszufinden, wie die Besucher auf die Seite aufmerksam wurden. Mit dem Header Referrer Policy teilt eine Webseite dem Browser mit, welche URL der vorher angezeigten Webseite der Zielseite mitgeteilt werden darf. Es gibt acht Einstellungsmöglichkeiten:
  • no-referrer
    Keinen Referrer Header senden
  • no-referrer-when-downgrade
    Keinen Header senden, wenn Verbindung von HTTPS auf HTTP wechselt
  • same-origin
    Nur Header senden, wenn die Domain gleich ist
  • origin
    Nur Domain Header senden, ohne Pfad
  • strict-origin
    Wie origin, aber Header wird nur bei HTTPS gesendet
  • origin-when-cross-origin
    Voller Pfad wird gesendet, wenn das Ziel die eigene Domain ist, ansonsten nur die Domain
  • strict-origin-when-cross-origin
    Wie die Option davor, bei Downgrade von HTTPS zu HTTP wird kein Header gesendet
  • unsafe-url
    Immer den vollen Header senden

Empfehlung: Referrer-Policy: same-origin

• Feature-Policy
  Mit diesem Header können Webseitenbesitzer verschiedene Plattformfeatures aktivieren oder deaktivieren. Dies gilt für die eigene Seite wie auch für eingebettete Seiten. Features können beispielsweise sein: geolocation, midi, notifications, push, sync-xhr, microphone, camera. Beispiel: Feature-Policy: push ’self‘; Das Beispiel aktiviert die Push-Funktion für die eigene Domain, deaktiviert jedoch die Funktion für alle anderen Domains.

Die Header lassen sich auf drei verschiedenen Wegen setzen: über die Konfigurationsdatei des jeweiligen Webservers (z.B. Apache oder nginx), über eine Server-Steuerungsdatei wie .htaccess oder direkt innerhalb der Webanwendung (in PHP, in Java, etc.).

Das Überprüfen der Sicherheitsheader wurde durch den Aufruf von testssl.sh im vorherigen Abschnitt bereits durchgeführt. Die Header lassen sich auch mit testssl.sh testen:

testssl -h 192.102.162.236

Alternativ kann auch das Tool cURL verwendet werden:

curl –head 192.102.162.236

Auswertung der Ergebnisse

Die Auswertung der Sicherheitsheader fällt nicht so umfangreich aus. Bei der Überprüfung konnte das testssl.sh Skript insgesamt zwei Sicherheitsheader feststellen:

Security headers             X-Frame-Options SAMEORIGIN
                                          Content-Security-Policy frame-ancestors ‘none’

Der erste Sicherheitsheader (X-Frame-Options) sorgt dafür, dass nur die eigene Seite die Einbindung als Frame erlaubt. Mit dem zweiten Sicherheitsheader (Content-Security-Policy) wird festgelegt, welche Quellen eingebettete Inhalte haben dürfen. Andere wichtige Sicherheitsheader fehlen jedoch: Strict-Transport-Security, X-Content-Type-Options und X-XSS-Protection.

Behebung der Sicherheitsheader-Befunde

Die fehlenden Sicherheitsheader müssen noch hinzugefügt werden. In diesem Artikel werden sie zentral in der Webserver-Konfiguration hinterlegt und gelten damit für alle vom Webserver angebotenen Webseiten. Wenn auf einem Webserver mehrere Webseiten gehostet werden, sollte zuvor kontrolliert werden, ob die jeweiligen Sicherheitsheader für die betreffende Webseite geeignet sind. Bei unserem Ubuntu Testserver werden die Sicherheitsheader in /etc/apache2/conf-enabled/security.conf konfiguriert:

Header always set Strict-Transport-Security „max-age=63072000; includeSubDomains; preload“
Header always set X-Content-Type-Options nosniff
Header always set X-Xss-Protection „1; mode=block“
Header always set Referrer-Policy „same-origin“

Damit die Sicherheitsheader auf diese Weise gesetzt werden können, muss sichergestellt sein, dass das Modul »Headers« in der Apache-Konfiguration aktiviert ist. Der Befehl a2enmod headers aktiviert das Modul, falls es deaktiviert ist.

Check der Verschlüsselung des WordPress-Servers

Bevor die Verschlüsselung überprüft und bewertet werden kann, ist es empfehlenswert, einen Blick in die derzeitigen allgemeinen Empfehlungen zu werfen. Das BSI empfiehlt sich hier als nennenswerte Anlaufstelle. In seiner technischen Richtlinie BSI TR-02102-2 »Kryptographische Verfahren: Verwendung von Transport Layer Security (TLS)« gibt das BSI Empfehlungen für den Einsatz des kryptografischen Protokolls TLS. Zum Zeitpunkt der Erstellung des Artikels ist Version 2019-1 der Technischen Richtlinie aktuell.

Bei der Wahl der TLS-Version empfiehlt das BSI grundsätzlich die Verwendung von TLS 1.2 und TLS 1.3. TLS 1.0 und TLS 1.1 (oder die schwächeren SSLv2 und SSLv3) werden aufgrund existierender Schwächen nicht empfohlen. Die empfohlenen Chiffren können den entsprechenden Tabellen in TR-02102-2 entnommen werden.

Zur Überprüfung der Verschlüsselung existieren verschiedene Tools. Das Tool https://ssllabs.com ist online einsetzbar. Alternativ ist auch das von Dirk Wetter entwickelte Skript testssl.sh empfehlenswert, dass i.d.R. aus den Distributionsrepositories bezogen werden kann. Ein Download über seine Homepage https://testssl.sh/ oder von Github ist ebenfalls möglich. In diesem Artikel verwenden wir testssl.sh, um die Verschlüsselung unseres Webservers zu überprüfen.

Mit dem Befehl testssl –hints –html 192.102.162.236

lässt sich eine Überprüfung der Verschlüsselung starten. Möchte man die Verschlüsselung anderer Dienste wie z.B. FTP oder IMAP überprüfen, ist es beispielsweise notwendig, den Schalter –t zu verwenden. Darüber hinaus gibt es eine Vielzahl von Optionen, die schnellere Prüfungen oder nur ganz bestimmte Überprüfungen durchführen. Die Schalter –html und –hints werden in diesem Fall dazu verwendet, um die Suchergebnisse als HTML-Bericht auszugeben (–html) und um weitere Hinweise zu Befunden anzuzeigen (–hints).

Auswertung der SSL-Testergebnisse

Zuerst werden die Ergebnisse der Überprüfung der Transportverschlüsselung ausgewertet. Der Prüfbericht von testssl.sh ist in mehrere Abschnitte aufgeteilt. Die Auffälligkeiten werden nachfolgend schrittweise besprochen.

Angebotene Protokolle

Im ersten Abschnitt werden die angebotenen Protokolle untersucht:

Farblich hat testssl.sh bereits die Befunde bewertet. Aus den Ergebnissen ist ersichtlich, dass noch SSLv3 und TLS 1.0 angeboten werden. Neuere Protokolle (TLS 1.2 und TLS 1.3) werden nicht angeboten. Die Ergebnisse entsprechen damit nicht den Empfehlungen des BSI und sollten entsprechend verbessert werden.

Angebotene Chiffren

Im nächsten Abschnitt werden die Kategorien der Chiffren bewertet:

Der Webserver bietet verschiedene Chiffren an, die auf jeden Fall vermieden werden sollten (beispielsweise NULL Ciphers, DES, 3DES, RC4). Diese Chiffren sind nicht mehr als sicher anzusehen.

Hier ist erkennbar, dass der Server nicht die zu verwendende Chiffre vorgibt, d.h. der Client kann unter den angebotenen Chiffren frei wählen. Ein potenzieller Angreifer könnte dies ausnutzen und absichtlich eine schwächere Chiffre wählen/erzwingen. Der DH-Parameter zur Aushandlung des Schlüssels ist außerdem mit 1024 Bit nicht stark genug.

Bekannte Verwundbarkeiten bei der Transportverschlüsselung

Im weiteren Verlauf testet das Skript auch auf bekannte Verwundbarkeiten. Hier das Ergebnis bei unserem Testwebserver (es werden aufgrund der Länge des Ergebnisberichts nur die Verwundbarkeiten angezeigt):

Die Ergebnisse zeigen deutlich, dass unsere Webserverkonfiguration in diesem Bereich ungeeignet für den produktiven Betrieb ist. Beispielsweise ermöglicht die Verwundbarkeit POODLE (englische Abkürzung für: Padding Oracle On Downgraded Legacy Encryption) das Auslesen von privaten Daten zwischen Client und Server bei verschlüsselten Verbindungen.

Behebung der Verschlüsselungsbefunde

Zur Behebung der Verschlüsselungsbefunde muss die Konfiguration des Webservers angepasst werden. Konkret müssen die passenden Chiffren und Protokolle konfiguriert werden. Außerdem muss sichergestellt sein, dass der Webserver die Chiffre vorgibt und der Client sie sich nicht aussuchen darf. Die Konfiguration wird in der Datei vorgenommen, in der auch der virtuelle SSL-Host konfiguriert ist. Bei unserem Testserver ist dies die folgende Datei: /etc/apache2/sites-enabled/default-ssl.conf

Innerhalb des Tags <VirtualHost _default_:443> müssen folgende Einstellungen konfiguriert werden:

SSLCipherSuite EECDH+AESGCM:EDH+AESGCM
SSLProtocol -all +TLSv1.3 +TLSv1.2
SSLHonorCipherOrder On
SSLSessionTickets Off
SSLCompression off

Die Einstellungen können abweichen, falls eine ältere Version von Apache eingesetzt wird. Die Option SSLCipherSuite legt fest, welche Chiffren vom Webserver angeboten werden. Mit SSLProtocol wird definiert, welche Protokolle verwendet werden dürfen. -all verbietet alle; danach werden mit +TLSv1.X die erlaubten einzeln hinzugefügt. Bei beiden Einstellungen sollte darauf geachtet werden, dass die Anzahl der Geräte, die eine Verbindung aufbauen können, eingeschränkt ist. Während sich bei der obigen Konfiguration alle neueren Systeme verbinden können, können alte Browser wie der Internet Explorer < Version 11 oder Android < 4.4 keine Verbindung mehr aufbauen. Welche Verfahren hier erlaubt sein sollten, muss im Einzelfall abgewogen werden. Handelt es sich beispielsweise um Dienste, auf die nur die eigenen Firmengeräte zugreifen werden, ist davon auszugehen, dass die neusten Chiffren problemlos unterstützt werden. Das Skript testssl.sh gibt hier Auskunft, welche Clients eine Verbindung aufbauen können. SSLHonorCipherOrder teilt dem Server mit, dass er die passende Chiffre auswählt. SSLSessionTickets und SSLCompression sollten zum Schutz vor Angriffen ebenfalls deaktiviert werden.

Zur Erhöhung der Performance kann außerdem folgende Konfiguration erfolgen:

SSLUseStapling on
SSLStaplingCache „shmcb:logs/stapling-cache(150000)“

Dies vermeidet, dass der Client selbst einen Request zur Verifikation des Zertifikats absenden muss.

Ende der Artikelserie zum Thema »IT-Security«

Die Artikel dieser Serie haben einen kleinen Einblick in einzelne Aspekte der Sicherheit von Webanwendungen gegeben. Es wurde deutlich, dass das Thema vielschichtig ist und viele Bausteine ineinandergreifen müssen, um eine geeignete Absicherung von Webservern zu erzielen. Gerne können wir auch Sie bei der Absicherung Ihrer Infrastruktur unterstützen und eine IT-Sicherheitsüberprüfung durchführen.