WordPress ist bei den meisten Nutzern gerade aufgrund seiner Flexibilität und einfachen Erweiterbarkeit sehr beliebt. Gerade letzteres bietet jedoch eine Vielzahl von Möglichkeiten, Backdoors einzuschleusen, die unerwünschten „Besuchern“ eine Menge Möglichkeiten für Unsinn verschaffen können.

Wie einfach es beispielsweise ist, eine Backdoor in ein Template zu integrieren, welche einen Benutzer in WordPress anlegt und diesem Administrator-Rechte zuweist, zeigt der Beitrag „How-To: Create Backdoor Admin Access in WordPress„. Der Code sitzt in der functions.php des Templates und wird durch einen speziellen Aufruf der Zielseite aktiviert. Mittels der Funktion wp_create_user aus wp-includes/registration.php wird nun ein neuer Benutzer in der Datenbank angelegt und zum Administrator gemacht. Fertig, die Tür ist offen. Egal, ob die Registrierung von neuen Benutzern erlaubt ist oder nicht.

Um solch eine Backdoor nachträglich in eine WordPress-Installation zu integrieren, benötigt ein Angreifer natürlich Zugriff auf die Daten, beispielsweise via FTP. Allerdings ist man darauf nicht zwingend angewiesen, was hindert einen potentiellen Angreifer daran, eine Seite aufzusetzen, von der man Unmengen an WordPress-Templates herunter laden kann, die durch die Bank mit einer solchen Funktion präpariert sind? Oder warum sollte ein Entwickler nicht ein solches Hintertürchen in sein wunderbares WordPress-Plugin integrieren? Hand aufs Herz: Wie groß wird der Anteil an WordPress-Nutzern wohl sein, die PHP beherrschen und ein solches Hintertürchen erkennen könnten? 10%? Und wie viele prüfen denn tatsächlich jedes Plugin oder Template auf potentiellen Schadcode? 1%? Weniger?

Aktuell überwiegt einfach das Vertrauen. Vertrauen in die Redlichkeit der Entwickler und Vertrauen in die Ehrlichkeit der Betreiber von Template-Portalen. Sicherlich löblich, offenbar ist noch nicht zu viel passiert in der Vergangenheit. Aber ein wenig Vorsicht sollte dennoch angebracht sein und somit sind vorbeugende Maßnahmen sicherlich nicht falsch.

Den oben beschriebenen „Exploit“ (um einen „echten“ Exploit handelt es sich meiner Meinung nach nicht wirklich) kann man auf verschiedene Weisen aushebeln.

Variante 1: Wir benennen die Datei wp-includes/registration.php einfach um. Damit hebeln wir allerdings automatisch sämtliche Funktionen zur Bearbeitung bereits existierender Benutzer aus. Also nicht so schick. Zudem ist das nach jedem WordPress-Update zu wiederholen.

Variante 2: Wir kommentieren die Funktion wp_create_user in der Datei wp-includes/registration.php aus. Das Gleiche müssten wir mit der Funktion wp_insert_user in der gleichen Datei tun. Auch hier sind verschiedene Funktionen in der Admin-Oberfläche anschließend defekt und auch dieses Procedere müsste nach jedem Update wiederholt werden. Also auch nicht wirklich schön…

Variante 3 (empfohlen): Wir legen einen zusätzlichen Verzeichnisschutz für das Verzeichnis /wp-admin/ an. Die meisten Provider bieten diese Funktion in der Admin-Oberfläche an, wer diese Funktion bei seinem Provider nicht findet, dem empfehle ich Punkt 8 dieses Artikels. Hier wird die Vorgehensweise recht gut erläutert, auch die anderen Tipps sind prinzipiell sehr zu empfehlen.
Dieser zusätzliche Verzeichnisschutz sorgt nun dafür, dass für den Zugriff auf /wp-admin/ eine zusätzliche Anmeldung erforderlich ist. Bevor also ein Angreifer, der bspw. die oben beschriebene Backdoor ausführen konnte, sich mit seinem neuen Benutzer an Eurem Blog anmelden könnte, müsste er eine weitere, von WordPress unabhängige Authentifizierung erfolgreich vollziehen. Wenn Ihr hier mit einem ausreichend starken Passwort arbeitet, wird das (relativ) schwierig.

Wie weiter oben bereits geschrieben, sehe ich die im verlinkten Beitrag aufgezeigte Möglichkeit zum Anlegen eines administrativen Benutzers nicht als „echten“ Exploit an sondern sehe die Problematik allgemein in der Möglichkeit der Erweiterbarkeit. Und sicherlich beschränkt sich das Problem somit nicht allein auf WordPress. Allerdings ist es natürlich durch die von WordPress zur Verfügung gestellten Funktionen wesentlich einfacher, erfolgreich eine Hintertür einzurichten. Möglicherweise sollten gerade die Funktionen zur Erstellung und Änderung von Benutzern gekapselt werden und eben nicht von jedem xbeliebigen Addon genutzt werden können. Aktuell ist es aber möglich, daher sollten WordPress-Nutzer sich nicht allein auf die mitgelieferten Sicherheitsfunktionen verlassen, sondern selbst Hand anlegen. Und sicherlich auch hin und wieder mal nachschauen, ob plötzlich neue Benutzer in der Datenbank auftauchen, obwohl die Registrierung nicht erlaubt ist.

Ich habe mir den Code des Exploits nicht im Detail zu Gemüte geführt (und werde auch sicher nicht so bald die Zeit finden, das zu tun), aber der gestern auf milw0rm veröffentlichte Code scheint mir doch nicht ganz ungefährlich für WordPress-Blogs zu sein. Ob die aktuelle Version 2.2.3 ebenfalls betroffen ist, kann ich im Augenblick nicht feststellen, zumindest bis 2.2.2 ist die Funktionalität verifiziert.

# Tested with WordPress 2.2, 2.2.2, 2.0.5, 2.0.6, 2.1, (...), PHP/5.2.4 for
# Apache 2.0.58 on Gentoo GNU/Linux. magic_quotes on and off for the different
# exploits.

Insofern ist diese Veröffentlichung dieses Exploits sicherlich das letzte notwendige Argument, um ein Update auf die aktuelle WordPress-Version durchzuführen. Und ich vermute, die Veröffentlichung erfolgte auch nur, weil die Lücken in WP 2.2.3 inzwischen gestopft wurden. Kann sich das vielleicht mal jemand genauer anschauen?

via BlogSecurity

Mir kommt es so vor, als würde derzeit Adobes Produktpalette etwas genauer unter die Lupe genommen werden, nachdem unlängst der Exploit für den BMP-Loader in Photoshop entdeckt wurde. Eine weitere kritische Sicherheitslücke wurde nun in dem für den Import von PNG-Dateien verantwortlichen Plugin PNG.8BI entdeckt, wie ZDNet schreibt. Auch hierbei handelt es sich wieder um einen Buffer Overflow, der durch manipulierte PNG-Dateien verursacht wird und zum Einschleusen von Schadcode ausgenutzt werden kann.

Betroffen von diesem Problem sind die Windows Versionen der Produkte Adobe Photoshop CS2, Adobe Photoshop CS3 sowie Adobe Photoshop Elements 5.x. Der einzige Schutz derzeit: Keine PNG’s von nicht vertrauenswürdigen Quellen öffnen. Wie das in der Praxis funktionieren soll, wenn bspw. Kunden ihre Daten als PNG anliefern, ist im Augenblick unklar. Gerade die „typischen“ Anwender liefern Bilder in der Regel als BMP oder inzwischen gelegentlich als PNG, seltener als PSD oder TIFF. Wahrscheinlich muss man es dann tatsächlich so halten, wie es diverse Druckereien immer noch vor machen: „Wir können nur dieses oder jenes Format…“

Ich hoffe nicht, in Kürze von weiteren Problemen in den anderen Modulen zu lesen, ein paar Import-Plugins für diverse Dateiformate gibt es ja noch.

Nachtrag: Wie ich bei heise lese hat Marsu, der Entdecker dieser Sicherheitslücken, weitere vergleichbare Probleme auch in anderen Produkten festgestellt. So existiert dieses Problem beim Umgang mit PNG-Dateien offenbar auch in Corel Paint Shop Pro 11.20. GIMP weist eine vergleichbare Lücke im RAS-Loader auf und in IrfanView kann mit manipulierten IFF-Dateien ein Buffer-Overflow erzeugt werden.

Heise informiert darüber, dass in den Windows Versionen von Adobe Photoshop CS2 und CS3 ein Fehler in der Verarbeitung von BMP-Dateien existiert. Entsprechend manipulierte BMP, DIP oder RLE-Dateien können einen Buffer-Overflow auslösen und so Code einschleusen.

Es existiert bereits ein Exploit für diese Lücke, Patches zum schließen der Lücke stehen jedoch noch nicht zur Verfügung.