Backdoor in WordPress ganz easy

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.

Tags: , , ,

  • Gerhard

    Das ist ja toll! Danke für diesen ausführlichen Beitrag, sehr nützlich! Finde den ganzen Blog schon sehr schön. Weiter so!

  • IT Quadrat

    Erstaunlich, welche “Geheimnisse” WordPress auch nach 2 Jahren intensiver Arbeit damit noch immer birgt. Danke für den sehr guten Artikel und Tipp.

  • http://www.xsized.de XSized

    Leute, eure Werbeagentur- und SEO-Links in den Kommentaren entferne ich ohnehin, also spart Euch die Mühe. Ansonsten wird das Entfernen irgendwann kostenpflichtig.

  • WP-Fan

    Oh mann,
    wenn man dann tatsächlich mal einen Dutzend WordPress-Blogs pflegen muss, dann ist das elendige Updaten und Patchen wirklich nervig.
    Man hätte schon längst auf WPMU umstellen sollen, dann braucht man nur ein einziges Update und gut ist.

  • Myxus

    Danke

    super Artikel, arbeite mich gerade in WP ein, bin beim Thema Sicherheit. Wenn man sich noch dazu Vorstellt, das der Code kryptisch zusammen gebaut wird hilft auch eine Dateiweite-Textsuche nach registration.php nichts. Deine drei Varianten schon gut, will man jedoch User-registration zum Kommentieren haben, hat man schon wieder ein Problem. Schande das WP.org das Thema nicht intensiver behandelt

    bbak:-)Myxus

  • http://www.nicht-spurlos.de/ Thomas

    Sehr gut erklärt. Zwei ganz nützliche Plugins finde ich sind die beiden.

    1. AntiVirus http://wpantivirus.com/ . Der scannt die Templates und meldet sofort wenn dort ein Exploit etc. versteckt wurde. Sehr hilfreich, da der Code schon etwas unübersichtlich wirken kann, wenn jemand nicht ganz firn ist.

    2. WP Security Scan http://semperfiwebdesign.com/plugins/wp-security-scan/ . Da werden “offene Scheunentore” angezeigt und empfohlen wie man sie schließt.

    Mit beiden Plugins finde ich fährt man relativ sicher wenn alles passt.

  • Kein Werbemann, Praktiker

    naja, also ein wenig künstlich aufgeblasen ist das ja schon, nicht wahr? Wenn ich auf dem Webserver des opfers PHP ausführen kann, dann ist es ja wohl nicht mehr schwer, da irgendwas böses anzustellen. Fragt sich nur, wie kommt die Datei auf den Server? Das ist ja nun keine neue Problematik, Foren-Admins kenen das schon lange und die Standard-Lösung lautet “kein php ausführen im Upload-Dir ermöglichen” – wenn Templates nunmal PHP benötigen, ist das hochladen und inflitrieren von PHP Code systembedingt möglich und sogar gewollt – es ist also schon eher fraglich , ob man bei sowas von “sicherheitslücke” sprechen kann. Es gibt Template-Systeme, die führen keinen Code aus – und ich kennen trotzdem niemanden, der Templates aus unsicheren Quellen auf seinem Server benutzen würde.
    Also heisse Luft irgendwie, alles.
    Aber der Tip mit der Extra-Absicherung des Admin-bereichs durch htaccess ist denncoh sinnvoll :)

  • http://www.xsized.de XSized

    Templates wurden schon mehrfach in modifizierten Varianten angeboten, die Code in WP-Installationen einschmuggelten. Darauf sollte dieser Artikel auch aufmerksam machen. Auch mein Template tauchte schon auf diversen Portalen auf und hatte “eigenartigen” Code im Handgepäck…

    Dass PHP-Code irgendwie auf den Server kommen muss, um ausgeführt zu werden, ist klar. Templates und auch Plugins sind da nun mal die Angriffspunkte, über die es gelingen kann. Der verlinkte Beitrag zeigte, wie leicht es via Template funktionieren kann, einen User anzulegen. Finde es daher nicht falsch, darauf hinzuweisen und eine praktikable Lösung aufzuzeigen, da grundsätzlich einen Riegel vor zu schieben.