In den letzten Tagen wurden Sicherheitslücken in einigen beliebten WordPress-Plugins bekannt, die wir ebenfalls bei einigen Webseiten einsetzen. Durch Sicherheitseinstellungen auf unseren Webservern wurden jedoch Schäden vermieden. Die betroffen Lücken wurden sofort nach Bekanntwerden geschlossen, so dass keine Gefahr mehr besteht. Mittlerweile sind alle Installationen upgedatet.
Folgenden Erweiterungen waren betroffen:
- wp-table
- wordtube
- mygallery
- myflash
Im Folgenden konnten wir dann wiederholte Einbruchsversuche auf mehreren Webseiten beobachten, die allerdings aus mehreren Gründen keinen Erfolg hatten. Die Attacken basierten auf den vermuteten Schwachstellen in einem der aufgezählten Plugins, und es ist für einen Angreifer natürlich leicht entsprechende Websites zu finden, die eines dieser Plugins verwenden. Solche Webseiten werden dann automatisiert “gescant”, um dem Angreifer mit einer Liste tatsächlicher verwundbarer Seiten zu versorgen. Diese Scans scheitern bereits schon an einer ersten Hürde, die wir speziell gegen solche Fälle auf unseren Webservern standardmäßig aktiviert haben: mod_security mit entsprechenden Regel-Sätzen. (Die Verwendung von mod_security kann vom Besitzer des Webspace deaktiviert werden, wir empfehlen aber dies für beinahe jeden Webspace zu aktivieren, insbesondere für interaktive PHP-Anwendungen wie WordPress!)
Schafft es der Angreifer diese erste Hürde zu umgehen – was nicht sonderlich schwierig ist und bei neuen unbekannten Angriffsvektoren, für die noch keine spezialisierte Regeln existieren, häufig der Fall ist – scheitert aber die Ausnutzung dieser Programmierlücke in den besagten Plugins an den bei uns standardmäßig vorkonfigurierten PHP-Einstellungen. Diese verhindern das Ausführen von nachgeladenem Fremd-Code. Die bei diesen Angriffen übliche Verfahrensweise ist häufig direkt eine “remote shell”-PHP-Anwendung von einem externen bereits gecracktem Server nachzuladen. Dies scheitert bei uns entweder an der aktuellen PHP5-Version, die dies bereits verhindert, und auf PHP4-Webspaces an der deaktivierten Sicherheits-Einstellung “allow_url_fopen”.
Sowie es möglich ist, empfehlen wir auch die optionale Einstellung des safe_mode für einen Webspace angeschaltet zu lassen. WordPress zum Beispiel läuft ganz hervorragend im safe_mode, man verschenkt nichts… die Plugins, die dabei Probleme machen, sollte man sich genauer ansehen und vielleicht auf den Einsatz solcher Plugins verzichten. Konkret bei mygallery ist es so, dass der Autor das Abschalten des safe_mode empfiehlt. Im Prinzip zu recht, denn der safe_mode alleine macht PHP nicht wirklich “sicher”, nur weil es so heißt. Doch der safe_mode hätte als letzte Hürde verhindert, dass das remote-shell-Script ausgeführt worden wäre, wenn es denn erfolgreich geladen worden wäre, wenn der Zugriff vorher durchgelassen worden wäre. Diese Einstellungen sind nicht dazu da, unsere Kunden zu gängeln, sondern sollen bewirken, dass die Websites laufen auch wenn sie unter Attacke sind und Ihre Daten nicht geklaut werden können, selbst wenn die Programmierer und Entwickler Ihrer Website mal früher irgendwann einen kleinen Fehler eingebaut haben sollten.
Um für solche komplexen Anwendungen wie WordPress einen jederzeit möglichen Update-Pfad bereit halten zu können, pflegen wir eine angepasste WordPress-Version in unserem eigenen Versionierungs-System (Subversion & trac). Dies enthält auch zahlreiche Bugfixes und für unsere Webserver angepassten “Tricks”, von uns gepflegte Themes und zusätzliche Sprachdateien, sowie natürlich eine Auswahl handverlesener sehr nützlicher WordPress-Plugins. Mit diesem System wird der jeweilige Software-Stand aller in einem Projekt befindlichen Dateien verwaltet, so dass wir bei Sicherheits-Updates oder akualisierten Plugins in der Lage sind, solche Kunden-Websites im laufenden Betrieb mit funktionierenden Updates zu versorgen, die mit uns eine Service-Vereinbarung getroffen haben.
Da es im Prinzip unseren Kunden aber überlassen bleibt, welche Dateien oder Versionen von PHP-Scripts oder Plugins auf den Webspace geladen werden, können wir nicht für alle Kunden sicherstellen, dass es keinerlei verwundbare Scripts im Webspace gibt. Wir behalten uns aber vor, solche Scripts und Dateien/Einstellungen jederzeit sofort zu entfernen, wenn es Anzeichen dafür gibt, dass sie aktiv ausgenutzt werden oder werden könnten.