Adventskalender 2014 – Tür 2

Nachdem ich gestern ein paar eher allgemeine Punkte zum Thema WordPress-Sicherheit angesprochen habe, gibt es heute mal ein paar Tipps aus der Praxis. Gleich vorneweg ein wichtiger Hinweis: Ein Sicherheitskonzept besteht immer aus einem ganzheitlichen Maßnahmenkatalog, aus vielen einzelnen Bausteinen, die sich gegenseitig ergänzen. So wie ein Damm ist ein Sicherheitskonzept immer nur so stark wie seine schwächste Stelle.

Die allermeisten Angriffe, denen eine WordPress-Installation ausgesetzt ist, zielen darauf ab, bekannte Lücken auszunutzen oder Zugang zum Blog über das massive Ausprobieren von Zugangsdaten zu erlangen. Speziellere Attacken, die beispielsweise auf den Webserver selbst abzielen, oder auf ein bestimmtes Blog direkt zugeschnitten sind, treten deutlich weniger häufig auf, vor allem weil sie in der Regel wesentlich mehr Aufwand für den Angreifer bedeuten. Massenattacken, wie sie bevorzugt von Botnets oder gekaperten Cloud-Systemen aus durchgeführt werden, leben davon, dass in möglichst kurzer Zeit möglichst viele Ziele abgeklopft werden – dementsprechend allgemein sind die Angriffsmuster gehalten. Alles was übermäßig Zeit braucht, drückt den Ertrag.

Gestern gab es ja schon einige Tipps zur Absicherung gegen erfolgreiche Loginversuche Unbefugter, die mit wenig Aufwand umsetzbar waren. Heute liefere ich ein paar Denkanstöße gegen eine sehr beliebte Sorte von Sicherheitslücken, die allgemein als „RFU“ (Remote File Upload, das Hochladen von Dateien auf den Webserver aus Drittquellen) bezeichnet wird. Eine der bekanntesten Lücken dieser Art wurde vor ein paar Jahren in TimThumb gefunden, einem eigentlich sehr nützlichen Helfer für die Bildbearbeitung (zuschneiden, Größe ändern, etc.). Da es leicht zu benutzen war und unter der GPL v2 freigegeben war, fand es in unzähligen Themes und Plugins Verwendung.

Dann wurde eine Lücke entdeckt, die es einem Angreifer ermöglichte, eine beliebige Datei von einem fremden Server auf den Webspace herunterzuladen. Eigentlich war diese Funktion dazu gedacht, Bilder aus externen Quellen einbinden zu können, ohne sie auf dem eigenen Webspace abzulegen (was aus Urheberrechtsgründen oftmals eine schlechte Idee wäre). Dummerweise fehlten dort aber einige Sicherheitsmaßnahmen, und so konnte ein Angreifer zielsicher Sachen wie eine Remote Shell (eine Art offenes Scheunentor für den Zugriff auf den Webspace und ggf. auch mehr) in die WordPress-Installation einschleusen. Die Zahl der Infektionen erreichte, je nachdem welcher Quelle man glauben mag, fünf- oder sechsstellige Höhe innerhalb kürzester Zeit. Inzwischen hat der Entwickler das Projekt komplett eingestellt und gibt Ratschläge, wie die Aufgabe „Bildbearbeitung“ stattdessen zu lösen ist. Klarer als „Wenn Du heute noch als WordPress-Entwickler Timthumb benutzt, machst Du etwas falsch“ (so der Timthumb-Autor) kann man es wohl nicht formulieren.

Die Abhilfe dagegen erscheint auf den ersten Blick simpel: Auch durch die böseste RFU-Lücke kann nicht auf den Webspace geschrieben werden, wenn der Webserver selbst (bzw. der PHP-Prozess, je nach Serverkonfiguration, mehr dazu später) keinen Schreibzugriff auf den Webspace hat. Logisch, oder? Dummerweise gibt es aber einige Situationen, in denen WordPress, Themes und Plugins durchaus auf den Webspace schreiben möchten. Das reicht von Cache-Plugins, die reichlich temporäre Cache-Dateien erzeugen müssen, über Themes, die Inhalte von Drittwebsites holen und zwischenspeichern, etwa für einen Twitter- oder Facebook-Feed, bis hin zum Update-Mechanismus von WordPress, der mitunter Schreibzugriff auf weite Teile der WordPress-Installation benötigt.

Hinzu kommt noch eine andere Problematik: Bei vielen Webhostern ist es überhaupt nicht möglich, den Webspace effektiv gegen Schreibzugriffe zu schützen. Vielfach sieht die Serverkonfiguration nämlich so aus: Webserver, FTP-Server (und ggf. PHP) laufen nicht unter getrennten Nutzern, haben also alle identische Zugriffsrechte. Das ist für den Webhoster eine einfache Sache, und einfach kostet wenig Geld – freut den Betreiber also. Der Nachteil für den Nutzer: Die Zugriffsrechte lassen sich ebenso einfach wieder zurücksetzen wie sie eingerichtet wurden, der Schutz gegen RFU-Lücken ist also wenig haltbar.

Besser sieht es bei Hostern aus, bei denen FTP-Zugang und Webserver als zwei unterschiedliche Nutzer konfiguriert sind. In diese Kategorie fällt beispielsweise einer meiner Lieblings-Hoster, All-Inkl. Dort gibt es zwei Nutzer, der eine wird für den FTP-Zugang verwendet, und der andere vom Webserver genutzt. Über den Kundenbereich lässt sich auf dem Webspace für jede Datei und jeden Ordner einstellen, ob entweder der Webserver oder der FTP-Server Besitz- und damit Schreibrechte hat. Eleganterweise kann WordPress mit so einer Konstellation sogar recht gut umgehen: Beim Update fragt WordPress bei einer solchen Einrichtung dann nach den FTP-Zugangsdaten, um das Update durchführen zu können. Auch das Problem mit Cache-Plugins, etc. läst sich damit recht gut eingrenzen: Für die absolut notwendigen Verzeichnisse stellt man dem Webserver Schreibrechte ein, der Rest bleibt unter FTP-Kontrolle. Das reduziert die Angriffsfläche auf ein Minimum.

Wie es mit den Schreibrechten bei diversen Hostern aussieht und wie man deren Möglichkeiten jeweils nutzt, hat Ernesto Ruge vor kurzem in geduldiger Kleinarbeit in einem Blogbeitrag zusammengestellt. Wer sich bei einem Hoster wiederfindet, kann außer einem Umzug zu einem anderen Hoster auch einige Maßnahmen ergreifen, um das Risiko zu minimieren:

• Unbenötigte Plugins und Themes vom Webspace entfernen. Auch wenn sie nicht aktiv sind, können Lücken in ihnen ausgenutzt werden!
• Per FTP-Client Schreibrechte überall dort entziehen, wo es problemlos möglich ist. Selbst wenn dies relativ leicht rückgängig gemacht werden kann, reduziert es die Angriffsfläche.
• Per Eintrag in der .htaccess die Ausführung von PHP-Dateien überall dort blockieren, wo üblicherweise keine PHP-Dateien liegen sollten. Dort verstecken sich Schädlinge nämlich nur allzu gern.

Die zuvor bereits angesprochenen Tipps wie „Updates immer möglichst bald durchführen“ erspare ich mir hier nochmal zu wiederholen. 🙂

Die Blockade von PHP-Scripten über .htaccess ist übrigens sehr einfach einzurichten. Es reicht dazu, eine Regel wie im folgenden gezeigt mit aufzunehmen:


<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^(.*)/uploads/(.*).php(.?) - [F]
</IfModule>


Wenn bereits ein Block mit „IfModule mod_rewrite.c“ in der .htaccess besteht, reicht es, den Inhalt der Zeile mit „RewriteRule“ hinter der Zeile mit „RewriteEngine On“ einzufügen. Sobald die geänderte .htaccess wieder hochgeladen ist, können PHP-Scripte, die z.B. durch eine Sicherheitslücke in einem Plugin irgendwo unter /wp-content/uploads/ gelandet sind, dort nicht mehr ausgeführt werden. Analog lässt sich das natürlich auch auf die Verzeichnisse von Themes und Plugins anwenden, in denen nur Grafiken oder CSS-Dateien liegen. Allerdings muss man dann darauf achten, diese Dateien auch wieder zu erneuern, wenn es Updates für das Plugin bzw. Theme gab.

Einen Tipp muss ich zum Thema von gestern übrigens noch nachtragen: Wenn sich ein Angreifer erfolgreich Zugang zum Blog verschafft hat, ist der nächste Schritt oft die Implantation von Schadcode im aktuellen Theme, etwa in der 404.php – diese Datei wird immer dann angesprochen, wenn eine nicht existierende URL aufgerufen wird und kein separates Plugin für eine Umleitung sorgt. Diesen Weg kann man dem Angreifer allerdings erfolgreich versperren, indem man die internen Editoren für Themes und Plugins in WordPress einfach deaktiviert. Dazu reicht ein simpler Eintrag in die wp-config.php:


define( 'DISALLOW_FILE_EDIT', true );


Diese Zeile einfach direkt hinter der ersten Zeile einfügen und die geänderte wp-config.php wieder hochladen. Ab jetzt sind die internen Editoren für Plugins und Themes nicht mehr zugänglich. In Verbindung mit oben Tipps (um zu verhindern, dass der Angreifer einfach ein manipuliertes Plugin oder Theme installiert), lässt sich WordPress auf diese Weise wieder ein Stück sicherer machen. Damit soll es für heute auch genug sein, der Artikel ist wieder viel länger als geplant geworden. Bis morgen, dann gibt es ein paar Quickies aus der Abteilung „Erste Hilfe“.